busstopologi

TCP/IP över Serielänkar 10/10/2016

Har den senaste tiden suttit och ägnat en del tid åt ett eget projekt. Huvudsakligen vill jag kunna använda en delad buss med seriegränsnitt för att kommunicera mellan olika enheter och använda TCP/IP i processen. Jag kom till en milstolpe nyligen där jag kunde använda ssh för att logga in på en annan dator över en seriebuss med RS232 signalnivåer. (eget hopkok.) Länken är en delad buss med en master, en uppsättning som bör fungera bra över RS485 nätverk.

Det finns 2 uppenbara frågor som jag tror dyker upp första gången man hör detta:

  • Varför? Vad är meningen? Trådade TCP/IP nätverk är redan ett löst problem.
  • Serielänkar? Det är 60 tals teknik. Vad är det för mening att hålla på med dessa idag?

Mitt motiv att sätta igång med detta kommer från observationer från Embedded och IoT världen. Det är lite oklart vad som skiljer dessa, men de kommer från olika bakgrund där embeddedvärlden har sina rötter i elektronikvärlden och har närmat sig mjukvara från lågnivåprogrammering, medan IoT kommer från server/cloudsidan och närmar sig via kommunikationsprotokoll.

I mötet mellan dessa kommer det uppstå nya frågor och utmaningar att lösa. Elektronikvärlden är väldigt driven av att minimera kostnader för hårdvara. Samtidigt sker utvecklingen inom cloudvärlden så snabbt det är ibland svårt att hitta fasta punkter som gäller över längre tid där.

Kraven på enhetlig addressering av enheter, end to end kryptering samt rika möjligheter att fråga enheterna vad de klarar av gör att TCP/IP kommer sakta men säkert ta sig ut till ändnoderna. Så det finns ett underliggande tryck på att göra enheterna mer självständiga och att de har gemensam adressering så centrala tjänster inte ska behöva ta till specialbehandling.
Även kryptering hela vägen ut till ändnoden är viktig. Transporten mellan blir mer och mer fragmenterad och sköts ofta av 3:de part. Med kryptering hela vägen ut blir designen av transportkedjan mycket mindre känslig och designen blir flexiblare. Dessa delar är redan lösta i internetvärlden. Väljer man TCP/IP som bas finns mängder av detta färdigt.

Så det finns anledning att ta internet hela vägen ut, men varför serielänkar? Måste finnas bättre sätt? Uppenbara alternativ är Wifi, Blåtand, ethernet, 3-5G eller fria radioband (868MHz).
Här kommer en vattendelare mot tidigare klassisk datorbaserad utveckling. IoT världen är mycket mer heterogen. Det finns plats för många lösningar. Tricket är att hårdvaran behöver anpassa sig till den fysiska verklighet där den befinner sig i, så länge man kan nå enhetlighet högre upp i stacken. Jag har här valt TCP/IP som den sammanstrålande punkten. På lägre nivåer behövs friheten att anpassa sig till fysisk verklighet. Idag i embeddedvärlden finns designfriheten, men man söker fortfarande att hitta enhetliga gränsnitt att visa upp uppåt.

En första skillnad man kan göra är mellan trådade och trådlösa länkar. Trådat har varit den klassiska lösningen, trådlöst den nya moderna som lovar enklare installation, mobilitet och en aura av att vara i framkant.
Väljer man trådlöst behöver man fortfarande hantera energiförsörjningen. Är dina enheter stora och kräver redan elanslutning, då funkar trådlöst bra. Man sparar den extra kabeln som annars kan behövas. Behövs mobiliteten, så är kabeln ivägen.

Däremot de scenarios där en mängd enheter installeras en gång, de ska sitta länge (10+ år) så batterier kan behöva bytas. De kan sitta otillgängligt så elförsörning är inte trivialt. De kan vara små så kraftelektronik (230V) blir en stor del av kostnaden. Dessutom kan de styra/reglera enheter som inte drar mycket ström, men tillräckligt för att batterier inte ska fungera. Det räcker med en liten skärm eller enkare motor som används ofta för att batterier kan behöva bytas årligen eller oftare.

Så behöver vi ändå dra en kabel för elförsörjning, då kan ett partvinnad extra par lätt följa med. Med denna kan man göra utvecklingen betydligt lättare och slippa vanliga radioproblem. Konkurrens om ethern, störningar, skärmande metallskåp, olika radioförhållanden vid olika årstider etc etc. Allt detta försvinner.

Så, det bör finnas nischer där kabel är motiverad. Men det är väl redan löst? Ethernet, kanske tillsammans med PoE (Power over ethernet) och man får samma effekt?
Kostnad är hindret. Ethernet har utvecklats till en kraftfull standard. Men allt fokus ligger på bättre prestanda medan smalbandig kommunikation till billig penning aldrig har varit i fokus. Ethernet idag är stjärnuppbyggt med switchar som en nödvändig byggsten. Med PoE drar prislappen iväg. Med stjärnnät blir det också gärna mer kabel än vad en busstopologi skulle ge.
Det jag siktar på är samma uppbyggnad som de gamla 10Mbit coaxsystemen, men med partvinnad tråd och lägre hastighet. För IoT finns massor med tillämpningar där att kunna prata är det viktiga, inte att prata fort.

Några exempel där detta kan passa:

  • Fastihetsautomation. Sensorer för luftkvalitet, temperatur, låsstyrning smarta hem.
  • Intelligenta energisystem. Solcellsinstallationer där enskilda paneler har kontrollers och enskilda batterier kontrolleras. Dessa enheter behöver kunna prata med varandra.
  • Laddinfrastruktur elbilar. Enskilda laddstolpar behöver kunna kommunicera med centralsystemet.

Eller varför inte:

  • Säkringarna i ett säkringsskåp kan informera om sin status. Elmätare på rad som bygger upp ett nät.
  • Ett modulärt system av microkontrollers på PCB som kan kopplas ihop av kund. Har dessa en standardiserad buss kan konfigureringen förenklas.

Gemensamt är att själva noderna är små och billiga. De är statiskt monterade. De behöver kommunicera, men inte stora mängder. Ev. är de svåra att komma åt för underhåll.
Fortfarande ska så klart konfiguration vara modern. Det ska räcka att koppla in enheterna så kan de sedan självkonfigureras eller slå upp sin konfiguration via onlineservrar.

Här hjälper teknikutveckligen oss på traven. Moderna mikrokontrollers som är billiga har trots det rätt mycket minne. Så det finns plats att införa t.ex. TCP/IP, kryptering och diverse applikationsprotokoll trots att mikrokontrollern är liten och billig. Med kabelbaserad energi fungerar också Linuxsystem med små fysiska dimensioner.

I det här läget blir en klassisk UART den minsta gemensamma nämnaren. Den ger möjlighet att läsa / skriva enskilda bytes. Så det enda vi behöver lägga till är det lågnivåprotokoll som binder samman existerande TCP/IP stackar med ett byte in/byte ut gränsnitt nedåt. Med detta på plats finns en stor flexibilitet att utforma hårdvaruinstallation, medan mjukvaran kan byggas upp av standardkomponenter ovanpå.

Men hur var det med den andra frågan. Detta måste väl finnas sedan 30 år tillbaka?
Det är inte nytt. Det finns som lösning is diverse tillämpningar. T.ex. går det att köpa automationboxar för industrin som skeppar TCP/IP över RS485 länkar. Dessa kostar dock 500+kr och har en formfaktor som inte passar.
Har inte hittat färdiga open sourcelösningar. För punkt till punkt finns T.ex SLIP eller PPP. Men har inte hittat något för busssystem.

Så målet är en protokollstack på låg nivå. Den enda kommunikationen nedåt är en byteström in/ut. Inga sidokanaler tillåtna (extra interruptlinor, eller breaksignaler). Endast timeout mellan paket kan användas som sidokanal, och helst sällan. Detta tillåter att man tunnlar byteströmmen vilket ökar flexibiliteten. Kommunikationen ska gå genom ett gemensamt medium med flera enheter kopplade till samma medium. Allt för att förenkla eventuell kabeldragning och installation. Idealt ska man kunna montera på en enhet med t.ex. en crimptång utan att behöva klippa kabeln till bussen.

Uppåt är gränssnittet ethernet frames. Det ska gå att koppla in detta på existerande TCP/IP stackar som redan finns på marknaden. Med detta borde man kunna öppna upp för nya system där modern mjukvara kan fungera tillsammans med traditonella installationer och med prispressade komponenter. Det borde kunna hjälpa till att lyfta traditionella embeddedsystem in i IoT världen.

Som sagt, prototyputveckling pågår. Fick upp en standard ssh session från en Linuxdator till en annan över en fysisk seriell buss nyligen. Det inkluderar kryptering/handskakning med val av algoritmer och sedan konsollaccess av fjärrdatorn. Allt medan en buss-master dirigerade vem som får sända paket.

Kommer ta upp utformningen av protokollet i kommande poster.