Download - © Vodafone 2003 Confidential - MathWorks · © Vodafone 2003 Confidential Version XX Model based development of a road usage charging application on an ‘on-board-unit’ (ECU)

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

Download - © Vodafone 2003 Confidential - MathWorks · © Vodafone 2003 Confidential Version XX Model based development of a road usage charging application on an ‘on-board-unit’ (ECU)

Top Related