Postoji nekoliko različitih osnovnih tipova softverske arhitekture u javnoj upotrebi.

U ovom diazjnu, softver jednostavno ima petlju. Petlja poziva podrutinu. Svaka podrutina upravlja delom hardvera ili softvera. Prekidi obično postavljaju zastavice, ili obnavljaju brojače koji čitaju ostatak softvera.

Običan API onemogućava ili omogućava prekide. Uradi li ispravno, on rukuje ugneždenim pozivima u ugneždenim podrutinama, i uspostavlja prethodna stanja prekida i osposobljava spoljšnjost. To je najednostavniji metod za izradu exokernel-a.

Tipično, uvek ima neka vrsta podrutine u petlji koja upravlja listom softverskih tajmera, upotrebom povremenih realno-vremenskih prekida. Kada tajmer istekne, pripadajuća podrutina se pokreće, ili se postavlja zastavica.

Svaki očekivani hardverski događaj bi trebalo zapamtiti zajedno sa softverskim tajmerom. Hardverski događaji omanu jedanput u milijardu slučajeva. To je otprilike jedanput u godini sa modernim hardverom. Sa milion masovno proizvedenih uređaja, napuštanje softverskog tajmera je poslovna katastrofa.

Mašine stanja mogu biti implementirane sa funkcijskim pokazivačem po mašinskom stanju (u C++, C ili assembly-ju, svakom slučaju). Promena stanja skladišti različita funkcija unutar pokazivača. Funkcijski pokazivač se izvršava svaki put kada se pokrene petlja.

Mnogi projektanti preporučuju čitanje svakog IO uređaja jedanput po petlji, i pamćenje rezultata tako da logika radi na postojanim vrednostima.

Mnogi projektanti daju prednost dizajnu njihove mašine stanja koja proverava samo jedne ili dve stvari po stanju. Obično je to hardverski događaj, i softverski tajmer.

Projektanti preporučuju da hijerarhijska mašina stanja treba da se pokrene u stanju najnižeg nivoa mašine pre višeg, pa će viši da radi sa tačnim informacijama.

Kompleksne funkcije poput internih kontrola sagorevanja se često upravljaju preko više-dimenzionih tabela. Umesto kompleksnih izračunavanja, kod pretražuje vrednosti. Softver može da interpolira između unosa, da bi zadržao malu i jeftinu tabelu .

Jedina bitna mana ovog sistema je da ona neće garantovati vreme odgovora na neki hardverski događaj.

Pažljivo pisanje koda može lako obezbediti da ništa ne omogući prekide za dugo vreme. Ovaj kod prekida radi u vrlo preciznom vremenskom intervalu.

Drugi glavni nedostatak ovog sistema je da on postaje kompleksan za dodavanje novih mogućnosti. Algoritam kome treba mnogo vremena da startuje mora biti pažljivo isečen tako da se samo mali deo izvrši pri svakom prolasku kroz glavnu petlju.

Ova sistemska snaga je njena jednostavnost, i na malim parčićima softvera petlja je obično toliko brza da niko ne obraća pažnju na to što je nepredvidiva.

Druga prednost je to što ovaj sistem garantuje da će softver raditi. Nema misterioznog operativnog sistema koji možemo da okrivimo za loše ponašanje.

Ovaj sistem je vrlo sličan prethodnom, izuzev što je petlja skrivena u API-ju. On definiše seriju zadataka, i svaki zadatak dobija sopstveni stek podrutine. Potom, kad je zadatak besploslen, on poziva besposlenu podrutinu (obično nazvanu "pause", "wait", "yield" i slično).

Arhitektura sa sličnim osobinama ima redosled događaja (event queue), i ima petlju koja uklanja događaje i poziva podrutine bazirane na polju unutar unosa redosleda (queue-entry).

Prednosti i mane su vrlo slične kontrolnoj petlji, sem što je dodavanje novog softvera lakše. Neko jednostavno napiše novi zadatak, ili ga doda prevodiocu redosleda (queue-interpreter).

Uzmite bilo koji od prethodnih sistema, ali dodajte tajmerski sistem koji pokreće podrutinu za odbrojavanje prekida (timer interrupt). Ovo dodaje potpuno nove sposobnosti sistemu. Po prvi put, rutine tajmera će se desiti u garantovanom vremenu.

Takođe, po prvi put, kod može ići po sopstvenoj strukturi podataka u neočekivanom intervalu. Rutine tajmera moraju da se tetiraju sa istom pažnjom kao rutina(e) prekida.

Uzmite prethodni multitasking sistem bez prethodnog pražnjenja, i pokrenite ga iz preemptive tajmera ili drugih prekida.

Odjednom je sistem prilično drugačiji. Svako parče koda može oštetiti podatke drugog zadatka - oni moraju biti precizno odvojeni. Pristup zajedničkim podacima moraju biti strogo kontrolisani od strane neke sinhronizacione strategije, na primer redosleda poruka ili semafora. (Nedavno su razvijene ne blokirajuće sinhronizacione strategije)

Često, na ovom stepenu, organizacije za razvoj kupuju real-time operativni sistem. To može biti mudra odluka ako organizaciji ne nedostaju ljudi sa veštinom da ga napišu, ili ako se portovanje operativnog sistema na hardver izvodi na nekoliko proizvoda. U suprotnom, budite svesni uobičajenog dodavanja šest do osam nedelja planu izvođenja, i uvek će programeri na njega svaliti krivicu za kašnjenje .

Oni su popularni za embedded projekte koji nemaju sistemski budžet. Po mišljenju barem jednog autora ovakvog članka, oni obično greše. Evo logike:

• Operativni sistemi su specijalno pakovane biblioteke ponovo upotrebljivog koda. Ako kod radi nešto korisno, projektant štedi vreme i novac, Ako ne, beskorisan je.
• Poslovnim operativnim sistemima nedostaju interfejsi za embedded hardver. Primer: ako neko koristi Linux da bi upisao nešto u kontroler motora ili telefonsku centralu, onda će većina realnih kontrolnih operacija završiti sa brojnim funkcijama u IOCTL pozivima. U međuvremenu, normalni read, write, fseek interfejs je besmislen. Tako, operativni sistem zapravo ometa razvoj embedded sistema.
• Većina embedded sistema ne radi kancelarisjki posao, pa je većina koda office opertivnog sistema protraćen. Primer: većina embedded sistema nikad ne koristi prikaz sistemskih fajlova na ekranu, pa je fajl sistem i GUI logika suvišna. Neupotrebljen kod je samo odgovornost pouzdanosti.
• Operativni sistemi Office stila štite hardver od korisničkih programa. Zapravo, oni duboko ometaju razvoj embedded sistema.
• Operativni sistemi moraju nepromenjeno biti portovani na embedded sistem. To jest, kod hardverskog drajvera svakako mora ponovo biti napisan. To je najteži deo operativnog sistema, pa ćete malo uštedeti koristeći ga.
• Istinski korisne, prenosne karakterisike operativnog sistema su mali delovi koda. Primer: osnovni TCP/IP interfejs je oko 3,000 linija C koda; kao i običan fajl sistem. Ako je potreban dizajnu, može se dobiti za manje od 10% tipičnog embedeed sistemskog razvojnog budžeta, bez autorskih prava, samo njegovim pisanjem. I, ako je potreban kod previše uopšten, pozadina magazina o embedded sistemima nudi prodavce besplatne C implementacije.

I pored toga Embedded Linux-u raste popularnost, pogotovu na moćnijim embedded uređajima poput Wireless ruterima i GPS navigacionim sistemima. Evo nekoliko razloga:

• Dostupan je prenos na uobičajene embedded platforme.
• Mogućnost ponovne upotrebe javno objavljenog koda za Device drajvere, Web servere, Firewall-ove i brojne druge pomoćne alatke.
• Mogućnost konfigurisanja distribucije da isključi nepotrebnu funkcionalnost.
• Mogućnost razvoja embedded aplikacija u korisničkom modu, što čini proces razvoja lakšim i prenosnijim.

Neki sistemi zahtevaju sigurno, podesno, pouzdano ili efikasno ponašanje koje je nepoželjno za prethodne strukture. Evo dobro poznatih trikova za konstruisanje takvih sistema:

1. Unajmite real-time programera. Oni koštaju malo više, ali mogu uštedeti godine ispravljanja grešaka i dodatnih gubitaka prihoda.
2. RMA (rate monotonic analysis), može biti upotrebljen za pronalaženje skupa zadataka koji rade pod definisanim hardverskim sistemom. U najjednostavnijoj formi, dizajner se uverava da najbrže završavani zadaci imaju najviši prioritet, i to u proseku, CPU ima najmanje 30% slobodnog vremena.
3. Harmonični zadaci optimizuju CPU efikasnost. Bazično, dizajneri se uvere da sve radi po otkucajima glavnog tajmera. To je teško uraditi sa real-time operativnim sistemom, jer oni uglavnom preklopaju zadatke dok čekaju na I/O uređaj.
4. Sistemi sa tačno dva nivoa prioriteta (obično radni i sa onemogućenim prekidima) ne mogu imati Prioritetno inverzivne probleme u kojima zadatak višeg prioriteta čeka na zadatak nižeg prioriteta da bi oslobodio semafor ili drugi resurs.
5. Sistemi sa monitorima ne mogu imati "mrtvu" petlju. Monitor blokira region koda preko prekida ili drugih prethodnih pražnjenja. Ako se monitor odnosi samo na mali, brzi deo koda, to će raditi prihvatljivo dobro. Ako monitor API-ija može da dokaže da radi na izvršenju u svim slučajevima, (čitaj, ako on prosto sprečava prekide) onda nije moguće zaustaviti ga.

To znači da su sistemi koji koriste dualni priritet i monitore sigurni i pouzdani jer gube mrtve petlje i prioritetne inverzije. Ako monitor radi do završetka, on se nikad neće zaustaviti. Ako koriste harmonične zadatke, oni mogu biti prilično efikasni. Svejedno, RMA ne može da okarakteriše ovaj sistem, i nigde ne postoje bolji nivoi prioriteta, uključujući operativni sistem i hardver.