Page 1

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

Nohau news når ca 15.000 läsare. Vill du vara med i tidningen? Kontakta redaktionen. Ansvarig utgivare: Mikael Johnsson, mikael.johnsson@nohau.se. Redaktör: Maria Eklind, maria.eklind@nohau.se. Tidningen trycks på miljövänligt papper från KLS Grafisk Hus Danmark, som är helt CO2-neutrala.


Erfarenheter från Combitech, Sectra Communications och Saab

Framgång med Modelldriven Utveck En viktig bit för att lyckas är att det modelldrivna arbetet måste harmoniseras med resten av företagets tradition eller metodik.

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.

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

– Vi utbildar teamet genom att bygga upp utbildningar

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

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

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

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

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

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

Combitech.

med i Nohaus kursverksamhet, säger Gert.

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.

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

Praktisk erfarenhet och kompetens

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

Produkter och system blir mer och mer komplexa, det vet

tionen är reducerad om du jobbar modellbaserat.

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

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

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

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

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

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

ter av produkten/systemet, som användningsaspekten, kravaspekten, komponenterna i sig och hur de interagerar.

Metodval

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

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

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

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

lade till guidelines.

eller agil.

A och O är att beskriva metodiken för modelleringsarbetet, 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 modellera. Alla detaljer framgår inte i ett sådant dokument, enbart de viktigaste bitarna och beskrivningen av metodiken.

2

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

nohau news - no 2 - 2009

– 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 konsumentmarknad, 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örjan av 90-talet vid forskning om produktionsutrustningar.


System Acceptance

Requirements Capture & Analysis

System & Software Model

System Analysis & Design

kling

-)System (Sub -)System Integration & Test

Module Integration & Test

SW Design

SW Implementation & Unit Test

A Model Provides a Mechanism to Unify All Development Artifacts.

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

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

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

vändningsfall), säger Gert.

duktion, som mycket av dagens agila utvecklingsmetoder bygger på, säger Gert. Michael Bertilsson, VD på Sectra Communications berättar att agila metoder även fungerar för komplexa system som säkerhetssystem med hög kvalitetspolicy.

- 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

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

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

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

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

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

något sätt ett grundmaterial till vad systemet ska kunna utföra.

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

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

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

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

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

antal komponenter upp som realiserar det som systemet

utvecklingschef på Produktdivision Tiger, på Sectra Com-

ska utföra, säger Gert.

munications.

Exempel på specifika kunder/projekt Agila metoder fungerar även för komplexa system som säkerhetssystem med hög kvalitetspolicy Michael Bertilsson, VD på Sectra Communications

– När det gäller mjukvara använder vi framför allt testdriven utveckling. Vi gör beskrivningen och testfallen först och implementerar sen, för att få fram en bra slutprodukt.

– 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.

Eftersom det alltid uppstår problem - kunden ändrar sig, vi ändrar oss internt - görs iterationer. Vi planerar om varannan 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 fortsättning sid. 4 »

nohau news - no 2 - 2009

3


Obemannade modeller – Oftast är det inbyggda delar i ett system vi utvecklar. Det kan t.ex. vara luftkonditioneringssystemet i hytten på

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.

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

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

Med Use case analys uttrycker vi vad maskinen ska kunna göra och hur den med hjälp av andra komponenter ska interagera. Ett annat större exempel är den obemannade flygfarkosten Skeldar (se bild föregående sida), som vi (Saab) utvecklade modellbaserat under Scrum-lika arbetssätt,

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

säger Gert.

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

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

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

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

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

UCAV (Unmanned Combat Aerial Vehicle), med smyg-

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

egenskaper.

och grundtanken var att spara tid och hitta fel tidigare. Då använde vi Rhapsody enbart som ritplanka, där modellerna inte var integrerade. Vi gjorde istället en jättestor modell av systemet, utan att gå hela vägen ner till kodgenerering. Successivt utvecklade vi Rhapsody och vi testade 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

Syftet med Neuron-programmet är att upprätthålla och utveckla den tekniska basen för de europeiska tillverkarna för nästa generation bemannade eller obemannade stridsflygplan.

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 flygelektroniken som ska hålla Neuron i luften, är det största av Saabs ”teknikrussin”, där Saab leder utvecklingsarbetet. Det är också avionikkompetensen som ska kunna användas för att uppdatera Jas Gripen.

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. Metoderna 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

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

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

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

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

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

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

olika funktioner för att övervaka farkosten.

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

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

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

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

test, även enhetstesterna och systemverifiering i riktiga

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

riggar med riktig hårdvara.

ningar.

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

Flyg får ju inte trilla ner på civilmark och skada omgivningen. 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

4

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

nohau news - no 2 - 2009

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.


Utbildningar inom Agila Metoder Våra Scrum-kurser kör vi i samarbete med Softhouse, ett konsultföretag specialiserat på Lean och Agile mjukvaruutveckling.

Agila Metoder

Lean and Agile for Managers

Agil projektledning skiljer sig lika radikalt från traditionell projektledning, som lättrörliga processer skiljer sig från traditionella metoder.

Denna kurs är till för dig som är ledare inom en mjukvaruorganisation och vill lära dig de senaste metoderna och verktygen från Lean och Agile för att kunna effektivisera era utvecklingsprocesser.

Istället för att planera, instruera och styra, så underlättar, coachar och leder den agila projektledaren.

Kursen, som är unik i sitt slag i Sverige, är delad i fyra delar där huvudpunkterna är följande:

CSM - Certified Scrum Master

• Value-stream mapping och minimering av waste

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

• Kanbansystem och hur du effektiviserar flödena i

(Muda) i din organisation.

dina processer.

införa agilt arbetssätt i ett utvecklingsteam, ett projekt eller en organisation.

• Agile Retrospectives för ständiga förbättringar (Kaizen).

Kursinnehåll och förkunskaper

• Hur du baserar dina prioriteringar på affärsvärde genom en strukturerad Backlog.

Under kursen blandas teoretiska genomgångar och praktiska övningar med målet att du under kursens gång ska få uppleva känslan av att delta i ett Scrum-projekt.

Planerade datum • 22-23/9 Stockholm

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

• 17-18/11 Malmö

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

Planerade datum

Pris • 1500 Euro

• 12-13/10 Malmö • 10-11/11 Malmö • 10-11/12 Göteborg

Pris • 1500 Euro

Se kursprogram på nästa uppslag grafik © Softhouse

nohau news - no 2 - 2009

5


Kursprogram Mer info

om kurserna på www.nohau.s e/training.asp Agile Methods Certified Scrum Master

2

Lean and Agile for Managers

2

Scrum for Team Members

1

Requirements Management, Version- and Configuration Mgt

dagar

Oktober

12-13 Mmo

November

10-11 Mmo

Oktober

November

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

1-2

Programming Skills

dagar

Software Architecture for Embedded Systems

2

Real-time Systems

3

Safe Programming Practices

2

Software Architecture - for Small Real-time Systems

2 dagar

24 Mmo

Oktober

6-7 Sthlm

November

€ 1500 € 1500

December

8 Cph

Pris *

On-site

€ 850

December

Pris *

3-4 Lkpg

€ 1470

11-13 Mmo

€ 1600

On-site

€ 1400 3-4 Mmo Oktober

November

3

Kontakta oss för att arrangera ett datum.

Together for Eclipse Essentials

1

Kontakta oss för att arrangera ett datum.

1,5

Kontakta oss för att arrangera ett datum.

Practical Modeling with UML

3

13-15 Sthlm 22-24 Gbg

Design Pattern

3

20-22 Sthlm

MBSE Architecture

2

13 + 20 Gbg

MBSE Design, Execution and Generation Code

2

21 + 4/11 Gbg 29 + 12/11 Sthlm

MBSE Simulation and Modelbased Testing

2

MBSE Bootcamp

2

nohau news - no 2 - 2009

On-site

Kontakta oss för att arrangera ett datum.

Designing JAVA Applications with Together for Eclipse

Business Analysis with Together Designer for Eclipse

10-11 Gbg

Pris *

Kontakta oss för att arrangera ett datum.

1

Requirements-Based Testing Workshop

December

6-7 Mmo

DefineIT Essentials

Object Oriented Methods

6

dagar

17-19 Jkpg

2-3 Sthlm December

1-3 Mmo

€ 1470 Pris *

€ 1890 € 1890

13 + 20 Sthlm

€ 1470 € 1470

12 + 26 Gbg Kontakta oss för att arrangera ett datum.

€ 1470

On-site


Programming Language & Development

dagar

Oktober

November

December

Pris *

JBuilder Essentials

3

Kontakta oss för att arrangera ett datum.

C Programming for Embedded Systems, I

2

15-16 Mmo

C Programming for Embedded Systems, II

3

7-9 Cph

C Programming for Embedded Systems, III

2

C++ Basic

2

C++ Supplementary

3

21-23 Gbg

€ 1580

C Engineering

3

7-9 Mmo

€ 1600

Reviewing C Code

2

BlackDuck - Protex Quick Start

3

Kontakta oss för att arrangera ett datum.

Using C++ in Embedded Systems

3

21-23 Cph

.Net for System Developers at the Forefront

5

24-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

Develop for ARM Cortex-M3

2

Develop Applications for ARM9

3

Develop Applications for ARM11

1

Develop Linux Based Embedded Systems

3

Communication

dagar

CANopen

2

CANbus

2

FlexRay - Workshop

1

Ethernet IP

2

Verification of Software / Quality and Test

dagar

€ 1000 4-6 Mmo 19-20 Cph

€ 1580 10-11 Mmo

€ 1000 € 1000

26-27 Mmo

Oktober

€ 1300

8-11 Gbg

November

8-9 Gbg

€ 1580

December

17-18 Gbg

Pris *

€ 1600 € 780 14-16 Oslo Oktober

18-20 Vantaa November

2-4 Mmo December

7-8 Sthlm

Oktober

€ 1600 Pris *

November

December

Pris *

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

Certifierad Testare Grundnivå - enligt riktlinjer från ISTQB och SSTB

4

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.

webb 3

SilkTest: Verification Testing Advanced

3

SilkPerformer: BDL Scripting Techniques

webb

SilkPerformer: Results Analysis & Correlation

4

SilkPerformer: Modeling & Implementing Load Tests

4

Design of Medical Devices

dagar

On-site

€ 1500

1

SilkTest: Verification Testing

On-site

€ 1200

Lauterbach Debugging

SilkTest: Testing Dynamic Application

On-site

On-site

€ 1890 9-12 Lkpg

€ 2400**

Finns som lärarledd eller webbaserad, kontakta kursansvarig. 3-6 Twyford

€ 1950

Kontakta oss för att arrangera ett datum. Finns som lärarledd eller webbaserad, kontakta kursansvarig. Kontakta oss för att arrangera ett datum. € 2400 Oktober

November

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.

December

Pris *

On-site

* 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. nohau news - no 2 - 2009

7


Av Joakim Larsson, Nohau

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

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

Det beror på att multicore kan dela upp kärnornas väntan 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

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

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

som kanske kunde hantera ett antal tasks med en enklare

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

schemaläggare.

ett multicore system kan exekvera minst två på samma

Att ens överväga ett dynamiskt OS i ett inbyggt system sågs nästan som en hädelse. Idag är det annorlunda.

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

gång och därav halvera tiden som måste spenderas i ”context 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ärlden betyder det också mer energisparande.

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

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

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

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

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

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

multicore och multicpu.

brukning som möjligt.

Det sker nu ett generationsskifte i hur inbyggda system designas. Att öka hastigheten på single core system är inte

3) Till sist - stabilitet

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

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

skulle det inte ta bort den flaskhals som ett single core

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

system har jämfört med ett multicore.

med ett singel core system. Anledningen till detta är att processer som vanligtvis

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).

8

nohau news - no 2 - 2009

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 klockfrekvensen i sitt single core system och därmed öka risken för instabilitet.


Komplexiteten i Multicore

Pekaren finns emellertid kvar med sitt gamla värde, som senare under exekvering olyckligtvis kan återanvändas till

Att skriva parallella program är sedan länge känt för att vara komplicerat. Att sedan optimera dessa applikationer

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

ä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.

Olika typer av Multicore system

Parallella program bidrar med en ny typ av buggar.

Det finns två typer av multicore system: Symmetric

Dessa har sitt ursprung från interaktion mellan multipla

Multi Processing (SMP) och Asymmetric Multi Proces-

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

sing (AMP).

precisionen i timingen av exekveringen, samt intern res-

Låt oss nu titta på de stora skillnaderna mellan dessa system (se fig. 1).

pektive extern kommunikation. Detta betyder att buggarna kan försvinna eller ändra beteende när man försöker debugga dem och de är extremt komplexa att återskapa. Denna typ av buggar går under namnet ”Heisenbugs”.

Skillnaderna mellan SMP och AMP Funktionsmässigt utgörs SMP som helhet av system, vilka har identiska kärnor. Dessa kärnor delar arbetsbördan under kontroll av ett enda SMP OS.

Heisenbugs

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

Orsaken till Heisenbugs är just slumpmässigheten i ett

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

komplext system. Bryter man ned systemet i delsystem

minneshantering, hantering av systemresurser med mera.

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

Intern kommunikation mellan skilda cpu:er och kärnor

också visa sig att olika komponenter i systemet fungerar tillsammans - men när man sätter samman allt till en enhet uppkommer felen.

I AMP använder sig systemet av intern kommunikation

Exempelvis kan problemet uppstå från adressaccesser

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

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

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

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

resurser, vilka i sig kan vara komplicerade att hantera.

objekt.

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

Problemet uppstår då det lokala objektet försvinner när programpekaren lämnar programblocket det var deklarerat i.

varuresurser. AMPs fördel i detta fall är just möjligheten till avgränsning. 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

Symmetric Multi Processing

Asymmetric Multi Processing

och därmed måste generalisera hur arbetsuppgifterna utförs.

Skräddarsy och specialisera I ett AMP-system kan man skräddarsy och specialisera en cpu/core till en viss typ av arbetsuppgift medan ett SMP-system bygger på att fördela likartade uppgifter. • Identiska cpu:er/cores.

AMP skiljer sig också från SMP

• Cpu:er/cores är olika.

genom att tillåta heterogena OS och

• Gemensam/identisk access till delat minne.

• Varje cpu/core har ett lokalt minne.

• Ett enda OS.

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

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

cpu:er/cores, medan SMP bygger på

• Behöver ha en debugginstans för varje cpu/core.

endast ett OS med unisona kärnor. Detta bidrar till att AMP-system tillför mindre OS overhead för varje enskild processor/kärna än vad ett SMPsystem gör.

fig. 1 fortsättning sid. 10 »

nohau news - no 2 - 2009

9


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ändringar, 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 system Som tidigare nämnt ställer komplexiteten i denna typ av system höga krav på utvecklingsverktygen och i synnerhet

fig. 2

möjligheten att kunna återskapa situationer då buggar uppstår. För att kunna testa och debugga denna typ av system

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

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

kommer denna brytpunkt att automatiskt sättas av bryt-

cera fram beteendet under kontrollerade former.

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

För att göra detta krävs kraftiga och avancerade utvecklingsverktyg. Med de debuggers som erbjuds från

Detta gäller oavsett hur man filtrerar brytpunkten, program, skriv/läsning, en viss process eller en funktion.

Lauterbach uppnås full transparens i multicore-systemet, oavsett om det är AMP eller SMP. Dock hanteras dessa på olika sätt.

AMP Vid AMP-debuggning hanteras varje kärna av en unik instans av debuggerns programvara. Här är möjligheten till

SMP

komplexa brytpunkter och funktionalitet för att hantera

Då ett SMP-system ska debuggas, profileras eller testas, används en instans av Lauterbach-debuggern för att debugga alla kärnor (se exempel fig. 2). Listan på aktiva task/processer indikerar vilken kärna

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).

som dessa exekveras på.

fig. 3

10

nohau news - no 2 - 2009


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 filtrera 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.

Det är av stor vikt att debuggern kan synkronisera brytpunkter 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 kommunikations-brytpunker.

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

Under förutsättning att denna logik finns implementerat

Lauterbach har ett enkelt, kraftfullt användargränssnitt

i target kan man spela in systemets beteenden. Att spela

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

in allt hela tiden är dock inte effektivt.

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

Dessa system klockas vanligtvis med en hastighet som

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

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

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

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

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

Detta bidrar till att om vi samplar allt hela tiden urskiljningslöst får vi dels en massa ”skräp” vi inte behöver, samt en del flödes- och data-access fel.

Debuggern påverkar inte realtidsegenskaperna vid exempelvis prestandamätningar och profileringar. Själva hanteringen av interna och externa minnen är helt

Att då spela in ett till grunden redan komplext system

transparent och till debuggern finns ett scriptspråk som

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

ger dig möjlighet att skriva testsviter och profileringar –

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

helt efter eget behov.

vändning av denna funktionalitet.

Borland nu MicroFocus MicroFocus 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.

Boktips - Real-Time Agility The 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 utveckling för att möta alla dessa

Stöd för Cortex-M3 Keil har släppt MCB1760 utvecklingskort och starter kit med stöd för processorfamiljen

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.

NXP LPC1700 Cortex™-M3.

nohau news - no 2 - 2009

11


Utnyttja våra Paketerade Lösningar 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 saker som kan förenklas eller automatiseras.

Model Driven Development Vi erbjuder följande tjänster: • Assessment

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

• Programvaruintegration och kick-start

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

• Mentorskap

förslag på förbättringar.

• Utbildning

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

• Workshop

Eftersom du sannolikt inte har utvecklingsprocessen som hu-

4

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

• Concept Workshop

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

• Technology Workshop

ning på din investering.

Exempel på paketlösning för MDD-utvecklare: • Rational Rhapsody • Lämplig compiler och debugger • RTOS/Embedded Linux • Kick-start

• Kick-start Workshop

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

Requirements Engineering, se exempel nedan.

2

Software Quality and Test

3

Embedded Development and Debugging

4

Model Driven Development, se exempel nedan.

• External Code Workshop

Mer info om våra lösningar Kontakta Magnus Engström, telefon: 040-592204, e-post: magnus.engstrom@nohau.se Datablad på olika paketlösningar finns även att hämta här:

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

1

• Implementation • Projektledning • Mentorskap • Eftervård • Utbildning • Process Improvement • Skills Improvement • Infrastructure

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: tom.traelvik@nohau.no

Exempel på paketlösning: Processgenomgång, kravhanteringsverktyg, kompetensutveckling och komigång hjälp.

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  

Kundtidning från Nohau Solutions