© Vodafone 2003 Confidential - MathWorks · © Vodafone 2003 Confidential Version XX Model based...

Confidential© Vodafone 2003

Ver

sion

XX

Model based development of a road usage charging

application on an ‘on-board-unit’ (ECU)

using embedded code generation


Pag

e 2

Outline

_ Introduction_Requirements and objectives for RUC_Hardware_Model based design_Version management_Model structure and optimization_Target for embedded coder and build process_ToDo‘s TMW_Results and conclusion_Demonstration


Pag

e 3

Introduction

_Vodafone RnD – D (former Mannesmann Pilotentwicklung) started in the early 90‘s with the development of a GPS / GSM based road usage charging application

_First trials were carried out on the German motorway A555 in 1994/95

_Participation in the German and Austrian procurement process_Project INITIATIVE – first interoperable solution supporting

DSRC and GPS / GSM_Project DIRECTS – development of a standardized solution for

the U.K._Membership in TC278 WG1 SG5

standardisation group


Pag

e 4

Main modules of a RUC system

System

Issuer of On-Board Equipment

On-Board Equipment

User

Vehicle

Clearing Operator

On-Road Service Provider

Enforcement Operator

Trusted Third Party

Collection AgentIssuer of Payment Means

Management ofService Rights

Management ofCharges

RUC systemcontrol

Claims andpayments settlement


Pag

e 5

OBU requirements

GeoObject Description

Position,Time,Speed

Balance IndicationPosition IndicationStatus Information

Position Comparison

Drive Analysis

Charge Communication

Payment Confirmation

GPS

Rules for Road Usage

GSM/GPRS Communicationwith Back Office

Enforcement DSRCControl

Payment Service Provider


Pag

e 6

Geo-Objects (according to the ISO pre-standard)

Corridor

ZoneVirtual Gantry


Pag

e 7

Hardware

_ Windows 2000 PC for simulation and rapid-prototyping implementation

• GPS-module– Simulation: read data from simulation file– Rapid-prototyping: GPS-receiver or OBU connected over a serial port

• COMM-module– Simulation: local network connection– Rapid-prototyping: mobile phone connected over a serial port

• ICC-module– SmartCard reader connected over a serial port

• FileSystem– Local hard disk with adequate file structure

• HMI-module– Active-X interface emulation as separate Simulink model (same touch and feel like real HMI)


Pag

e 8

_ ARM7 based ECU from SiemensVDO automotive (B2 sample)• System freq.: ~49MHz• Memory: 1MB SRAM, 8MB Flash (3MB application, 5MB file sys.)• Operating System (RTOS): pSOS• GPS-module

– Simulation: read data from simulation file– On-Line: GPS-receiver module with firmware and API

• COMM-module– GSM/GPRS telecommunication module

• ICC-module– Integrated SmartCard reader

• FileSystem– Flash file system

• HMI-module– Three coloured LED– LCD display for strings and with dedicated symbols – Two push-buttons

Hardware (1)


Pag

e 9

Development cycle/process (generic)

environment specification

system design

automatic code generation

simul

atio

n

simulation

design

requirementanalysis + specification

model design

mathematical +physical describtion

embedding processmodel

validation (measurements)

MODEL

simulation +analysis (stability)

MODEL

embedding process model +requirements

control system design

validated controllerstrategy

simul

atio

n

design

impl

emen

tatio

n

simulation

MODEL

adaptation for genericimplementation(e.g. DDC, sample times, fixed point)

validated controllerstrategy

adding driver blocks to themodel

e.g.:datatype accomodationdriver block substitution

embeddedtarget

adding driver blocks to themodel

implementation of newHW-specific drivers for graphical reuse

rapidprototyp

validated model

validatedcontrollerstrategy

validatedcontrollerstrategy

testin

g

testin

g

impl

emen

tatio

n

RT analysis:worst case execution timeworst case response time

Target requirements:memory (static, dynamic)

realisation


Pag

e 10

Development cycle/process (adapted)


Pag

e 11

Version Management

_RCS integrated in SimuLink (per model)• Suitable for model version

_Library version as tag (list) of RCS• Including c-, tlc-, mdl-, several m-files

_m-script to check version at beginning of each simulation or codegeneration run

• Warning if not current version (refering to the repository)• Updating list, when repository is prepared

_SimuLink blocks accessing current version of• Model• Library• BSP• Embedded target

Version number is in the generated C-code


Pag

e 12

Model structure

_Model consists of linked modules_Module-Library_Blocks linked in Sub-Libraries with html-documentation


Pag

e 13

Model optimizations

_Data-typing• Integer types whenever possible (without FP-Blockset)• Boolean-type for Events and logical signals• Double-type blocks for simulation only (activeX, m-file S-

function)• Data-typed SimuLink-variables as block parameter

_ If-else-Subsystems instead of switches

_Fcn-call or enabled Subsystems instead of triggered

_Configuration-data-sets as „constant from File“-block


Pag

e 14

Implementation

_TLC-files for inlined C-code

_CSCs and data typing for efficient memory usage and performance gains

S-functionshardware interfaces

_embedded target with RTOS

_multitasking sw-architecture with rate monotonic priorities

_asynchronous block support

everything generated automatically

Simulink/Stateflowenvironment

runtime environment

ARM7 embedded targetPC

simulation + rapid prototyping

_ Changing to a new target system requires• Provide runtime environment• Adaptation of hw-interface TLC-files

_ No changes to the application model !!


Pag

e 15

Target for Embedded Coder

_Automatic generation of model specific main file• Initialize hw-platform and data structures

(e.g.: BSP and firmware)• Spawns necessary model tasks

_Configuration of the generated model code• Task parameters (e.g.: priorities, stack size)• Levels of debug outputs• Compiler options• Integrated flash download• Start-up configuration

_Support of External Mode


Pag

e 16

Final sw-architecture of application model

tBaseRateHMI(1), ICC(1)

tRate1Control, COMM, HMI(2), ICC(2)

tAsyncGPS, RI,

Voter

GPS receiverfirmware

Realtime Operating System + Board Support Package

timer

EV_newFix

EV_T1

EV_T2

MSG_PayEV

task stack size reserved [kB] [% of total reserved] used [kB] [% of total reserved]application 56,0 42% 43,7 33%BSP + firmware 78,4 58% 13,0 10%total 134,4 100% 56,7 42%

static memory ROM [kB] [% of total] RAM [kB] [% of total]autogen. objects 638,5 42,7% 128,1 30,8%libraries 855,7 57,3% 288,2 69,2%total 1494,2 100,0% 416,3 100,0%


Pag

e 17

Build processes

library buildprocess

load to workspace- constants- defines- configs- error codes

generate automatically- parameter *.h, *.c files- error codes *.h file

compile S-functione.g.: mex -v gsm_antenna_connected.c

parameter.hparameter.cerror_codes.h

driver.dll

driver.hdriver.c

model.rtw

target_main.cmodel.cmodel.h...

model.axf

system.tmf

system.tlctlc-block-library

model.mk

download to target flash

execute model implementation

Real-TimeWorkshopbuild process

load to workspace- constants- defines- configs- error codes- Custom Storage Classes

model pre-load function

RTW-build

TargetLanguageCompiler

BSP and compiler libraries,

parameter.hparameter.c

error_codes.h

make


Pag

e 18

Custom Storage Classes

_Extented struct CSC• Structs in structs• Extern type definition of struct• M-script to automatically convert h-files to csc• Name conversion due to unique alias and csc-names

_Efficient codegeneration• No temporary local variables• Direct use of memcpy, fread, fwrite in device drivers

_Structs realized as busses in Simulink_Constant signal CSC can be changed during execution

• Parameter sets can be changed without restart (remote update)


Pag

e 19

Defines & constants

_Challenge• consistency of constants and defines between different

levels of abstraction and notations e.g. Simulink, Stateflow, S-functions, TLC generated code

_Solution• One central structure• Automatically generation of all necessary references

_Realisation• M-file with defined data structure• During build process automatic generation of *.c *.h-files• Use of defines and constants as following:

– Simulink: workspace variable– Stateflow: workspace variable, define– S-function: define– TLC generated code: workspace variable, define


Pag

e 20

Shared Interfaces

all error codes are defined in ONE m-File by

• Error-Number e.g. 0x01020304• OBU-Displaytext e.g. No Card• OBU-Logflag e.g. true• C-code define e.g. #define ICC_NO_SMARTCARD• Description e.g. %No Smartcard

load in Matlab workspace for using• in Simulink

auto generate a header-file for using• in Stateflow• in transaction system• in smartcard • In geodata production• ...

e.g. system-wide error codes


Pag

e 21

Results

OBU-field test with ~2800transactions and GPS-tracing

100,0%

100,0%

99,3%

96,9%

0,0%

0,0%

0,4%

1,6%

0,0%

0,0%

0,3%

1,5%

95% 96% 97% 98% 99% 100%

tolling correct uncorrect geodata software bugs

OBU-Simulation (field test)

OBU-field test repeated

OBU-Simulation repeated (field test)

(geodata-patch,bugfix by PC-Simulation)

(geodata-patch,bugfix by PC-Simulation)


Pag

e 22

Facts

Manpower for development

• Since October 2002• 36 man-month

Testing facts

• about 70.000 communications• about 135.000 transactions


Pag

e 23

Conclusion

_Complete complex application realized with auto codegeneration using embedded coder

• Efficient code, no coding errors• Application knowledge instead of coding skills

_Simulation and Implementation with the same model• High level debugging feature• Fast prove of algorithm changes

_MatLab environment enables application-depended customized toolset for testing and analysis

• Geofile check• GPS data conversions (e.g.NMEA mat)• Parse telegrams and files• Data visualization


Pag

e 24

ToDo‘s TMW

_sequence of block initialization_enabled & triggered subsystem loses first trigger event_enabled subsystem with reset also reset trigger output_nested for-subsystems_split up c-code in files without the use of atomic subsystems_use of model- and file-dependencies instead of complete

rebuilt (incremental built)_busses as inputs ins Stateflow_Stateflow parsing, when additional header files included _ Including header files on chart-basis instead of model-wide


Pag

e 25

Demonstration

1290

1

43

29/42

7

44

45

46

6

5

4

32A

2

27

28

VG1_LR_N 6004 VG1_LR_S

6003 VG2_LR_N

6006 VG2_LR_S

6005

VG_Wood_W / 6010

VG_WR_N / 6008VG_WR_S / 6007

VG_A639 6009

City_Zone 6001

VG_M621_N 6014

VG_Belle_N 6012

Belle_Isle 6000

Rothwell 6002

769

773

770

781

788

782

774791

795

792

794

811

799

798

1381

1382

1291

820

821

830

831

843

8131292

812

772

771

761

© Vodafone 2003 Confidential - MathWorks · © Vodafone 2003 Confidential Version XX Model based...

Documents

Transcript of © Vodafone 2003 Confidential - MathWorks · © Vodafone 2003 Confidential Version XX Model based...