Prsentation af IAR visualSTATE

Lars Kornbek lars.kornbek@iar.dk

Agenda
Lidt historie samt firma prsentation
visualSTATE Grundlggende visualSTATE opbygning
Designeren og UML Formel verifikation Test / Validering samt prototyping Kodegenerering og RealLink Dokumentation

Kunderne og deres applikationer Nste visualSTATE release Demo af visualSTATE

Lidt historie samt firma

prsentation

visualSTATE and IAR A/S History

1985 1987 1989 1991 1993 1995 1997 1999 2001 University B&O R&D B&O Technology Beologic A/S Baan IAR

Today

IAR Systems World wide

San Francisco San Jos Boston Munich London Uppsala Jonkoping Aarhus Tokyo
Sales App. Dev. Services R&D Sales Sales App. Dev. Services Sales App. Dev. Services R&D R&D

From idea to target!

Vision
To radically improve the software development process for embedded application development. We are creating new leading edge embedded solutions that drastically shorten the entire development process while still achieving more efficient results.

visualSTATE
programming tool for Design, Prototyping, Code Generation, Test & Documentation

Embedded Workbench
development toolkit based on C/C++ compilers

Different Architectures. One Solution.

The IAR Solution is now available for more than 30 chip architectures!

Intel OKI Hitachi Mitsubishi NEC Motorola Atmel Zilog Microchip Technologies
32-bit

Sharp
8-bit

DSP

16-bit

Toshiba Texas Instruments Samsung

ITT

National Semiconductor

The IAR Embedded Workbench

A complete development suite for embedded development: Project management functionality Editors for source code and binary files ANSI C & Embedded C++ compilers Assembler Linker & librarian Debugger (Simulator, Emulator & ROM-monitor)

IAR MakeApp
automatic code generators for device drivers

BlueTooth

MakeApp for BlueTooth

StarterKit

PreQual

Other Products / Services

Consultant services
Project startup Project preview project development

Training
Product training Technology training (C++, EC++, UML, BT, etc)

Technical Support Services Application development Services

Hvad er vigtigt for embeddede systemer?

Krav til embeddede systemer

Tidskrav
Eksekverings-tid / Real-time Deterministisk

Ressource forbrug / Kodestrrelse

RAM ROM

Kvalitet / plidelighed

Grundlggende visualSTATE opbygning

From idea to target

Traditional Development Typical CASE-tool based development IAR based development

Analysis

Informal analysis

High-level Analysis & Design Tool

strictly formal

UML SDL

SA
Informal method

Design

Incomplete design

Verification

Trial & Error

IAR visual STATE

Embedded Workbench MakeApp
Manual coding

Coding

Integration

Manual coding

Manual coding

From Design To Final Tested Code in an Easy Way

IAR visualSTATE notations

State machines designed in IAR visualSTATE can be designed using two notations :
S/E notation based on the Mealy notation
SE_RESET

S1

E1 / A2A3

E1 / A1

S2

S3

E1!S4/A2A3

UML notation for Statecharts

Hierarchy Concurrency Memory in state machines

Hvad er en tilstandsmaskine ?
En maskine/system med en tilstands-orienteret dynamisk opfrsel Et dynamisk system, der reagerer p pvirkninger afhngig af tid og tilstand

Et tilstandsdiagram beskriver
Livs-forlbet af et system Hvordan systemet reagerer p pvirkninger i alle situationer

Eksempler
Mobiltelefoner Automater (kaffe, slik, cigaretter, Dankort, ...) Operatr-paneler Symaskiner Reguleringer (varme, lys, fugtighed, ...)

De centrale elementer i tilstandsmaskiner er :

Events States Actions

Events
Hndelser, der pvirker tilstandsmaskinen Har i princippet ingen tidsmssig udstrkning (forekommer momentant og asynkront)

States
Beskriver systemets tilstand mellem to events Har tidsmssig udstrkning

Actions
Beskriver systemets pvirkning p omgivelserne Har i princippet ingen tidsmssig udstrkning (udfres momentant og uden afbrydelser)

Traditionel implementation af tilstandsmaskiner

Manuel kodning med switch-case Manuel kodning med tabeller Manuel kodning med tilstandsklasser Arv og polymorfe operationer (C++/Java)

switch ( current_state ) { case ALARM : if ( event == ALARM_KVITTERING ) { StopAlarm(); current_state = INGEN_ALARM; } break; case ... : }

Hvordan hndterer vi hierarki, concurrency og synkroniseringer ved manuel kodning

Rule notation

event CSV : NSV AV

CSV = current state vector NSV = next state vector AV = action vector

Each state machine is always in one and only one state State changes (transitions) are triggered by one and only one event

visualSTATE Fundamentals
Event Queue
Real Life Real Life

x=port(0);

Device Driver convert inputs to events

visualSTATE enigne

Device Driver convert actions to outputs

port(1) = 1;

Events

Action functions

Technological concept
Mathematical proof of correct code through binary arrays with unique interpretation
Well defined set of mathematical operations

Patented
Modeling

Run-time

Pa te

nte d
State analysis

Kernel functionality verified in millions of applications since 1987

Hvad kan visualSTATE?

Design vha. grafisk programmering

Event1() / A Event3() / Event4() / D Event5() / B Event2() /

Prototype p baggrund af design

Manuel test
Event1 Event3 Event7 Event4 ... Event6() /
Event1() / A Event3() / Event4() / D Event5() / B Event2() /

Event6() /

Automatisk test
Fejl hvis Event1 og state1 og state2 {

Kodegenerering
Event1() / A Event3() / Event4() / C D Event5() / B Event2() / Event6() /

Dokumentation

This TV set has been developed for a Motorola platform...

if (SEM.CSV [4] == 0x05) SEM.WSV [3] = 0x0F; .... }

Event1() / A

Event3() / Event6() / Event4() / C D Event5() /

Event2() /

Designer / UML

Hvad er UML

UML, Unified Modeling Language UML er en metode / notation der prver at samle nogle af de forskellige objekt orienterede metoder. OMG godkendte UML som standard i 1997. 3 modeller
Kravmodeller (USE-case diagram og sekvensdiagram) Strukturer (klassediagrammer) Opfrsel (tilstandsdiagrammer)

Hvorfor UML

Veldefineret objekt model Uafhngig af implementerings sprog Mulighed for genbrug Samme platform uafhngig af type applikation Bred vifte af vrktjer Bred vifte af litteratur, trning og konsulentydelser Efterhnden udbredt p undervisnings institutioner

Designing a stereo...

Either the tape recorder or the radio or the CD player is active...

Events are added...

Transition

Event

A new hierarchical level is introduced

Substate

Super state

The states STOPPED, PLAYING and RECORDING are only active when state TAPE is active

Concurrency is introduced
Composite state

Concurrent substate

State PLAYING or state STOPPED and state CD or state NO_CD are active

Actions are added

Action

Entry and Exit actions

Entry action Exit action

Entry actions are activated each time a state in entered Exit actions are activated each time a state is left

Initial states
Initial state

Initial states are used to initialize the statecharts and as default states in superstates

History states

History state

History states are used to apply memory to the statecharts

Variables
Variable

Signals

Signal

Signals can be used to send a message to another state machine

Internal transitions
Internal transition

An internal transition does not cause any state change

In the real world...

Events could be interrupts, a button press, timeouts, reset... States represents whatever the product is doing right now... Actions could control valves, displays, a CAN bus... Variables could be used to represent temperatures, counters, flags...

Summary - UML and visualSTATE, Rules :

Each state machine is always in one and only one state State changes (transitions) are triggered by one and only one event / event group / signal Upon receipt of a trigger, all state combinations are frozen until all transitions have been handled, and all variables are double buffered (if necessary)

Summary - UML and visualSTATE, Transition :

State condition Guard expression

Trigger Condition side

EV(p) S1 [(x < 7) || (y > 10)]

/ [z = MAX] A2(x, y) S4 ^SIG

Action side Action function

Assignment

Force state

Signal

Design / metode
De 6 trin :
1. Identificr events og actions 2. Identificr states 3. Gruppr efter hierarki 4. Gruppr efter concurrency 5. Tilfj transitioner 6. Tilfj synkroniseringer

Trin 1 : Identificr events og actions

Events er omgivelsernes pvirkning p systemet = input til tilstandsmaskinen Events er eksterne hndelser

Signaler er interne hndelser fra systemet selv

Actions er systemets pvirkning p omgivelserne = output fra tilstandsmaskinen Actions er systemets reaktion p de eksterne pvirkninger

Trin 2 : Identificr states

States identificeres udfra kravspecifikation samt viden om problem-domnet.

Dren kan vre ben eller lukket Dren kan vre lst eller ulst Switchen kan vre i en af de tre positioner Lyset kan tndt eller slukket

Trin 3 : Gruppr efter hierarki

Undersg hvilke states, der i sig selv har dynamisk opfrsel, samt om visse tilstande kun vil optrde i bestemte situationer

Med denne gruppering modelleres, at dren ikke kan vre ben eller lukket, nr den er lst. Modellen indkapsler muligheden for at bne en dr kun muligt, nr dren er ulst

Trin 4 : Gruppr efter concurrency

Undersg hvilke tilstande, der kan vre aktive p samme tid Opdel i flere parallelle aktive tilstandsmaskiner

Det skal vre muligt at bne, lukke og lse dren samtidigt med at switchen ndres og samtidigt med at lyset skifter

Trin 5 : Tilfj transitioner

Identificr hvilke tilstandsskift og udfrelse af actions, der skal foreg, nr events forekommer Beskriv scenarier (sekvenser af pvirkninger) og tilfj transitioner, der understtter disse

Bemrk, at der er indfrt yderligere hierarki af design hensyn n transition til hver switch-position

Trin 6 : Tilfj synkroniseringer

Identificr hvilke transitioner, der er betingede og tilfj evt. yderligere transitioner Identificr hvilke transitioner, der har brug for at sende interne beskeder

Nr dren bnes mens switchen er i sensitive, s skal lyset tndes.... .... etc.

IAR visualSTATE Designer

Graphical overview of system behavior Hierarchical state systems Multiple and interrelated state machines Parallel threads of control UML Statecharts State Transition Diagrams

Formel verifikation

IAR visualSTATE Testing

Dynamic Formal Verification
Dead end

S11 S21

KEY3 S14 KEY1

Conflicting Transition

KEY1 S22 S12

S13

KEY2 [S21 && S22]

Unreachable Transition

Interrelationships between statemachines are checked All combinations are checked

Verificator settings
Exhaustive computation 7 different checks Use of elements Reachable transitions Conflicting transitions Activation of elements State dead end Local dead end System dead end Forward / Backward mode Backward = no dead-end check

Test / Validering samt prototyping

IAR visualSTATE Testing

Manual validation
Simulation Sending events Monitoring Current States Active events Guards Triggered actions Timers Variables Signals
E1() / AA AB

E3() / E4() / E2() /

AD

E3() /

AC

IAR visualSTATE Testing

Log & Animation
Record test sequences Static analysis, use of Events Actions Signals Internal & Externalvariables Dynamic analysis Test coverage analysis Non-activated elements Most frequently used

Prototyping

Why prototyping
You can build a model that looks and behave like your final product You can get feedback from marketing, sales and customers and therefore make corrections in a much earlier state in your development process and therefore save money. It will help you increase the awareness and knowledge of your product before it is launched With visualSTATE your final product will behave in a way 100% identical to that of your prototype.

Prototyping with Altia FacePlate

Altia integration to visualSTATE

Other Prototype possibilities

Visual C / C++
App note 10743: Prototyping in Visual C++ with IAR visualSTATE

Borland C++ builder

IAR DK can provide you with an example.

Visual Basic
App note 45079: Prototyping in Visual Basic with visualSTATE expert DLL.

Delphi
App note 45079: Prototyping in Visual Basic with visualSTATE expert DLL.

Kodegenerering og RealLink

IAR visualSTATE Code generation

Features
Automatic Code Generation based on the design Generation of very compact code for 8/16/32-bit microprocessors integrates with any ANSI-C Compiler Integrates with any RTOS

Advantages
SW-consistency between design and actual code is guaranteed Avoid manual coding, spaghetti coding and reverse engineering

Flexible realization in any target

Automatic codegeneration

Application
Model

Complete Target Application

^ Design + Test + Prototyping

Real-Link

API* RTOS Hardware

Device Drivers

8-/16-/32-bit
*) Foot print: 600 bytes to 2K

Connectivity via Real-Link

Host Target Application Validator
Model

TCP/IP

Direct

Real-Link Server

Wire

Real-Link Agent*
*) Foot print: ~1K (RS232 interface)

Documentation

IAR visualSTATE Documentation

Features
Automatic generation of design/test/code documentation Customized generation of documents

Advantages
100% consistent with current implementation Customized documentation/manual Up-to-date documentation

Our customers

Automotive Telecom Medical Electronics Aerospace & Defense Financial Industrial machinery Industrial instruments Consulting & Education Multimedia & Entertainment

One generic product for a variety of industries

Case Stories

Husqvarna Viking, MMI for sewing machine Grundfos Group, Pumps Bang & Olufsen, TV, video and stereo Danfoss A/S, MMI for flow meters P.I.V. Eldutronik, frequency controller Spark Holland, laboratory equipment Wittenborg A/S, Vending machines http://www.iar.com/Products/vS/References

Other Customers

Canon Inc. LG Electronics Digianswer A/S DE-VI A/S DEIF A/S Migatronic A/S FBI laboratory

KONE Corporation Lego Systems A/S Novo Nordisk A/S Scanvgt International A/S Siemens Elema AB Siemens AG Terma Elektronic A/S

Next visualSTATE release

Hierarchical Coder C++ wrapper Verification of guard and assignments Trace generation w/ Validator integration New UML modeling constructs Team work (+VCS) New Navigator Graphical breakpoints and transitions General bug fixing, performance and stability improvements

Future: More UML support ???

Questions