nohau news no 2-09

news

Nohau news når ca 15.000 läsare. Vill du vara med i tidningen? Kontakta redaktionen. Ansvarig utgivare: Mikael Johnsson, [email protected].

Redaktör: Maria Eklind, [email protected]. Tidningen trycks på miljövänligt papper från KLS Grafisk Hus Danmark, som är helt CO2-neutrala.

nr. 2/2009 - nyhetsbrev från nohau solutions

En viktig bit för att lyckas är att det modell-drivna arbetet måste harmoniseras med resten av företagets tradition eller metodik.

– Om du bara kör på enligt grundmetodiken, kommer

du inte att kunna koppla dig bra mot resten av företa-

get. Kan t.ex. inte projektledaren metoden så bra, blir det

svårt att styra projektet effektivt, säger Gert Johansson,

Combitech.

Gert har lång erfarenhet av modellbaserad utveckling, han

har varit involverad i flera olika projekt och delar gärna

med sig av sina erfarenheter.

Praktisk erfarenhet och kompetens

Produkter och system blir mer och mer komplexa, det vet

vi. Modellerna är ett sätt att hantera komplexiteten, där du

börjar på en övergripande nivå, för att sen detaljera vissa

delar på en specifik nivå. Därefter belyser du olika aspek-

ter av produkten/systemet, som användningsaspekten, kra-

vaspekten, komponenterna i sig och hur de interagerar.

– Det är viktigt att ha ett utbildningskoncept, när du

startar upp ett modellbaserat projekt, som i sig är kopp-

lade till guidelines.

A och O är att beskriva metodiken för modelleringsarbe-

tet, vilka språkdelar som ska användas och hur metodiken

i modellen ska vara uppbyggd.

Beskriv också hur du ska koppla dig mot specifikationer

(t.ex. kravspecar) och dokument (t.ex. styrdokument).

Fråga dig vad det är i modellen som motsvarar dessa

dokument. Gör sedan en mappning mot det traditionella

arbetssättet som resten av företaget jobbar med.

På Combitech skapar vi guidelines för hur vi ska mo-

dellera. Alla detaljer framgår inte i ett sådant dokument,

enbart de viktigaste bitarna och beskrivningen av meto-

diken.

Resten av problemen tar man allteftersom. Under tiden

du jobbar med det lär du dig att hantera det automatisk

till nästa gång, säger Gert.

– Vi utbildar teamet genom att bygga upp utbildningar

efter de olika kompetenser eller domäner vi jobbar inom.

Vi samutnyttjar kurserna för både intern kompetensut-

veckling och att driva kurser externt. Våra konsulter är

med i Nohaus kursverksamhet, säger Gert.

Varför modellbaserat?

– En bild säger mer än tusen ord. Grafisk information

ger en bättre förklaring, det underlättar förståelsen och

ger en snabb överblick. Ett standardiserat språk ger helt

enkelt fördelar och risken för inkonsistens i dokumenta-

tionen är reducerad om du jobbar modellbaserat.

Företaget har mångårig erfarenhet av modelleringstek-

niker. Från början arbetade vi med bland annat UML och

nu på senare tid även med SysML, säger Gert.

Metodval

Modellbaserad utveckling kräver ett språk som UML eller

SysML, och en metod som t.ex. vattenfall, inkrementell

eller agil.

– Vi försöker sy ihop agila metoder med modellbaserad

utveckling. Metodvalet beror på marknad och typ av kund.

Agila metoder som t.ex. scrum är helt perfekt för en kon-

sumentmarknad, där mycket förändras.

I agila metoder jobbar du med en NU-analys, där du

hela tiden frågar dig vad som är mest viktigt just nu för

den här produkten. Därefter prioriterar du listan, frågar

dig senare samma sak igen, och prioriterar åter om inför

nästa inkrement.

Mina första kontakter med agila metoder fick jag i bör-

jan av 90-talet vid forskning om produktionsutrustningar.

Erfarenheter från Combitech, Sectra Communications och Saab

Framgång med Modelldriven Utveckling

2 nohau news - no 2 - 2009

Toyota Production System var då framgångsrikt och do-

kumenterat i litteraturen. Det är dessa ideer inom pro-

duktion, som mycket av dagens agila utvecklingsmetoder

bygger på, säger Gert.

Michael Bertilsson, VD på Sectra Communications berät-

tar att agila metoder även fungerar för komplexa system

som säkerhetssystem med hög kvalitetspolicy.

– Vi följer en utvecklingsprocess, som bygger mycket på

agila metoder, något som har fasats in i verksamheten sedan

början av 2000-talet, säger Michael.

– Vi följer ingen specifik metod som scrum eller extreme

programming, istället plockar vi det vi tycker är vettigt och

passar vår speciella verksamhet, förtydligar Jan Boqvist,

utvecklingschef på Produktdivision Tiger, på Sectra Com-

munications.

– När det gäller mjukvara använder vi framför allt test-

driven utveckling. Vi gör beskrivningen och testfallen först

och implementerar sen, för att få fram en bra slutpro-

dukt.

Eftersom det alltid uppstår problem - kunden ändrar sig,

vi ändrar oss internt - görs iterationer. Vi planerar om var-

annan vecka, efter den föränderliga bild vi och projektet

lever i. Så genom att inte detaljplanera från början löser

man sådana problem, säger Jan.

Den grundläggande arkitekturen

– I den grundläggande arkitekturen siktar vi på att få

med systemvyn. På sikt sparar du tid om du börjar med

att titta på krav och behov, (behovsanalys), Use cases (an-

vändningsfall), säger Gert.

- Att hitta vad som ska göras är första uppgiften. Vilka

intressenter finns det för denna produkt och vem/vilka ska

använda denna produkt?

Därefter sätts rollerna ihop och kanske andra tekniska

system som ska kunna kopplas mot vår produkt.

Sedan bör man fundera på vad användarna vill kunna

göra med systemet och vilken nytta de ska ha av det. Det

är en viktig del i användningsfallsanalys och det blir på

något sätt ett grundmaterial till vad systemet ska kunna

utföra.

Det säger inget om hur systemet är uppbyggt, det kommer

i nästa steg. För att kunna lösa allt detta modelleras ett

antal komponenter upp som realiserar det som systemet

ska utföra, säger Gert.

Exempel på specifika kunder/projekt

– Nokia var ett stort projekt runt 2002 där vi utvecklade

mjukvara för digitalboxar. Ett 50-tal personer var med i

utvecklingen, vi delade upp modellen i många små bitar, så

att varje utvecklare kunde sitta och jobba med sin bit.

Konfigurationshantering finns inbyggt i verktygen så alla

versionshanterade sin bit. Då håller man koll på hur arbetet

framskrider och man håller sig synkroniserad med resten

av modellen, säger Gert.

Michael Bertilsson, VD på Sectra Communications

Agila metoder fungerar även för komplexa system som säkerhets-system med hög kvalitetspolicy

Framgång med Modelldriven Utveckling

A Model Provides a Mechanism to Unify All Development Artifacts.

SystemAnalysis & Design

SW Design

SW Implementation& Unit Test

ModuleIntegration & Test

SystemAcceptance

(Sub -)System Integration & Test

(Sub -)System Integration & Test

System &Software Model

RequirementsCapture & Analysis

nohau news - no 2 - 2009 3

fortsättning sid. 4 »

Nina Andersson, SAAB AB

Med modellbaserat arbetssätt blir systemet tydligare eftersom du får upp det i modeller och sekvensdiagram.

Syftet med Neuron-programmet är att upprätthålla och ut-

veckla den tekniska basen för de europeiska tillverkarna för

nästa generation bemannade eller obemannade stridsflyg-

plan.

nohau news - no 2 - 20094

Obemannade modeller

– Oftast är det inbyggda delar i ett system vi utvecklar.

Det kan t.ex. vara luftkonditioneringssystemet i hytten på

en grävmaskin, där vi då har beskrivit funktionaliteten.

Med Use case analys uttrycker vi vad maskinen ska kun-

na göra och hur den med hjälp av andra komponenter ska

interagera.

Ett annat större exempel är den obemannade flygfar-

kosten Skeldar (se bild föregående sida), som vi (Saab)

utvecklade modellbaserat under Scrum-lika arbetssätt,

säger Gert.

Dassault nEUROn är en annan flygfarkost, ett litet enmo-

torigt obemannat flygplan för militärt bruk, ett så kallat

UCAV (Unmanned Combat Aerial Vehicle), med smyg-

egenskaper.

Neuron är ett samarbetsprojekt mellan bl.a. Dassault

i Frankrike, Saab och EADS och beräknas få sin första

flygning 2011. Avioniksystemet, den avancerade flyg-

elektroniken som ska hålla Neuron i luften, är det största

av Saabs ”teknikrussin”, där Saab leder utvecklings-

arbetet. Det är också avionikkompetensen som ska kunna

användas för att uppdatera Jas Gripen.

På Saab ansvarar Nina Andersson för projektet och hon

berättar att det nu är ett jättestort system, med ett antal

olika datorer som interagerar för att få till en mängd

olika funktioner för att övervaka farkosten.

– Det måste finnas flera olika system som håller koll så

att farkosten inte sticker iväg i periferin. Inom de militära

bitarna är man väldigt hårt styrd av regler och utprov-

ningar.

Flyg får ju inte trilla ner på civilmark och skada omgiv-

ningen. I vissa fall måste vi vara oberoende i testarbetet,

det innebär att samma person som utvecklar funktion inte

får utveckla test, säger Nina.

Rhapsody i säkerhetskritiska system

– Jag har jobbat modellbaserat i många år, på Saab är det

dock lite ojämnt hur vi har jobbat. Gripen t.ex. är väldigt

styrd i det gamla sättet. Men det håller på att omdanas,

och vi går mer och mer över till modellbaserat, speciellt

nya system som kommer in.

I de gamla systemen kommer det att dröja för det hand-

lar om att omstrukturera hela systemet. Turn-around-tiden

är väldigt lång i vår värld, säger Nina.

– Men vi började att tänka på modellbaserad utveckling

i projekten med Gripen och TMS (stödsystem för piloter)

och grundtanken var att spara tid och hitta fel tidigare.

Då använde vi Rhapsody enbart som ritplanka, där mo-

dellerna inte var integrerade. Vi gjorde istället en jättestor

modell av systemet, utan att gå hela vägen ner till kod-

generering. Successivt utvecklade vi Rhapsody och vi test-

ade att kodgenerera.

Vad vi nu försöker göra i Neuron är att koppla ihop olika

verktyg där vi automatgenererar test från Rhapsody på

det vi redan har gjort. Då vi gjorde modifieringarna för

kodningsreglerna själva, har det gett oss möjlighet att

använda Rhapsody i ett säkerhetskritiskt system, säger

Nina.

Arbetsglädje– Med ett modellbaserat arbetssätt är det lättare att

överblicka, dessutom har du roligare när du jobbar. Meto-

derna vi använder varierar, men vi jobbar en hel del agilt.

Mycket är ju dokumentstyrt, men på vägen dit är vi väldigt

informella och vi jobbar med att granska modellerna.

På vägen fram bygger vi alltså upp vårt system, och vi

kör i korta utvecklingsperioder där vi utvecklar fulla funk-

tioner med unit test och allt. Det är vårt sätt att jobba, att

vi tar med oss hela systemet till en viss nivå, säger Nina.

Neuron-teamet har till uppgift att utveckla funktion - från

ax till limpa. Utvecklarna har varit tvungna att göra all

test, även enhetstesterna och systemverifiering i riktiga

riggar med riktig hårdvara.

– Det skapar engagemang och de tycker att det är jätte-

roligt att jobba på detta sätt, så roligt att de i början nästan

glömde bort dokumentationen.

I min roll som projektledare är det också lättare att

flytta på personal, då ju allt finns beskrivet, man använder

samma nomenklatur och man sitter inte lika fast i det

man utvecklar just nu, säger Nina.

Agila MetoderAgil projektledning skiljer sig lika radikalt från traditio-

nell projektledning, som lättrörliga processer skiljer sig

från traditionella metoder.

Istället för att planera, instruera och styra, så underlättar,

coachar och leder den agila projektledaren.

CSM - Certified Scrum Master

Lär dig att bemästra rollen som Scrum Master, och att

införa agilt arbetssätt i ett utvecklingsteam, ett projekt

eller en organisation.

Kursinnehåll och förkunskaper

Under kursen blandas teoretiska genomgångar och prak-

tiska övningar med målet att du under kursens gång ska få

uppleva känslan av att delta i ett Scrum-projekt.

Efter genomförd kurs erhåller varje deltagare en personlig

licens. De enda förkunskaper som krävs är grundläggande

erfarenhet av mjukvaruprojekt.

Planerade datum

12-13/10 Malmö•

10-11/11 Malmö•

10-11/12 Göteborg•

Pris

1500 Euro•

Lean and Agile for Managers

Denna kurs är till för dig som är ledare inom en mjukva-

ruorganisation och vill lära dig de senaste metoderna och

verktygen från Lean och Agile för att kunna effektivisera

era utvecklingsprocesser.

Kursen, som är unik i sitt slag i Sverige, är delad i fyra

delar där huvudpunkterna är följande:

Value-stream mapping och minimering av waste •

(Muda) i din organisation.

Kanbansystem och hur du effektiviserar flödena i •

dina processer.

Agile Retrospectives för ständiga förbättringar •

(Kaizen).

Hur du baserar dina prioriteringar på affärsvärde •

genom en strukturerad Backlog.

Planerade datum

22-23/9 Stockholm•

17-18/11 Malmö•

Pris

1500 Euro•

Utbildningar inom Agila Metoder

Våra Scrum-kurser kör vi i samarbete med Softhouse, ett konsultföretag

specialiserat på Lean och Agile mjukvaruutveckling.

grafik

© Softhouse


Se kursprogram på nästa uppslag

Agile Methods dagar Oktober November December Pris * On-site

Certified Scrum Master 2 12-13 Mmo 10-11 Mmo 10-11 Gbg € 1500

Lean and Agile for Managers 2 6-7 Mmo € 1500

Scrum for Team Members 1 Kontakta oss för att arrangera ett datum.

Requirements Management, Version- and Configuration Mgt dagar Oktober November December Pris * On-site

DefineIT Essentials 1 Kontakta oss för att arrangera ett datum.

Effective Requirements 2 Kontakta oss för att arrangera ett datum.

CaliberRM Essentialsalso available as web based training 1 Kontakta oss för att arrangera ett datum.

Advanced Requirements Management with CaliberRM 1 Kontakta oss för att arrangera ett datum.

StarTeam Essentials 1 Kontakta oss för att arrangera ett datum.

StarTeam Advanced: Server Administration 1 Kontakta oss för att arrangera ett datum.

Managing StarTeam Projects 3 Kontakta oss för att arrangera ett datum.

Defining High-Quality Requirements 1 20 Oslo 24 Mmo 8 Cph € 850

Requirements-Based Testing Workshop 1-2 Kontakta oss för att arrangera ett datum.

Programming Skills dagar Oktober November December Pris * On-site

Software Architecture for Embedded Systems 2 6-7 Sthlm 3-4 Lkpg € 1470

Real-time Systems 3 11-13 Mmo € 1600

Safe Programming Practices 2 € 1400

Software Architecture - for Small Real-time Systems 2 3-4 Mmo 2-3 Sthlm € 1470

Object Oriented Methods dagar Oktober November December Pris * On-site

Designing JAVA Applications with Together for Eclipse 3 Kontakta oss för att arrangera ett datum.

Together for Eclipse Essentials 1 Kontakta oss för att arrangera ett datum.

Business Analysis with Together Designer for Eclipse 1,5 Kontakta oss för att arrangera ett datum.

Practical Modeling with UML 313-15 Sthlm 22-24 Gbg

17-19 Jkpg 1-3 Mmo € 1890

Design Pattern 3 20-22 Sthlm € 1890

MBSE Architecture 2 13 + 20 Gbg 13 + 20 Sthlm € 1470

MBSE Design, Execution and Generation Code 221 + 4/11 Gbg 29 + 12/11 Sthlm

€ 1470

MBSE Simulation and Modelbased Testing 2 12 + 26 Gbg € 1470

MBSE Bootcamp 2 Kontakta oss för att arrangera ett datum.


Kurs-program

Mer info om kurserna på www.nohau.se/training.asp

Programming Language & Development dagar Oktober November December Pris * On-site

JBuilder Essentials 3 Kontakta oss för att arrangera ett datum.

C Programming for Embedded Systems, I 2 15-16 Mmo € 1000

C Programming for Embedded Systems, II 3 7-9 Cph 4-6 Mmo € 1580

C Programming for Embedded Systems, III 2 19-20 Cph 10-11 Mmo € 1000

C++ Basic 2 € 1000

C++ Supplementary 3 21-23 Gbg € 1580

C Engineering 3 7-9 Mmo € 1600

Reviewing C Code 2 26-27 Mmo € 1300

BlackDuck - Protex Quick Start 3 Kontakta oss för att arrangera ett datum.

Using C++ in Embedded Systems 3 21-23 Cph 8-11 Gbg € 1580

.Net for System Developers at the Forefront 524-26/11 + 8-9/12 Mmo

€ 2350

Python for Programmers - Part 1 1 16 Mmo € 780

Python for Programmers - Part 2 1 17 Mmo € 780

Applications in Embedded Systems dagar Oktober November December Pris * On-site

Develop for ARM Cortex-M3 2 8-9 Gbg 17-18 Gbg € 1200

Develop Applications for ARM9 3 € 1600

Develop Applications for ARM11 1 € 780

Develop Linux Based Embedded Systems 3 14-16 Oslo 18-20 Vantaa 2-4 Mmo € 1600

Communication dagar Oktober November December Pris * On-site

CANopen 2

CANbus 2 7-8 Sthlm € 1500

FlexRay - Workshop 1

Ethernet IP 2

Verification of Software / Quality and Test dagar Oktober November December Pris * On-site

Lauterbach Debugging 1 13 Vantaa 10 Sthlm 15 Mmo € 780

Lauterbach Trace Functions 1 14 Vantaa 11 Sthlm 16 Mmo € 780

Lauterbach for Linux Based Systems 1 15 Vantaa 12 Sthlm 17 Mmo € 780

Lauterbach for DSP Based Systems 1 16 Vantaa 13 Sthlm 18 Mmo € 780

Test in Practice 3 € 1890

Certifierad Testare Grundnivå - enligt riktlinjer från ISTQB och SSTB 4 9-12 Lkpg € 2400**

Unit Test with Cantata++ for C++/C 1 Kontakta oss för att arrangera ett datum.

Klockwork Insight 3 Kontakta oss för att arrangera ett datum.

Software Reengineering - Workshop 3 Kontakta oss för att arrangera ett datum.

Managing Quality with SilkCentral Test Manager 2 Kontakta oss för att arrangera ett datum.

SilkTest: Testing Dynamic Application webb Finns som lärarledd eller webbaserad, kontakta kursansvarig.

SilkTest: Verification Testing 3 3-6 Twyford € 1950

SilkTest: Verification Testing Advanced 3 Kontakta oss för att arrangera ett datum.

SilkPerformer: BDL Scripting Techniques webb Finns som lärarledd eller webbaserad, kontakta kursansvarig.

SilkPerformer: Results Analysis & Correlation 4 Kontakta oss för att arrangera ett datum.

SilkPerformer: Modeling & Implementing Load Tests 4 € 2400

Design of Medical Devices dagar Oktober November December Pris * On-site

Patient Risk Management in Medical Devices 1 Kontakta oss för att arrangera ett datum.

Validation of Software in Medical Devices 1 Kontakta oss för att arrangera ett datum.

Basic Regulatory Training for Design Engineers 1 Kontakta oss för att arrangera ett datum.

Architecture of Medical Devices Containing Embedded Systems 2 Kontakta oss för att arrangera ett datum.


* Med reservation för ändringar. Priserna gäller i Sverige och är i euro, exkl. moms. ** Certifieringsavgift på 200 ingår ej. Sthlm = Stockholm, Gbg = Göteborg Cph = Köpenhamn, Mmo = Malmö, Lkpg = Linköping, Jkpg = Jönköping, Oslo, Norge, Vantaa, Finland, Twyford, UK.

Av Joakim Larsson, Nohau


De senaste åren har kraven på inbyggda system ökat på

prestanda, stabilitet och användningsområden. För att

möta applikationshanteringen använder man idag i allt

större utsträckning MMU – tunga operativsystem som

Linux och Symbian.

Tidigare klarade man sig med ”nakna” applikationer

som körde direkt på kortet. Ibland användes hårda RTOS

som kanske kunde hantera ett antal tasks med en enklare

schemaläggare.

Att ens överväga ett dynamiskt OS i ett inbyggt sys-

tem sågs nästan som en hädelse. Idag är det annorlunda.

Utöver detta ställer användargränssnitten allt högre krav,

samtidigt som hanteringen av data ökar i nästan alla sys-

tem. För att möta dessa krav är lösningen för branschen

multicore och multicpu.

Det sker nu ett generationsskifte i hur inbyggda system

designas. Att öka hastigheten på single core system är inte

en lösning för ökad prestanda. Även om möjligheten fanns

skulle det inte ta bort den flaskhals som ett single core

system har jämfört med ett multicore.

Varför Multicore?Anledningarna till detta är många. Bland annat kan

nämnas cpu stalling, temporärt stoppande av cpu:n i

väntan på minnes-accesser. Singel core exekverar alltså

samma system långsammare än ett multicore system med

samma totala MIPS prestanda (Millions Instruction Per

Second).

Det beror på att multicore kan dela upp kärnornas vän-

tan på minnes-accesser.

Single core system kan inte göra så, systemet måste

stoppas helt varje gång en minnes-access ska ske.

1) Ingen parallellism i single core system

Hur snabb single core än är kommer det inte att kunna ex-

ekvera mer än en funktion/task/process åt gången, medan

ett multicore system kan exekvera minst två på samma

gång och därav halvera tiden som måste spenderas i ”con-

text switchen”.

2) Energikonsumtion - värme - hållbarhet

Dessa tre faktorer har en inbördes bidragande påverkan

på varandra. Många drar en parallell med att multicore

direkt betyder mer perfomance, men i den inbyggda värl-

den betyder det också mer energisparande.

Har man lägre energikonsumtion utvecklas mindre vär-

me och systemets komponenter håller längre. Vissa typer

av applikationer är direkt beroende av en så låg energiför-

brukning som möjligt.

3) Till sist - stabilitet

Här kan man se det på två sätt. Först och främst kom-

mer systemet rent generellt att bli mer stabilt i jämförelse

med ett singel core system.

Anledningen till detta är att processer som vanligtvis

skulle tävla om resurserna på ett singel core system nu

kan bli separerade, schemalagda och dedikerade uppgifter

dynamiskt under exekvering.

Jakten på prestanda kan göra att man frestas öka klock-

frekvensen i sitt single core system och därmed öka risken

för instabilitet.

Joakim Larsson, Nohau

För att möta dessa krav för branschen är lösningen multicore och multicpu

Varför Embedded Multicore?Debuggern – nyckelverktyget för hantering av komplexa system


Komplexiteten i MulticoreAtt skriva parallella program är sedan länge känt för att

vara komplicerat. Att sedan optimera dessa applikationer

är om möjligt ännu svårare. Debugga och testa systemet

ställer inte bara höga krav på utvecklarna utan också på

de utvecklings- och testverktyg som används.

Parallella program bidrar med en ny typ av buggar.

Dessa har sitt ursprung från interaktion mellan multipla

processer och kärnor, vilka i sin tur ofta är beroende av

precisionen i timingen av exekveringen, samt intern res-

pektive extern kommunikation.

Detta betyder att buggarna kan försvinna eller ändra be-

teende när man försöker debugga dem och de är extremt

komplexa att återskapa. Denna typ av buggar går under

namnet ”Heisenbugs”.

Heisenbugs

Orsaken till Heisenbugs är just slumpmässigheten i ett

komplext system. Bryter man ned systemet i delsystem

kommer problemet förmodligen att försvinna. Det kan

också visa sig att olika komponenter i systemet fungerar

tillsammans - men när man sätter samman allt till en en-

het uppkommer felen.

Exempelvis kan problemet uppstå från adressaccesser

till ”dangling pointers”. En ”dangling pointer” kan upp-

stå då en global pekare sätts att peka på ett lokalt skapat

objekt.

Problemet uppstår då det lokala objektet försvinner när

programpekaren lämnar programblocket det var deklare-

rat i.

Pekaren finns emellertid kvar med sitt gamla värde, som

senare under exekvering olyckligtvis kan återanvändas till

andra objekt vilket gör att pekaren kan peka på fel adress

eller fel typ.

Olika typer av Multicore systemDet finns två typer av multicore system: Symmetric

Multi Processing (SMP) och Asymmetric Multi Proces-

sing (AMP).

Låt oss nu titta på de stora skillnaderna mellan dessa

system (se fig. 1).

Skillnaderna mellan SMP och AMP

Funktionsmässigt utgörs SMP som helhet av system, vil-

ka har identiska kärnor. Dessa kärnor delar arbetsbördan

under kontroll av ett enda SMP OS.

AMP använder sig av en helt annan teknik - att låta

varje cpu/core ha sitt eget OS med allt vad det innebär av

minneshantering, hantering av systemresurser med mera.

Intern kommunikation mellan skilda cpu:er och kärnor

I AMP använder sig systemet av intern kommunikation

mellan de skilda cpu:s/cores för att kunna synka eller ut-

byta data. För att kunna göra detta krävs extra hårdvaru-

resurser, vilka i sig kan vara komplicerade att hantera.

SMP å andra sidan gör detta internt utan extra hård-

varuresurser.

AMPs fördel i detta fall är just möjligheten till avgräns-

ning. Olika cpu:s/cores har olika uppgifter och skiljer sig

ofta även i minnesuppsättning, medan kärnorna i ett SMP

alltid delar på alla typer av uppgifter

och därmed måste generalisera hur ar-

betsuppgifterna utförs.

Skräddarsy och specialisera

I ett AMP-system kan man skräd-

darsy och specialisera en cpu/core till

en viss typ av arbetsuppgift medan ett

SMP-system bygger på att fördela lik-

artade uppgifter.

AMP skiljer sig också från SMP

genom att tillåta heterogena OS och

cpu:er/cores, medan SMP bygger på

endast ett OS med unisona kärnor.

Detta bidrar till att AMP-system till-

för mindre OS overhead för varje en-

skild processor/kärna än vad ett SMP-

system gör.

Symmetric Multi Processing

Identiska cpu:er/cores.•

Gemensam/identisk access till •delat minne.

Ett enda OS.•

Multitrådade arbetsuppgifter •kommer att vara fördelade av ett OS i run-time vilket medför endast en debugginstans för hela

systemet.

Asymmetric Multi Processing

Cpu:er/cores är olika.•

Varje cpu/core har ett lokalt •minne.

Varje cpu/core har ett oberoende •OS/kontroll-mjukvara.

Behöver ha en debugginstans för •

varje cpu/core.

fig. 1

fortsättning sid. 10 »


AMP-systemen å andra sidan måste handskas med

andra svårigheter, som att olika cpu:s/cores måste kunna

dela information genom att använda sig av IPC moduler

(Inter Processing Communication) till vilka de behöver

semaforer.

Att utbyta data på detta sätt genom delade minnen kan i

AMP-system leda till datakorruption och strukturföränd-

ringar, vilka sker parallellt då systemet exekverar.

Då både SMP och AMP exekverar flera processer/task

simultant måste de hantera delade resurser som klockas,

det gör att du som utvecklare eller testare måste kunna

hantera sofistikerade debugg- och testsystem.

Debuggern – nyckelverktyget för hantering av komplexa sys-tem

Som tidigare nämnt ställer komplexiteten i denna typ av

system höga krav på utvecklingsverktygen och i synnerhet

möjligheten att kunna återskapa situationer då buggar

uppstår.

För att kunna testa och debugga denna typ av system

krävs det att man på något sätt kan återskapa och provo-

cera fram beteendet under kontrollerade former.

För att göra detta krävs kraftiga och avancerade ut-

vecklingsverktyg. Med de debuggers som erbjuds från

Lauterbach uppnås full transparens i multicore-systemet,

oavsett om det är AMP eller SMP. Dock hanteras dessa

på olika sätt.

SMP

Då ett SMP-system ska debuggas, profileras eller testas,

används en instans av Lauterbach-debuggern för att de-

bugga alla kärnor (se exempel fig. 2).

Listan på aktiva task/processer indikerar vilken kärna

som dessa exekveras på.

Då en brytpunkt sätts på en funktion eller en process

kommer denna brytpunkt att automatiskt sättas av bryt-

punktslogiken i Lauterbach-debuggern på alla kärnor.

Detta gäller oavsett hur man filtrerar brytpunkten, pro-

gram, skriv/läsning, en viss process eller en funktion.

AMP

Vid AMP-debuggning hanteras varje kärna av en unik in-

stans av debuggerns programvara. Här är möjligheten till

komplexa brytpunkter och funktionalitet för att hantera

intern kommunikation i debuggern ett måste.

Med Lauterbach-debuggern kan man dessutom filtrera

vad som ska spelas in, vilka kärnor som ska bryta vilka,

samt när och hur. (se exempel fig. 3).

fig. 2

fig. 3

Boktips - Real-Time AgilityThe Harmony/ESW Method for Real-Time and Embedded Systems Development

Bruce Powel Douglass visar

hur du kan utnyttja de bästa

metoderna för agil utveck-

ling för att möta alla dessa

utmaningar.

Han presenterar Harmony processen; en beprövad,

start-to-finish strategi för utveckling av mjukvara

som kan minska kostnader, spara tid och eliminera

eventuella brister.

Borland nu Micro-FocusMicroFocus med huvudkontor i England har köpt

Borland. Köpet kombineras med MicroFocus tidigare

övertag av Compuwares division Application Testing /

Automated Software Quality. Med dessa strategiska

förvärv skapar MicroFocus en stark produktportfölj

inom Test Management och Automatiserad test.

Precis som tidigare kan du köpa dessa produkter av

Nohau.

Stöd för Cortex-M3Keil har släppt MCB1760

utvecklingskort och starter kit

med stöd för processorfamiljen

NXP LPC1700 Cortex™-M3.


Fördelarna med en robust JTAG debugger

Fördelarna med en robust JTAG-debugger är att man

kan hantera och reproducera ett felbeteende för att kunna

upptäcka buggar.

Debuggern stödjer intern kommunikation mellan olika

instanser och kan med hjälp av komplexa brytpunkter fil-

trera om en brytpunkt ska aktiveras eller inte, beroende

på vilken kärna som uppfyller ett visst krav tillsammans

med en skriving/läsning av ett minne, för en viss process

eller task.

Under förutsättning att denna logik finns implementerat

i target kan man spela in systemets beteenden. Att spela

in allt hela tiden är dock inte effektivt.

Dessa system klockas vanligtvis med en hastighet som

gör att deras egen tracelogik ibland inte hinner med att

leverera data och programtrace i tillräckligt hög takt.

Detta bidrar till att om vi samplar allt hela tiden ur-

skiljningslöst får vi dels en massa ”skräp” vi inte behöver,

samt en del flödes- och data-access fel.

Att då spela in ett till grunden redan komplext system

som kräver leverans av mer tracepaket enbart i syfte att

tala om hur programflödet sker, talar för förnuftig an-

vändning av denna funktionalitet.

Det är av stor vikt att debuggern kan synkronisera bryt-

punkter för att från en kärna kunna bryta alla andra. I

SMP-system är detta trivialt – det går inte att göra på

något annat sätt än hur OS:et är implementerat.

I ett AMP-system är detta något helt annat och kan

ställa till det rejält om man inte har en stabil debugger

som kan ta hand om denna typ av interna kommunika-

tions-brytpunker.

Varför använda Lauterbach debuggern till dessa system?

Lauterbach har ett enkelt, kraftfullt användargränssnitt

för uppsättning av flera CPU:er och olika arkitekturer.

Här går det helt att anpassa efter specifika targets.

Systemet är dessutom generellt och sätter inga gränser

för varken antal kärnor eller arkitektur, vilket i slutänden

förenklar och kortar ned debugg-fasen i projektet.

Debuggern påverkar inte realtidsegenskaperna vid exem-

pelvis prestandamätningar och profileringar.

Själva hanteringen av interna och externa minnen är helt

transparent och till debuggern finns ett scriptspråk som

ger dig möjlighet att skriva testsviter och profileringar –

helt efter eget behov.

Model Driven Development

Vi erbjuder följande tjänster:

Assessment•

Programvaruintegration •och kick-start

Mentorskap•

Utbildning•

Workshop•

Concept Workshop•

Technology Workshop•

Kick-start Workshop•

External Code Workshop•

Mer info om våra lösningar

Kontakta Magnus Engström, telefon: 040-592204,

e-post: [email protected]

Datablad på olika paketlösningar finns även att hämta här:

www.nohau.se/support.asp?service2=93

Sedan 2008 finns vi även representerade i Norge.

Kontakt: Tom Trælvik, Skøyenåsveien 5D, NO-0686

Oslo. Tele: +47 92 44 22 09, e-post: [email protected]

Utnyttja våra Paketerade Lösningar

1

2

3

4

Nohau levererar mätbara förbättringar i din utvecklingsprocess

Vår ambition är att hjälpa din organisation sänka kostnaderna

för era utvecklingsprojekt. Det är oftast inget magiskt i detta

arbete, utan en rättfram jakt på tidstjuvar, flaskhalsar och sa-

ker som kan förenklas eller automatiseras.

Eftersom du sannolikt inte har utvecklingsprocessen som hu-

vudsakligt affärsmål kan det kännas bra att ha en partner som

kan ta en förutsättningslös diskussion och sedan komma med

förslag på förbättringar.

Vi nöjer oss inte med det. Vi hjälper din organisation att införa

nya processer, metoder och teknologier, och vi ser till att till-

sammans få det att fungera så att du får bästa möjliga avkast-

ning på din investering.

Lösningsområden vi är fokuserade på:

Requirements Engineering, se exempel nedan.

Software Quality and Test

Embedded Development and Debugging

Model Driven Development, se exempel nedan.

Requirements Engineering

Vi erbjuder följande tjänster inom Requirements Engineernig:

Assessment•

Implementation•

Projektledning •

Mentorskap•

Eftervård •

Utbildning•

Process Improvement•

Skills Improvement•

Infrastructure•

Exempel på paketlösning:

Processgenomgång, krav-hanteringsverktyg, kompe-tensutveckling och kom-igång hjälp.

1

Exempel på paketlösning för MDD-utvecklare:

Rational Rhapsody•

Lämplig compiler och •debugger

RTOS/Embedded Linux•

Kick-start•

4

nohau solutions ab

Box 1030

SE-212 10 Malmö Sweden

Tel: +46 40 59 22 00

Fax: +46 40 59 22 29

www.nohau.se

nohau news no 2-09

Documents