RTS, Real Time System, hette kameran som blev symbolen för den elektroniska kamerarevolutionen i slutet av 1970-talet.

"Realtidskameran" var ett samarbete mellan Zeiss och Kyocera, en syntes av tysk optik och japansk elektronik, formgiven av Porsche och försedd med en prislapp som till fullo matchade ambitionerna.


Nyckelordet bakom kameran Contax RTS var "realtid". Elektroniken skulle hjälpa fotografen att ta sin bild i exakt rätt ögonblick, utan onödig tidsspillan för funderingar, inställningar eller ens mekaniska fördröjningar. Hela konstruktionen var genomsyrad av elektroniken, och avtryckarknappen var monterad direkt på en mikrobrytare. Ordet realtid var förstås en marknadsploj, men den gick hem.

Begreppet "realtid" är luddigt. Realtid handlar om att göra elektroniska system så snabba att de kan samverka med ett yttre fysikaliskt förlopp, och det inbjuder förstås till att man väljer den definition som passar en själv.

Det enda som är gemensamt för definitionerna är att systemen ska göra sin uppgift inom en bestämd tidsgräns. Tidsfaktorn är lika viktig som de rent tekniska funktionerna.

Realtidssystem är legio inom automation, i militärelektronik, i flygplan och tåg - och för deras trafikledning - i processindustrier och i medicinsk elektronik som pacemakrar. Det grundläggande draget är att systemet kommunicerar med en fysisk process. Systemet måste få indata från den fysiska processen, det vill säga mätvärden från givare samt signaler för larm och gränslägen. Det måste också kunna påverka processen, och därför behövs det styrenheter av olika slag, till exempel ventiler eller förstärkare.



Mjuk och hård realtid


Det finns mjuka och hårda realtidssystem. Ett mjukt system behöver inte alltid hålla sig inom tidsgränsen. SJ:s biljettdator är ett mjukt system, för där gör det inget om det tar några sekunder extra att spotta ut en biljett när systemet är hårt belastat. I ett hårt realtidssystem måste däremot tidskravet hållas oavsett situationen. Järnvägens ATC-system är ett hårt system, för där vore det en katastrof om det inte skulle hinna att slå om en signal i tid.

Den här indelningen inbjuder naturligtvis till tekniska tvister. Puristerna tycker att ett realtidssystem ska klara alla tänkbara situationer inom tidsgränserna, det vill säga att ett riktigt realtidssystem är ett hårt system.

En vanlig missuppfattning är att ett realtidssystem måste vara extremt snabbt. Det är helt fel. Ett realtidssystem ska "bara" vara tillräckligt snabbt, vilket vi kan se av följande två exempel.



Cykelstyre och turbo


Ett vanligt cykelstyre är ett realtidssystem som alla känner till. Hjulet svänger inom några millisekunder efter det att man har börjat vrida styret. Här är det uppenbart att det inte duger med att ha en fördröjning på ett par sekunder innan hjulet börjar att svänga.

En längre fördröjning fanns i Saabs äldre turbobilar. Det tog någon sekund innan turbon började att leverera effekt när man hade stampat gasen i botten. Det systemet var också ett realtidssystem, låt vara med andra krav än för cykelstyret. Fördröjningen var acceptabel i förhållande till det yttre fysiska förloppet, och därmed var turbon ett realtidssystem.

Men åter till elektroniken! Ett tidigt realtidssystem var den amerikanska luftvärnsroboten Hawk, där Hawk stod för Homing All the Way Killer. Det krystade namnet sa att roboten sökte sig mot målet under hela tiden som den var i luften, och att den alltså tog hänsyn och anpassade sig till hur målet rörde sig.

Då, i slutet av 1950-talet, handlade det förstås om ett realtidssystem som var uppbyggt med analog elektronik. Dagens realtidssystem är oftast digitala och till en stor del uppbyggda med programvaror.

Då måste det finnas ett operativsystem i botten, och där finns det ett problem. De generella operativsystemen - DOS, Windows 95 och NT, Unix i otaliga former, OS/2, Linux och MacOS - arbetar inte under några tidskrav. En del operativsystem kan fördela uppgifterna så att processorn ägnar en viss tid åt var och en, men de är dåliga på att avgöra vilken uppgift som är viktigast i ett givet ögonblick. Det är operativsystemet, inte den yttre verkligheten, som avgör vad som ska göras och när det ska göras.



Särskilda operativsystem krävs


Det går visserligen (ibland) att räkna ut hur snabbt det går att utföra en bestämd uppgift med en viss maskin- och programvara och ett generellt operativsystem, men några garantier har man inte. Än mer osäkert blir det om operativsystemet ska hantera flera uppgifter samtidigt och dessutom rangordna dem enligt omständigheter som styrs av ett yttre fysiskt förlopp.

Det vanliga sättet att komma runt det här problemet är att använda speciella realtidsoperativsystem, RTOS.

De är operativsystem som har konstruerats för att kunna ta hänsyn till det som händer i den fysiska omvärlden. Ett RTOS ska hantera flera samtidiga förlopp och samtidigt garantera att elektroniken gör sitt jobb inom benhårt satta tidsgränser.

Ett generellt operativsystem ärkonstruerat så att det ska klara en mängd olika uppgifter. Det har därför stora krav på minne och på processorprestanda. För ett RTOS skyr man den sortens resurskrav som pesten. De funktioner som ett RTOS ska utföra är väl specificerade. Överflöd i form av generell kod och generella drivrutiner blir då bara en börda och en komplikation. Ett RTOS klarar sig med några hundra kbyte.

Nackdelen med specialiseringen blir förstås att det behövs olika RTOS för olika uppgifter. Därför finns det kanske 100 olika kommersiella RTOS. Man väljer helt enkelt ett RTOS som är avsett för en viss typ av tillämpning.

För varje tillämpning finns det i regel flera parallella förlopp som ska övervakas eller styras. Förloppen kallas oftast för processer. Processerna kan vara mer eller mindre viktiga, och därför tilldelas de olika prioritet.

Prioriteten avgör vilka processer som ska ha förtur, och under vilka villkor. Prioriteringen kan vara given på förhand, men den kanske också ska kunna påverkas av schemalagda processer eller genom att en operatör ingriper.



Att byta process är kritiskt


I en del realtidssystem kanske det bara pågår några få processer, medan det i andra är flera som löper samtidigt.

Då är det också viktigt hur snabbt ett RTOS kan växla mellan processerna. En del system kan bara växla mellan processerna när en process avslutats, medan andra växlar genom att avbryta den pågående processen och skicka ut den till ett minne där den får ligga och vänta innan den får fortsätta att exekvera sin kod.

Eftersom programvaran är så viktig i realtidselektronik är det intressant att se hur operativsystemen utvecklas. Företag som utvecklar realtidsoperativsystem försöker att göra dem mer generella och flexibla genom att bygga upp dem med anpassningsmoduler kring en gemensam kärna.

Samtidigt försöker flera företag att komplettera de generella operativsystemen med tilläggsrutiner som gör att de lättare kan användas för realtidssystem. Det gäller särskilt för Windows NT, som börjar bli vanligt inom automation. Speciellt intressant kan dock realtidsvarianter av Linux bli. Linux, som är ett Unix-liknande operativsystem, har en öppen och gratis källkod som flera utvecklare försöker att realtidsanpassa.

Per Stymne

Frilansjournalist