Systemutveckling börjar alltid med en rad krav på den nya produkten, krav som kan komma från användare eller marknadsavdelning eller lagstiftare. Det första resultatet, åtminstone i projekt som drivs på ett systematiskt sätt, är en abstrakt modell av den produkt eller det system som ska tas fram. Nästa steg är att låta den eller dem som är ansvariga för arkitekturen på systemnivå fundera på hur den där modellen ska realiseras. Och då uppstår det intressanta problem, konstaterar Tietoenators Tryggve Mathiesen. - Det finns inga verktyg för systemarkitekter som klarar av att ta hänsyn till att program och hårdvara har olika egenskaper. Tittar man närmare på dem som finns så utgår egentligen allihop från att det underliggande systemet har en processor som utför operationer i tur och ordning. Därför drar verktygen med sig ett sekventiellt arbetssätt som inte utnyttjar det faktum att hårdvara i grunden är parallell. Med ett idealiskt verktyg skulle systemarkitekten kunna ägna sig åt experimentell dekonstruktion, stycka systemet i delar på olika ledder och köra jämförande simuleringar för att hitta den bästa realiseringen. I brist på detta tvingas han eller hon förlita sig på nedärvd kunskap om hur man "brukar" göra.

Tietoenator i Göteborg provar ett nytt angreppssätt i ett projekt. Målet är att utveckla en produkt åt uppdragsgivaren och tillvägagångssättet är att modellera hela systemet, både program och elektronik, i UML, och man försöker i det längsta undvika att göra skillnad mellan sådant som ska bli hårdvara respektive program.

- Vi modellerar systemet och bryter ner det i beståndsdelar. En sådan del kan endera bli kod för en processor eller ett gränssnitt med egenskaper som ska realiseras i hårdvara, säger Tryggve Mathiesen som är metodansvarig för hårdvaruutveckling hos Tietoenator R&D Services i Göteborg.

UML är ett modelleringsspråk som normalt mest förknippas med administrativa datasystem. Programkod kan man generera automatiskt från en UML-beskrivning, numera dessutom med ganska gott resultat, men för hårdvaran är situationen inte lika behaglig. När något ska implementeras på ett kretskort eller i en FPGA krävs en manuell övergång från UML-beskrivningen till modeller i andra verktyg som Matlab eller Xilinx Systemgenerator. Det finns visserligen en tilläggsmodul till Rhapsody, det UML-verktyg som används i projektet, som kan generera VHDL-kod, men kvaliteten på den koden blir för dålig. Än en gång är det oförmågan att slå mynt av den inbyggda parallellismen i en asic eller FPGA som spökar.

- I dagsläget skulle inte automatgenererad VHDL hjälpa oss särskilt mycket, utom möjligen för enklare protokoll med begränsad parallellism, säger Tryggve Mathiesen.

Istället dokumenterar man gränssnittet till hårdvarumodulen i UML och ser till att uppdatera dokumentationen så snart något av vikt ändras under implementationen.

- Under hela projektet har vi alla gränssnitt och egenskaper beskrivna i en sammanhållen modell, det är det som är det viktiga, säger Tryggve Mathiesen.

UML-projektet har pågått i ungefär två år och sysselsätter 4-5 personer på Tietoenator tillsammans med några personer från beställaren. Programvaruarkitekt med ansvar för den övergripande konstruktionen är Peter Billing, även han konsult på Tietoenator och nöjd med UML-experimentet så här långt.

- UML är ganska nytt även för mig, men jag tycker att man får en helt annan helhetsbild av systemet på det här sättet.

UML måste tolkas
En finess han nämner är att man kan använda verktyget, Rhapsody, till att exekvera UML-modellen, och den vägen åtminstone se att systemet hänger ihop logiskt.

Thomas Ahlstrand, metodspecialist på konsultföretaget Nexus, är inte lika övertygad om att UML och realtidssystem är en lyckad kombination. UML har fått ett enormt genomslag, säger han, men det innebär inte att det är användbart för allting.

- Såvitt jag vet finns det fortfarande inga exempel på lyckade realtidsprojekt med UML.

Ett problem som Thomas Ahlstrand ser är att UML-notationen i princip kan tolkas hur som helst.

- Alla böcker om UML börjar med rådet att man ska "implementera" notationen för sitt projekt, alltså komma överens om vad olika diagram ska motsvara i verkligheten, säger han.

Frågan blir då inte om man använder UML utan snarare hur man använder det.

Mot det kan förespråkarna ställa att Rhapsody och den tillhörande utvecklingsmetoden Ropes, som Tietoenator också utnyttjar, är just en implementation av UML för inbyggda system. Både Rhapsody och Ropes har amerikanen Bruce Powel Douglass som upphovsman, och han har även skrivit flera böcker i ämnet.

Tryggve Mathiesen har hämtat inspiration från andra UML-projekt, bland annat ett på Combitech.

- Möjligen är vi först med att anamma Ropes så pass strikt i ett kommersiellt projekt, säger han.

Tätt mellan testerna
Ropes beskrivs bäst som en iterativ process. Man varvar analys, konstruktion och test i relativt korta cykler, en till två månader, och under varje varv har man ett antal delmål som ska uppnås.

Fördelen med ett sådant arbetssätt är dels att det blir tätt mellan testerna så att många fel kan upptäckas och rättas tidigt i projektet, dels att det går att anpassa projektet vartefter kraven förändras.

Dessutom kan det vara skönt för utvecklarna att nästa mål ligger inom synhåll och inte ett eller två år bort.

Iterativa processer är sedan länge standard inom programutveckling, men det finns ett problem med att tillämpa dem för inbyggda system: det är svårt att börja skriva programkoden innan den underliggande elektroniken fungerar. Eller åtminstone är så väl specificerad att den låter sig simuleras.

I Ropes hanterar man det genom att inleda projektet med en fullständig analys av kraven för att sedan arbeta iterativt i konstruktionsfasen, men det finns en annan möjlighet.

- När du har lång ledtid på hårdvaran kan du använda programmerbar logik till att köpa dig tid, säger Peter Billing på Tietoenator.

En FPGA kan minska ledtiden för hårdvaran från månader till veckor. Som bonus kan den också förses med en inbyggd processor och på så sätt hjälpa till att skjuta upp valet mellan hårdvara och programkod.

Lennart Pettersson