Openecu User Guide Simulink

User Guide
OpenECU Developer Platform

Sim-API
Release 3.2.0-FS r2022-1
Copyright © 2021 OpenECU

Table of Contents
Foreword .................................................................................................................. xii
1. Disclaimer .................................................................................................... xii
2. Health and Safety information ........................................................................ xii
1. Introduction ............................................................................................................ 1
1.1. Overview ..................................................................................................... 1
1.2. Included in your OpenECU kit ...................................................................... 2
1.2.1. Hardware ......................................................................................... 2
1.2.2. Software — C-API ............................................................................ 2
1.2.3. Software — Simulink API .................................................................. 2
1.2.4. Required Tools ................................................................................. 3
1.3. About MATLAB and Simulink ....................................................................... 3
1.4. Licensed Features ....................................................................................... 3
1.5. OpenECU requirements ............................................................................... 4
1.5.1. Hardware requirements ..................................................................... 4
1.5.2. Software requirements ...................................................................... 4
1.5.3. Assumed knowledge ......................................................................... 4
1.6. General development process ...................................................................... 5
1.7. Co-operational development with Pi .............................................................. 5
1.8. Warnings and safety guidelines .................................................................... 5
1.8.1. Verification of OpenECU by OpenECU ................................................ 6
1.9. Warning ...................................................................................................... 7
1.9.1. Personal safety ................................................................................. 7
2. Installation ............................................................................................................. 8
2.1. Introduction ................................................................................................. 8
2.1.1. Third party tool requirements ............................................................. 8
2.1.2. Third party tool requirements — C-API ............................................... 8
2.1.3. Third party tool requirements — Simulink-API ..................................... 8
2.1.4. Third party tool requirements — installation ........................................ 9
2.1.5. Third party tool requirements — compatibility .................................... 10
2.2. Installing OpenECU ................................................................................... 12
2.3. License setup ............................................................................................ 19
2.3.1. Floating license ............................................................................... 20
2.3.2. Node-locked license ........................................................................ 21
2.4. Removing OpenECU ................................................................................. 21
2.5. Integration notes for third party tools ........................................................... 23
2.5.1. Microsoft Windows 10 ..................................................................... 23
2.5.2. MATLAB ......................................................................................... 23
2.5.3. PiSnoop ......................................................................................... 24
2.5.4. ATI Vision ...................................................................................... 24
2.5.5. ETAS INCA calibration tool .............................................................. 25
2.5.6. Vector CANape ............................................................................... 25
2.5.7. Wind River (Diab) C Compiler v5.9.4.8 (deprecated) .......................... 26
2.5.8. Wind River (Diab) C Compiler v5.9.6.7 ............................................. 26
2.5.9. Python ............................................................................................ 27
3. Quick start ........................................................................................................... 29
3.1. Introduction ............................................................................................... 29
3.2. Installed examples ..................................................................................... 29
3.3. Exercise — Step 1 .................................................................................... 32
3.3.1. Modelling the design ....................................................................... 34
3.3.2. Defining constants and variables ...................................................... 35
3.3.3. Setting block parameters ................................................................. 36
3.3.4. Resource files ................................................................................. 44
3.3.5. Checking the model ........................................................................ 46
3.3.6. Running the model simulation .......................................................... 48
3.3.7. Building the model .......................................................................... 48
Copyright 2021, OpenECU ii

User Guide OpenECU Developer
Platform Sim-API
3.3.8. Programming the ECU .................................................................... 48

3.3.9. Playing with the application ............................................................. 50
4. Software overview ................................................................................................ 51
4.1. How to find OpenECU ............................................................................... 52
4.1.1. In Windows .................................................................................... 52
4.1.2. In MATLAB — After installation ........................................................ 52
4.1.3. In MATLAB — Help (R2015b) .......................................................... 53
4.1.4. In MATLAB — Help (R2016a and newer) ......................................... 53
4.1.5. In MATLAB — Library browser (R2013a and newer) .......................... 54
4.1.6. In MATLAB — Command line (all versions) ...................................... 54
4.2. Introduction to OpenECU ........................................................................... 55
4.2.1. Working with OpenECU ................................................................... 55
4.2.2. Create model .................................................................................. 56
4.2.3. Update model ................................................................................. 66
4.2.4. Simulate model ............................................................................... 67
4.2.5. Build model .................................................................................... 67
4.2.6. Program ECU with model ................................................................ 67
4.2.7. Test model ..................................................................................... 69
4.3. Simulink and OpenECU ............................................................................. 69
4.3.1. Block use restrictions ...................................................................... 70
4.3.2. Auto-coders .................................................................................... 71
4.3.3. Configuration sets ........................................................................... 71
4.3.4. Configuration options ...................................................................... 72
4.3.5. Selecting an auto-coder ................................................................... 77
4.3.6. Building a model ............................................................................. 79
4.4. System modes .......................................................................................... 84
4.4.1. Boot mode ...................................................................................... 85
4.4.2. Reprogramming mode ..................................................................... 85
4.4.3. Application mode ............................................................................ 85
4.5. Programming an ECU ................................................................................ 86
4.6. OpenECU blockset features ....................................................................... 90
4.6.1. Calibration tool support ................................................................... 91
4.6.2. Adaptive parameters ....................................................................... 91
4.6.3. Communications ............................................................................. 92
4.6.4. Compiler options ............................................................................. 94
4.6.5. Deprecated blocks .......................................................................... 94
4.6.6. Fault support .................................................................................. 94
4.6.7. PID support .................................................................................... 95
4.6.8. Freeze Frame support ..................................................................... 95
4.6.9. Service $09 InfoType support .......................................................... 95
4.6.10. IUPR support ................................................................................ 95
4.6.11. Analogue and digital inputs ............................................................ 95
4.6.12. Operating system .......................................................................... 97
4.6.13. Analogue and digital outputs .......................................................... 98
4.6.14. Real-Time Workshop (RTW) support .............................................. 99
4.6.15. Target ECU identification and configuration ..................................... 99
4.6.16. Timing .......................................................................................... 99
4.6.17. Utilities ......................................................................................... 99
4.6.18. Versioning ................................................................................... 100
4.7. Adapting an existing model for OpenECU .................................................. 100
4.8. Migrating between versions of Simulink ..................................................... 122
5. Design and modelling ......................................................................................... 123
5.1. Introduction .............................................................................................. 123
5.2. Design rules and guidelines ..................................................................... 123
5.2.1. Sampling rate rules ....................................................................... 123
5.2.2. Data storage rules ......................................................................... 124
5.2.3. Block properties ............................................................................ 124
5.2.4. Model appearance ........................................................................ 125
Copyright 2021, OpenECU iii

Platform Sim-API
5.2.5. Naming rules ................................................................................ 125

5.2.6. Logical operations ......................................................................... 127
5.2.7. Data type conversion ..................................................................... 129
6. Software detail ................................................................................................... 132
6.1. OpenECU blockset .................................................................................. 134
6.1.1. 1-d calibration map look-up and interpolation (put_Calmap1d) .......... 134
6.1.2. 2-d calibration map look-up and interpolation (put_Calmap2d) .......... 137
6.1.3. Application build date (psc_AppBuildDate) ...................................... 140
6.1.4. Application version (psc_AppVersion) ............................................. 141
6.1.5. Analogue input — basic (pai_BasicAnalogInput) .............................. 143
6.1.6. Analogue input — processed (pai_AnalogInput) .............................. 144
6.1.7. Build model (prtw_Build) ................................................................ 151
6.1.8. Boot code build date (psc_BootBuildDate) ...................................... 151
6.1.9. Boot code version (psc_BootVersion) ............................................. 153
6.1.10. Boot code part number (psc_BootPartNumber) .............................. 154
6.1.11. CAN bus status (pcx_BusStatus) .................................................. 156
6.1.12. CAN configuration (pcx_CANConfiguration) ................................... 158
6.1.13. CAN Baud Override (pcx_CANBaudOverride) ............................... 159
6.1.14. CAN receive message (pcx_CANReceiveMessage) ....................... 161
6.1.15. CAN transmit message (pcx_CANTransmitMessage) ..................... 166
6.1.16. CANdb message receive (pcx_CANdb_ReceiveMessage) .............. 170
6.1.17. CANdb transmit message (pcx_CANdb_TransmitMessage) ............ 175
6.1.18. CAN status — deprecated (pcx_CANStatus) ................................. 180
6.1.19. CCP configuration (pcp_CCPConfiguration) .................................. 181
6.1.20. CCP raster configuration (pcp_RasterConfig) ................................ 185
6.1.21. CCP seed/key security (pcp_CCPSecurity) ................................... 187
6.1.22. CCP inhibit reprogramming (pcp_CCPInhibitReprogramming) ......... 191
6.1.23. CCP CRO receive count (pcp_CCPRxCount) ................................ 192
6.1.24. Compiler options (pcomp_CompileOptions) ................................... 193
6.1.25. Configure auto-coder (RTW EC) (prtw_ConfigUsingRtwEc) ............ 198
6.1.26. Configure auto-coder (RTW RTMODEL)
(prtw_ConfigUsingRtwRtmodel) ............................................................... 199
6.1.27. Configuration M5xx (pcfg_Config_M5xx) ....................................... 199
6.1.28. Debounce (put_Debounce) .......................................................... 203
6.1.29. DTC clear all (pdtc_ClearAll) ........................................................ 205
6.1.30. DTC clear all if active (pdtc_ClearAllIfActive) ................................. 206
6.1.31. DTC clear all if inactive (pdtc_ClearAllIfInactive) ............................ 207
6.1.32. DTC diagnostic trouble code (pdtc_DiagnosticTroubleCode) ........... 208
6.1.33. DTC enable periodic lamp updates
(pdtc_EnablePeriodicLampUpdates) ......................................................... 212
6.1.34. DTC memory update (pdtc_Memory) ............................................ 213
6.1.35. DTC table definition (pdtc_Table) ................................................. 215
6.1.36. Digital input (pdx_DigitalInput) ...................................................... 216
6.1.37. Digital output (pdx_DigitalOutput) ................................................. 218
6.1.38. Digital output monitor (pdx_Monitor) ............................................. 220
6.1.39. Digital data input (pdd_DataInput) ................................................ 223
6.1.40. Digital data output (pdd_DataOutput) ............................................ 225
6.1.41. Fault check (put_FaultCheck) ....................................................... 226
6.1.42. Frequency input (pdx_FrequencyInput) ......................................... 227
6.1.43. H-Bridge output (pdx_HBridgeOutput) ........................................... 230
6.1.44. J1939 configuration (pj1939_Configuration) ................................... 233
6.1.45. J1939 channel configuration (pj1939_ChannelConfiguration) .......... 235
6.1.46. J1939 DM1 receive (pj1939_Dm1Receive) .................................... 237
6.1.47. J1939 DM1 decode DTC (pj1939_Dm1DecodeDtc) ........................ 241
6.1.48. J1939 DM1 transmit (pj1939_Dm1Transmit) .................................. 243
Copyright 2021, OpenECU iv

Platform Sim-API
6.1.52. J1939 parameter group receive message (pj1939_PgReceive) ....... 253

6.1.53. J1939 parameter group requested (pj1939_PgRequested) ............. 260
6.1.54. J1939 parameter group transmit (pj1939_PgTransmit) ................... 263
6.1.55. Link options (pcomp_LinkOptions) ................................................ 267
6.1.56. Memory configuration (pmem_MemoryConfiguration) ..................... 270
6.1.57. Model identification (put_Identification) .......................................... 271
6.1.58. Non-volatile adaptive check-sum (pnv_AdaptiveChecksum) ............ 275
6.1.59. Non-volatile adaptive 1-d map look-up (pnv_AdaptiveMap1d) .......... 276
6.1.60. Non-volatile adaptive 2-d map look-up (pnv_AdaptiveMap2d) .......... 280
6.1.61. Non-volatile adaptive scalar (pnv_AdaptiveScalar) ......................... 284
6.1.62. Non-volatile adaptive array (pnv_Array) ........................................ 286
6.1.63. Non-volatile memory status (pnv_Status) ...................................... 289
6.1.64. Non-volatile file system access (pnv_File) ..................................... 291
6.1.65. Non-volatile filesystem flush (pnv_FileFlush) ................................. 294
6.1.66. Non-volatile file information (pnv_FileStats) ................................... 295
6.1.67. Non-volatile filesystem information (pnv_FilesystemInfo) ................ 298
6.1.68. Internal RAM test error (psc_InternalRamTestError) ....................... 300
6.1.69. Internal RAM test progress (psc_InternalRamTestProgress) ........... 301
6.1.70. Internal ROM test error (psc_InternalRomTestError) ...................... 303
6.1.71. Internal ROM test progress (psc_InternalRomTestProgress) ........... 305
6.1.72. Platform code build date (psc_PlatformBuildDate) .......................... 306
6.1.73. Platform code version (psc_PlatformVersion) ................................. 308
6.1.74. Platform code part number (psc_PlatformPartNumber) ................... 309
6.1.75. Processor loading (psc_CpuLoading) ............................................ 311
6.1.76. PWM input measurement (pdx_PwmInput) .................................... 313
6.1.77. PWM output — fixed frequency (pdx_PWMOutput) ........................ 318
6.1.78. PWM output — variable frequency
(pdx_PWMVariableFrequencyOutput) ...................................................... 322
6.1.79. Range check (put_RangeCheck) .................................................. 326
6.1.80. Reset module (put_Reset) ........................................................... 326
6.1.81. Reset count — stable (psc_ResetCount) ....................................... 328
6.1.82. Reset count — unstable (psc_UnstableResetCount) ...................... 330
6.1.83. Reprogramming code build date (psc_PrgBuildDate) ...................... 331
6.1.84. Reprogramming code version (psc_PrgVersion) ............................ 333
6.1.85. Reprogramming code part number (psc_PrgPartNumber) ............... 334
6.1.86. Retrieve registry key (preg_RetrieveKey) ...................................... 336
6.1.87. Require platform version (put_RequirePlatformVersion) .................. 344
6.1.88. Show Simulink's sample time colours
(prtw_ShowSampleTimeColours) ............................................................. 346
6.1.89. Secondary micro receive message (psmc_ReceiveMessage) .......... 346
6.1.90. Secondary micro transmit message (psmc_TransmitMessage) ........ 348
6.1.91. Signal gap detection (put_SignalGapDetection) ............................. 349
6.1.92. Signal prepare — deprecated (put_SignalPrepare) ........................ 351
6.1.93. Signal validate (put_SignalValidate) .............................................. 353
6.1.94. Slew rate check (put_SlewRateCheck) .......................................... 358
6.1.95. SPI communication fault count (psp_FaultCount) ........................... 359
6.1.96. Stack used (psc_StackUsed) ....................................................... 360
6.1.97. Task duration (pkn_TaskDuration) ................................................ 362
6.1.98. Task period overrun (pkn_TaskPeriodOverrun) .............................. 364
6.1.99. Time (real) (ptm_RealTime) ......................................................... 366
6.1.100. Time (Simulink) (ptm_SimulinkTime) ........................................... 368
6.1.101. Watchdog kick (psc_KickWatchdog) ............................................ 371
6.1.102. Vehicle to grid communication - Protocol Handshake
(pv2g_Protocol_Handshake_Message) .................................................... 372
6.1.103. Vehicle to grid communication - DIN 70121 (pv2g_DIN_Message)
............................................................................................................... 377
6.1.104. Vehicle to grid communication - ISO 15118 v1
(pv2g_ISO_15118_V1_Message) ............................................................. 400
Copyright 2021, OpenECU v

Platform Sim-API

(pv2g_ISO_15118_V2_Message) ............................................................. 432
6.1.106. Vehicle to grid connection management (pv2g_Connection) .......... 475
6.1.107. Vehicle to grid connection information (pv2g_Link_Info) ................ 476
6.2. Automatic ASAP2 entries ......................................................................... 479
6.2.1. Boot build information .................................................................... 479
6.2.2. Reprogramming build information ................................................... 480
6.2.3. Platform build information .............................................................. 480
6.2.4. Application build information .......................................................... 481
6.2.5. Application and library task timing information ................................. 482
6.2.6. Memory use information ................................................................ 485
6.2.7. Memory error correction events ...................................................... 486
6.2.8. Floating point conditions ................................................................ 486
6.2.9. J1939 related information .............................................................. 487
6.2.10. Engine related information ........................................................... 488
6.3. OpenECU software versioning .................................................................. 488
6.4. OpenECU commands .............................................................................. 488
6.4.1. Documentation .............................................................................. 488
6.4.2. Blockset ........................................................................................ 490
6.4.3. Model and build list actions ............................................................ 492
6.4.4. Model configuration and build ........................................................ 496
6.4.5. Change versions of OpenECU ....................................................... 502
6.4.6. Supporting tools ............................................................................ 504
7. Extended diagnostics functions ........................................................................... 506
7.1. Introduction to Diagnostics ....................................................................... 507
7.2. Diagnostic Legislation .............................................................................. 508
7.3. Approach ................................................................................................. 510
7.4. Diagnostic trouble codes and freeze-frames .............................................. 511
7.5. Diagnostic monitors, tests and performance ratios ...................................... 512
7.6. Worked example — building a diagnostic system ....................................... 513
7.6.1. Step 1 — test conditions at the monitor level ................................... 513
7.6.2. Step 2 — individual flow tests ........................................................ 514
7.6.3. Step 3 — general NVM storage and other blocks ............................ 514
7.6.4. J1979/ISO 15031 scan tool request/response ................................. 515
7.6.5. J1939 scan tool request/response .................................................. 518
7.7. Extended diagnostic Simulink blocks ......................................................... 518
7.7.1. Calibration verification number (CVN) (psc_CvnCalc) ....................... 518
7.7.2. DTC clear all (pdtc_ClearAll) .......................................................... 520
7.7.3. DTC clear all if active (pdtc_ClearAllIfActive) ................................... 520
7.7.4. DTC clear all if inactive (pdtc_ClearAllIfInactive) .............................. 520
7.7.5. DTC match and clear (pdtc_ClearDtcs) ........................................... 520
7.7.6. DTC control (pdtc_Control) ............................................................ 523
7.7.7. DTC diagnostic trouble code (extended)
(pdtc_DiagnosticTroubleCodeExt) ............................................................ 524
7.7.8. DTC lamp states (pdtc_Status) ...................................................... 534
7.7.9. DTC match exists (pdtc_MatchExists) ............................................. 537
7.7.10. DTC memory update (pdtc_Memory) ............................................ 539
7.7.11. DTC table definition (pdtc_Table) ................................................. 539
7.7.12. DTC table cleared indication (pdtc_TableCleared) .......................... 539
7.7.13. ISO configuration (piso_Configuration) .......................................... 541
7.7.14. ISO security permissions (pdg_Permissions) ................................. 546
7.7.15. ISO DTC extended data records (pdg_ExtendedDataRecord) ......... 550
7.7.16. Routine control (pdg_RoutineControl) ........................................... 553
7.7.17. Parameter identifier (ppid_Pid) ..................................................... 558
7.7.18. Parameter identifier scaling (ppid_Scaling) .................................... 563
7.7.19. Freeze frame (pff_FreezeFrame) .................................................. 565
7.7.20. DM25 freeze frame (pff_Dm25FreezeFrame) ................................. 569
7.7.21. Freeze frame configuration (pff_Configuration) .............................. 570
Copyright 2021, OpenECU vi

Platform Sim-API
7.7.22. J1939 configuration (pj1939_Configuration) ................................... 572

7.7.23. J1939 channel configuration (pj1939_ChannelConfiguration) .......... 572
7.7.24. J1939 Transmit DTC DM (pj1939_TransmitDtcDm) ........................ 573
7.7.33. J1939 DM7 decode (pj1939_Dm7Decode) .................................... 580
7.7.35. J1939 DM10 transmit (pj1939_Dm10Transmit) .............................. 584
7.7.51. J1939 parameter group receive message (pj1939_PgReceive) ....... 618
7.7.52. J1939 parameter group requested (pj1939_PgRequested) ............. 619
7.7.53. J1939 parameter group transmit (pj1939_PgTransmit) ................... 619
7.7.54. J1939 send acknowledgement message (pj1939_SendAck) ........... 619
7.7.55. J1939 update NTE status (pj1939_UpdateNteStatus) ..................... 620
7.7.56. J1979 service $09 Infotype input (pdg_InfotypeInput) ..................... 621
7.7.57. Diagnostic monitor entity (ppr_DiagnosticMonitorEntity) .................. 623
7.7.58. Diagnostic test entity (ppr_DiagnosticTestEntity) ............................ 628
7.7.59. General denominator (ppr_GeneralDenominator) ........................... 634
7.7.60. Ignition cycle (ppr_IgnitionCycle) .................................................. 635
7.7.61. PPR memory update (ppr_Memory) .............................................. 636
7.7.62. Monitors incomplete count (ppr_MonitorsIncomplete) ..................... 637
A. Reference documentation ................................................................................... 639
A.1. ECU hardware reference documentation ................................................... 639
B. Supporting tools ................................................................................................. 640
B.1. Introduction ............................................................................................. 640
B.2. PiSnoop .................................................................................................. 640
B.2.1. Example Screenshots ................................................................... 641
B.3. ATI Vision ............................................................................................... 642
B.3.1. Creating a new project and strategy in ATI Vision ........................... 642
B.3.2. Downloading an application with an ATI Vision strategy ................... 649
B.3.3. Configuring two OpenECUs on the same CAN bus with ATI Vision... 653
B.3.4. Configuring CCP seed/key security with ATI Vision ......................... 656
B.4. ETAS INCA ............................................................................................. 656
B.5. Vector CANape ....................................................................................... 666
B.5.1. Configuring CCP seed/key security with Vector CANape .................. 673
B.6. FreeCCP ................................................................................................. 674
B.6.1. Programming an OpenECU ........................................................... 674
B.6.2. Choosing the CAN card device (Kvaser) ........................................ 674
Copyright 2021, OpenECU vii

Platform Sim-API
B.6.3. Choosing the CAN card device (Vector) ......................................... 674

B.6.4. Choosing the CCP settings ........................................................... 675
B.6.5. Checking that the OpenECU device is active .................................. 675
C. Examples .......................................................................................................... 676
C.1. Introduction ............................................................................................. 676
C.2. Custom C code ....................................................................................... 676
C.2.1. Introduction .................................................................................. 676
C.2.2. Procedure .................................................................................... 676
D. Memory configurations ....................................................................................... 682
E. ASAP2 compliance ............................................................................................. 683
F. CCP compliance ................................................................................................ 684
F.1. EXCHANGE_ID message handling ........................................................... 685
G. CCP troubleshooting guide ................................................................................. 688
G.1. Anatomy of an ATI Hub ........................................................................... 688
G.2. No communication between PC and ATI Hub ............................................ 689
G.2.1. Symptoms .................................................................................... 689
G.2.2. Possible causes ........................................................................... 689
G.3. No communication between PC and OpenECU ......................................... 690
G.3.1. Symptoms .................................................................................... 690
G.3.2. Possible causes ........................................................................... 690
H. Data dictionary tool errors .................................................................................. 695
H.1. Command line option messages .............................................................. 695
H.2. File handling messages ........................................................................... 698
H.3. ASAP2 generation messages ................................................................... 699
H.4. Automatic DDE generation messages ....................................................... 703
H.5. Interface file messages ............................................................................ 703
H.6. DDE processing messages ...................................................................... 705
H.7. Code generation messages ..................................................................... 720
H.8. ELF to DDE generation messages ........................................................... 734
H.9. Data type checks between ELF and DDE messages .................................. 735
I. Change log ......................................................................................................... 736
I.1. ................................................................................................................ 736
J. Glossary of terms ............................................................................................... 746
K. Contact information ............................................................................................ 748
Copyright 2021, OpenECU viii

List of Figures
3.1. OpenECU integrated with MATLAB's launch pad ................................................. 29
3.2. Quick start loom ................................................................................................ 33
3.3. Connected quick start model .............................................................................. 35
3.4. Analogue input transfer function ......................................................................... 42
3.5. Configured quick start model .............................................................................. 44
3.6. Updated quick start model ................................................................................. 46
4.1. OpenECU integrated with Window's Start button ................................................. 52
4.2. OpenECU integrated with MATLAB's help system (R2015b) ................................. 53
4.3. OpenECU integrated with MATLAB's help system (R2016a and newer) ................. 53
4.4. OpenECU integrated with MATLAB's library browser (R2013a and newer) ............. 54
4.5. Example development pattern for modelling an application ................................... 55
4.6. Breaking the input and output processing from the application .............................. 66
4.7. Simulink's Model Explorer showing OpenECU configuration sets ........................... 72
4.8. Building an application (in outline) ...................................................................... 79
4.9. System modes .................................................................................................. 84
4.10. System modes for M560 and M580 .................................................................. 88
4.11. Signal update rates .......................................................................................... 96
4.12. Signal update rates .......................................................................................... 98
6.1. J1939 DTC states ............................................................................................ 209
6.2. Output of H-Bridge during mode transition ......................................................... 231
6.3. Example time-line to explain the ptm_RealTime block ........................................ 367
6.4. Example time-line to explain the ptm_SimulinkTime block ................................... 369
7.1. Functional Levels within a Diagnostics System .................................................. 508
7.2. Scan tool link via platform ................................................................................ 511
7.3. Use of PID blocks to collect data ...................................................................... 512
7.4. Building a diagnostic system — monitor level .................................................... 514
7.5. Building a diagnostic system — individual test ................................................... 514
7.6. Building a diagnostic system — warning lamps .................................................. 515
7.7. Building a diagnostic system — generic counters ............................................... 515
7.8. J1939 request/response example ..................................................................... 518
7.9. Platform OBD state machine - no transitions between Previously Active and
Pending ................................................................................................................. 526
7.10. Platform OBD state machine - transitions between Previously Active and
Pending ................................................................................................................. 526
7.11. Freeze frame capture and deletion .................................................................. 566
Copyright 2021, OpenECU ix

List of Tables
2.1. Install components ............................................................................................. 15
3.1. Step1 - model identification block parameters ...................................................... 37
3.2. Step1 - CAN configuration block parameters ....................................................... 39
3.3. Step1 - CCP configuration block parameters ....................................................... 39
3.4. Step1 - analogue input block parameters ............................................................ 41
3.5. Step1 - PWM output block parameters ................................................................ 43
3.6. Simulink model colouring ................................................................................... 47
3.7. FEPS voltages .................................................................................................. 50
4.1. Standard MATLAB commands ........................................................................... 54
4.2. Data dictionary columns ..................................................................................... 58
4.3. Simulink data dictionary object properties ............................................................ 62
4.4. Simulink data dictionary object storage classes ................................................... 64
4.5. FEPS voltages .................................................................................................. 69
4.6. ASAP2 naming schemes ................................................................................... 74
4.7. FEPS voltages .................................................................................................. 89
4.8. Model Configuration Parameters for R2015b ..................................................... 101
4.9. Model Configuration Parameters for R2016a or R2016b ..................................... 103
4.10. Model Configuration Parameters for R2017a or R2017b ................................... 106
4.11. Model Configuration Parameters for R2018a and R2018b ................................. 109
4.12. Model Configuration Parameters for R2020a .................................................... 111
4.13. Model simulation settings for R2021b .............................................................. 114
5.1. Variable naming convention ............................................................................. 126
5.2. 1-d map lookup naming convention .................................................................. 127
5.3. 2-d map lookup naming convention .................................................................. 127
6.1. Interval notation ............................................................................................... 134
6.2. CAN block type codes ..................................................................................... 164
6.3. CCP defaults ................................................................................................... 185
6.4. Generic pin naming convention ......................................................................... 273
6.5. CAN signal gap error codes ............................................................................. 351
6.6. CAN signal prepare invalid codes. .................................................................... 353
6.7. CAN signal validate error codes. ...................................................................... 356
6.8. Protocol handshake messages ......................................................................... 373
6.9. DIN messages ................................................................................................. 377
6.10. ISO v1 messages .......................................................................................... 400
6.11. ISO v2 messages .......................................................................................... 433
6.12. Automatic ASAP2 entries for boot build information .......................................... 479
6.13. Automatic ASAP2 entries for reprogramming build information (M220, M221,
M250, M460, M461, M550, M670) ........................................................................... 480
6.14. Automatic ASAP2 entries for platform build information .................................... 480
6.15. Automatic ASAP2 entries for application build information ................................. 481
6.16. Automatic ASAP2 entries for application rate task timing information .................. 482
6.17. Automatic ASAP2 entries for auxiliary task timing information ............................ 483
6.18. Automatic ASAP2 entries for CPU loading information ...................................... 483
6.19. Automatic ASAP2 entries for eTPU loading information .................................... 484
6.20. Automatic ASAP2 entries for maximum application rate task timing information... 484
6.21. Automatic ASAP2 entries for run-time information ............................................ 485
6.22. Automatic ASAP2 entries for reset information (M110, M220, M250, M460,
M461) .................................................................................................................... 485
6.23. Automatic ASAP2 entries for number of instances of period overruns or skips of
periodic tasks ......................................................................................................... 485
6.24. Automatic ASAP2 entries for memory use information ...................................... 485
6.25. Automatic ASAP2 entries for memory error correction events ............................ 486
6.26. Automatic ASAP2 entries for floating point conditions ....................................... 486
6.27. Automatic ASAP2 entries for J1939 related information .................................... 487
6.28. Software component versions (for M560-000) .................................................. 488
Copyright 2021, OpenECU x

Platform Sim-API
7.1. Diagnostic Service Comparisons ....................................................................... 509

7.2. PDG supported services .................................................................................. 515
7.3. DTC initialisation values ................................................................................... 528
7.4. UDS DTCFormatIdentifier options ..................................................................... 545
7.5. RoutineControl request sub-function ................................................................. 555
7.6. InputOutputControl Status (KW2000-3 draft) ...................................................... 559
D.1. Memory configurations supported ..................................................................... 682
F.1. Supported CCP commands .............................................................................. 684
F.2. Supported CCP commands (in older versions of ECUs) ..................................... 685
F.3. Original EXCHANGE_ID message .................................................................... 685
F.4. Modified EXCHANGE_ID message ................................................................... 685
F.5. EXCHANGE_ID selection values ...................................................................... 686
F.6. EXCHANGE_ID manufacturing data key values and binary format ...................... 686
I.1. Release summary for v3.2.0-r2022-1 ................................................................. 736
Copyright 2021, OpenECU xi

Foreword
Before using OpenECU, it is very important to read and understand the warning
and safety information given in Section 1.8, “Warnings and safety guidelines” and in
Section 1.9, “Warning”.
Pi, the Pi logo and OpenECU are trademarks of OpenECU Ltd. Microsoft, Windows,
Excel, Word, MATLAB, Simulink, StateFlow, Vision, CANape and INCA are all registered
trademarks of their respective owners.
1. Disclaimer
OpenECU makes no representation or warranties of any kind whatsoever with respect to
the contents hereof, and specifically disclaims any implied warranties of merchantability or
fitness for any particular purpose. OpenECU shall not be liable for any errors contained
herein, or for incidental or consequential damages in connection with the furnishing,
performance or use of the software, associated hardware, or this written material.
OpenECU reserves the right to revise this publication from time to time, and to make
changes in the content hereof without obligation to notify any person of such revision or
changes.
A copy of the OpenECU Terms and Conditions of Sale is available on request, and includes
a declaration of the warranty and limitation of liability which apply to all OpenECU products
and services.
2. Health and Safety information

Under the terms of European and UK Health and Safety Legislation, OpenECU is required
to classify any hazardous materials in the products it supplies and to provide relevant safety
information to users.
Any hazardous materials in Pi products are clearly marked with appropriate symbols. Product
Safety Data Sheets relating to these materials are available on request.
Copyright 2021, OpenECU xii

Chapter 1. Introduction
1.1. Overview ............................................................................................................. 1
1.2. Included in your OpenECU kit .............................................................................. 2
1.2.1. Hardware ................................................................................................. 2
1.2.2. Software — C-API .................................................................................... 2
1.2.3. Software — Simulink API .......................................................................... 2
1.2.4. Required Tools ......................................................................................... 3
1.3. About MATLAB and Simulink ............................................................................... 3
1.4. Licensed Features ............................................................................................... 3
1.5. OpenECU requirements ....................................................................................... 4
1.5.1. Hardware requirements ............................................................................. 4
1.5.2. Software requirements .............................................................................. 4
1.5.3. Assumed knowledge ................................................................................. 4
1.6. General development process .............................................................................. 5
1.7. Co-operational development with Pi ...................................................................... 5
1.8. Warnings and safety guidelines ............................................................................ 5
1.8.1. Verification of OpenECU by OpenECU ........................................................ 6
1.9. Warning .............................................................................................................. 7
1.9.1. Personal safety ......................................................................................... 7
1.1. Overview
Thank you for choosing Pi Innovo's OpenECU platform.
Pi Innovo's OpenECU platform offers a new solution to engine and vehicle control system
development. Based on Pi's extensive experience of ECU development, and backed by Pi's
unrivalled capabilities in project and customer support, OpenECU helps you get quickly to
what you need: working, robust control systems.
By using production ECU hardware as an auto-code platform, you gain all the advantages
of auto-coding and rapid prototyping, but with hardware that meets full production
environmental and packaging requirements (see Section A.1, “ECU hardware reference
documentation” for environmental and packaging details).
The OpenECU system consists of:
• a range of production ECU hardware modules — some have support for engines with up
to 8 cylinders (or more with multiple modules);
• an optional range of tested engine and vehicle control strategies, from individual functional
blocks to complete strategy suites;
• a comprehensive range of support and consultancy services, ranging from sensor selection
and system design advice through to complete bespoke system development.
Applications of the OpenECU platform include:
• engine control system development;
• chassis control system development;
• after treatment control system development;
• transmission control system development;
• hybrid powertrain control system development;
• vehicle fleet trials.
Copyright 2021, OpenECU 1

Introduction
For support contact information, please see the last page of this manual.
1.2. Included in your OpenECU kit

There are several OpenECU packages available from Pi, which can include the following
items.
1.2.1. Hardware
The following items of hardware are available as part of OpenECU:
Electronic Control Unit (ECU)

This is the computer that monitors and controls all aspects of the electronic system's
behaviour. The image built from your application is programmed into the ECU. There
are four different models of ECU currently available — 4 in-line cylinder and V8 cylinder,
in both development and fleet models (see Section A.1, “ECU hardware reference
documentation” for further details).
Connectors
All the connectors and terminals required to connect the ECU, the calibration tool and
your PC together.
Tools
You will require an appropriate crimping tool for the ECU connectors. OpenECU will
give you details on request.
1.2.2. Software — C-API

The following items of software are available as part of the OpenECU C-API:
OpenECU C Application Programming Interface (API)

A documented C-API to the OpenECU library which allows control of the ECU from an
application. The C-API broadly provides the same functionality as the OpenECU Simulink
blockset.
1.2.3. Software — Simulink API

The following items of software are available as part of the OpenECU Simulink API:
Complete OpenECU strategy suites (optional)

These are complete Simulink models that simulate all the control functionality of an entire
engine or other dynamic system. Complete strategies comprise many levels of design
and modelling, and are the product of many years of design research and testing at
OpenECU Complete strategies are available for petrol (I4 and V8 cylinder) systems.
OpenECU Simulink strategies (optional)

These are complete Simulink models that have been designed to simulate whole blocks
of engine control functionality, such as spark generation, rev limiting, etc. They are the
blocks from which the complete strategy suites (above) are developed. Designed by Pi,
they can be integrated with your own models, and are used in exactly the same way as
all Simulink blocks.
OpenECU Simulink blocks

These functional blocks supplement those that are normally available in Simulink, and
are used to create inputs, outputs and signal processing capabilities for engine-related
functions such as angle calculations, spark timings, etc. They are designed by Pi, and
form the platform for higher-level engine functionality, but are used in exactly the same

Introduction
way as all Simulink blocks. They are the blocks from which the strategies (above) are
developed.
1.2.4. Required Tools

The following software items are required but not provided as part of OpenECU.
Calibration Tool
This electronic tool is used to program the auto-generated code into the ECU, and to
monitor (and, in some cases, alter) the values of certain parameters while the ECU is
running. Pi's own PiSnoop product is one option, along with several industry-standard
alternatives, and we will be able to recommend a suitable product on request.
Compiler
A tool which takes the Simulink generated code representing the graphical model and
turns it into an executable image that can be run on OpenECU hardware.
1.3. About MATLAB and Simulink

Simulink is a powerful simulation and analysis software engine which is used throughout
academia and industry to develop and analyse dynamic systems.
Simulink is a widely used software package for modelling, simulating and analysing dynamic
systems, which is based upon the MATLAB software engine. It allows you to build graphical
models of linear and non-linear systems, using a simple drag-and-drop interface and a library
of functional blocks. You can then simulate your model under dynamic running conditions
to analyse its behaviour, and continuously interact with the parameters while the simulation
is running.
Many functional blocks are included in the standard Simulink library, allowing you to model
any system whose dynamics you want to simulate. This library is supplemented by Pi's
OpenECU blocks, which are specialised for use with the OpenECU platform.
1.4. Licensed Features

OpenECU allows for several different options enabling different features. The licensing
system retains control of the ability to use these features depending on what the customer
has purchased.
The current set of available features is:
• OPENECU
The main feature. Enabled when you purchase any version of OpenECU
• CAPI_BUILD
Allows for building OpenECU applications with the C-API. This feature is also a prerequisite
for SIMULINK_BUILD.
• SIMULINK_SIMULATE
Allows for simulation of OpenECU models in Simulink. This feature is also a prerequisite
for SIMULINK_BUILD.
• SIMULINK_BUILD
Allows for building OpenECU models with the Sim-API. Because the Sim-API wraps the
C-API, both features are required to build OpenECU Simulink models

Introduction
• EXT_DIAG
Extended diagnostics features.
• Allows use of the Extended diagnostics blockset in Simulink models.
• Allows use of the Extended diagnostics library functions at run time in OpenECU
applications
See Chapter 7, Extended diagnostics functions.
1.5. OpenECU requirements

To make the best use of OpenECU, certain hardware, software and knowledge requirements
need to be fulfilled, as described below.
1.5.1. Hardware requirements

To run the Pi OpenECU software, you will need an IBM-compatible PC with the minimum
specifications listed below.
• CPU: a modern Intel or AMD x86 32-bit or 64-bit processor.

• RAM: 2 GiB minimum, but more recommended (larger applications will require more RAM).
• Free hard disk space: 2 GiB.
Either the physical system or a system simulator is ultimately required to test and calibrate
your ECU and the system model you have created to run on it. A suitable Calibration/
reprogramming communications tool is also required conforming to the ASAP2 standard.
1.5.2. Software requirements

You will need the following software pre-installed on your PC:
• Operating system: Microsoft Windows 10
• MathWorks: MATLAB and Simulink (and optionally, Stateflow and Stateflow Coder).
• MathWorks: Simulink Coder (formerly Real-Time Workshop) versions:
• Compiler: Wind River Diab Only the C language version is required (note, C++ is not yet
supported).
• Calibration tool: PiSnoop, ATI Vision™, ETAS INCA, or Vector CANape.
Note
See OpenECU Compatibility with Third Party Tools for a complete list of compatible
versions of each tool.
1.5.3. Assumed knowledge

This manual describes how to incorporate the OpenECU development platform provided by
OpenECU into your own designs. It does not include a tutorial about C, embedded systems,
MATLAB or Simulink.
A working knowledge of design modelling and system dynamics principles in an engineering

environment is required to make the best use of OpenECU and its associated tools.

Introduction
Ultimately, it is the quality of your own system designs that will be reflected in the quality of
your system control strategy.
Note also that there are serious hardware and personal safety considerations involved in
developing automotive control systems. Please make sure that you read and understand the
notes given in Section 1.8, “Warnings and safety guidelines” to reduce the chance of any
such hazards.
1.6. General development process

The OpenECU design and build process is comprised of the following steps:
1. Design a model of your system, using Simulink library blocks, and optionally those blocks
that OpenECU has developed and included for the OpenECU platform. If you have
purchased a complete engine strategy suite, this will have been done for you. This process
will typically have many cycles of design and HIL (hardware-in-loop) testing.
2. Once you are satisfied that your model simulation functions within your design parameters,
the C code can be auto-generated from Simulink.
3. The C code is passed to the compiler, which generates the executable for the ECU
operating system. This is then programmed into the ECU using the Calibration Tool.
4. The ECU is then connected to either the physical system or a system simulator (e.g. Pi
AutoSim). There then follows a cycle of calibration and testing to optimise the model and
its parameters to the particular characteristics of the target system (or simulator). This may
involve returning to the Simulink model to adapt its design.
1.7. Co-operational development with Pi

OpenECU has over 14 years of experience designing powertrain controllers, working
closely with customers to get to the best possible control system solution. Millions of cars
and trucks on the road use Pi-designed engine control.
OpenECU comes with a wide range of options for customer and project support, allowing
you to draw on over 500 man-years of control system design experience. Whichever option
you choose, you can count on real commitment from Pi to provide what you need, and to
go the extra mile.
For contact information, refer to Appendix K, Contact information.
1.8. Warnings and safety guidelines

It is very important to read and understand the following warnings and safety guidelines.
Inappropriate use of the OpenECU system can lead to loss of data, damage to software and
hardware, and possible personal injury if safe vehicle operation is compromised.
The safe operation of OpenECU is the responsibility of the those using it. The level of risk
associated with the user's application must be ascertained and appropriate mitigation devices
used to reduce the potential risks to an acceptable level. These mitigation devices may
include a system 'kill switch', driver training, backup systems and use of the vehicle in safe
environments.
A structured approach to testing is recommended, particularly before the product is used in

environments where it may be in contact with members of the public (e.g. the public highway).
This testing may include HIL, static vehicle system test and/or vehicle test in a test track
environment.

Introduction
OpenECU supplies OpenECU on the basis that:
• The responsibility for ensuring that the use of OpenECU is safe lies with the
customer.
• The customer will include appropriate mitigation devices as identified by the hazard
analysis they perform (such as engine kill switch, back up devices).
• All users must be competent to make appropriate safety judgements.
• The user will read all OpenECU documentation (including this document) to ensure its
safe use.
• Use of OpenECU 3.2.0-FS r2022-1 in a safety-related system must conform to the Safety
Manual for the specific controller hardware.
• OpenECU 3.2.0-FS r2022-1 software has been developed according to ISO 26262 to
support functional safety and can provide a basis for achieving compliance according to
ISO 26262 for selected Hardware and Software versions. Talk to us about how this can
fit into your functional safety system.
OpenECU also strongly recommends that:
• Applications be developed using a process suitable for the application.
• HIL testing be used prior vehicle testing.
• "Off public highway" vehicle testing be performed prior to road testing.
1.8.1. Verification of OpenECU by Pi Innovo

Pi Innovo considers the safety and quality of its products to be of paramount importance.
The integrity of the product can be considered by assessing the three 'components' which
comprise the system.
Systems, rather than software, have a Safety Integrity Level (SIL). The SIL of the customer's
resultant system will have to be assessed and defined by their knowledge of the processes
used to develop all the components (including those supplied by Pi) comprising the complete
system.
1.8.1.1. Hardware
The hardware is a production unit (see Section A.1, “ECU hardware reference
documentation” for module environmental specifications). However different applications will
have different requirements for output monitoring. Those outputs that are selected (by the
customer) to drive safety related outputs should include output monitor circuits. The use of
outputs for critical devices which do not contain a monitor feedback is strongly discouraged.
1.8.1.2. Platform
The platform comprises functionality which allows the high level strategy to operate in the
specific hardware target (electronic box). It includes:
• The operating system (RTOS) to schedule tasks, process interrupts and manage the
internal stack etc..
• The hardware drivers enabling the inputs to be read, and the outputs driven.
• The calibration tool support, CAN support and module reprogramming.

Introduction
For the Simulink API, software is predominantly hand-coded with some additional auto-coded
Simulink models.
The configuration of the platform is the customer's responsibility. It is entirely possible,

through careless configuration, to 'cross wire' inputs or outputs for example. This could, for
example, lead to injector 1 firing when you intended injector 2 to fire. The mis-calibration
of analogue inputs could lead to undesired behaviour such as steering angle or accelerator
pedal position to be mis-calculated.
Documented vehicle prove out tests should mitigate against this leading to severe outcomes.
1.8.1.3. Strategy
The strategy may be developed entirely by the customer, or be a development by the
customer of generic libraries supplied by OpenECU. In either case the integrity of the
resultant strategy model must be the responsibility of the customer.
Pi's generic libraries have been extensively validated via module testing, HIL system testing
and vehicle testing but have not undergone unit testing.
1.9. Warning
The supplied libraries have been validated for a specific application and a specific
hardware set. The user MUST validate the correct function of the strategies in their
application.
1.9.1. Personal safety

The process of testing automotive systems can involve many personal safety hazards
— high-speed machinery, extremely flammable and potentially explosive fuels, and the
possibility of loss of vehicle control is a combination that can be fatal if sensible precautions
are not followed.
As the system designer and tester, it is your responsibility to ensure that your working
practices are specifically designed to minimise or eliminate the possibility of personal injury,
and to incorporate into your designs such fail-safe functionality as is necessary. This includes
the avoidance of certain dynamical situations such as open throttles and other 'positive
feedback' scenarios where control of the system may be lost.

Chapter 2. Installation
2.1. Introduction ......................................................................................................... 8
2.1.1. Third party tool requirements ..................................................................... 8
2.1.2. Third party tool requirements — C-API ....................................................... 8
2.1.3. Third party tool requirements — Simulink-API ............................................. 8
2.1.4. Third party tool requirements — installation ................................................ 9
2.1.5. Third party tool requirements — compatibility ............................................ 10
2.2. Installing OpenECU ........................................................................................... 12
2.3. License setup .................................................................................................... 19
2.3.1. Floating license ....................................................................................... 20
2.3.2. Node-locked license ................................................................................ 21
2.4. Removing OpenECU ......................................................................................... 21
2.5. Integration notes for third party tools ................................................................... 23
2.5.1. Microsoft Windows 10 ............................................................................. 23
2.5.2. MATLAB ................................................................................................. 23
2.5.3. PiSnoop ................................................................................................. 24
2.5.4. ATI Vision .............................................................................................. 24
2.5.5. ETAS INCA calibration tool ..................................................................... 25
2.5.6. Vector CANape ....................................................................................... 25
2.5.7. Wind River (Diab) C Compiler v5.9.4.8 (deprecated) .................................. 26
2.5.8. Wind River (Diab) C Compiler v5.9.6.7 ..................................................... 26
2.5.9. Python .................................................................................................... 27
2.1. Introduction
This chapter describes the installation process for the OpenECU Simulink Blockset package
and its dependencies.
2.1.1. Third party tool requirements

OpenECU developer software has been tested to work with Windows 10.
2.1.2. Third party tool requirements — C-API

For C based development, OpenECU-FS requires one of the following compiler tools:
• Wind River Diab compiler
To program and calibrate an OpenECU with an application, OpenECU integrates with the
following calibration tools. Only one calibration tool is required:
• PiSnoop
• ATI VISION
• ETAS INCA
• Vector CANape
2.1.3. Third party tool requirements — Simulink-API

For Simulink model based development, OpenECU requires (at a minimum) the following
MathWorks tools:

Installation
• MATLAB (base product)
• Simulink (to develop the models)
• Simulink Coder (to generate C code from the models)
• MATLAB Coder (Simulink Coder depends on this)
In addition, if you need to add state diagrams to the model, then you will also need:
• Stateflow (to develop state flow diagrams inside your model) Simulink Coder generates C
code from the state flow diagrams inside your model.
Simulink Coder generates C code which does not lend itself to efficient repeatable testing.
When creating a production version of your product, you may need better control of the
structure of the C code generated from the model to reduce the cost of testing the C code
against any industry standards. Under these circumstances you will also need:
• Embedded Coder (to generate C code from the models)
To compile the generated C code (from either Simulink Coder or Embedded Coder), you will
need one of the following compilers:
To program and calibrate an OpenECU with an application, OpenECU integrates with the
following calibration tools. Only one calibration tool is required:
• PiSnoop
• ATI VISION
• ETAS INCA
• Vector CANape
2.1.4. Third party tool requirements — installation

OpenECU works with a number of applications (both required and optional) supplied by other
companies. If you intend to use OpenECU with one of the following tools, it is best to install
them before OpenECU. The installer will then integrate the OpenECU developer software
with these applications. See OpenECU Compatibility with Third Party Tools for a list of
supported versions.
• MATLAB
• ETAS INCA calibration tool
OpenECU works with a number of other applications, but these need not be installed prior
to the OpenECU developer software.
• Simulink Coder, formerly Real-Time Workshop, (optional)
• Embedded Coder, formerly Real-Time Workshop Embedded Coder, (optional):
• Stateflow
• Wind River (Diab) C compiler

Installation
• PiSnoop
• ATI Vision calibration tool
• Vector CANape calibration tool
2.1.5. Third party tool requirements — compatibility

OpenECU has been tested against the latest versions of each tool listed below. OpenECU
may work with other versions of these applications, but Pi only provides technical support
for the latest version.
Operating system
OpenECU works with the following operating systems.
• Microsoft Windows
Version License Installation and setup Troubleshooting

a
Win 10 Issued by Installation instructions provided No known issues
Microsoft by Microsoft.
No special setup required.
a
OpenECU developer software may not function correctly on encrypted drives. OpenECU developer software must be able to
create files on the host file system. If using an encrypted drive, be sure that permission settings will allow OpenECU to create
files. OpenECU cannot provide support for issues with encrypted drives.
Modeling tools
A modeling tool allows the user to diagrammatically describe their application logic and
control. That tool generates source code which OpenECU automatically builds into an
application using a compiler (next section). OpenECU supports the following modeling tools.
• Mathworks MATLAB/Simulink

R2015b Issued by Installation instructions provided No known issues
(deprecated) Mathworks by Mathworks.
32-bit Setup requires MATLAB's
PATH variable to be adjusted,
R2015b
which the OpenECU installer
(deprecated)
can do for you, see OpenECU
R2016a
Developer Software Installation
(deprecated)
and Release Note.
R2016b
(deprecated)
R2017a
(deprecated)
R2017b
(deprecated)
R2018b
R2020a
R2021b
64-bit
Note
Mathworks by default only gives the "latest" versions of its tools as downloads from
their website, which may not be the qualified version.

Installation
Because of this, you will need to install MATLAB using a ISO image for [Rxxxx]. That
will install the General Release for [Rxxx] without any updates.
Once installed, you will then need to manually update to [Rxxxx] [specific update]
using the installation package on MathWorks.com Only a License Administrator can
download the ISO and the update files.
How do I download a MATLAB ISO archive?
mathworks.com/matlabcentral/answers/101103 [https://www.mathworks.com/
matlabcentral/answers/101103]
How can I download and install a MATLAB Update manually?
mathworks.com/matlabcentral/answers/456448 [https://www.mathworks.com/
matlabcentral/answers/456448]
Compilers
A compiler translates C source code (either written by hand or generated by a modeling tool)
into machine code that runs directly on the ECU.
All OpenECU targets use Freescale PowerPC microcontrollers. The M560 and M580
use an MPC5746C for the primary microcontroller and SPC560P34 for the secondary
microcontroller.
See the Technicical Specification for your target for more information.

v5.9.4.8 Issued by Installation instructions provided Known Defects for Diab v5.9.4.8
(deprecated) Wind River by Wind River.
Setup requires the Window's
PATH environment variable to
be adjusted, or an OpenECU
specific environment variable
to be created, see Integration
notes for Diab v5.9.4.8.
v5.9.6.7 Issued by Installation instructions provided Known Issues for Diab v5.9.6.7
Wind River by Wind River. (and earlier)
Setup requires the Window's
PATH environment variable to
be adjusted, or an OpenECU
specific environment variable
to be created, see Integration
notes for Diab v5.9.6.7.
Programming, Data Logging, and Calibration Tools
OpenECU requires a tool to program (or “Flash”) the ECU with the application code from
compilation. Once programmed, the ECU will execute the application. Interaction with the
executing application requires a data logging or calibration tool to read and write information
in the application.
These tools have been tested for reprogramming, data logging, and calibration capabilities.
Some of them have many other features which have not been tested with OpenECU.

Installation
• Pi Snoop

Any Issued by Pi Installation instructions provided No known issues.
by Pi with the tool.
• ATI Vision

v2.5 through Issued by Installation instructions provided OpenECU Developer Software
a
v6.0 ATI by ATI. Installation and Release Note,
“ATI Vision, Known defects”
The following Vision toolkits are
typically used when working
with OpenECU: Data Acquisition
Toolkit, Calibration Toolkit,
Universal ECU Interface
Standard Toolkit, APOLLO
Data Analysis Toolkit, CAN
Interface Toolkit and HORIZON
Scripting/Remote API Toolkit.
In particular, the HORIZON
Scripting/Remote API Toolkit is
required if OpenECU builds are
to generate Vision strategy files
(.vst).
a
The OpenECU method of configuring ATI Vision uses standardised ASAP2 files. As a result, all future versions of Vision are
expected to be backwardly compatible (e.g., version 3.7 and version 4.0 are known to be compatible).
• ETAS INCA

v7.2.7 Issued by Installation instructions provided No known issues.
ETAS by ETAS.
Setup requires INCA to read
the ProF files for OpenECU
for reprogramming purposes,
which the OpenECU installer
can do for you, see OpenECU
Developer Software Installation
and Release Note.
• Vector CANape

v8 through v17.0 Issued by Installation instructions provided No known issues.
Vector by Vector.
2.2. Installing OpenECU

The installer program, openecu_platform_3_2_0_FS_r2022-1.exe, installs all the
necessary files for the OpenECU platform. This file can be obtained from the Pi Document
and Download Center web page [http://www.OpenECU.com/downloads].

Installation
The installation process for the OpenECU developer software is performed by a wizard. To
run the wizard, execute the appropriate installer program. The installation can be stopped at
any point by selecting the Cancel button.
The installer requires that the user has administrative rights to make changes on the
computer. If a user without rights is trying to execute the installer a dialog box will be
displayed and the installation stops. Login with an administrator account or contact your
network administrator and try again.
If a version of an OpenECU installer is already running, a dialog box will appear saying so.
Select OK (which stops the current installer) and change to the other OpenECU installer to
continue.
If a version of MATLAB is running, a dialog box will appear saying so. Quit all instances of
MATLAB, then select OK to continue installation.
The installation process starts with an introduction. Select Next to continue.

Installation
The next windows to appear present the license agreement for using OpenECU developer
software and related software. Read the license agreements and if acceptable, select I accept
the terms of the License Agreement and then Next. If not acceptable, do not install the
software.
The next window to appear provides a number of components that can be installed or
patched.

Installation
The following table breaks out each of the components:
Table 2.1. Install components
Component Required Installed Description

by default
Platform Yes Yes A selection of packages to install, including the
C-API and Sim-API components.
OpenECU Yes Yes Install the Simulink interface to OpenECU,
Sim-API documentation and support packages.
Blockset Yes Yes Install the OpenECU blockset.
Sim-API (optional) Yes Install the OpenECU blockset, ECU Technical
Manuals Specifications and other documentation in
(HTML) HTML format.
Sim-API (optional) Yes Install the OpenECU blockset, ECU Technical
Manuals Specifications and other documentation in PDF
(PDF) format.
Sim-API (optional) Yes Install some examples of how to use the
Examples OpenECU blockset.
OpenECU C- Yes Yes Install the OpenECU C-API files and libraries.
API
C-API Yes Yes Install the C interface to OpenECU,
documentation and support packages.
C-API (optional) Yes Install the OpenECU C-API User Guide,
Manuals ECU Technical Specifications and other
(HTML) documentation in HTML format.
C-API (optional) Yes Install the OpenECU C-API User Guide,
Manuals ECU Technical Specifications and other
(PDF) documentation in PDF format.
C-API (optional) Yes Install some examples of how to use the
Examples OpenECU C interface.
Extended (optional) No Install the On-Board Diagnostic (OBD) library.
Diagnostics This library is available at extra cost.
Features

Installation
Component Required Installed Description

by default
Python Yes Yes Install the Python application. This application is
used to provide build support when generating
and compiling the model source code.
Tools (optional) No Installs additional OpenECU tools.
GCC (optional) Yes Installs the GNU Compiler Collection (v4.7.3)
and related tools for OpenECU targets.
lmadmin (optional) No Installs the installers for the lmadmin license
installer server from flexera.
FreeCCP (optional) No Installs the FreeCCP programming tool (note
that this tool is provided without support or
warranty).
Integration (optional) Yes Options to have the OpenECU installer integrate
OpenECU with third party tools, like MATLAB
and INCA.
MATLAB (optional) Yes During installation, the OpenECU blockset is
Integration integrated into MATLAB's PATH.
INCA-ProF (optional) No During installation, INCA-ProF is update to
Integration understand how to program an OpenECU.
Start Menu (optional) Yes During installation, the Window's Start menu
Shortcuts is updated to include shortcuts to installed
components.
Adjust the component selection as required (especially if you require the installer to update
an installed copy of ETAS INCA) and select the Next button.
The next window asks for a destination path to be specified. By default, the installer presents
a path to your local drive.
Warning
If the default path is changed, ensure that only digits, upper and lower case letters and
the _ character are used to specify directory names. An installation path that includes
any space characters will cause problems later on.

Installation
If the MATLAB integration component was selected, the next window presented provides a
list of installed and compatible versions of MATLAB. The example here shows that OpenECU
should be integrated with MATLAB R2008b.
Select which versions of MATLAB will be used with OpenECU and select the Next button.
If no version should be updated select None.
If no compatible versions of MATLAB were found, the next window presents the command
to run to add OpenECU to MATLAB (more details given in Section 2.5.2, “MATLAB”).
If the INCA-ProF integration component was selected, the next window presented provides
a list of installed versions of INCA.

Installation
Select which versions of INCA will be used with OpenECU and select the Next button. If no
version should be updated select None.
Note
If any version of INCA is selected, then the installer will add OpenECU integration to
all versions of INCA. This is simply a consequence of the way INCA works.
If no versions of INCA were found, the next window presents details on how to achieve this
by hand (more details given in Section 2.5.5, “ETAS INCA calibration tool”). The instructions
should be carried out when INCA-ProF runs.
If the Start Menu Shortcuts component was selected, then the next window presented asks
the user to select where in the Start menu the OpenECU items will be added. During install,
the installer adds short cuts to the documentation components selected and to the OpenECU
uninstall application.

Installation
Once installation has completed, the user is provided an option to read the getting started
guide, the release notes and to visit the OpenECU web site.
Getting started guide

If you are a first time user of OpenECU, it is strongly recommend following the
getting started guide, which covers what tools can be used with OpenECU and how to
configure OpenECU and those tools to work together.
Release notes
If you are installing a new version of OpenECU, it is strongly recommended that
you read the release notes. Some releases of OpenECU change the functionality of
features which may have an impact on existing applications.
2.3. License setup

Machine identification generated by the license tools is required to activate an OpenECU
platform license.
This section is a quick setup guide to get OpenECU working with your license. Consult
the license administration guide for more information on license management and

Installation
administration. This document is provided with the installation at "[install path]\doc_user

\License-Administration-Guide.pdf".
2.3.1. Floating license

To setup a floating license, the vender daemon will have to be run on the designated license
server as well as have a license file on that machine. This section describes setting up the
vendor daemon for a floating license.
2.3.1.1. Server
• After installing the platform, copy the files in "[install path]\tools\flexera\i86_n3\" to your
designated license server. On that machine, run lmtools.exe.
• Select the "System Settings tab", check "Include Domain", and press the button that says
"Save HOSTID Info to a File".
• Email the file to OpenECU with the purchase order. When the purchase is complete, Pi
will send you a valid license file. (Or if you have already completed the purchase, reply to
the welcome email with this information)
• It is recommended that lmadmin license server manager be used to serve licenses. Run
the lmadmin installer to install the software. Once the installation is complete, copy the
vender daemon, openecu.exe, into the install directory, "C:\Program Files (x86)\FlexNet
Publisher License Server Manager\".
• Start the license server manager. You can then use the web interface to upload the license
file and start serving your license.
Note
If a license has not yet been purchased, email the file to OpenECU with the
purchase order. When the purchase is complete, Pi will send a valid license file. If
the purchace has already been completed, reply to the welcome email with this
information.
• It is recommended that lmadmin license server manager be used to serve licenses. Run
the lmadmin installer and start the license server manager. The web interface can then be
used to upload the license file and start serving your license.

Installation
Note
Details on installing and using the lmadmin tool are in Chapter 9 of the License
Administration Guide, "[install path]\doc_user\License-Administration-Guide.pdf".
Note
lmgrd is also provided with the platform as an alternative to lmadmin; consult Chapter
10 of the License Administration guide for details on its use.
2.3.1.2. Client
• On the user development machine, set the environment variable
OPENECU_LICENSE_FILE to <port>@<hostname>to tell the OpenECU platform to look
for a floating license from the license server.
2.3.2. Node-locked license

To setup a node-locked license, a license file must be placed on the development machine.
• After installing the platform, run the file: '[install path]\tools\flexera\i86_n3\lmtools.exe'
• Select the "System Settings tab", check "Include Domain", and Press the button that says
"Save HOSTID Info to a File" (see screen shot above)
• Email the file to OpenECU with the purchase order. When the purchase is complete, Pi
will send you a valid license file. (Or if you have already completed the purchase, reply to
the welcome email with this information) If a license has not yet been purchased, email
the file to OpenECU with the purchase order. When the purchase is complete, Pi will
send a valid license file. If the purchace has already been completed, reply to the
welcome email with this information.
• Copy the file to the directory "C:\openecu" or update the OPENECU_LICENSE_FILE

environment variable with the location of your file.
Note
A floating license can be temporarily assigned as a node-locked license by navigating
to '[install path]\tools\flexera\i86_n3\' and executing 'lmutil lmborrow' in a command
window. To get more information run 'lmutil lmborrow help'.
2.4. Removing OpenECU

Navigate through the Windows All Programs Start Menu shortcuts and find the OpenECU
Developer Software directory. Select the version of OpenECU to remove and run the
uninstaller.
The uninstaller requires that the user has administrative rights to make changes on the
computer. If a user without rights is trying to execute the uninstaller a dialog box will be
displayed and the uninstaller stops. Login with an administrator account or contact your
network administrator and try again.

Installation
If a version of an OpenECU uninstaller is already running, a dialog box will appear saying
so. Select OK and change to the other OpenECU uninstaller to continue.
The uninstaller presents the location of the previous install to remove. Select the Uninstall
button to continue (this will remove that version of OpenECU) or select the Cancel button
to stop the uninstall.
When uninstalling, if this version of OpenECU is present in MATLAB's PATH, then the
uninstaller will not remove the reference. Next time MATLAB is started, it will try to gain
access to the deleted OpenECU directory and will raise an error. When this occurs, manually
remove the OpenECU directories by selecting MATLAB's menu option File->Set Path....
Note
The OpenECU uninstaller does not remove the INCA-ProF configuration files for CCP.

Installation
2.5. Integration notes for third party tools

2.5.1. Microsoft Windows 10
2.5.1.1. Integration
The installer integrates the OpenECU package with Windows 10 by modifying the Start menu,
by modifying some registry items and by copying files to a local drive.
2.5.1.2. Known defects/issues

OpenECU developer software may not function correctly on encrypted drives. OpenECU
developer software must be able to create files on the host file system. If using an
encrypted drive, be sure that permission settings will allow OpenECU to create files.
OpenECU cannot provide support for issues with encrypted drives.
2.5.2. MATLAB
The installer integrates the OpenECU package with MATLAB and Simulink. However, if for
any reason the installer could not find an installed version of MATLAB, the user can manually
integrate the OpenECU blockset by issuing the following MATLAB commands:
addpath '[install path]\openecu'

addpath '[install path]\openecu\rtw\c\openecu_ert\code_templates'
addpath '[install path]\openecu\rtw\c\openecu_ert'
addpath '[install path]\openecu\rtw\c\openecu_grt'
addpath '[install path]\openecu\mex_r<release>'
addpath '[install path]\openecu\mfile'
addpath '[install path]\openecu\model'
Note
where the text [install path] is replaced by the installed location of the OpenECU
blockset, e.g., c:\openecu\platform\1_9_2; and the text <release> is replaced
with the major version of MATLAB (e.g., 2013b or 2013b_64 for 64-bit versions of
MATLAB).
Once the path has been added, the user can check the OpenECU version by issuing the
following MATLAB command:
ver openecu
A correct response will look something like:
OpenECU Blockset (OpenECU) Version <number> <date>
If nothing is printed, or an error message is returned, then the path specified by the addpath
command was incorrect and should be changed.
2.5.2.2. Known issues

• Open: When loading an OpenECU model, Simulink may issue warnings similar to this:
Warning: Model '...' was last saved using an old version (...) of Simulink.
For advice on upgrading this model to the current version of Simulink, see
the Upgrade Advisor.

Installation
> In oe_test_required_platform_vers at 26
In oe_make_rtw_hook at 153
In openecu_make_rtw_hook at 6
In general\private\openmdl at 13
In open at 159
In uiopen at 167
Workaround: Turn off the Notify when loading an old model option in Simulink's
preferences:
2.5.3. PiSnoop
Unlike some other calibration tools, during installation there is nothing special to be done
when integrating PiSnoop and OpenECU.

None.
2.5.4. ATI Vision

when integrating Vision and OpenECU.

• Open: integration issues with OpenECU while creating a Vision VST (strategy) file.
There have been integration issues between Vision and OpenECU, when the user
requests a build create a Vision VST (strategy) file. If OpenECU cannot create a strategy
file, then it may be necessary to register the COM interface for Vision by running the
RegisterCOMInterface.bat file included in the install of ATI Vision.

Installation
• Open: does not operate correctly with encrypted hard drives.

There have been reports of Vision interacting poorly with encrypted hard drives. At the
moment, it is not clear what the problem might be. On one occasion, Pi worked with ATI
and a customer and determined a work around that is not understood. The work around
was to rename the executable file for Vision to something longer than 11 characters.
• Open: some earlier versions do not support CCP seed/key correctly.

ATI Vision 2006 (v3.2) is the earliest version for which CCP seed/key security has been
validated by OpenECU. Earlier versions may support CCP seed/key security (see the
relevant Vision documentation) but bugs in the CCP implementation on various targets
are known to exist. ATI have recommended that earlier versions should not be used, or
should be used with caution.
2.5.5. ETAS INCA calibration tool

The installer integrates the OpenECU package with the ETAS INCA tool. However, if for
any reason the installer could not find an installed version of INCA, the user can manually
integrate the necessary ProF component.
The INCA-ProF tool programs OpenECU over CCP using a set of configuration files. In order
to manually integrate these configuration files, the user must run INCA, open an experiment,
select manage memory then flash programming.
The user is then presented with a dialog box to browse ProF configurations, or a ProF settings
dialog box (in which case the user must select Configure...).
With the browse ProF configurations dialog box, select the "Install..." button and browse to
the install location of OpenECU:
[install path]\tools_integration\inca_prof
and select OK. This will have manually installed the INCA-ProF configuration file for
OpenECU.
Note
If manually integrating and the ProF files cannot be found in the location above, then re-
run the OpenECU installer and select the Integration -> INCA-ProF Integration option
and try again.

None.
2.5.6. Vector CANape

when integrating CANape and OpenECU.

None.

Installation
2.5.7. Wind River (Diab) C Compiler v5.9.4.8

(deprecated)
2.5.7.1. Installation
The Wind River (Diab) compiler 5.9.4.8 can be installed by running the file setup.exe from
the supplied media — several options will be presented during the compiler install and the
following responses should be used:
• On Choose your Activation Type window, select one of the following options:
• Permanent activation if you have been assigned with a license file from Wind River,
usually named WRSLicence.lic. The full path should point to the license file.
• Temporary activation if you wish to use the Wind River (Diab) compiler on an evaluation
basis, or temporary basis until a permanent license is provided.
• If using a single version of the Wind River (Diab) compiler, either setup the
OPENECU_DIAB_5_9_4_8 environment variable as described in the next point, or adjust
Window's system path to include the absolute path to the compiler's bin directory.
• If using multiple versions of the Wind River (Diab) compiler (for instance, when you are
using two or more versions of OpenECU which require different versions of the Wind River
(Diab) compiler), the environment variable OPENECU_DIAB_5_9_4_8 must be set to the
absolute path to the compiler's bin directory. This macro must terminate in a “\” and must
use the DOS 8.3 short naming convention.
E.g., D:\Progra~1\diab\5_9_4_8\win32\bin\
Note
After setting the environment variable, MATLAB may need to be restarted to pick up
the new setting. If in doubt, issue the:
oe_check_compiler
command at MATLAB's prompt to check that the environment variable is correctly

setup and the compiler is available.
2.5.7.2. Known defects

There is a compiler defect in which the optimizer may ignore local variable assignments under
certain cases. Compiler patch diab_5_9_4_8_patch_TCDIAB-14743 is available from the
OpenECU website.

• See ver 5.9.6.7 known issues.
2.5.8. Wind River (Diab) C Compiler v5.9.6.7

The Wind River (Diab) compiler 5.9.6.7 can be installed by running the file setup.exe from
the supplied media — several options will be presented during the compiler install and the
following responses should be used:

Installation
• On Choose your Activation Type window, select one of the following options:
• Permanent activation if you have been assigned with a license file from Wind River,
usually named WRSLicence.lic. The full path should point to the license file.
• Temporary activation if you wish to use the Wind River (Diab) compiler on an evaluation
basis, or temporary basis until a permanent license is provided.
• If using a single version of the Wind River (Diab) compiler, either setup the
OPENECU_DIAB_5_9_6_7 environment variable as described in the next point, or adjust
Window's system path to include the absolute path to the compiler's bin directory.
• If using multiple versions of the Wind River (Diab) compiler (for instance, when you are
using two or more versions of OpenECU which require different versions of the Wind River
(Diab) compiler), the environment variable OPENECU_DIAB_5_9_6_7 must be set to the
absolute path to the compiler's bin directory. This macro must terminate in a “\” and must
use the DOS 8.3 short naming convention.
E.g., D:\Progra~1\diab\5_9_6_7\win32\bin\
Note
After setting the environment variable, MATLAB may need to be restarted to pick up
the new setting. If in doubt, issue the:
oe_check_compiler
command at MATLAB's prompt to check that the environment variable is correctly

setup and the compiler is available.

None currently known.

• Closed: compiling the main model file can take a long time.
Small models compile in a short period of time, but once the code presented to the compiler
exceeds a limit, the compiler takes a long time to compile the main model file (model-
name.c).
Workaround: the compiler sets aside an amount of memory for the compilation phase
and if the size of the model code exceeds the limit, the compilation slows down. This can
be avoided by increasing the size of the compiler's buffer using a command line option.
Add the pcomp_CompileOptions block to the model, set the mode parameter to Add
to options and set the compiler options parameter to -Xparse-size=100000. If the
compilation is still slow, increase the option value further.
2.5.9. Python
Python is general purpose, high level interpreted programming language, distributed under
the PSF license which allows use in non open-source commercial applications. The license
can be found in the [install path]\tools\python\license.txt file.
Python is a required component of the OpenECU installation.

Installation

None identified.

• Open: When using OpenECU, Python may raise an error about an incorrect DLL. For
example, “The procedure entry point for X could not be located in the dynamic link library
py[name].dll”. This can occur if another application installed on the same machine as
OpenECU has also installed Python (for instance, dSpace ControlDesk).
Workaround: Browse to the Windows system directory. Depending on the version of

Windows, this will be one of:
c:\windows\system32; or
c:\windows\syswow64
Locate the DLL referred to in the error message. The file will start with the characters “py”
and end with “.dll”. Group all Python DLLs and move them to a temporary location, then
restart OpenECU.
Temporarily moving DLLs will cause the other application to run incorrectly (and if DLLs
unrelated to Python are inadvertantly moved, then the applications that rely on those DLLs
may not run correctly). You can resolve this by returning the moved DLLs to their original
location, or possibly moving the DLLs to the location of the installed applications.
Note
The OpenECU installation of Python does not write files to the Windows directories,
or modify global registry entries relating to Python. As such, the OpenECU
installation of Python is entirely local to OpenECU and will not affect other packages.

Chapter 3. Quick start
3.1. Introduction ....................................................................................................... 29
3.2. Installed examples ............................................................................................. 29
3.3. Exercise — Step 1 ............................................................................................ 32
3.3.1. Modelling the design ............................................................................... 34
3.3.2. Defining constants and variables .............................................................. 35
3.3.3. Setting block parameters ......................................................................... 36
3.3.4. Resource files ......................................................................................... 44
3.3.5. Checking the model ................................................................................ 46
3.3.6. Running the model simulation .................................................................. 48
3.3.7. Building the model .................................................................................. 48
3.3.8. Programming the ECU ............................................................................ 48
3.3.9. Playing with the application ..................................................................... 50
3.1. Introduction
This chapter gives you a quick introduction to building and simulating models, and an
introduction to programming the OpenECU device.
The step1 exercise in Section 3.3, “Exercise — Step 1” describes how to incorporate the Pi
OpenECU blocks into your own Simulink designs, and how to test and calibrate your models
on the ECU. The exercise requires the following resources:
• a working knowledge of MATLAB and Simulink;

• a complete installation of Pi's OpenECU Simulink blocks: see Chapter 2, Installation;
• a complete installation of supporting tools (e.g., compiler, calibration tool, etc.: see
Chapter 2, Installation and Appendix B, Supporting tools);
3.2. Installed examples

The installation of OpenECU comes with a number of explanatory examples of how to use
OpenECU, including a completed step1 example (see Section 3.3, “Exercise — Step 1”)
configured for each supported ECU.
These examples can be accessed through MATLAB's launch pad or start menu. For instance,
select the launch pad, browse to the OpenECU selection and click on examples.
Figure 3.1. OpenECU integrated with MATLAB's launch pad

Quick start
Or with later versions of MATLAB, run the following at MATLAB's command prompt.
oe_examples
The examples model will open with a series of subsystems:
Step 1 completed Multi - rate demo Fixed angular demo
Two pot demo CANdb demo Extended Diagnostics
Two pot with S- Function NVM demo
Open the subsystem of interest and a series of blocks representing the example for at least
one ECU will appear.

Quick start
Step1 completed Step1 completed Show

G850 M220 Loom
Step1 completed Step1 completed

M460 M250
Step1 completed
M461
For each example there is a block that details the loom, or how to connect OpenECU pins to
other devices to make the example work. An example or loom specification can be viewed
by double clicking or opening the appropriate block.
The available examples are:
CANdb demo
An example which shows how the CANdb blocks (pcx_CANReceiveMessage and
pcx_CANTransmitMessage) of OpenECU can be utilised.
Extended diagnostics
An example which shows how to use the extended diagnostics library to link diagnostic
trouble code, freeze frame, in-use performance ratio and J1939 communication blocks
together.
Fixed Angular demo

An example which shows how the angular functionality of OpenECU can be used to track
engine position via crank and cam wheel inputs, and produce fixed pulses for injectors
and ignition coils.

Quick start
Multi-rate demo
An example which shows how to transfer data between two portions of a model which
run at different rates. Simulink has specific rules about how to connect different rates this
and the example shows how this can be achieved.
NVM demo
An example which shows how the Adaptive Parameters (NVM) functionality of OpenECU
should be used. This includes two methods accumulating data to be stored (incremental
(2d map) or direct (array)) and the additional required blocks to commit the adapted
values to NVM.
Step1 completed
A set of completed step1 models for each ECU is available for reference (useful for just
trying OpenECU without the need to follow the detailed steps presented later).
Two pot. demo

A similar example to step1 that shows a simple combination of input reading, processing
and output driving.
Two pot. demo with S-Function

An example with the same functionality as the Two pot. demo but with some of the internal
signal processing being achieved by using an S-Function.
Most examples can be run on any ECU. If you find an example but there isn't a corresponding
model for your ECU, change the ECU target as described in by the put_Identification block
and then adjust any I/O pin selections. If you need a hand, please contact us.
3.3. Exercise — Step 1

Creating a temperature limit warning
This exercise describes how to build, simulate and test a model that monitors a temperature
and activates a warning lamp if a temperature threshold is breached. The model uses a single
analogue input to measure the temperature, and a single PWM output to activate a 5 volt
warning lamp.
The exercise requires the OpenECU to be connected to various devices and components as
pictured in Figure 3.2, “Quick start loom”.

Quick start
Figure 3.2. Quick start loom
FEPS 17-19V, 0V
IGN Power supply
VPWR 12V DC
GND 0V
Calibration
CAN0-L, CAN0-H CAN
OpenECU 2 Tool
5V supply
Analogue input Pot Resistor
Sensor GND
LED
PWM output
M460 CAN0-L CAN0-H Terminated?

M220 M250 M461 M560 M670 M220 A43 A28 No
FEPS A27 A27 A2 ZA1 Y22 M250 A43 A28 No
VPWR A2 A2 A20 XH4 Y3 M460 A37 A36 Yes
GND A31 A31 C1 XG4 Y2 M461 A37 A36 Yes
IGN A26 A26 A12 XD1 Y25 M560 YF4 YE4 Yes
CAN0-L A43 A43 A37 YF4 Y11 M670 Y11 Y12 Yes
CAN0-H A28 A28 A36 YE4 Y12
5V supply A25 A25 C8 XG3 Y8 External CAN termination required on
Analogue input A19 A19 A28 XA1 Y31 loom if CAN bus not terminated
Sensor GND A40 A40 C9 XG2 Y9
PWM output A37 A18 A15 YB1 Y29
By following the instructions below, you will complete the model design, test the simulation,
create compiled C code and test the model running on the ECU.

Quick start
3.3.1. Modelling the design

Before any engineering project reaches the design and modelling stage, several detailed
planning stages should be carried out to define suitable functional requirements and
specifications. Once you have a detailed target for your design, you can then start to create
and model it. Many engineers prefer to use pen and paper, but it's equally acceptable these
days to develop your design directly in modelling packages such as MATLAB and Simulink.
In this example, we have designed and partially modelled the system for you — you need
only finish the modelling process as described below.
3.3.1.1. Building the graphical model

To create the model:
1. Create an empty model
Create an empty directory somewhere to store the step1 model. Start up MATLAB/
Simulink and change to that directory. Read off the part and issue numbers from the
label on your ECU. The part number is the text string beginning '01T-'. The issue number
appears immediately afterwards: it is the number before the 'm'. For example, the label
on an M250 module might read:
Part No. 01T-068276-000 2m1
In this example, the part number is '01T-068276-000' and the issue number is 2. Note
that some part do not include the last three characters. Issue the following command at
MATLAB's command prompt:
oe_create_model('step1',
'dd', 'stp',
'template', 'minimal',
'part', '01T-068276-000',
'issue', 2)
This will create an OpenECU model named 'step1' with appropriate model settings as well
as a basic build list and a data dictionary using the prefix 'stp'. Replace the text string
'01T-068276-000' with the part number for your ECU, and the number 2 with the issue
number for your ECU. For more information issue the following command at MATLAB's
command prompt:
help oe_create_model
If your ECU part number does not have the final three characters, just enter what is there,
for example:
oe_create_model('step1',
'dd', 'stp',
'template', 'minimal',
'part', '01T-068276',
'issue', 2)
A new model with 'minimal' template has opened containing a single block called
put_Identification and while the model was opening, some additional text was printed to
the MATLAB command window.
Obtaining workspace data from each feature data dictionary...

Workspace variables loaded
2. Populate the model

Quick start
Open the Library browser window and select the blocks that you will use in your model.
These blocks are:
• from the Source list: Ground;
• from the Sink list: Terminator;
• from the Math list: Constant, Relational Operator;
• from the Pi OpenECU, Input Drivers list: Analogue Input;
• from the Pi OpenECU, Output Drivers list: PWM Output;
• from the Pi OpenECU, CAN Drivers list: CAN Configuration;
• from the Pi OpenECU, Utilities list: Identification, CCP Configuration.
Change the operation of the Relational Operator block to greater-than (>).
3. Connect the blocks
Connect the blocks together as shown in Figure 3.3, “Connected quick start model” (note
that the text in gray is commentary for this manual and need not be entered in your model):
Figure 3.3. Connected quick start model

Configuration of target
The CCP configuration block specifies the CCP settings.

The block has been configured for the defaults used by OpenECU.
The model identification block identifies the target hardware. The CAN configuration block sets up Note that CCP communications has been configued to occur on CAN port 0,
There must be one in every OpenECU model. the baud rate for a CAN port. which was setup by the CAN configuration block to the left.
Bit Rate: 500 kBps

Strategy Identification Bus ID: CAN A (pin YE4+YF4) CAN receive ID: 1785
CAN transmit ID: 1784
Description: CAN station address: 0
Step1 model, taken from the user guide. CAN bus ID: CAN A (pin YE4+YF4)
Version: 1.0.0 CCP enabled: on

ECU type: M560
ECU part number: 01T-070018-000 Bit Rate: 500 kBps
Issue number: 2 Bus ID: CAN A (pin YE4+YF4)
Copyright: 2015, OpenECU
Simple input and output processing
The analogue input block reads an input channel and The PWM output block pulses an output channel at a given frequency.
converts it to an engineering value after checking for faults. In this example, the duty_cycle inport is set to 0 or 1 depending on the
outcome of the comparison, which forces the output to low or high without pulsing.
Channel: AIN (pin XA1) analog_value

Sample time: 0.01 stp_ect duty_cycle Channel: DOT (pin XD4)
Raw Units: Volts stp_ect_state Inversion: off
Default duty cycle: 0
Transfer function (Map): Initial duty cycle: 0 sim_duty_cycle
raw axis: [.2 1.12 2.04 2.96 3.88 4.8] Frequency: 1000 Hz
sim_raw_value eng. lookup: [135 96 74 55 20 -42] confirmed_faults Offset: 0 ms
fault [Min/max dutycycle]: [0 1]
[Min/max eng. value]: [-40 130]
[Min/max raw value]: [0 5]
Default eng. value: 60
Absolute slew rate limit: 50000 This is another constant block
Leaky bucket rise/fall/hyst: 20, 10, 0.5 transient_fault_flag which forces the fault inport
of the PWM output block to zero,
the no fault condition. In your own
models it may be useful to force the
PWM output to a default duty cycle
when a fault is confirmed.
Terminate the simulation
Terminate the simulation outport so that the model
inport so that the model builds without any warning
builds without any warning This is a constant block which refers to a messages.
messages. calibration name from the data dictionary.
Note
The analogue input needs to be connected to ground and the PWM output needs to
be terminated to prevent Simulink from reporting an Unconnected Input error when
the simulation is run. The grounded inputs and outputs to and from your system only
provide simulated inputs and outputs when running in Simulink. When running on
the target ECU, these grounded inputs and outputs are ignored and the blocks read
sensors and drive actuators.
4. Save the model
Save the model. You now have a partially complete graphical model of your design.
We still need to incorporate some design variables and parameters in some of the blocks and
interconnecting wires or signals in our model. By naming things, we can use the calibration
tool to set or inspect their values when we test the working system running on the ECU.
3.3.2. Defining constants and variables

While designing and running the model, and later testing it with the calibration tool, it is very
useful to be able to interactively display and set the values that are present on parts of the
model. You can do this by assigning names to a signal or input at the modelling stage, and
then display or set the value associated with that variable as the model simulation is running.
Variables must be named according to a system described in full in Section 5.2.5, “Naming
rules”. This system helps you to identify what type of information the variable holds, and
where it is initialised and used — very helpful in tracking down any design faults. Note that
calibratable variables of this type can only be changed on-the-fly with the development ECU

Quick start
(i.e. not with the fleet ECU, which requires programming of its memory to change any variable
values).
3.3.2.1. Signals
We will use two signal variables in our design:
stp_ect
This is the value of the temperature that is output from the Analogue Input block,
representing the temperature of the engine in degrees Centigrade;
stp_ect_state
This is the result of the relational operator that calculates whether the engine temperature
is greater than the threshold temperature. It is 1 when the threshold is breached, and
0 otherwise.
Label the signals on either side of the Relational Operator block as follows:
stp_ect >
stp_ect_state
To assign a name to a signal:
1. double-click on the appropriate signal and a text box will open beneath it;
2. type in the variable name, then click outside the box to complete.
3.3.2.2. Constants and variables

We will also use a variable so that we can change the threshold temperature while the
simulation is running. Note that calibratable variables of this type can only be changed on-
the-fly in the ECU with the development ECU (i.e. not with the fleet ECU, which requires
programming of its memory to change any variable values).
The variable to set up is stpc_ect_limit — the threshold temperature (in degrees

Centigrade) which defines the temperature above which our warning light will switch on.
To set this variable:
1. double-click on the Constant block that leads into the lower of the two Relational Operator
inputs. A dialogue box appears.
2. click in the Value box, and instead of entering a numerical value, enter the variable name
stpc_ect_limit. This now references a MATLAB workspace variable (which we will
create further on).
You will also need to set a single constant used in the model:
3. double-click the Constant block that leads into the fault_value inport of the PWM Output
block. A dialogue box appears.
4. click in the Value box and enter boolean(0). This instructs the PWM Output block that
there are no faults in the system.
3.3.3. Setting block parameters

Before we can run the model simulation, each Simulink block requires a number of
parameters that define initial conditions, sample rates, and various other dynamic properties
of the model.
Block parameters are set by double-clicking on the block and entering appropriate values in
the various parameter fields that are displayed. Some parameters may only take on certain

Quick start
values, in which case the text field is replaced by a drop-down list, from which you can select
the appropriate value.
3.3.3.1. Setting the model identification parameters

The parameters dialogue box for the Model Identification looks like this:
Set the block mask parameters as the figure shows. A full description of the block mask
parameters is given later on Section 6.1.57, “Model identification (put_Identification)”, but a
summary of the items and their meaning is given here for this example.
Table 3.1. Step1 - model identification block parameters

Parameter Description Set to
ECU type Identifies the name of the type of ECU. (already set by running
the oe_create_model
command)
Part Number Identifies the hardware part number of (already set by running
the ECU. the oe_create_model
command)
Issue number Identifies the issue number of the ECU. (already set by running
the oe_create_model
command)
Pin naming Specifies the naming given to each Generic pin naming
blocks channel or pin selection.
Application name Specifies a name for the application/ Step1 example, v%ver-
model. Although this parameter has major%.%ver-minor%.%ver-
no functional effect on the model, it subminor%, %target%

Quick start

is used when generating the model
ASAP2 file and can be retrieved
over CCP using the EXCHANGE-ID
message.
Description Specifies a description of the model Step1 model from OpenECU
(this parameter has no functional effect manual.
on the model).
Major version Specifies the major version number 1
number of the model. This value can be read
over CCP by a ASAP2 compliant tool
and is useful to determine if the target
hardware is running the correct version
of the model.
Minor version Specifies the minor version number 0
of the model.
Sub-minor version Specifies the minor version number 0
of the model.
Copyright Specifies a copyright for the model 2012.
(this parameter has no functional effect
on the model).
Note
It is essential to include a put_Identification block in all OpenECU top level models. If
this block is not present, the model will not work as documented.
3.3.3.2. Setting the CAN configuration parameters

The parameters dialogue box for the CAN Configuration looks like this:
parameters is given later in Section 6.1.12, “CAN configuration (pcx_CANConfiguration)”,
but a summary of the items and their meaning is given here for this example.

Quick start
Table 3.2. Step1 - CAN configuration block parameters

Bit rate The bit rate (or baud rate) of the CAN bus. 500 kBps
CAN bus identifier Which CAN bus the configuration applies to. CAN 0
3.3.3.3. Setting the CCP Configuration parameters

The parameters dialogue box for the CCP Configuration looks like this:
parameters is given later in Section 6.1.19, “CCP configuration (pcp_CCPConfiguration)”,
Table 3.3. Step1 - CCP configuration block parameters

Receive message A unique standard CAN message identifier 1785
identifier for CCP CRO messages. This is the CAN
identifier used to talk to the OpenECU
device. For this example, we'll use the
default value.
Transmit message A unique standard CAN message identifier 1784
identifier for CCP DTO messages. This is the CAN
identifier used to talk from the OpenECU
device. For this example, we'll use the
default value.
Station address The station address for CCP sessions. 0
OpenECU will only communicate using CCP
if a session is opened using this station
address. For this example, we'll use the
default value.
CAN bus identifier Which CAN bus CCP communications will CAN 0
occur on. Previously, we configured CAN 0
to run at 500 kBps, so we'll use CAN 0 for
CCP communications.
Enable CCP during Whether to communicate using CCP (tick)
model execution? when the model is executing or whether

Quick start

it will only communicate using CCP when
programming. We will want to view signals
stp_ect and stp_ect_state when the
model is running (and possibly change
calibrations as well) so this should be
ticked.
Use CRO extended As the model has been configured with 11 (untick)
ID? (29 bit) bit CAN identifiers for CCP i.e., CRO set to
1785, so this should be unticked.
Use DTO extended As the model has been configured with 11 (untick)
ID? (29 bit) bit CAN identifiers for CCP i.e., DTO set to
1784, so this should be unticked.
3.3.3.4. Setting Analogue Input parameters

The parameters dialogue box for the Analogue Input looks like this:
parameters is given later on Section 6.1.6, “Analogue input — processed (pai_AnalogInput)”,

Quick start
Table 3.4. Step1 - analogue input block parameters

Channel Which channel will be used for the raw input AIN (pin A19) for
from the temperature sensor. M220,
AIN (pin A19) for
M250,
AIN (pin A28) for
M460 and M461, or
AIN (pin Y31) for
M560, M580 and
M670
Raw data units Units in which the raw analogue values for Volts
this block are interpreted.
Transfer function The type of tranfer function to use when Map
type converting from raw values to engineering
values. In this example we set it to use an
interpolating lookup map.
Transfer function raw The values of this and the engineering [.2 1.12 2.04 2.96
axis lookup define a transfer function that is 3.88 4.8]
characteristic of the particular temperature
sensor we're using. The raw axis defines
some arbitrary inputs to the sensor, and
the eng lookup defines the corresponding
output behaviour. Note that the number
here represents the analogue pin voltage
because Raw data units is set to Volts.
Transfer function (see above) [135 96 74 55 20 -42]
engineering lookup
Default engineering The default starting value for the parameter 60
value (in °C).
Separate min/max Option to separate the Minimum/maximum unchecked
values engineering value and Minimum/maximum
raw value into four separate parameters.
Not used in this example.
Minimum/maximum The minimum and maximum values that are [-40 130]
engineering value to be expected for this value (in °C).
Minimum/maximum The minimum and maximum raw values [0 5]
raw value that are expected at the input to the block's
transfer function. These units correspond
to the setting of Raw data units, hence the
range for Volts.
Absolute raw slew The maximum rate at which the signal is 10000000
rate limit expected to rise or fall. By setting this to a
large number, we can ensure that the block
will never detect a slew rate limit fault.
Leaky bucket rise This is the threshold rate above which 20
rate incoming fault data will trigger a permanent
fault. Setup for this example so that a fault
is never detected.
Leaky bucket fall rate This is the threshold rate below which 10
incoming fault data will cease to trigger a

Quick start

fault indication. Setup for this example so
that a fault is never detected.
Leaky bucket This is the amount of hysteresis in the leaky 0.5
hysteresis bucket fault filter system. Setup for this
example so that a fault is never detected.
Sample time The time (in seconds) between samples, 0.01
i.e., how often this block will be integrated.
The transfer function allows for non-linear conversion but must adhere to the same
restrictions as the put_Calmap1d block (e.g., regarding axis monotonicity). The transfer
function from the analogue input block data above in Figure 3.4, “Analogue input transfer
function”.
Figure 3.4. Analogue input transfer function
3.3.3.5. Setting PWM Output parameters

The parameters dialogue box for the PWM Output looks like this:

Quick start
Set the block mask parameters as the figure shows. A full description of the block
mask parameters is given later on Section 6.1.77, “PWM output — fixed frequency
(pdx_PWMOutput)”, but a summary of the items and their meaning is given here for this
example.
Table 3.5. Step1 - PWM output block parameters

Channel Which channel will be used for the PWM DOT (pin A37) for
output signal. M220,
DOT (pin A18) for
M250,
DOT (pin A15) for
M460 and M461, or
DOT (pin Y29) for
M560, M580 and
M670
Inversion Whether the logical function of the block will (unticked)
be inverted (ticked) or not (unticked).
Default duty cycle The default output duty cycle used when 1
a fault is specified. In this example, the
fault inport is always force to zero, so this
condition never arises.
Initial duty cycle The initial duty cycle before the model starts
to run.
Frequency The frequency of the signal. Although this 1000
example always uses a 0% or 100% duty
cycle, i.e., always on or off, the frequency
must still be specified.
Offset The offset of the signal relative to other 0
PWM signals of the same frequency. An

Quick start

advanced feature that can be ignored in this
case.
Minimum/maximum The minimum and maximum duty cycle [0 1]
duty cycle range for this input.
Sample time The time (in seconds) between block 0.01
iterations.
This example uses a PWM output to drive an output either fully on (100% duty-cycle) or fully
off (0% duty-cycle). A digital output block Section 6.1.37, “Digital output (pdx_DigitalOutput)”
could have been used instead and is the more logical choice for this example. However, the
example uses a PWM output block to show that different outputs can be used in equivalent
ways.
3.3.3.6. Summary so far

Your model should now look like Figure 3.5, “Configured quick start model”.
Figure 3.5. Configured quick start model


Bit Rate: 500 kBps

Strategy Identification Bus ID: CAN A (pin YE4+YF4) CAN receive ID: 1785

ECU type: M560
Channel: AIN (pin XA1) analog_value

raw axis: [.2 1.12 2.04 2.96 3.88 4.8] Frequency: 1000 Hz
fault [Min/max dutycycle]: [0 1]
So far, you have populated the model with a number of Simulink and OpenECU blocks,
defined some behaviour by linking the blocks together to interact and now need to provide
the framework around the model to allow it to be built and run on an OpenECU device.
3.3.4. Resource files

Your model file includes the information to describe the dynamics of your design, but it needs
some other information — parameters and initial values of variables — to function correctly
and remain flexible for future alterations and additions to its design. There are two types files
that are used for this:
Data dictionary
A text file which holds information about the variables you have set up in your design
model that you will want to inspect on the physical system with the calibration tool. We
created three variables in this model, whose initial conditions, ranges and types must be
recorded in the data dictionary;
M-file build list

A text file which tells the model where to find the blocks and data dictionaries that are to
be used by the model. In this case, there is only 1 data dictionary used.
Draft versions of these resource files were created by the oe_create_model command.
3.3.4.1. Editing the data dictionary

The data dictionary for this model will consist of 4 lines (1 for the column labels, and 3 others
for the variables in our model). Each line needs to have 10 tab-delimited fields entered, which

Quick start
are used to tell the model about the type and structure of each of the 3 variables. As the data
dictionary is a tab-delimited text file, it is often simpler to use a spreadsheet application (e.g.
Microsoft Excel) to create or edit the file, although you can, of course, use any text editor. It
is not recommended that you use MATLAB's own text editor for editing data dictionary files,
as tab characters are handled poorly.
To edit the data dictionary for your model:
1. Use your spreadsheet application or text-editing application to open the file called
stp_dd.txt in the directory called stp in the directory you created at the start of this
exercise.
The file has three lines — the top line always contains the column labels for reference, and
the other two lines contain dummy variables to be replaced by variables from our model.
2. Copy and paste the line that starts with stp_dummy so that the file looks like:
Name Value Units Type Accuracy Min Max Description

stp_dummy NA real_T 0.01 0 0 Dummy measurable, delete t ...
stp_dummy NA real_T 0.01 0 0 Dummy measurable, delete t ...
stpc_dummy_cal 0 NA real_T 0.01 0 0 Dummy calibratable, delete ...
Then change each line, making sure not to delete or add any TAB characters, so that
the file looks like:

stp_ect degC real_T 0.01 -40 140 Temperature of engine
stp_ect_state state BOOL 1 0 1 1 if over temperature, 0 if not
stpc_ect_limit 90 degC real_T 0.01 -40 140 Temperature threshold
3. Save the file — if you're using a spreadsheet application to edit the data dictionary file,
save in a tab-delimited text format.
4. At MATLAB's command prompt, issue the command:
oe_read_build_list
which deletes the dummy workspace variables and replaces them with the set of variables
entered into the stp_dd.txt file. If any errors or warnings are displayed, go back and
edit the file until it matches the above (a complete list of error and warning messages are
given in Appendix H, Data dictionary tool errors).
Once read without errors, the workspace will have been updated and look something like:

Quick start
5. Optionally, in R2015a and later, a Simulink based data dictionary can be used in place of
a text based data dictionary by issuing the following command, at MATLAB's command
prompt:
oe_config_using_sim_dd
This will convert the text based data dictionary to a Simulink data dictionary which can
then be edited within Simulink in Model Explorer.
More detailed information on the structure of the data dictionary can be found in
Section 4.2.2.2, “Data dictionary files”.
3.3.5. Checking the model

The model is now complete, but before its built, we can check it by updating the model. This
also activates a number of visual indicators which help the user read the model, including
library links and rate colouring.
To update the model (right click on the background and select the Update diagram menu
item). Your model should now look like Figure 3.6, “Updated quick start model”.
Figure 3.6. Updated quick start model

Bit Rate: 500 kBps

Strategy Identification CAN receive ID: 1785
Bus ID: CAN A (pin YE4+YF4)

ECU type: M560
ExportedGlobal
Channel: AIN (pin XA1) analog_value ExportedGlobal
raw axis: [.2 1.12 2.04 2.96 3.88 4.8] 5
Frequency: 1000 Hz
5 fault [Min/max dutycycle]: [0 1]
Library links
Each of the OpenECU blocks has a small icon of an arrow in the bottom left hand corner
of the block display. This indicates that the block on the screen is a reference to the
OpenECU library.

Quick start
It is possible to break the library links but its very important that OpenECU blocks remain
as library links. When they remain as library links, when the OpenECU software is
updated, linked blocks are updated as well. If the link were broken, then the OpenECU
software is updated, the unlinked block remains at the older version of OpenECU.
Warning
Mixing versions of OpenECU blocks in a model may lead to undefined results when
the model is simulated or run on the target.
Block and signal colouring

All of the blocks and signals have been coloured red (or magenta). This means that all
the blocks run at the same rate and that the rate is the fastest in the model. If other rates
were present in the model, Simulink would colour blocks and signals that run at those
rates different colours.
Table 3.6. Simulink model colouring
Colour Description
Red Fastest discrete sample time
Green Second fastest discrete sample time
Blue Third fastest discrete sample time
Light blue Fourth fastest discrete sample time
Dark green Fifth fastest discrete sample time
Orange Sixth fastest discrete sample time
Black Continuous blocks — these cannot be used with OpenECU.
Cyan Blocks in triggered sub-systems — triggered sub-systems do
not have a defined periodic rate and run sporadically when the
trigger activates.
Yellow A mixed or hybrid system which contains more than one rate.
Purple/Magenta An invariant or constant — something which does not change
during the run of the model. Simulink will try to optimise these
items.
The colouring is a very useful indicator of related tasks and helps the model designer
break up the functionality between rates. As much as possible, functionality should be
placed at the slowest rate possible to ensure that as much computing power on the ECU
is made available.
Exported global indication

Signals that need to be viewed while the model is running on the target must be defined
as Exported Global. When the model is updated, Simulink explicitly shows the Exported
Global item on the diagram and its a useful indicator in case you forgot to set the type.
Vectors of signals
The analogue input block shows a vector of outputs as a thick line with the number 5
written beside it. This means the vector contains 5 elements. More information about
each of those elements can be found in Section 6.1.6, “Analogue input — processed
(pai_AnalogInput)”.

Quick start
3.3.6. Running the model simulation

To run your model in simulation prior to running it on OpenECU target hardware select Start
from the Simulation menu, or click on the button in the Simulink toolbar. If your model has no
design errors in it, and Simulink can find all the resources it needs, the simulation will run.
Of course, for this example, you cannot change the behaviour of the simulation as it runs. In
order to do this, you can replace the ground input to the pai_AnalogInput block with a signal
generator and attach scopes to the signals to view during the simulation.
3.3.7. Building the model

The process of building the model creates a number of files which can be downloaded or
programmed into an OpenECU to run in real-time. The build process is started by selecting
the model, and either pressing CTRL-B or selecting the menu option Tools -> Real-Time
Workshop -> Build Model. This instructs RTW to generate C code from the model and to
invoke OpenECU's template makefile to compile the C code.
The result of a successful build produces a number of files in the same directory as the step1
model:
• step1_tool_generic.a2l — the generic ASAP2 file for the build model (includes details
about the stp signals amongst other things);
• step1_tool_inca.a2l — the ETAS INCA specific ASAP2 file for the build model;
• step1_tool_vision.a2l — the ATI Vision specific ASAP2 file for the build model;
• step1_tool_canape.a2l — the Vector CANape specific ASAP2 file for the build model;
• step1_tool_vision.vst — the ATI Vision Strategy file for the build model (combined
ASAP2 and S-record files — only generated if a compatible version of ATI Vision is
installed);
• step1.a2l.err — any errors that resulted from creating the ASAP2 file (if there are any
errors, a short extract is displayed at the end of the build);
• step1_image_small.s37 — the image bytes to program into the OpenECU in Motorola S-
record format (small representing the minimum amount of code and data bytes to program
the OpenECU device) — suitable for the ATI Vision calibration tool;
• step1_image_small.hex — the image bytes to program into the OpenECU in Intel HEX
format — suitable for the Vector CANape and ETAS INCA calibration tool;
• step1.elf — the compiler's version of some of the above files — suitable for the PiSnoop
development tool;
• step1.snx — lists of variables PiSnoop will show or hide automatically — suitable for the
PiSnoop development tool;
If the build fails for any reason, go back through the stages of the example and identify any
corrections, or look at the installed and completed step1 model to identify any differences.
3.3.8. Programming the ECU

The OpenECU is programmed with any CCP compliant tool. Specific instructions for ATI
Vision, Vector CANape and ETAS INCA calibration tools are provided in Appendix B,
Supporting tools.
At a minimum, the OpenECU device will need to be powered and be connected to the CCP
tool over CAN as shown in the following diagram.

Quick start
FEPS 17-19V, 0V
IGN Power supply
VPWR 12V DC
OpenECU GND 0V
Calibration
CAN0-L, CAN0-H CAN
2 Tool
M220 M460 M560 CAN0-L CAN0-H Terminated

M221 M250 M461 M580 M670 M220 A43 A28 No
IGN - A26 A12 XD1 Y25 M560 YF4 YE4 Yes
CAN0-L A43 A43 A37 YF4 Y11 M560 YF4 YE4 Yes
CAN0-H A28 A28 A36 YE4 Y12 M670 Y11 Y12 Yes
External CAN termination required on

loom if CAN bus not terminated

Quick start
The OpenECU device can be programmed by following these steps:
1. Apply a positive FEPS voltage, as given in the following table and then power cycle the
ECU (the FEPS signal may not be detected if applied simultaneously with the ECU power).
Upon detecting the FEPS signal the ECU is placed into its reprogramming mode, where
it does not run the application and responds only to reprogramming commands.
2. Program the ECU following the instructions in Appendix B, Supporting tools.
3. Once programmed, ground the FEPS pin and power cycle the ECU. This places the ECU
in its application mode, where the ECU runs the programmed application.
Table 3.7. FEPS voltages

M560
M580 Result
0V FEPS pin is grounded. On power up, the
ECU attempts to run the last programmed
application in application mode. If a
application has not been programmed, the
ECU enters reprogramming mode.
— FEPS pin is positive. On power up, the ECU
enters reprogramming mode. If a application
has previously been programmed, the ECU
uses the CCP settings of the application.
Otherwise, the ECU uses the default CCP
settings.
< -16V FEPS pin is negative. On power up, the
ECU enters reprogramming mode. The
ECU uses the default CCP settings and
ignores any CCP settings stored in any
programmed application.
3.3.9. Playing with the application

Once programmed, ground the FEPS pin, power cycle the ECU, and the application will start.
Then use an ASAP2/CCP compliant tool to view the stp_ect and stp_ect_state signals,
and to set stpc_ect_limit (if you are using a developer module).

Chapter 4. Software overview
4.1. How to find OpenECU ....................................................................................... 52
4.1.1. In Windows ............................................................................................ 52
4.1.2. In MATLAB — After installation ............................................................... 52
4.1.3. In MATLAB — Help (R2015b) ................................................................. 53
4.1.4. In MATLAB — Help (R2016a and newer) ................................................. 53
4.1.5. In MATLAB — Library browser (R2013a and newer) ................................. 54
4.1.6. In MATLAB — Command line (all versions) .............................................. 54
4.2. Introduction to OpenECU ................................................................................... 55
4.2.1. Working with OpenECU .......................................................................... 55
4.2.2. Create model .......................................................................................... 56
4.2.3. Update model ......................................................................................... 66
4.2.4. Simulate model ....................................................................................... 67
4.2.5. Build model ............................................................................................ 67
4.2.6. Program ECU with model ........................................................................ 67
4.2.7. Test model ............................................................................................. 69
4.3. Simulink and OpenECU ..................................................................................... 69
4.3.1. Block use restrictions .............................................................................. 70
4.3.2. Auto-coders ............................................................................................ 71
4.3.3. Configuration sets ................................................................................... 71
4.3.4. Configuration options .............................................................................. 72
4.3.5. Selecting an auto-coder .......................................................................... 77
4.3.6. Building a model ..................................................................................... 79
4.4. System modes .................................................................................................. 84
4.4.1. Boot mode .............................................................................................. 85
4.4.2. Reprogramming mode ............................................................................. 85
4.4.3. Application mode .................................................................................... 85
4.5. Programming an ECU ........................................................................................ 86
4.6. OpenECU blockset features ............................................................................... 90
4.6.1. Calibration tool support ........................................................................... 91
4.6.2. Adaptive parameters ............................................................................... 91
4.6.3. Communications ..................................................................................... 92
4.6.4. Compiler options ..................................................................................... 94
4.6.5. Deprecated blocks .................................................................................. 94
4.6.6. Fault support .......................................................................................... 94
4.6.7. PID support ............................................................................................ 95
4.6.8. Freeze Frame support ............................................................................. 95
4.6.9. Service $09 InfoType support .................................................................. 95
4.6.10. IUPR support ........................................................................................ 95
4.6.11. Analogue and digital inputs .................................................................... 95
4.6.12. Operating system .................................................................................. 97
4.6.13. Analogue and digital outputs .................................................................. 98
4.6.14. Real-Time Workshop (RTW) support ...................................................... 99
4.6.15. Target ECU identification and configuration ............................................. 99
4.6.16. Timing .................................................................................................. 99
4.6.17. Utilities ................................................................................................. 99
4.6.18. Versioning ........................................................................................... 100
4.7. Adapting an existing model for OpenECU ......................................................... 100
4.8. Migrating between versions of Simulink ............................................................. 122
This chapter provides an overview of OpenECU developer software in more depth than the
quick start covered in Chapter 3, Quick start. From this chapter, you will:
• Understand how to access OpenECU through Simulink, in particular, the OpenECU

blockset and user guides.

Software overview
• Understand the process in creating and developing an OpenECU Simulink application,

how OpenECU uses data dictionaries to describe the signals and constants in the model,
and how to program an ECU with that application.
• Understand how to interact with the different Simulink coders through configuration sets,
as well as what features of Simulink are not supported by OpenECU.
• Understand the different system modes an ECU select, including the different software
components that make up the ECU's firmware.
4.1. How to find OpenECU

4.1.1. In Windows
During the installation of OpenECU, menu items are added to Windows Start menu. You can
access OpenECU documentation by selecting the Start menu, then OpenECU Developer
Software, then the version of OpenECU that is of interest:
Figure 4.1. OpenECU integrated with Window's Start button
4.1.2. In MATLAB — After installation

Having asked for MATLAB integration during the installation of OpenECU developer
software, the OpenECU blockset is available to use from within Simulink. The integration with
MATLAB resembles other blocksets, and as closely as possible, OpenECU tries to integrate
into the existing available MATLAB commands.
To find out if OpenECU was successfully installed, type the following command at the
MATLAB prompt:
ver openecu
and MATLAB will display the version of OpenECU installed. A correct response will look
something like:

Software overview
OpenECU Blockset (OpenECU) Version 3.2.0-FS r2022-1
Note
The ver command is a MATLAB standard command. OpenECU integrates with a small
number of these commands, see Table 4.1, “Standard MATLAB commands”.
4.1.3. In MATLAB — Help (R2015b)

In MATLAB R2015b, the user guide can be reached by selecting Help > Documentation
from the main toolbar, then by selecting Supplemental Software on the window that
appears. Finally select OpenECU (OpenECU) Blockset which is listed in the contents of the
Supplemental Software window.
Figure 4.2. OpenECU integrated with MATLAB's help system (R2015b)
4.1.4. In MATLAB — Help (R2016a and newer)

In MATLAB R2016a and later, the user guide can be reached by selecting Help >
Documentation from the main toolbar, then by selecting OpenECU (OpenECU) Blockset.
Figure 4.3. OpenECU integrated with MATLAB's help system (R2016a

and newer)

Software overview
4.1.5. In MATLAB — Library browser (R2013a and

newer)
The blockset is accessible through the library browser, which is itself available through any
main Simulink window:
Figure 4.4. OpenECU integrated with MATLAB's library browser (R2013a

and newer)
The functionality of OpenECU is split into various components (e.g., angular, input, output)
and documented in Section 4.6, “OpenECU blockset features”. The blocks can be dragged
from the library browser to a model.
4.1.6. In MATLAB — Command line (all versions)

The OpenECU blockset is integrated into MATLAB through various standard commands:
Table 4.1. Standard MATLAB commands

Command Description
ver Display the versions of all toolboxes and blocksets MATLAB knows
about.
ver openecu Display the version of the OpenECU blockset only.
help openecu Display the commands specific to OpenECU. Further help on each
command can be displayed by executing help <command> (e.g.,
help oe_freeccp).
Note
If too much information is displayed at once when using these commands, the display
can be broken into pages by executing the command:
more on
then repeating the command which displayed too much information.

Software overview
Further commands specific to OpenECU are available and reference documentation is

available in Section 6.4, “OpenECU commands”.
4.2. Introduction to OpenECU

4.2.1. Working with OpenECU
To help explain the methods for working with OpenECU, Figure 4.5, “Example development
pattern for modelling an application” shows a simple development process for working with
a model and an ECU.
Figure 4.5. Example development pattern for modelling an application

1
Create
model
Update
model
Simulate
model
Build
model
Program
ECU
6
Test
model
1. Create model — using the oe_create_model script will create a basic model containing
essential OpenECU blocks and will create a data dictionary. How to use this script and
what a data dictionary is, is described in more detail in Section 4.2.2, “Create model”.
2. Update model — by adding to the model's logic and algorithms, or amend what is already
there with feedback from simulating or testing the model. Some tips on model structure
can be found in Section 4.2.3, “Update model”.
3. Simulate model — on the PC using Simulink's simulation feature to quickly check the
overall functionality of the model without having to power up an ECU. Sometimes its
necessary or simply quicker to skip the simulation stage and try the model out on an

Software overview
ECU. While simulation can help spot problems before running the model on an ECU, it is
essential to test the model on the ECU to confirm correct behaviour. Simulation is covered
in Section 4.2.4, “Simulate model”.
4. Build model — to create the files necessary to program an ECU with the model. Building
the model is taken care of by a combination of Simulink and OpenECU — there are no
manual steps to creating the ECU files, except to start a model build. An overview of how to
start a model build is given in Section 4.2.5, “Build model” and the automatic build process
and outputs are detailed in a later section, Section 4.3.6, “Building a model”.
5. Program ECU — to place the built model onto an ECU ready to run. Typically,
programming an ECU involves the use of a calibration tool and OpenECU is compatible
with ATI Vision, Vector CANape and ETAS INCA. Programming an ECU is covered in
detail in Section 4.5, “Programming an ECU”.
6. Test model — to determine if the model logic and algorithms perform adequately
and provide any feedback to update the model. Some tips on testing can be found in
Section 4.2.7, “Test model”.
4.2.2. Create model

An OpenECU model consists of three or four components:
Simulink Data Units Build
Model dictionary file list
file(s) file(s) (optional) file
Simulink model file(s)

One or more Simulink model file which use Simulink and OpenECU (and
possibly custom) blocks to detail the functionality of the application. The
model files are covered in Section 4.2.2.1, “Model”.
Data dictionary file(s)

One or more text files or Simulink data dictionary files which detail
each of the named block parameters and named signals in the Simulink
model. Details include units, range, description, and more. The data
dictionary files are covered in Section 4.2.2.2, “Data dictionary files”.
Units file
An optional text file which lists the allowable units used to describe
named parameters and signals in the model. The units file is covered in
Section 4.2.2.3, “Units file”.
Build list file

One MATLAB file which lists the data dictionary files used by the model.
The build list file is read when the Simulink model is loaded into Simulink
and the workspace is populated with data dictionary information. The
build list file is covered in Section 4.2.2.4, “Build list file”.
Note
Simulink Data Dictionaries are supported in R2015a and later.
4.2.2.1. Model
An OpenECU model can be created by:
1. creating a new directory to store the model;

Software overview
2. changing MATLAB's current path to the newly created directory;
3. issuing the following command at MATLAB's prompt:
oe_create_model '[model-name]' 'dd' '[dd-name]' 'part'

'[part-number]' 'template' 'basic'
Where the text [model-name] is replaced by the name to be given to the model, the
text [dd-name] is replaced by the name of the data dictionary and the text [part-
number] is replaced by the part number of the target (e.g., 01T-068144-000 for the
M460-000). The command opens a new Simulink model, creates a basic build list and
data dictionary file, adds put_Identification block to configure the ECU.
The model parameters are important to the correct working of OpenECU models and
are discussed in a little more detail in the following sections.
4. save the model.
The procedure above uses a default name for the data dictionary and a default version of
hardware but these can be specified when creating the model.
oe_create_model('model-name', 'dd', '[dd_name]', 'part', '[part-

number]')
where [dd_name] is replaced by the name of the data dictionary (e.g., the step1 model
from Section 3.3, “Exercise — Step 1” uses a data dictionary named stp) and where [part-
number] is replaced by the part-number of the target (see Section 6.1.57, “Model identification
(put_Identification)”). For more details, issue this command at MATLAB's command window:
help oe_create_model
The oe_create_model command will not be able to create a new model when it cannot
understand some of the parameters given to it or if it cannot access the file system (e.g., if
the file cannot be written or the file system is full).
If an error does occur when creating the model, once the problem that caused the error has
been resolved, it is best to remove the intermediate set of files that the oe_create_model
command generated, before issuing the command a second time.
4.2.2.2. Data dictionary files

A data dictionary can be either a text file, or a Simulink proprietary format file with the
extension .sldd starting in R2015a. Prior to R2015a only text file based data dictionary files
are supported.
4.2.2.2.1. Text file based

A text file based data dictionary file is a simple tab delimited text file format and must contain
at minimum: the name, default value and type for calibratables and the name and type only
for displayables. When a model is loaded, the data dictionary files are read into MATLAB's
workspace to support simulation or building. Optionally, these can be used to generate
ASAP2 files at build time. See Section 4.3.4, “Configuration options” for details.
Note that non-ASCII characters appearing in the data dictionary may not be interpreted
correctly by the calibration tool reading the resultant ASAP2 files, since different calibration
tools use different extended encoding conventions. It is best therefore to stick to ASCII
characters within the data dictionary.

Software overview
Each data dictionary file is stored in a directory of the same name. Given the example of the
model read_sensor above, then there would be two directories named min and mot:
Each data dictionary file stored in each of those directories must be named data
dictionary name_dd.txt. Given the example of the model read_sensor above,
then there would be two files named min_dd.txt and mot_dd.txt in the corresponding
directories:
Each data dictionary follows a simple format, separated into columns and will look something
like:

moi_pressure kPa real_T 0.01 20 80 Pressure reading
moi_temperature degC real_T 0.01 -40 150 Temperature reading
To help readability, comment lines can be inserted into a data dictionary file. Comment lines
are ignored and start with either a ** or the -- character sequence. For example:

** A comment line
moi_pressure kPa real_T 0.01 20 80 Pressure reading
-- Another comment line

moi_temperature degC real_T 0.01 -40 150 Temperature reading
Each column has a heading, followed by as many data dictionary entries as necessary. Each
column is separated by a TAB character and because of this, Excel is a very useful tool for
editing the files (in Excel, save the file as Text (tab delimited) *.txt).
Each column has a use:
Table 4.2. Data dictionary columns

Column Description
Name The name of the data dictionary entry. The name must conform to the
naming convention detailed in Section 5.2.5, “Naming rules”.
Value The value of a calibration constant, 1d or 2d map. A value should not
be created for a Simulink signal.
Units The engineering units for this entry (can be restricted to a set of
possibilities with a units file (Section 4.2.2.3, “Units file”)).
Description A description of the data dictionary entry. Must not contain single or
double quotes.
Type Any one of int8_T, uint8_T, int16_T, uint16_T, int32_T
uint32_T, real_T or bool. The type must match the type assigned
to the signal by Simulink.
Accuracy The number of decimal digits to display when viewing the data
dictionary entry with a calibration tool. For instance, 1 shows no digits
after the decimal point, 0.01 shows two digits after the decimal point.
Min The minimum expected value for this data dictionary entry.

Software overview
Column Description
Max The maximum expected value for this data dictionary entry.
Scale This column is optional. It specifies the amount by which the displayed
value will be scaled from the raw value read from the ECU.
Offset This column is optional. It specifies the amount by which the displayed
value will be offset from the raw value read from the ECU.
Enums A comma separated list of data dictionary entries which provide the
possible values this data dictionary entry can be. This column is
optional.
Defn This column is optional. It specifies the file in which the equivalent C
variable for the DDE will be defined. Only applicable when using RTW
Embedded Coder, the column is ignored for other auto-coders.
Decl This column is optional. It specifies the file in which the equivalent C
variable for the DDE will be declared. Only applicable when using RTW
Embedded Coder, the column is ignored for other auto-coders.
Lookup Reserved for future use, do not use.
Group Reserved for future use, do not use.
Rate Reserved for future use, do not use.
An example of how the data dictionary can be used to name model signals, model
constants and map look-ups is given below. Each entry follows the naming convention laid
out in (Section 5.2.5, “Naming rules”). Explore the OpenECU demos for more examples
(Section 3.2, “Installed examples”).
Name Value Units Type Min Max Description
** Example of a signal DDE

moi_pressure kPa real_T 20 80 Example of a named signal
** Example of a constant look-up DDE

moic_constant 50 kPa real_T 20 80 Example of a calibration constant
** Example of set of a 1D table/map look-up DDEs

moim_1d_map_x [20 40 80] kPa real_T 20 80 Example of a x-axis for a 1d map
moim_1d_map_z [0 0 1] state bool 0 1 Example of a z-data for a 1d map
** Example of set of a 2D table/map look-up DDEs

moim_2d_map_x [20 40] kPa real_T 20 80 Example of a x-axis for a 2d map
moim_2d_map_y [1 5 10] sec real_T 0 25 Example of a y-axis for a 2d map
moim_2d_map_z [0 1; 4 5; 8 9] steps real_T 0 100 Example of a z-data for a 2d map
** Example of set of an array DDE

moiv [1 2 3 5 8 13] counts real_T 0 100 Example of an array
Instead of using values to represent discrete states, enumerations can be used instead.
These represent the discrete states using a textual name rather than a number. For instance,
in the following example, moi_state can have two enumerations: MOI_RUNNING which
represents the value 0 and MOI_STOPPED which represents the value 1. It is easier to
understand and interpret the enumerations than the values.
Name Value Units Type Min Max Enums Description
moi_state state real_T 0 1 MOI_RUNNING, MOI_STOPPED Example of a st ...
MOI_RUNNING 0 enum real_T Enumeration for ...

MOI_STOPPED 1 enum real_T Enumeration for ...
When a model is loaded, each data dictionary entry is checked for errors. A complete list
of checks is given in Appendix H, Data dictionary tool errors. If any errors or warnings are
displayed, go back and edit the file to remove the errors.

Software overview
Note
When a data dictionary is changed OpenECU does not automatically read the file.
Instead, the user must read the data dictionaries by running the command:
oe_read_build_list
at MATLAB's prompt.
4.2.2.2.2. Simulink based
In R2015a and later, a Simulink based data dictionary file with an extension of .sldd can
be used with OpenECU. This type of data dictionary holds the same information as a text
based data dictionary, only the data is stored in oe.Parameter and oe.Signal objects in
the data dictionary file from within Simulink, instead of externally in text files. This file can be
edited manually from within Simulink using the Model Explorer interface, or programmatically
in Simulink using the Simulink.data.dictionary class and API.
The data dictionary file is specified in the Model Properties dialog box of the model File->
Model Properties-> Model Properties under the Data tab, as shown in the image below.
The data dictionary file can be viewed or edited by clicking the icon in the bottom left hand
corner of the model once it has been configured to use a data dictionary, as shown below.

Software overview
The data dictionary file is then edited in Model Explorer Tools-> Model Explorer, as shown
below.
To add a new oe.Parameter or oe.Signal object to the data dictionary select Add->
Add Custom... from the Model Explorer menu, and in the dialog box, specify the name of
the variable and the class of the variable (either oe.Parameter or oe.Signal), as shown
below.

Software overview
OpenECU uses the following properties for each signal object:
Table 4.3. Simulink data dictionary object properties

oe.Parameter oe.Signal property Text based Description
property column
equivalent
Object name Object name Name The name of the object
in the data dictionary.
The name does not
need to conform to the
naming convention if
the model is configured
to use oe objects, and
to disable the naming
convention.
name.Value Value The value of a paramter
constant, 1d or 2d
map. Only valid for
oe.Parameter objects.
name.DocUnits name.DocUnits Units The engineering units
for this entry. Units file is
not supported.
name.Description name.Description Description A description of the data
dictionary entry.
name.DataType name.DataType Type A Simulink supported
data type.
name.Accuracy name.Accuracy Accuracy The number of decimal
digits to display when
viewing the data
dictionary entry with
a calibration tool. For
instance, 1 shows no
digits after the decimal
point, 0.01 shows two
digits after the decimal
point.

Software overview
oe.Parameter oe.Signal property Text based Description

property column
equivalent
name.Scale name.Scale Scale The amount by which
the displayed value will
be scaled from the raw
value read from the
ECU.
name.Offset name.Offset Offset The amount by which
the displayed value will
be offset from the raw
value read from the
ECU.
name.Min name.Min Min The minimum expected
value for this data
dictionary entry.
name.Max name.Max Max The maximum expected
value for this data
dictionary entry.
name.Enums name.Enums Enums A comma separated
list of oe.Parameter
objects which provide
the possible values this
data dictionary entry can
be. This property can be
left blank.
name name Defn This property is optional.
.CoderInfo .CoderInfo It specifies the file in
.CustomAttributes .CustomAttributes which the equivalent
.DefinitionFile .DefinitionFile C variable for the DDE
will be defined. Only
applicable when using
Embedded Coder, the
property is ignored for
other auto-coders.
name name Decl This property is optional.
.CoderInfo .CoderInfo It specifies the file in
.CustomAttributes .CustomAttributes which the equivalent
.HeaderFile .HeaderFile C variable for the DDE
will be declared. Only
applicable when using
Embedded Coder, the
property is ignored for
other auto-coders.
With a Simulink data dictionary, in order to make each variable available in a calibration tool,
the variable must have certain properties set in order to control the storage of that variable.
The properties must be set differently depending on the auto-coder used (see Section 4.3.2,
“Auto-coders” for more details about auto-coders), and the desired type and scope of the
variable.
The following table details the desired variable type in the model or calibration tool, and the
data object and properties required for each auto-coder which must be set to generate that
variable in the model and make available in the calibration tool:

Software overview
Table 4.4. Simulink data dictionary object storage classes
Variable Auto Data object Properties

type coder
Constant any oe.Parameter name
scalars .CoderInfo
.StorageClass = 'Auto'
Calibration GRT oe.Parameter name
scalars RTMODEL .CoderInfo
.StorageClass = 'ExportedGlobal'
Calibration
maps (1d
or 2d), or
Arrays
Displayable GRT oe.Signal name
signals RTMODEL .CoderInfo
.StorageClass = 'ExportedGlobal'
Calibration EC oe.Parameter name
scalars .CoderInfo
.StorageClass = 'Custom'
Calibration
maps (1d name
or 2d), or .CoderInfo
.CustomStorageClass = 'Global'
Arrays
name
.CoderInfo
.CustomAttributes
.MemorySection = 'Calibration'
Displayable EC oe.Signal name
signals .CoderInfo
.StorageClass = 'Custom'
name
.CoderInfo
.CustomStorageClass = 'Global'
name
.CoderInfo
.CustomAttributes
.MemorySection = 'Displayable'
Note
In the Model Explorer interface, the name.CoderInfo.StorageClass, and
name.CoderInfo.CustomStorageClass, properties are normally merged into the
same drop down selection field. The 'Global (Custom)' selection will select both
name.CoderInfo.StorageClass = 'Custom' and name.CoderInfo.CustomStorageClass
= 'Global' at the same time.
A model configured to use a text based data dictionary can be automatically converted to
use a Simulink data dictionary with all of the existing data dictionary entries imported into
the .sldd file by calling the following command:

Software overview
oe_config_using_sim_dd
at MATLAB's command prompt.
By default, the script will convert the currently active model, using the data dictionary file
name model-name.sldd. If the data dictionary file already exists it can be overwritten with
additional parameters. See details at oe_config_using_sim_dd.
In addition to the previously mentioned data dictionary variables, additional data can also be
stored in a Simulink data dictionary file, such as Simulink.Bus objects, Simulink enum type
definitions, Configuration Sets, and other built-in Simulink types. Please refer to the Simulink
documentation for further details on the data that can be stored in a Simulink data dictionary
file.
4.2.2.3. Units file

A units file is a simple text file format, where each line represents a single allowable unit.
When a model is loaded, the data dictionary entries and unit entries are read, and any data
dictionary that does not use one of the unit entries raises a warning.
A units file is only supported with text based data dictionaries.
A units file is stored in the same directory as the model. A units file for a model must
have the file-name model-name_units.txt where model-name is replaced by the name
of the model. An example units file for a model named read_sensor would be named
read_sensor_units.txt and might look like:
degC
kPa
In this example, only two units: degC or kPa, can be used for each data dictionary entry.
To help readability, comment lines can be inserted into the units file. Comment lines are
ignored and start with either a ** or the -- character sequence. For example:
** Allowable units for the read_sensor model

degC
kPa
4.2.2.4. Build list file

A build list file is a simple m-script that specifies what the data dictionary files are called.
When a model is loaded, the build list is read to determine which data dictionaries are to be
read into MATLAB's workspace.
A build list file for a model must have the file-name model-name_bl.m where model-
name is replaced by the name of the model. An example build list file for a model named
read_sensor would be named read_sensor_bl.m and would like very similar to:
feature_list = [{'min',
'mot'}];
In this example, the build list defines two data dictionary files, named min and mot. Further
data dictionary files can be added by extending the vector feature_list. It is important to
use three characters for each data dictionary name.
If a model is configured to use a Simulink data dictionary, the build list file will only list the
feature directories which are to be added to the MATLAB path. The data dictionary files are
specified within the model properties.

Software overview
4.2.3. Update model

The update model stage adds or adjusts the functionality of the model. It's important to keep
the data dictionary files up to date with changes to the model. It's easy to leave changes
to the data dictionary until later, but that often leads to multiple build and update cycles as
missing data dictionary elements are found during the testing stage.
Before Simulink starts to simulate a model on the host PC, or builds a model to run on an ECU,
Simulink attempts to solve the model and applies consistency checks during the solving. This
process is called a diagram update. A diagram update can be performed at any point by
pressing CTRL+D in a model window, or by selecting the Edit -> Update diagram.
Note
It is useful to periodically update the model diagram to check that everything has been
accounted for. However, Simulink does not provide a mechanism for OpenECU to
ensure the text based data dictionary files have been incorporated into the model.
Therefore, if the data dictionary files have been updated, prior to a diagram update,
the user must issue the following command:
oe_read_build_list
at MATLAB's command prompt to ask OpenECU to read the data dictionary files.
4.2.3.1. Model composition

If you are unfamiliar with Simulink models then note that it is worth the extra effort up front
to partition your application into smaller blocks of functionality. Each block of functionality
is placed in a subsystem. With complex areas of functionality, breaking those areas of
functionality into less complex interrelated blocks, each within a subsystem, can help
readability.
Simulink provides a Model Explorer tool which makes it easy to navigate between parts of
the model based on the hierarchy of the subsystems. And OpenECU can incorporate the
model hierarchy into the files used to communicate with the ECU while the ECU is running
the model.
For instance, at a top level, a useful pattern to follow breaks the model into an input, output
and application subsystem.
Figure 4.6. Breaking the input and output processing from the
application
Out1 In1 Out1 In1
Input Model Output

Processing Processing Processing
Input processing
The input subsystem reads sensor and actuator feedback signals
and decodes communication messages, transforming raw sensor
information into engineering units (possibly applying filters and other
validation techniques to ensure the input data is usable). The input

Software overview
subsystem can be broken down into further subsystems, perhaps one to

read the raw sensor information, one to process into engineering units,
and one to validate the inputs (perhaps against other sensor inputs or
against a plant model of the system under control).
Application processing
The model subsystem processes the input subsystem data, determining
how the system it is controlling should react. The model subsystem
would be further broken down into smaller subsystems, each performing
a small portion of the overall functionality. The model subsystem creates
the data in engineering units necessary to drive the output subsystem.
Output processing
The output subsystem drives the actuators connected to the ECU to
achieve the demands of the model subsystem.
By breaking the model into these subsystems, the input and output subsystems can easily
be replaced when targeting another ECU. For instance, when moving to a more powerful
ECU because the application has grown, or when moving to a less powerful ECU because
the production needs for the prototyped application mean a cheaper ECU can be used.
4.2.4. Simulate model

Simulink provides a mechanism to simulate the model on the host PC. Please refer to the
Simulink documentation for further details. Note that while simulation has many uses, it is
not necessary to simulate the model before building the model to run on an ECU.
4.2.5. Build model

With the application model and data dictionary files in place, the application model can be
built and linked with the OpenECU and compiler libraries to generate a binary image which
can be programmed and run on an OpenECU.
To start a build, press CTRL+B in a model window, or select the menu option Tools -> Real-
Time Workshop -> Build model.
Detail on the build process, the generated build files and a summary of common issues can
be found in Section 4.3.6, “Building a model”.
4.2.6. Program ECU with model

Supporting tools.
tool over CAN as shown in the following diagram.

Software overview
FEPS 17-19V, 0V
IGN Power supply
VPWR 12V DC
OpenECU GND 0V
Calibration
CAN0-L, CAN0-H CAN
2 Tool

M221 M250 M461 M580 M670 M220 A43 A28 No


Software overview
The OpenECU device can be programmed by following these steps:
1. Apply a positive FEPS voltage, as given in the following table and then power cycle the
ECU (the FEPS signal may not be detected if applied simultaneously with the ECU power).
Upon detecting the FEPS signal the ECU is placed into its reprogramming mode, where
it does not run the application and responds only to reprogramming commands.
2. Program the ECU following the instructions in Appendix B, Supporting tools.
3. Once programmed, ground the FEPS pin and power cycle the ECU. This places the ECU
in its application mode, where the ECU runs the programmed application.

M560
M580 Result
settings.
4.2.7. Test model

Once the ECU has been programmed, the ECU remains in reprogramming mode until the
ECU is restarted by power cycling the ECU. Without FEPS applied, the ECU will enter
application mode and run the model.
The testing phase seeks to ensure that the built Simulink model acts as expected under
all circumstances. OpenECU provides a CCP interface to allow calibration tools to access
model information. See Appendix B, Supporting tools for an introduction to how to use one
of the supported calibration tools to monitor the model while it runs on the ECU.
4.3. Simulink and OpenECU

The OpenECU blockset provides varied access to the features of both Simulink and the target
ECU. The OpenECU blockset includes a real-time operating system, methods to measure
input quantities from ECU pins and internal ECU signals, methods to receive and transmit
CAN messages, and a host of other functions. See Section 4.6, “OpenECU blockset features”
for details.
The OpenECU blockset works with most Simulink and RTW features. However, there are
a small number of restrictions. For instance, the OpenECU blockset is a discrete blockset
and does not work with continuous time blocks. See Section 4.3.1, “Block use restrictions”
for details.

Software overview
The OpenECU blockset provides a number of additional RTW options. These options include
setting the application stack size, controlling what binary files are created at the end of a
build, through to selecting which compiler to use. See Section 4.3.4, “Configuration options”
for details.
The OpenECU blockset works with RTW's auto-coders: Generic Real-Time (GRT) and
Embedded Coder (EC). The blockset provides mechanisms to create configuration sets
(which are sets of parameters which tell RTW how to generate code) for each of the
auto-coders, and some utility blocks to quickly switch between configuration sets. See
Section 4.3.2, “Auto-coders” for details.
4.3.1. Block use restrictions

While OpenECU works with most of the functionality of Simulink and RTW, there are only a
few major restrictions when using the OpenECU blockset in conjunction with RTW. Those
that must be avoided are discussed in more detail below.
Cannot use continuous blocks

For some targets the auto-code generator cannot produce code for
these blocks, and for those for which it can there is significant
computational overhead. See the Simulink documentation for a list of
continuous time blocks (including Derivative, Integrator, Memory, State-
Space, Transfer Fcn, Transport Delay, Variable Transport Delay, Zero-
Pole).
Cannot divide by zero

Division by zero, or overflow due to division by very small numbers, will
cause the model running on the OpenECU target hardware to create
a large number (approximately 3.4E38) which will propagate into any
calculation which uses it (M110, M220, M221, M250, M460, M461, M560
and M670 targets). Restrict division by clamping the divisor to a finite,
non-zero number.
Cannot use algebraic loops

These occur when the output of a calculation appears as one of its
inputs. In many applications a variable is updated based on a previous
value. In such cases a loop can be avoided by inserting a unit delay (1/
z) block. RTW cannot produce code if algebraic loops exist.
For readability purposes, it is best to show a unit delay block used to

avoid an algebraic loop flowing from right to left. Where a unit delay block
is used for other purposes (such as comparing successive values of a
flow) it should be shown flowing left to right.
Cannot use blocks that access elapsed timers

The concept of elapsed timers is not supported. These are where
instead of blocks using an absolute time reference to determine the time
between successive iterations, the time between successive iterations
are determined relative to each other. This is a restriction imposed by
the OpenECU product, not RTW.
Cannot use dynamic memory

Blocks that require the use of C malloc() or C++ new(), or other
dynamic memory are not supported. This is a restriction imposed by the
OpenECU product, not RTW.
Cannot use C++

Blocks that require the use of C++ are not supported. This is a restriction
imposed by the OpenECU product, not RTW.

Software overview
Cannot use non-inlined S-functions

User written non-inlined S-functions or other blocks that are non-inlined
are not supported. This is a restriction imposed by the OpenECU
product, not RTW.
Note that inlined S-functions are supported, see Section C.2, “Custom
C code” for more.
Shared utility source and model references

Shared utility source and model references are only supported in
Embedded Coder. Model references only support the put_Identification
block. No other OpenECU block is supported in model references, only
native Simulink blocks. This is a restriction imposed by the OpenECU
product, not RTW.
Cannot iterate quicker than 1 millisecond

OpenECU schedules model rate tasks at a resolution of 1 millisecond.
This is a restriction imposed by the OpenECU product, not RTW.
4.3.2. Auto-coders
Simulink Coder (formerly Real-Time Workshop) provides a number of different auto-coders,
each with increasing levels of functionality:
Generic Real-Time — RTMODEL

The GRT RTMODEL auto-coder is available with a license of Simulink
Coder (or Real-Time Workshop) and provides the next level of auto-
coding.
Although similar to GRT RSIM, the overall structure of the generated

code is more like Embedded Coder. This auto-coder provides better
memory use (making more memory available to the model) and
generates better code in some situations.
This auto-coder is appropriate for rapid-prototyping tasks only.
Embedded Coder
The EC auto-coder is available with a license of Embedded Coder (or
Real-Time Workshop Embedded Coder). This license is separate from
the Simulink Coder license.
This auto-coder provides good control over the generation of functions,

of variable and function naming, of memory allocation and code layout
within files. This auto-coder improves on memory use and again
generates better code in various situations.
These improvements make this auto-coder suitable for production tasks.
See OpenECU Compatibility with Third Party Tools for a complete list of supported coder
versions.
OpenECU provides a collection of configuration sets to select between each of these auto-
coders.
4.3.3. Configuration sets

A configuration set comprises groups of related parameters called components. These
components provide various options which control how an auto-coder generates code from
a model. Configuration sets can be viewed through Simulink's Model Explorer.

Software overview
Figure 4.7. Simulink's Model Explorer showing OpenECU configuration

sets
The picture in Figure 4.7, “Simulink's Model Explorer showing OpenECU configuration sets”
shows an OpenECU configuration set for each of the auto-coders described in Section 4.3.2,
“Auto-coders”. Only one configuration set is used at any time and Simulink shows this by
marking it active (in this case, the GRT RTMODEL auto-coder is active).
Each of the components is listed in the middle pane. Selecting any of the components shows
the component options in the right hand pane. Although it is possible to modify these options,
it is recommended that models keep the original OpenECU settings.
4.3.4. Configuration options

OpenECU provides a number of configuration options which affect the build process.
The options can be accessed by opening an OpenECU model and selecting the menu
option Simulation-> Configuration Parameters... (or Simulation-> Model
Configuration Parameters in later versions of Simulink) then browsing to the OpenECU
options under Real-Time Workshop (or Code Generation in later versions of Simulink).
Under the Real-Time Workshop (or Code Generation in later versions of Simulink)
categories, there are both built-in Simulink options, and OpenECU additional options.
The built-in Simulink options that OpenECU recognizes are:
• Interface
Interface
The OpenECU build process will recognize the "ASAP2" setting for this parameter.
This option will set the parameter 'GenerateASAP2' to 'on', and during the build
process, an ASAP2 file will be generated using Simulink's built-in ASAP2 generation
process in place of the OpenECU ASAP2 generation process.
The OpenECU additional options are grouped into the following categories:
• OpenECU code generation options
This group of options affects the model generated code before it is built.

Software overview
Maximum data dictionary entry name length

Specify the maximum data dictionary entry name length,the range should be between
31 and 255 characters. If a data dictionary identifiers exceeds the maximum length
then a warning will be generated and the name will be shortened during the ASAP2
generation. If length is given a value of 0, then there will be no limit on identifier length.
Re-read build list before building

When this option is selected and a build starts, OpenECU reads the build list and
data dictionaries. This brings the latest information from the data dictionaries into the
workspace and overwrites any changes to existing entries in the workspace.
System stack size

Specifies the amount of RAM dedicated to stack usage. Stack is used by the auto-
generated code and platform to maintain a working store of calculations. The default
size of the stack is 5KB which should be large enough for most models. The size can
be changed by altering the default, for instance, by reducing the value based on the
automatic ASAP2 variable mpl_max_used_stack to provide more RAM for model
functionality.
• OpenECU image generation options
This group of options affects what images are generated at the end of a build. An image
is downloaded or flashed onto the ECU to run on target.
Generate image as a S-record file

If selected, the OpenECU build process will generate a Motorola S-record file which
represents the image to download. If not selected, the file is not produced (or deleted
if it previously existed).
If the S-record file is produced, it is named model_name_image_small.s37 where

model_name is replaced by the name of the model.
Generate image as a Intel HEX file

If selected, the OpenECU build process will generate an Intel HEX files which represent
the image to download. If not selected, the file is not produced (or deleted if it previously
existed).
If the HEX file is produced, it is named model_name_image_small.hex where

model_name is replaced by the name of the model.
Generate ATI Vision strategy file

If selected, the OpenECU build process will attempt to generate an ATI Vision strategy
file. The build process does this by invoking the ATI Vision tool, so the tool must be
installed on the machine which builds the model. This feature is supported if the ATI
Vision software is version 2.0 or above.
If not selected, the Vision strategy file is not produced (or is deleted if it previously
existed).
If a strategy file is produced, it is named model_name.vst where model_name is

replaced by the name of the model.
Continue building if creation of ATI Vision strategy file fails

If selected, the OpenECU build process will ignore any failures to generate an ATI
Vision strategy file. This can occur, if the wrong version of ATI Vision is used to
generate the strategy file.
If not selected, the OpenECU build process will stop when there is a failure to generate
an ATI Vision strategy file.

Software overview
• OpenECU ASAP2 generation options
This group of options affects the ASAP2 generated file (and the ATI Vision Strategy file
if selected).
ASAP2 naming scheme

This option provides a number of naming schemes that can transform the DD entry
names in any generated ASAP2 file.
Data dictionary names take the form prefix_name (as detailed in Section 5.2.5,
“Naming rules”) and are used for each ASAP2 entry. Some calibration tools can group
names together based on the prefix (for instance, ATI Vision's Structure naming:
Names as groups import feature). This feature converts the data dictionary names
before inserting them into the ASAP2 file to match tool features.
Table 4.6. ASAP2 naming schemes
Scheme Description
prefix_name Keep data dictionary names unchanged, e.g.,
mbe_engine_rpm remains as mbe_engine_rpm
prefix.name Change mbe_engine_rpm to mbe.engine_rpm
prefix.name_prefix Change mbe_engine_rpm to mbe.engine_rpm_mbe
name Change mbe_engine_rpm to engine_rpm
name_prefix Change mbe_engine_rpm to engine_rpm_mbe
Generate automatic platform ASAP2 entries

If selected, the OpenECU build will generate a set of ASAP2 entries with the prefix
mpl. These entries provide information about the build time and run time as detailed
in Section 6.2, “Automatic ASAP2 entries”.
If not selected, these automatic variables are not generated.
Generate generic ASAP2 file

If selected, the OpenECU build process will generate a generic ASAP2 file that should
be readable by any calibration tool. The ASAP2 file contains only information about
DD entries. The user will need to tell the tool about memory regions and CCP settings.
If not selected, the generic file is not produced (or deleted if it previously existed).
If a generic ASAP2 file is produced, it is named model_name_tool_generic.a2l

where model_name is replaced by the name of the model.
Generate ATI Vision ASAP2 file

If selected, the OpenECU build process will generate an ASAP2 file tailored specifically
for the ATI Vision calibration tool. If not selected, the Vision file is not produced (or
deleted if it previously existed).
If a ATI Vision ASAP2 file is produced, it is named model_name_tool_vision.a2l

Note
If the Generate ATI Vision Strategy file option is selected, this option need not
be selected.

Software overview
Generate ETAS INCA ASAP2 file

for the ETAS INCA calibration tool. If not selected, the ETAS INCA file is not produced
(or deleted if it previously existed).
If a ETAS INCA ASAP2 file is produced, it is named model_name_tool_inca.a2l

Generate Vector CANape ASAP2 file

for the Vector CANape calibration tool. If not selected, the Vector CANape file is not
produced (or deleted if it previously existed).
If a Vector CANape ASAP2 file is produced, it is named

model_name_tool_canape.a2l where model_name is replaced by the name of
the model.
Generate DDEs for DTC parameters

If selected, the OpenECU build process will add DDEs to the generated ASAP2 file, to
enabled calibration of J1939 and J1979 IDs. The generated DDEs will be named <DTC
name>_<parameter>. If not selected, DDEs will not be added to the generated file.
Derive ASAP2 array and map sizes from the workspace

If selected, the OpenECU build process will generate an ASAP2 file using the array
and map sizes found in the workspace, not the build list DDE files.
For instance, if a DDE is declared as having 4 elements but the workspace is modified
to have 5 elements after the build list has been read, then if this option is selected,
a build will generate an ASAP2 file which specifies 5 elements for that DDE. If this
option is not selected, a build will generate an ASAP2 file which specifies 4 elements
for that DDE.
Note
This feature requires that the RTW option Re-read build list before building is not
selected. If it is selected, then at the start of a build, OpenECU will re-read the
build list DDE files, overwriting any changes made to the equivalent workspace
variables.
Generate old style ASAP2 map names

If selected, the OpenECU build process will generate old-style ASAP2 map names.
Old style ASAP2 map names contain _z at the end of the map name. This usage was
used in releases older than version 1.9.0 and this option was introduced to allow for
backwards compatibility of calibration files.
• OpenECU compiler selection
This group of options selects between the available supported compiler versions for
OpenECU models.
Compiler
Which compiler to use to build an OpenECU model. The compiler and linker options
can be adjusted using the pcomp_CompileOptions and pcomp_LinkOptions blocks.
• OpenECU target settings
This group of options is used for model reference only in Embedded Coder. It is ignored
in all other auto-coders.

Software overview
Propogate settings to Model References

Clicking this button will propogate the target settings from the current model to all of
the model reference blocks used within this model. If the model is not in memory,
it will be loaded and then saved. Clicking this button has the same effect as calling
oe_propogate_target_settings(bdroot) from MATLAB's command window.
ECU type
Specifies the ECU that the model will run on (e.g. M250, M460, etc.). This field is used
only for model reference targets. For all other models use the put_Identification block
in your model. The put_Identification block will automatically make changes to this field
when present in the model.
Part number
Specifies the part number that appears on the ECU casing, followed by a hyphen and
three character suffix. The suffix denotes the option. The part number must match the
ECU type field (e.g. M250 option 000 = 01T-068276-000). This field is used only for
model reference targets. For all other models use the put_Identification block in your
model. The put_Identification block will automatically make changes to this field when
present in the model.
Issue number
Specifies the issue or revision number of the ECU. This is the first number that appears
after the hardware part number on the label of the ECU. This field is used only for
model reference targets. For all other models use the put_Identification block in your
model. The put_Identification block will automatically make changes to this field when
present in the model.
• OpenECU data dictionary
This group of options affects the data dictionary used for building and simulating a model.
Use oe data objects

If selected, oe.Parameter and oe.Signal objects are used when reading a text
based data dictionary file with any auto-coder selected. If using a Simulink based data
dictionary, this option is ignored, and oe data objects will always be used.
Disable naming convention

If selected the naming convention rules can be disabled, only if the model is configured
to use a Simulink data dictionary and the 'Use oe data objects' option is selected. This
option is disabled if 'Use oe data objects' is not selected, and cannot be used to disable
the naming convention when using text based data dictionaries.
• OpenECU checksum configuration
This group of options affects the checksums that are applied to the application and
calibration data.
Checksum Type
Specifies checksum type. This checksum is calculated at build time and stored as
part of the binary image. It is compared with another checksum that is calculated on
the ECU during startup. If the checksums do not match, then the application is not
permitted to run. The CRC checksum is more likely to detect errors than the IPv4 style
checksum, but it takes significantly longer for the ECU to calculate during initialization.
Checksum Regions
Specifies regions to checksum. If this is set to include the calibration, then care must
be taken when using calibration tools. The tools will be able to modify calibrations, but
once the modifications are flashed the checksum will be invalidated and the application
will not be permitted to run.

Software overview
4.3.5. Selecting an auto-coder

Switching between configuration sets changes the RTW auto-coder. This can be done one of
two ways: right click on the configuration set in Simulink's Model Explorer and select Activate;
or place one (or more) of the prtw_ConfigUsingRtwEc, prtw_ConfigUsingRtwRtmodel helper
blocks in the model and double click the appropriate one.
The helper blocks perform a couple of actions which the Model Explorer won't.
• The helper blocks will create an appropriate configuration set if one isn't available. This
can be useful if a configuration set has been accidentally removed, or if more than one
configuration set for the same auto-coder is required (perhaps to experiment with RTW
options for that auto-coder).
• The helper blocks will read the build list and populate the workspace with DDEs. This
occurs because the EC auto-coder requires the workspace variables to have different types
from the GRT auto-coders. See Section 4.3.5.2, “Using the EC auto-coder” for more.
Note
Note that there is a prtw_Build helper block which starts a model build when double
clicked.
4.3.5.1. Using the GRT (RTMODEL) auto-coder

Add a prtw_ConfigUsingRtwRtmodel block to the model and double click the block to select
the GRT (RTMODEL) auto-coder.
There is little about this auto-coder and OpenECU which is configurable. Its worth noting that
the data dictionary elements are available in the workspace using basic MATLAB types. The
data dictionary elements can be used as any other MATLAB variable in scripts and general
calculations.
4.3.5.2. Using the EC auto-coder

Add a prtw_ConfigUsingRtwEc block to the model and double click the block to select the
ERT (EC) auto-coder.
4.3.5.2.1. Data dictionary elements

Like the other auto-coders, the data dictionary elements are used to populate the
workspace, but instead of using the basic MATLAB types, the workspace variables use
the custom storage class oe.Signal to represent named signal lines between blocks,
and oe.Parameter to represent block parameters (either constants or calibrations). These
variables cannot be used as other MATLAB variables because these types contain many
pieces of information.
To access the value for a parameter, use the expression [variable-name].Value. There
is no value for signals stored in MATLAB's workspace.
It can be useful to switch between the EC auto-coder and other auto-coders using the
OpenECU utility blocks. When switching to a GRT auto-coder, the data dictionary is read
into the workspace using MATLAB's basic types, and can be accessed like other MATLAB
variables.
4.3.5.2.2. C variable types

OpenECU uses Embedded Coder's Data Type Replacement feature to match the type of
each C variable in the model to the same variable type used by the OpenECU library code.

Software overview
Simulink Type OpenECU Type Description

double FREAL Floating point type, 64-bits wide. Some OpenECU
targets support 64-bit wide floating point types and
some don't. On those that do support 64-bit wide
floats, none have native support from the processor
and require significant software emulation support,
slowing down the application. For that reason,
OpenECU implements Simulink 64-bit wide floating
point type as a 32-bit floating point type (which is
what FREAL resolves to).
single F32 Floating point type, 32-bits wide. See the
technical specification for the ECU regarding the
implementation of floating point support.
int32 S32 Signed integer, 32-bits wide.
uint32 U32 Unsigned integer, 32-bits wide.
boolean BOOL Boolean type, at least 1-bit wide, typically 8-bits wide.
int INT Signed integer, at least 16-bits wide.
uint UINT Unsigned integer, at least 16-bits wide.
This ensures that the model code and library code match when linked together, and can also
help when checking code compliance against various coding standards (e.g., with MISRA-
C, Guidelines for the use of the C language in critical systems).
4.3.5.2.3. C file templates

OpenECU uses Embedded Coder's Templates feature to provide a consistent structure to
each source code file generated by Embedded Coder. To that end, OpenECU provides
templates stored in a sub-directory to the Embedded Coder template makefile for OpenECU.
If alternative templates are required then modify the configuration set for Embedded Coder
to point to alternative files. But note that each time the OpenECU Embedded Coder
configuration set is created, the templates will need to be modified again.
Note
The model can be broken into source files using subsystems. Functionality contained
in a subsystem, which has a Real-Time Workshop system code set to Function, can
specify the file into which the functionality of the subsystem is auto-coded.
4.3.5.2.4. C data placement

OpenECU uses Embedded Coder's Data Placement feature to provide a mechanism to place
declarations and definitions of C variables in specific files.
By default, declarations and definitions are placed in globals.h and globals.c, but these
settings can be overridden by changing the name in the configuration set. But note that each
time the OpenECU Embedded Coder configuration set is created, the data placement files
will need to be modified again.

Software overview
Variables can also be placed in specific files by specifying the file to use in the data dictionary,
under the decl and defn columns. See Table 4.2, “Data dictionary columns” for more.
4.3.6. Building a model

As outlined in Section 4.2.5, “Build model”, a model build creates the target ECU images
which can be programmed onto an ECU and run in real-time. Figure 4.8, “Building an
application (in outline)” gives an outline of the build process.
Figure 4.8. Building an application (in outline)
Inputs to build process
Data OpenECU
Simulink
dictionary blockset
model
files
Inputs from elsewhere

1
OpenECU
library
file
Auto code
from RTW
Compiler
library
files
2
Intermediate build steps
Linker
script
files
Object
files
MAP ELF
file file
5 4
Target Target
ASAP2 image
file file
Final outputs from build process
The build process has a number of inputs:
Data dictionary files

The data dictionary files describe the data variables of the application
code. Data variables are all C global variables, either RAM or ROM

Software overview
based. For each data variable which must be accessible from the
calibration tool, there is a corresponding data dictionary element (DDE)
which details attributes of the data variable, like description, type, units,
and so on. See Section 4.2.2.2, “Data dictionary files”. for more.
The user must provide the data dictionaries.
Simulink model
The application in model form. There are some restrictions on what the
model can contain, see Section 4.3.1, “Block use restrictions”.
The user must provide the model.
Simulink blockset
Supporting Simulink blocks which provide direct access to the ECU's
functionality. OpenECU software provides the Simulink blockset. An
overview of the blockset is given in Section 4.6, “OpenECU blockset
features”.
OpenECU library files

One or more compiler specific library files for OpenECU. The library files
are linked with the application object files to create a binary image for
execution on the target.
OpenECU software provides the library files.
Compiler library file

The compiler's own support libraries (e.g., implementation of the C
standard library or compiler specific extensions).
The compiler software provides the library file.
Linker script files

The scripts tell the compiler how to combine the application object files,
interface object files and libraries to create the binary image to run on
the target ECU. This includes details about the layout of memory and
how object file sections are allocated to memory.
OpenECU software provides the linker files.
The inputs are processed in a number of steps to create intermediate objects:
1. Runs RTW to generate C code from the Simulink model and DDEs. The
generated C code includes the implementation of the model logic and
any necessary code to bind the model with the OpenECU and compiler
libraries.
2. Runs the compiler for the application code files. The compiler generates
object files used in the link stage.
3. Runs the linker to combine the object files from the application and
interface tool, as well as the compiler's library and OpenECU libraries, to
generate an ELF file.
4. Runs support tools and scripts to extract a binary image of the application
from the ELF file. At this stage, the binary image is modified with check-
sums and auxiliary data to support robust operation on the ECU.
5. Runs support tools and scripts to generate an ASAP2 file from the target
and DDE information. The ASAP2 file is used during reprogramming and
calibration of the ECU.

Software overview
From those intermediate steps, the final set of objects are created:
Target ASAP2 file

An ASAP2 file details the memory areas used by the binary application
image as well as how DDEs have been allocated to memory. The ASAP2
file is used by PC based tools to reprogram an ECU or to calibrate
an ECU. See Section 4.5, “Programming an ECU” and Appendix B,
Supporting tools for more.
Target image file

The target image file contains the binary image of the application
code and data. Once an ECU is programmed with the image file, the
application can be executed. See Section 4.5, “Programming an ECU”
for more.
To build the executable code for the ECU, select the model window so it becomes focused
then press CTRL+B to start the RTW build. Alternatively, place a prtw_Build block in the model
and double click the block.
The build process starts by re-reading the build list to ensure the latest DDE information is
present when generating the ASAP2 file.
### Starting Real-Time Workshop build procedure (with modification for OpenECU) for model:
Clearing any previously loaded build list...
Obtaining workspace data from each feature data dictionary...
Workspace variables loaded
The build then continues with the standard RTW build mechanism with a few additions for
OpenECU. In some earlier versions of RTW, if this is the first time the model has been built,
the build creates the RTW library which can take some minutes to complete. Subsequent
builds of the same model skip this part of the build.
4.3.6.1. Build output

During the build, MATLAB will display a series of diagnostic and status messages with
respect to the build. In MATLAB versions prior to r2014b, all messages will be logged to the
main MATLAB console.
In MATLAB versions r2014b and later messages will be logged to The Diagnostic viewer
window. This window can be viewed by clicking the link at the bottom of the model window.
4.3.6.2. Results of a build

If the build is successful, a number of files will be created:
• model_name_tool_generic.a2l — the generic ASAP2 file for the build model;

• model_name_tool_inca.a2l — the ETAS INCA specific ASAP2 file for the build model;
• model_name_tool_vision.a2l — the ATI Vision specific ASAP2 file for the build model;
• model_name_tool_canape.a2l — the Vector CANape specific ASAP2 file for the build
model;
• model_name_tool_vision.vst — the ATI Vision Strategy file for the build model
(combined ASAP2 and S-record file — only generated if a compatible version of ATI Vision
is installed, see the image generation options in Section 4.3.4, “Configuration options”);
• model_name.a2l.err — any errors that resulted from creating the ASAP2 file (if there are
any errors, a short extract is displayed at the end of the build);

Software overview
• model_name_image_small.s37 — the image bytes to program into the OpenECU in

Motorola S-record format (small representing the minimum amount of code and data bytes
to program the OpenECU device) — suitable for the ATI Vision calibration tool;
• model_name_image_small.hex — the image bytes to program into the OpenECU in Intel
HEX format — suitable for the Vector CANape calibration tool;
• model_name.elf — the compiler's version of some of the above files — suitable for the
PiSnoop development tool;
• model_name.snx — lists of variables PiSnoop will show or hide automatically — suitable
for the PiSnoop development tool;
where the text model_name denotes the name of your .mdl model file. Each of these files
can be found in the same directory as your model file.
Note
A subset of these files can be produced by altering the OpenECU RTW options
(accessed by opening an OpenECU model and selecting the menu option
Simulation -> Simulation parameters... then browsing to the OpenECU
options under Real-Time Workshop. More details on these settings are given in
Section 4.3.4, “Configuration options”.
One of the ASAP2 files and one of the image files can now be used with a calibration tool
to program the ECU via CCP (or if you are using a recent version of ATI Vision, you can
simply use the strategy file).
Also at the end of a successful build, a short summary of the memory used by the model is
displayed. It looks a little like:
Strategy memory:
142696 bytes of strategy/code memory used
250519 bytes remaining
Calibration memory:
3376 bytes of calibration memory used (rough indication, includes Simulink support data)
Workspace memory:
14040 bytes of workspace/displayable memory used, including
176 bytes of adaptive data, and
2 bytes of diagnostic trouble code data, and
8192 bytes of model stack
Built at: 2005, 08, 02 (year, month, day) 10:52:47 (hour:min:sec)
but the values will vary based on your model.
Strategy memory
Shows the amount of model code used and remaining.
Calibration memory
Shows the amount of calibration data (as well as Simulink support data)
used and remaining.
Workspace memory
Shows the amount of used and remaining RAM, where RAM is used
for general model calculations and signals, adaptive data and overall
program stack.
As your model develops, it is useful to take regular snap shots of the memory usage to
determine how quickly development is using up memory (and the same can be done by taking
regular snap shots of the ASAP2 variables mpl_cpu_loaded and mpl_max_used_stack
to determine how quickly development is using up CPU resources).

Software overview
4.3.6.3. Long build times

There are a couple of sources of long build times.
Building the RTW library source code

It can take some time to build the RTW sources, increasing in duration
with increasing versions of MATLAB.
The commands to compile the RTW sources are easily recognisable

during a build, where each source file that belongs to the RTW library
starts with rt_.
dcc -@mk_rtw_cc_opts.cfg -o rt_atan2.o [path]\rt_atan2.c

...
Versions of MATLAB after R2008a (inclusive) do not require the RTW

library source code to be built in full and do not suffer from the larger
compile times when building a model for the first time.
Building the model source code

With versions of Diab 5.5.1.0 and later, larger models can take a
significant amount of time to compile. This is due to a buffer size issue
with the compiler. See Section 2.5.8.3, “Known issues” for a description
of the work around to be used with the pcomp_CompileOptions block.
4.3.6.4. Common build warnings and errors

There are a couple of warnings and errors that occur more often than others and its worth
reviewing those here:
Cannot find the Diab compiler

An error message, similar to the following, indicates that the Diab
compiler could not be found.
dcc -@mk_rtw_cc_opts.cfg -o [file-name].o [path to file].c

'dcc' is not recognized as an internal or external command,
operable program or batch file.
In order for the Diab compiler to run, the compiler must be installed
and the the path to the compiler must be specified in one of two
environment variables. See the instructions provided in the installation
guide, Section 2.5, “Integration notes for third party tools”.
Cannot run the Diab compiler

An error message, similar to any of the following, indicates that the Diab
compiler cannot find a license.
fatal error (dcc:1635): License error: FLEXlm error:

Cannot find license file (-1,73:2 "No such file or directory")
fatal error (dcc:1635): License error: FLEXlm error:
No such feature exists (-5,357)
In order for the Diab compiler to run, it must have access to a valid
license. The Diab compiler license is created by WindRiver after you
purchase the compiler. If you run into trouble with your Diab compiler
license, please contact OpenECU technical support and we will try to
help out.
Model too large for ECU memory space

An error message, similar to any of the following, indicates that the
model has become too large for the target ECU.

Software overview
dld -@mk_model_link_opts.cfg -@O=[model-name].map -o [model-name].elf

dld: '.' (0x[string]) is assigned invalid value: 0x[string]
The ECU has various memory spaces of finite size. If the model
becomes too large to fit into these memory spaces, then the Diab linker
will raise an error. It may be possible to optimise the build to reduce the
final model size. Please contact OpenECU technical support and we will
try to help out.
Model uses absolute time

A warning message, similar to the following, indicates that the model
uses absolute time.
### RTW build information:

Warning: the RTW generated code was found to contain calls to
functions that access absolute time. See the OpenECU,
Simulink and RTW documentation about absolute time,
including a list of blocks that depend on absolute time.
After a period of time, Simulink's absolute time will
eventually saturate and blocks that use absolute time
will fail to work correctly (including some functionality
of blocks in triggered subsystems).
As part of the build process, OpenECU checks the Simulink/RTW

generated code to determine if the model uses absolute time. Absolute
time has some limitations, see Section 6.1.100, “Time (Simulink)
(ptm_SimulinkTime)” for more.
4.4. System modes

In Figure 4.9, “System modes”, each of the major system modes is shown. When the ECU is
turned on (or is recovering from a powered reset), the bootloader decides which major mode
to enter based on external inputs to the ECU.
Figure 4.9. System modes
Boot mode
Bootloader
Determine which mode

to enter.
Libraries
Reprogrammer
Application
Reprogramming mode Application mode
Boot mode
Boot mode starts after reset, performs some tests and, if successful,
determines what mode to enter (see Section 4.4.1, “Boot mode”).

Software overview
Reprogramming mode
Reprogramming mode is entered if the FEPS pin is asserted before the
ECU is powered up, if there is an invalid application image in memory,
or for certain targets if the ECU is running the application and allowing
reprogramming while a reprogramming request is received (FEPS-less)
(see Section 4.4.2, “Reprogramming mode”).
Entering reprogramming mode causes the ECU to listen to the

communication buses for reprogramming instructions. The ECU does
not run the application.
Application mode
Application mode is entered if the FEPS pin is not asserted and if there
is a valid application image in memory (see Section 4.4.3, “Application
mode”).
Entering application mode causes the ECU to run the application.

The ECU listens to the communications buses for reprogramming
instructions, but the application can inhibit reprogramming from
occurring if necessary.
4.4.1. Boot mode

When the ECU is turned on (or is recovering from a powered reset), the bootloader performs
various tests. These include:
• Tests on memory devices, looking for hard faults such as shorts on address lines, or
memory locations which cannot hold their contents;
• Tests on the code to run, looking for hard faults in the contents of code and data;
• Tests on the frequency of reset, looking for unexpected resets which occur back to back
in a short period of time.
If the tests fail then the bootloader will either reset or attempt to enter reprogramming mode,
flashing a code to indicate the cause (see the technical specification for each ECU for details
about code flashing). If the tests pass, then the bootloader will determine what mode to enter
next (see Section 4.4.2, “Reprogramming mode” and Section 4.4.3, “Application mode” for
details on how each mode is chosen).
4.4.2. Reprogramming mode

When the ECU is turned on (or is recovering from a powered reset), the bootloader will
enter reprogramming mode if the FEPS pin is asserted, if there is an invalid application
image in memory, or for certain targets if the ECU is running the application and allowing
reprogramming while a reprogramming request is received (FEPS-less).
In reprogramming mode, the ECU listens to the communications buses for instructions to
reprogram, as described in Section 4.5, “Programming an ECU”.
4.4.3. Application mode

When the ECU is turned on (or is recovering from a powered reset), the bootloader will enter
application mode if the FEPS pin is not asserted and if there is a valid application image in
memory.
When application mode is entered, the library initialises the ECU hardware and starts running
the application model.

Software overview
The platform performs various operations in the background including checks on RAM
hardware. If a RAM error is detected, an unrecoverable error is raised (resulting in ECU reset)
because program execution is otherwise likely to fail in an unpredictable manner.
Similarly non-volatile data is revalidated in the background and treated as if it is no longer

available if validation fails. Thus if run-time memory corruption occurs affecting non-volatile
data, any subsequent attempt to read that data will be handled in the same way as if the data
were not present (default used instead).
Background checking for code or calibration corruption works through the Calibration
Verification Number computation on supported targets with the OBD library option. Ensure
that the CVN is recomputed continually if run-time corruption checking is required. If it is
detected, an unrecoverable error is raised (resulting in ECU reset). This is in addition to boot-
time checksum validation.
4.5. Programming an ECU

Supporting tools. If you have another CCP compliant tool, please refer to the manufacturer's
instructions for further details in programming and refer to Appendix F, CCP compliance
which details how OpenECU complies with the CCP 2.1 standard.
tool over CAN 0 or CAN A (whichever the target ECU makes available). In some cases the
OpenECU module will need to have the FEPS line connected to a power supply capable of
up to 19 volts (depending on target), as shown in the following diagram.
Note
The FEPS voltage must be asserted before the ECU is powered up. Powering the
FEPS input and ECU simultaneously (i.e. shorting the FEPS and VPWR inputs) may
result in reprogramming mode not being detected.

Software overview
FEPS 17-19V, 0V
IGN Power supply
VPWR 12V DC
OpenECU GND 0V
Calibration
CAN0-L, CAN0-H CAN
2 Tool

M221 M250 M461 M580 M670 M220 A43 A28 No


Software overview
OpenECU operates in three system modes:
Boot mode
This is the mode initiated when the ECU is turned on (or recovering from
a powered reset). Boot mode choose whether to enter reprogramming
mode or application mode.
Reprogramming mode
This is the mode required to reprogram the OpenECU with the CCP tool.
This mode is entered differently depending on the ECU. All OpenECU
modules can be made to enter this mode by asserting the FEPS pin with
a positive voltage (above the required threshold) and power cycling the
OpenECU device.
Application mode
This is the mode required to run the application on OpenECU. Start this
mode by grounding the FEPS pin and power cycle the OpenECU device.
For the M560 and M580 targets, the next illustration shows how each mode is entered.
Figure 4.10. System modes for M560 and M580

ECU powers up (ignition or wake-on-CAN);
or ECU resets
/
Enter boot mode
Application checksum validates;

and FEPS grounded
/
Enter application mode
Boot
mode
Application checksum invalid;

CAN messages time out
or FEPS has pos or neg voltage

/
Enter reprogramming mode
ECU resets
Reprogramming Application
/
mode mode
Reprogramming request received;
and application allows reprogramming;
/
Enter reprogramming mode
There are a number of ways in which an ECU can be reprogrammed:
Reprogramming — ECU not previously programmed

Reprogramming the ECU without an application can be done with or
without FEPS on the M560 and M580.
Without a programmed application, reprogramming mode will use the

default CCP settings as defined in Table 6.3, “CCP defaults”. As
explained in the table, these settings will vary depending on the version
of firmware that is programmed into the ECU.

Software overview
Reprogramming without FEPS — ECU previously programmed (M560,

M580)
Once the ECU has been programmed with a valid application, that ECU
can be reprogrammed without having to apply FEPS.
With a programmed application, reprogramming mode will use the CCP

settings defined by the application already programmed. If an application
with different CCP settings is programmed then the new CCP settings
are used after the ECU is power cycled.
Forced reprogramming with negative FEPS (M560, M580)

The M560 and M580 can be made to use the default CCP settings
instead of the application settings by applying a negative voltage to
FEPS and then cycling power to the ECU. Reprogramming mode will
then use the default settings for CCP.
The defined CCP settings are defined in Table 6.3, “CCP defaults”. As
explained in the table, these settings will vary depending on the version
of firmware that is programmed into the ECU.
Once programmed, an ECU will remain in reprogramming mode until the power is cycled.
After the power cycle, the ECU will determine which mode to enter based on the FEPS
voltage. To start the application after programming, ensure FEPS is grounded and power
cycle the ECU.
The FEPS pin is asserted by applying a voltage to the pin. The required voltage varies
between ECUs.

M560
M580 Result
settings.
As a shortcut, the device can be reprogrammed via a CCP compliant tool without cycling
the power to the ECU (FEPS may or may not been to be applied depending on the
ECU). When reprogramming starts, the OpenECU device switches from application mode to
reprogramming mode. It may be undesirable to allow this method due to safety reasons, so
the pcp_CCPInhibitReprogramming block can switch this method off.
If the OpenECU device has never been programmed before, it uses the CCP settings given
in Table 6.3, “CCP defaults”. The CCP compliant tool must use the same settings. Once

Software overview
the OpenECU device has been reprogrammed with an application that uses different CCP
settings, the CCP compliant tool must be changed to use these settings.
Certain OpenECU devices might require different protocols for programming than CCP such
as J1939 or ISO 15765. Please consult the technical specification of your device to determine
the supporting protocols.
4.6. OpenECU blockset features

The OpenECU blockset provides varied access to the features of both Simulink and the target
ECU. The OpenECU blockset library groups common functionality together (as described in
Section 4.1.5, “In MATLAB — Library browser (R2013a and newer)”):
• OpenECU provides a series of blocks to store information across power cycles. The
information can be stored in scalars, arrays or maps, and the scalars and maps can be
adapted over time (for instance, when learning the mechanical end stops for valve positions
over time). See Section 4.6.2, “Adaptive parameters” for details.
• OpenECU provides a series of communication blocks, which handle CAN, CCP (a

calibration protocol over CAN), J1939 (an SAE protocol for vehicle communication) and
basic signal checking. The blockset provides support for Vector CANdb files (which
describe networks, CAN messages and CAN signals in detail). See Section 4.6.3,
“Communications” for details.
• OpenECU provides a series of blocks to adjust the compiler and linker options for a model
build. Support for selecting which compiler to use as well as adjusting the options given to
the compiler and linker allow some control when incorporating custom code and working
around compiler bugs. See Section 4.6.4, “Compiler options” for details.
• OpenECU has a mechanism for retiring old blocks and replacing them with more capable
blocks through deprecation. See Section 4.6.5, “Deprecated blocks” for details.
• OpenECU provides a series of blocks for fault and diagnostic trouble code logging. The
fault information can be stored across power cycles and the diagnostic trouble codes can
be automatically handled in some J1939 messaging. See Section 4.6.6, “Fault support”
for details.
• OpenECU provides a series of blocks for analogue and digital input processing.
Support includes measuring analogue inputs, digital, frequency and PWM inputs. See
Section 4.6.11, “Analogue and digital inputs”.
• OpenECU provides a series of blocks to interact with the operating system The operating
system schedules the different operations the ECU must perform to function correctly,
including running the functionality assigned to each model rate. The blocks provide access
to run-time schedule information, including how much processing time is taken up running
all the software. See Section 4.6.12, “Operating system”.
• OpenECU provides a series of blocks for analogue and digital output processing.
Support includes driving constant current outputs, digital, PWM and stepper outputs. See
Section 4.6.13, “Analogue and digital outputs”.
• OpenECU provides a series of utility blocks to make some of the example models easier
to use the first time around. These blocks can be incorporated in other models and provide
quick mechanisms to configure each of the auto-coders, turn on and decode the sample
time colours and build a model. See Section 4.6.14, “Real-Time Workshop (RTW) support”.
• OpenECU provides a series of blocks to configure each of the target ECU specific features,
not covered in a general sense by other groups of blocks. For instance, the blocks provide

Software overview
a mechanism to select whether some inputs are VRS single-ended or Hall effect and select
the over-current trip level for some outputs. See Section 4.6.15, “Target ECU identification
and configuration”.
• OpenECU provides a series of blocks which provide timing information. Simulink maintains
a base rate time, with a resolution as accurate as the quickest model rate. The ECU
maintains a much higher resolution timer as well as access to the current time since power
on. The blocks provide access to these timers. See Section 4.6.16, “Timing”.
• OpenECU provides a series of blocks to perform common and general functions. These
blocks are provided by OpenECU to support the same functionality across all versions of
Simulink that OpenECU supports. See Section 4.6.17, “Utilities”.
• OpenECU provides a series of blocks to access version information when using Simulink
and when running the model on an ECU. For instance, there is a block to determine if the
expected version of OpenECU is being used when editing the model, and a block to get
the version of OpenECU software running an ECU. See Section 4.6.18, “Versioning”.
4.6.1. Calibration tool support

Calibratables and displayables are defined in a data dictionary, which can be set up per
model. More details are given in Section 4.2.2.2, “Data dictionary files”.
OpenECU has specific support for ATI Vision, ETAS INCA and VECTOR CANape but can
also generate generic ASAP2 information for inclusion into any ASAP2 compliant calibration
tool.
4.6.2. Adaptive parameters

The blockset library provides a series of blocks which allow the modeller to adjust scalars,
1-d and 2-d maps while the model is being iterated.
• Section 6.1.61, “Non-volatile adaptive scalar (pnv_AdaptiveScalar)”

• Section 6.1.59, “Non-volatile adaptive 1-d map look-up (pnv_AdaptiveMap1d)”
• Section 6.1.60, “Non-volatile adaptive 2-d map look-up (pnv_AdaptiveMap2d)”
• Section 6.1.62, “Non-volatile adaptive array (pnv_Array)”
The blockset library provides access to non-volatile storage: storage retained when the power
is removed from the module by either connecting a low power source to the Keep alive power
pin to retain the contents of RAM storage, or by committing the data to Flash storage (see
the technical specification for details on which storage type is supported by each target).
• Section 6.1.58, “Non-volatile adaptive check-sum (pnv_AdaptiveChecksum)”

• Section 6.1.63, “Non-volatile memory status (pnv_Status)”
4.6.2.1. Storage of data across power cycles

On start-up, the blockset library attempts to retrieve adaptive data prior to running the model
application. While the application is running, the time at which the adaptive data is stored
back to non-volatile memory is determined by the application itself.
The adaptive data is check-summed using a 16-bit CRC. Failure to match the check-sum
against the adaptive data during library initialisation means that the data cannot be recovered.
In this case, adaptive data is reverted to the default for each adaptive element (the defaults
can be specified by the application).
There are two types of non-volatile memory dedicated to adaptive data:

Software overview
Battery backed RAM

Storage that requires an external power source when the ECU is powered down (not
available on all target ECUs),
Flash
Storage that requires no external power supply when the ECU is powered down (not
available on all target ECUs).
See Section A.1, “ECU hardware reference documentation” for details of what non-volatile
memory stores are available for each target ECU.
The application starts a commit of adaptive data to non-volatile store through the
pnv_AdaptiveChecksum block.
Note
If the non-volatile memory store is Flash, then the library will halt the application while
committing adaptive data to non-volatile memory. This is to prevent any higher-rate
tasks interrupting and attempting to access the Flash device (which will generally be
unavailable at that time).
The worst case scenario is for the application to be stopped for about 1.8 seconds. It
is the responsibility of the application to ensure that there will be no detrimental side
effects to stopping the application for this length of time, e.g., the application should
ensure all coil and injector outputs are turned off if applicable for that ECU.
It should also be noted that, once started, it is not possible to interrupt the Flash commit
process. So if, for example, a user of the ECU requests that the ECU start-up before
the process has completed, the ECU will not try to start until control is passed back
to the application.
The application can determine if the adaptive data requires a commit to non-volatile memory
through the pnv_Status block. When the ECU decides to power down, if this block shows the
data as unmodified there will be no need to store the data to non-volatile memory again; this
is important for a Flash-based solution as this means there is no need to write the data to
Flash, thus minimising shutdown time and reducing the number of Flash write cycles.
4.6.3. Communications
4.6.3.1. CAN communications
Functions to pack and transmit or receive and unpack CAN messages are provided. These
functions also report status information, for example: bus off. User selectable data types for
the message fields are supported at the Simulink block level.
• Section 6.1.12, “CAN configuration (pcx_CANConfiguration)”

• Section 6.1.13, “CAN Baud Override (pcx_CANBaudOverride)”
• Section 6.1.11, “CAN bus status (pcx_BusStatus)”
• Section 6.1.14, “CAN receive message (pcx_CANReceiveMessage)”
• Section 6.1.15, “CAN transmit message (pcx_CANTransmitMessage)”
Functions to use Vector CANdb files to define CAN messaging are provided:
• Section 6.1.16, “CANdb message receive (pcx_CANdb_ReceiveMessage)”

• Section 6.1.17, “CANdb transmit message (pcx_CANdb_TransmitMessage)”

Software overview
4.6.3.2. CCP communications

Designed to work with ASAM (ASAP 1 and 2) compliant calibration tools. Data acquisition is
at configurable rates for variables in the model, allowing the bandwidth available over CCP
to be maximised. The CCP handler uses CAN transmit and receive functionality in the same
way as the model (but these are largely hidden and not exposed through the model).
• Section 6.1.19, “CCP configuration (pcp_CCPConfiguration)”

• Section 6.1.21, “CCP seed/key security (pcp_CCPSecurity)”
• Section 6.1.22, “CCP inhibit reprogramming (pcp_CCPInhibitReprogramming)”
• Section 6.1.23, “CCP CRO receive count (pcp_CCPRxCount)”
4.6.3.3. J1939 (SAE) communications

Functions to pack and transmit or receive and unpack J1939 messages are provided. User
selectable data types for the message fields are supported at the Simulink block level.
• Section 6.1.44, “J1939 configuration (pj1939_Configuration)”

• Section 6.1.45, “J1939 channel configuration (pj1939_ChannelConfiguration)”
• Section 6.1.53, “J1939 parameter group requested (pj1939_PgRequested)”
• Section 6.1.52, “J1939 parameter group receive message (pj1939_PgReceive)”
• Section 6.1.54, “J1939 parameter group transmit (pj1939_PgTransmit)”
• Section 7.7.54, “J1939 send acknowledgement message (pj1939_SendAck)”
Functions to handle diagnostic messaging are provided:
• Section 6.1.46, “J1939 DM1 receive (pj1939_Dm1Receive)”

• Section 6.1.47, “J1939 DM1 decode DTC (pj1939_Dm1DecodeDtc)”
• Section 6.1.48, “J1939 DM1 transmit (pj1939_Dm1Transmit)”
• Section 6.1.49, “J1939 DM2 receive (pj1939_Dm2Receive)”
• Section 6.1.50, “J1939 DM2 decode DTC (pj1939_Dm2DecodeDtc)”
• Section 7.7.33, “J1939 DM7 decode (pj1939_Dm7Decode)”
• Section 7.7.24, “J1939 Transmit DTC DM (pj1939_TransmitDtcDm)”
• Section 7.7.55, “J1939 update NTE status (pj1939_UpdateNteStatus)”

Software overview
4.6.3.4. Signal checks

Functions to help diagnose missing CAN signals are also provided:
• Section 6.1.91, “Signal gap detection (put_SignalGapDetection)”

• Section 6.1.92, “Signal prepare — deprecated (put_SignalPrepare)”
• Section 6.1.93, “Signal validate (put_SignalValidate)”
4.6.4. Compiler options

Although not necessary in the majority of cases, it is sometimes useful to be able to modify the
compiler or linker options while building a model. For instance, to turn on debug symbols, to
turn off an optimisation which may be causing a problem, or to affect preprocessor conditions
of hand written code included in the build.
• Section 6.1.24, “Compiler options (pcomp_CompileOptions)”

• Section 6.1.55, “Link options (pcomp_LinkOptions)”
4.6.5. Deprecated blocks

Sometimes, as the functionality of a block changes, the change cannot be made without
breaking the behaviour the model expects of the block. For instance, when a block has a
couple of options replaced by a single option, the block cannot adjust itself when the model
loads, and Simulink will print a series of error messages.
When this kind of change occurs, rather than change the existing block, a new block is created
with the new functionality, while the old block is retained as is. This allows the model to
load without Simulink printing errors and the model can be changed to use the new block
as required.
However, to remove old functionality over time, the old block will be removed in a future
version of the developer software, ensuring the blockset remains efficient. Blocks which are
to be removed in the future are marked deprecated, and the documentation for those blocks
indicates how to replace the block with an equivalent block that isn't marked deprecated.
Currently, the following blocks are marked deprecated and will be removed in a future version
of the developer software. Please replace the use these blocks as soon as possible.
• Section 6.1.18, “CAN status — deprecated (pcx_CANStatus)”

• Section 6.1.92, “Signal prepare — deprecated (put_SignalPrepare)”
4.6.6. Fault support

The block library provides support for Diagnostic Trouble Codes (DTCs), or fault indicators,
which can be organised into a series of tables.
• Section 6.1.35, “DTC table definition (pdtc_Table)”

• Section 6.1.32, “DTC diagnostic trouble code (pdtc_DiagnosticTroubleCode)”
• Section 7.7.7, “DTC diagnostic trouble code (extended)
(pdtc_DiagnosticTroubleCodeExt)”
• Section 7.7.6, “DTC control (pdtc_Control)”
• Section 7.7.8, “DTC lamp states (pdtc_Status)”
• Section 6.1.29, “DTC clear all (pdtc_ClearAll)”
• Section 6.1.30, “DTC clear all if active (pdtc_ClearAllIfActive)”
• Section 6.1.31, “DTC clear all if inactive (pdtc_ClearAllIfInactive)”
• Section 7.7.5, “DTC match and clear (pdtc_ClearDtcs)”

Software overview
• Section 7.7.9, “DTC match exists (pdtc_MatchExists)”

• Section 6.1.34, “DTC memory update (pdtc_Memory)”
• Section 7.7.12, “DTC table cleared indication (pdtc_TableCleared)”
and to provide simple signal checks:
• Section 6.1.41, “Fault check (put_FaultCheck)”

• Section 6.1.79, “Range check (put_RangeCheck)”
• Section 6.1.94, “Slew rate check (put_SlewRateCheck)”
4.6.7. PID support

The block library provides support for Parameter Identifiers (PIDs).
• Section 7.7.17, “Parameter identifier (ppid_Pid)”

• Section 7.7.18, “Parameter identifier scaling (ppid_Scaling)”
4.6.8. Freeze Frame support

The block library provides support for freeze frames. Freeze frames capture pertinent
operating conditions upon the occurrence of a fault. The platform supports freeze frames
over the J1979 and J1939 protocols.
• Section 7.7.21, “Freeze frame configuration (pff_Configuration)”

• Section 7.7.19, “Freeze frame (pff_FreezeFrame)”
• Section 7.7.20, “DM25 freeze frame (pff_Dm25FreezeFrame)”
4.6.9. Service $09 InfoType support

The block library provides support for service $09 InfoTypes.
• Section 7.7.56, “J1979 service $09 Infotype input (pdg_InfotypeInput)”
4.6.10. IUPR support

The block library provides support for In-Use Performance Ratio (PPR).
• Section 7.7.57, “Diagnostic monitor entity (ppr_DiagnosticMonitorEntity)”

• Section 7.7.58, “Diagnostic test entity (ppr_DiagnosticTestEntity)”
• Section 7.7.59, “General denominator (ppr_GeneralDenominator)”
• Section 7.7.60, “Ignition cycle (ppr_IgnitionCycle)”
• Section 7.7.61, “PPR memory update (ppr_Memory)”
• Section 7.7.62, “Monitors incomplete count (ppr_MonitorsIncomplete)”
4.6.11. Analogue and digital inputs

The blockset library provides the mechanism for Simulink I/O blocks to access real hardware
pins. There are a variety of general input blocks:
• Section 6.1.6, “Analogue input — processed (pai_AnalogInput)”

• Section 6.1.5, “Analogue input — basic (pai_BasicAnalogInput)”
• Section 6.1.36, “Digital input (pdx_DigitalInput)”
• Section 6.1.42, “Frequency input (pdx_FrequencyInput)”
• Section 6.1.76, “PWM input measurement (pdx_PwmInput)”

Software overview
• Section 6.1.39, “Digital data input (pdd_DataInput)”
4.6.11.1. Hardware effects on signals

The functions work at the level of the micro-processor pin but the input and output circuitry of
the ECU may change the characteristics of the signal. For instance, the input circuitry may
include filtering or inversion. See the technical specification in Section A.1, “ECU hardware
reference documentation” for a description of how the input and output circuitry works for
an ECU.
4.6.11.2. External devices

There are two types of I/O on OpenECU hardware: direct and indirect I/O.
Figure 4.11. Signal update rates
Direct
output signal
Output
circuitry
Processor
To external actuators
Output Output
device circuitry
Serial Direct
communications output signal
Internal to ECU External to ECU
Direct I/O
Direct I/O takes place on demand. The application calls the necessary function and the
function takes a measurement or sets a driver accordingly.
Indirect I/O
Indirect I/O is delayed.
For an input, the application calls the necessary function and the data to be read is taken
from a buffer of data that was sampled some time ago. Once the model has completed
each model rate once, the data is buffered at the quickest rate which requests the data.
Thus indirect inputs are delayed by at most one iteration of the quickest rate which
requests the input.
For an output, the application calls the necessary function and the data to be written is
buffered and actioned some time later. Once the model has completed each model rate
once, the buffered data is actioned at the quickest rate which writes the indirect output.
Indirect I/O always occurs when there is an device between the processor and the pin. The
device communicates to the processor across a serial link and it is this communication which
introduces the delay. Only I/O channels noted as serial in the technical specification (see
Section A.1, “ECU hardware reference documentation”) are affected.
4.6.11.3. Monitors
Each target ECU provides some measure of feedback for a subset of the output pins. For
instance, measuring the reference voltage for A/D conversions to determine if the reference
voltage generator has failed. A complete list of the monitors can be found in the technical
specifications (see Section A.1, “ECU hardware reference documentation”). Each monitor

Software overview
is read by using one of the blocks, e.g., using the Section 6.1.5, “Analogue input — basic
(pai_BasicAnalogInput)” block to read the analogue voltage of a monitor.
4.6.12. Operating system

Task Scheduling
The Real-Time Operating System (RTOS) schedules tasks to a resolution of 1
millisecond. Portions of the model which run at the same rate, are gathered together
into tasks which are each assigned a unique priority and are fully pre-emptive. The
priority of each task is assigned according to model rate (quickest rate is assigned the
highest priority) with the angular rate (if enabled in the RTW options) assigned the highest
priority. Tasks are also set up to handle CCP communications; polling for received CAN
messages and software queuing for CAN transmit messages.
The blockset library provides access to information about the tasks at run time:
• Section 6.1.75, “Processor loading (psc_CpuLoading)”
• Section 6.1.97, “Task duration (pkn_TaskDuration)”
Stack
Each task shares the same stack space, an area of RAM dedicated to storing temporary
information about the task and the functionality the task is performing. The amount of
stack space is finite and must be specified when the model is built. The blockset library
provides information about how much stack has be used since ECU power on or last
reset:
• Section 6.1.96, “Stack used (psc_StackUsed)”
Watchdog
Each ECU implements a watchdog, a mechanism to reset the ECU if the ECU software
appears to be misbehaving. A simple watchdog scheme is implemented by the platform
software but the application model can take control of the watchdog and implement a
more complex scheme.
• Section 6.1.101, “Watchdog kick (psc_KickWatchdog)”
Memory tests
Each ECU implements an internal memory test during startup to check for hard memory
faults. Hard memory faults are memory faults that have become permanent such as
a shorted address line, or a memory cell that cannot change state. RAM is tested by
performing a destructive walking one's test on the address and data lines and a memory
recall test on the memory cells. ROM is tested by calculating a checksum of the contents.
If a hard memory fault is detected, then the ECU will reset itself to force safety related
outputs to a default state.
Some ECUs also implement a continuous internal memory test during runtime to check
for soft memory faults. Soft memory faults are transient memory faults, such as might
occur when a memory cell changes state due to stray electron releases. The error
correction module hardware is capable of detecting and correcting errors that are limited
to a single bit wrong in a 64-bit double word. If more than one bit is wrong in a 64-bit
double word, then the hardware can detect the error, but it cannot be corrected. If an
uncorrectable soft memory fault is detected, then the ECU will reset itself to force safety
related outputs to a default state.
The blockset library provides Simulink blocks to report the status of the continuous
internal memory soft error test as well as the address of the last detected correctable
error.
• Section 6.1.69, “Internal RAM test progress (psc_InternalRamTestProgress)”
• Section 6.1.71, “Internal ROM test progress (psc_InternalRomTestProgress)”
• Section 6.1.68, “Internal RAM test error (psc_InternalRamTestError)”
• Section 6.1.70, “Internal ROM test error (psc_InternalRomTestError)”

Software overview
4.6.13. Analogue and digital outputs

The blockset library provides the mechanism for Simulink I/O blocks to access real hardware
pins. There are a variety of general output blocks:
• Section 6.1.37, “Digital output (pdx_DigitalOutput)”

• Section 6.1.77, “PWM output — fixed frequency (pdx_PWMOutput)”
• Section 6.1.78, “PWM output — variable frequency (pdx_PWMVariableFrequencyOutput)”
• Section 6.1.43, “H-Bridge output (pdx_HBridgeOutput)”
and a way to diagnose the status of the electrical connections of some ECU loads:
• Section 6.1.38, “Digital output monitor (pdx_Monitor)”
4.6.13.1. Hardware effects on signals

The functions work at the level of the micro-processor pin but the input and output circuitry of
the ECU may change the characteristics of the signal. For instance, the input circuitry may
include filtering or inversion. See the technical specification in Section A.1, “ECU hardware
reference documentation” for a description of how the input and output circuitry works for
an ECU.
4.6.13.2. External devices

There are two types of I/O on OpenECU hardware: direct and indirect I/O.
Figure 4.12. Signal update rates
Direct
output signal
Output
circuitry
Processor
To external actuators
Output Output
device circuitry
Serial Direct
communications output signal
Internal to ECU External to ECU
Direct I/O
Direct I/O takes place on demand. The application calls the necessary function and the
function takes a measurement or sets a driver accordingly.
Indirect I/O
Indirect I/O is delayed. The application calls the necessary function but the data to be
read or set is actioned some time after the function returns.
Indirect I/O always occurs when there is an device between the processor and the pin. The
device communicates to the processor across a serial link and it is this communication which
introduces the delay. Only I/O channels noted as serial in the technical specification (see
Section A.1, “ECU hardware reference documentation”) are affected.
4.6.13.3. Monitors
Each target ECU provides some measure of feedback for a subset of the output pins. For
instance, measuring the reference voltage for A/D conversions to determine if the reference

Software overview
voltage generator has failed. A complete list of the monitors can be found in the technical
specifications (see Section A.1, “ECU hardware reference documentation”). Each monitor
is read by using one of the OpenECU blocks to read the monitoring state of an output. For
instance, using the pdx_DigitalInput block to read one of the digital state monitors, or the
pai_BasicAnalogInput block to read one of the voltage monitors.
4.6.14. Real-Time Workshop (RTW) support

RTW creates software tasks for each rate in the model, and Simulink can colour each block
in the model based on the rate of the block. This can make it easier to understand what parts
of the model run at which rate, and to understand how information is passed between rates.
• Section 6.1.88, “Show Simulink's sample time colours (prtw_ShowSampleTimeColours)”
To support switching between auto-coders, the blockset library provides a set of blocks which
switch between the different configuration sets. Simulink configuration sets contain options
for a specific auto-coder. Currently, building models against the RTW (GRT RTMODEL) and
RTW (EC) auto-coders is supported.
• Section 6.1.26, “Configure auto-coder (RTW RTMODEL) (prtw_ConfigUsingRtwRtmodel)”

• Section 6.1.25, “Configure auto-coder (RTW EC) (prtw_ConfigUsingRtwEc)”
The blockset provides a utility block to start a model build. Pressing CTRL+B in a model
window performs the same functionality.
• Section 6.1.7, “Build model (prtw_Build)”
4.6.15. Target ECU identification and configuration

All ECUs supported by OpenECU have a common subset of functionality, which applies
equally to all ECUs.
• Section 6.1.57, “Model identification (put_Identification)”

• Section 6.1.86, “Retrieve registry key (preg_RetrieveKey)”
Some ECUs have capabilities which don't fit into the standard framework, and special support
is provided for those capabilities.
• Section 6.1.27, “Configuration M5xx (pcfg_Config_M5xx)”
4.6.16. Timing
Real time applications, like those developed for OpenECU, often need to time events
or durations, at different resolutions. The blockset library provides two mechanisms to
manipulate time: using the Simulink task timers; and using the ECU processor's timers.
• Section 6.1.99, “Time (real) (ptm_RealTime)”

• Section 6.1.100, “Time (Simulink) (ptm_SimulinkTime)”
4.6.17. Utilities
The I/O library also provides a number of support or utility functions to facilitate module
configuration and diagnosis:
• Section 6.1.80, “Reset module (put_Reset)”
map look-up and interpolation:

Software overview
• Section 6.1.1, “1-d calibration map look-up and interpolation (put_Calmap1d)”

• Section 6.1.2, “2-d calibration map look-up and interpolation (put_Calmap2d)”
signal conditioning:
• Section 6.1.28, “Debounce (put_Debounce)”
4.6.18. Versioning
For configuration management purposes, it can be useful to restrict the version of developer
software that can be used when editing and building a model. The blockset library provides
a flexible way to specify the allowable versions.
• Section 6.1.87, “Require platform version (put_RequirePlatformVersion)”
For configuration management and debugging purposes, it can be useful to know the
versions of software running on an ECU are compatible. The blockset library provides a way
to retrieve the version numbers of the various software components running on an ECU.
• Section 6.1.9, “Boot code version (psc_BootVersion)”

• Section 6.1.73, “Platform code version (psc_PlatformVersion)”
• Section 6.1.84, “Reprogramming code version (psc_PrgVersion)”
And a way to retrieve the date that each of those software components was built.
• Section 6.1.8, “Boot code build date (psc_BootBuildDate)”

• Section 6.1.72, “Platform code build date (psc_PlatformBuildDate)”
• Section 6.1.83, “Reprogramming code build date (psc_PrgBuildDate)”
A way to ensure the code and calibration memory regions have not been altered is provided.
• Section 7.7.1, “Calibration verification number (CVN) (psc_CvnCalc)”
4.7. Adapting an existing model for OpenECU

Existing models, not created with the OpenECU oe_create_model, command can be
converted to run with OpenECU with some effort. Some models which already follow some of
the guidelines set out in Chapter 5, Design and modelling will be easier to convert than others.
When converting any model, you will need to consider the following changes (as well as
those in Section 4.3.1, “Block use restrictions”):
Note
Some of the settings are harder to configure than others. It may be easier overall to
create a new model using the:
oe_create_model
command and copying the systems and blocks to this new model.
Simulink model settings

The OpenECU build mechanism relies on particular settings for the model, e.g., that
it can be solved with a discrete solver not a continuous one. The model configuration
parameters in the tables below should be configured for each version of Simulink.

Software overview
Table 4.8. Model Configuration Parameters for R2015b
Tab Item Parameter Setting

Solver Simulation Stop time It's a good idea to set the stop time
time to some large number (e.g. inf)
so that your simulation doesn't stop
unexpectedly when you're testing
it (this value is ignored when the
model is built and run on target).
Solver options Type OpenECU runs the model at regular
periodic intervals, so set to Fixed-
step.
Solver And OpenECU is a discrete
controller, so set the solver to
discrete (not continuous states).
Fixed step Set to auto to allow the Simulink
size solver find the quickest model rate.
Tasking and Periodic Set to Unconstrained.
sample time sample time
options constraint
Tasking mode Set to auto.
for periodic
sample times
Automatically Set to off.
handle data
transfers
between
tasks
Higher Set to on.
priority value
indicates
higher task
priority
Optimisation Simulation Block Set to off.
and code reduction
generation
Implement Set to on to save RAM usage on
logic signals the target ECU (but OpenECU will
as boolean work with this parameter set to off).
data
Use integer Set to off.
division
to handle
net slopes
that are
reciprocals of
integers
Use floating- Set to off.
point
multiplication
to handle
net slope
corrections

Software overview

Conditional Set to on to help improve switch
input branch and multiport switch block
execution execution.
Application Set to inf.
lifespan
Data Use memset Set to on to improve code space.
initialisation to initialise
floats and
doubles to 0.0
Integer and Remove Set to off
fixed-point code from
floating-point
to integer
conversions
that wraps ...
Remove Set to on
code from
floating-point
to integer
conversions
with
saturation ...
Accelerating Compiler Set to Optimizations off (faster
simulations optimisation builds)
level
Verbose Set to off
accelerator
builds
Signals and Inline Set to on so that signals can be
Parameters parameters calibrated.
>> Simulation
Signal Set to on to save RAM usage.
and code
storage reuse
generation
Signals and Enable local Set to on.
Parameters block outputs
>> Code
Eliminate Set to on
generation
superfluous
temporary
variables
Minimize Set to on
data copies
between local
and global
variables
Reuse block Set to on
outputs
Inline Set to on
invariant
signals

Software overview

Use memcpy Set to on to improve code space
for vector
assignment
Memcpy Set to 64
threshold
Loop unrolling Set to 5
threshold
Maximum Set to Inherit from target
stack size
(bytes)
Stateflow Use bitsets Set to off
for storing
state
configuration
Use bitsets Set to off
for storing
Boolean data
Hardware Embedded Hardware Set to Determined by Code
implementation hardware board: Generation system target file..
Device Set to Freescale.
vendor
Device type Set to 32-bit PowerPC.
Code Generation Target System target Set to openecu.tlc.
selection file
Build options Template Set to openecu_r2015b.tmf (note
makefile that this option is automatically set
at the start of each build based on
the version of Simulink running).
Table 4.9. Model Configuration Parameters for R2016a or R2016b

step.
options constraint

Software overview

for periodic
sample times
Show Set to off.
concurrent
execution
options
Allow tasks Set to off.
to execute
concurrently
on target
handle data
transfers
between
tasks
Higher Set to on.
priority value
indicates
higher task
priority
Optimisation Simulation Block Set to off.
and code reduction
generation
data
Use integer Set to off.
division
to handle
net slopes
that are
reciprocals of
integers
point
multiplication
to handle
net slope
corrections
lifespan
Data Use memset Set to on to improve code space.
initialisation to initialise
floats and
doubles to 0.0

Software overview

floating-point
to integer
conversions
that wraps ...
Remove Set to on
code from
floating-point
to integer
conversions
with
saturation ...
Accelerating Compiler Set to Optimizations off (faster
simulations optimisation builds)
level
Verbose Set to off
accelerator
builds
Signals and Inline Set to on so that signals can be
Parameters parameters calibrated.
>> Simulation
and code
storage reuse
generation
Signals and Enable local Set to on.
Parameters block outputs
>> Code
Eliminate Set to on
generation
superfluous
temporary
variables
Minimize Set to on
data copies
between local
and global
variables
outputs
Inline Set to on
invariant
signals
for vector
assignment
Memcpy Set to 64
threshold
threshold
stack size
(bytes)
Stateflow Use bitsets Set to off
for storing

Software overview

state
configuration
for storing
Boolean data
vendor
Code Generation Target System target Set to openecu_grt.tlc.
selection file
Build options Template Set to openecu_r2016a/b.tmf (note
makefile that this option is automatically set
at the start of each build based on
the version of Simulink running).
Table 4.10. Model Configuration Parameters for R2017a or R2017b

step.
options constraint
for periodic
sample times
handle data
transfers
between
tasks
Higher Set to on.
priority value
indicates
higher task
priority

Software overview

Optimization Simulation Use integer Set to off.
and code division
generation to handle
net slopes
that are
reciprocals of
integers
point
multiplication
to handle
net slope
corrections
lifespan
floating-point
to integer
conversions
that wraps ...
Advanced Compiler Set to Optimizations off (faster
parameters optimisation builds)
level
Verbose Set to off
accelerator
builds
Block Set to off.
reduction
storage reuse
data
Remove Set to on
code from
floating-point
to integer
conversions
with
saturation ...
Use memset Set to on to improve code space.
to initialise
floats and
doubles to 0.0

Software overview

Optimization Code Default Set to Inlined so that signals can be
> Signals and generation parameter calibrated.
Parameters behavior
Inline
parameters
Inline Set to on
invariant
signals
for vector
assignment
Memcpy Set to 64
threshold
threshold
stack size
(bytes)
Enable local Set to on.
block outputs
outputs
Eliminate Set to on
superfluous
temporary
variables
Optimization > Stateflow Use bitsets Set to off
Stateflow for storing
state
configuration
for storing
Boolean data
vendor
Code Generation Target System target Set to openecu_grt.tlc.
selection file
Build process Template Set to openecu_grt_r2017a/
makefile b_64.tmf (note that this option is
automatically set at the start of
each build based on the version of
Simulink running).

Software overview
Table 4.11. Model Configuration Parameters for R2018a and R2018b

Solver Type OpenECU runs the model at regular
selection periodic intervals, so set to Fixed-
step.
Solver details Fixed step Set to auto to allow the Simulink
options constraint
Treat each Set to on.
discrete rate
as a separate
task
to execute
concurrently
on target
handle rate
transition for
data transfer
Higher Set to on.
priority value
indicates
higher task
priority
Math and Data Basic Default for Set to double.
Types parameters underspecified
data type:
Use division Set to off.
for fixed-point
net slope
computation:
point
multiplication
to handle
net slope
corrections
Use Set to off.
algorithms

Software overview

optimized for
row-major
array layout
lifespan
Advanced Implement Set to on to save RAM usage on
parameters logic signals the target ECU (but OpenECU will
data (vs.
double)
vendor
Simulation Advanced Block Set to off.
Target parameters reduction
Compiler Set to Optimizations off (faster
optimization builds)
level
storage reuse
Verbose Set to off
accelerator
builds
Code Generation Target System target Set to openecu_grt.tlc. (Note
selection file that this changes the active
configuration, changes to other
configurations are not automatically
applied to this one.)
Build process Generate Set to on.
makefile
Template Set to openecu_grt_r2018a_64.tmf
makefile or openecu_grt_r2018b_64.tmf
(note that this option is
automatically set at the start of
each build based on the version of
Simulink running).
Make Set to make_rtw.
command
Code Generation Basic Default Set to Inlined so that signals can be
> Optimization parameters parameter calibrated.
behavior
for vector
assignment

Software overview

Memcpy Set to 64
threshold
threshold
stack size
(bytes)
Advanced Inline Set to on
parameters invariant
signals
block outputs
outputs
Eliminate Set to on
superfluous
temporary
variables
Remove Set to on
code from
floating-point
to integer
conversions
with
saturation ...
to initialise
floats and
doubles to 0.0
Remove Set to off
code from
floating-point
to integer
conversions
that wraps ...
Advanced Use bitsets Set to off
parameters > for storing
Stateflow state
configuration
for storing
Boolean data
Table 4.12. Model Configuration Parameters for R2020a


Software overview

step.
Solver details Fixed step Set to auto to allow the Simulink
options constraint
discrete rate
as a separate
task
to execute
concurrently
on target
handle rate
transition for
data transfer
Higher Set to on.
priority value
indicates
higher task
priority
Math and Data Basic Default for Set to double.
Types parameters underspecified
data type:
Use division Set to off.
for fixed-point
net slope
computation:
point
multiplication
to handle
net slope
corrections
Use Set to off.
algorithms
optimized for
row-major
array layout
lifespan

Software overview

Advanced Implement Set to on to save RAM usage on
parameters logic signals the target ECU (but OpenECU will
data (vs.
double)
vendor
Simulation Advanced Block Set to off.
Target parameters reduction
optimization builds)
level
storage reuse
Verbose Set to off
accelerator
builds
Code Generation Target System target Set to openecu_grt.tlc. (Note
selection file that this changes the active
configuration, changes to other
configurations are not automatically
applied to this one.)
Build process Toolchain Set to OpenECU Diab 5.9.6.7 |
gmake (64-bit Windows). (Note the
toolchain is updated automatically
by the Compiler option.)
Build Set to Faster Builds (Note the
configuration options Faster Builds, Faster Runs,
and Debug are identical).
behavior
for vector
assignment
Memcpy Set to 64
threshold
threshold
stack size
(bytes)

Software overview

Advanced Inline Set to on
signals
block outputs
outputs
Eliminate Set to on
superfluous
temporary
variables
Remove Set to on
code from
floating-point
to integer
conversions
with
saturation ...
to initialise
floats and
doubles to 0.0
Remove Set to off
code from
floating-point
to integer
conversions
that wraps ...
Stateflow state
configuration
for storing
Boolean data
or the following simulation settings for R2021b:
Table 4.13. Model simulation settings for R2021b

step.

Software overview

discrete (no continuous states).
Solver details Fixed-step Set to auto to allow the Simulink
options constraint
discrete rate
as a separate
task
to execute
concurrently
on target
handle rate
transition for
data transfer
Allow multiple Set to off.
tasks to
access inputs
and outputs
Higher Set to on.
priority value
indicates
higher task
priority
Math and Data Math Simulation Set to Gradual Underflow.
Types behaviour
for denormal
numbers
Use Set to off.
algorithms
optimized for
row-major
array layout
Data types Default for Set to double.
underspecified
data type:
Use division Set to Off.
for fixed-point
net slope
computation
Gain Set to off.
parameters
inherit a built-
in integer
type that is
lossless

Software overview

point
multiplication
to handle
net slope
corrections
Inherit Set to off.
floating-
point output
type smaller
than single
precision
Advanced Application Set to inf.
parameters lifespan
data (vs.
double)
Hardware Embedded Hardware Set to None.
Implementation hardware board
vendor
Device details Will be configured by the OpenECU
System Target file. Do not set
manually
Advanced Will be configured by the OpenECU
parameters System Target file. Do not set
manually
Model Options for Rebuild Set to If any changes detected.
Referencing all referenced
Enable Set to off.
models
parallel model
reference
builds
MATLAB Set to None.
worker
initialization
for builds
Enable strict Set to on.
scheduling
checks for
reference
models
Options for Total number Set to Multiple.
referencing of instances
this model allowed per
top model
Propagate Set to Infer from blocks in model.
size of

Software overview

variable-size
signals
Minimize Set to off.
algebraic loop
occurances
Propagate all Set to off.
signal labels
out of the
model
Pass fixed- Set to off.
size scalar
root inputs by
value for code
generation
Model Leave empty unless required
dependencies otherwise by Simulink.
Advanced Perform Set to on.
parameters consistency
check on
parallel pool
Include Set to off.
custom code
for referenced
models
Simulation Language Set to C.
Target
Insert custom Leave empty unless custom code is
C code in required.
generated...
Additional Leave empty unless custom code is
build required.
information...
Import custom Set to off.
code
Reserved Leave empty unless required
names otherwise.
Advanced Block Set to on.
parameters reduction
optimization builds).
level
Verbose Set to off.
accelerator
builds
Dynamic Set to off.
memory
allocation

Software overview

in MATLAB
functions
Dynamic Set to 65536.
memory
allocation
threshold
in MATLAB
functions
Enable Set to off.
continuous-
time MATLAB
functions
to write to
initialized
persistent
variables
Enable Set to On for simulation.
memory
integrity
checks
Compile-time Set to 50.
recursion limit
for MATLAB
functions
Enable run- Set to off.
time recursion
for MATLAB
functions
Enable Set to off.
implicit
expansion
in MATLAB
functions
Generate Set to off.
typedefs for
imported
bus and
enumeration
types
Break on Ctrl- Set to on.
C
Echo Set to on.
expressions
without
semicolons
Allow setting Set to off.
breakpoints
during
simulation
Code Generation Target System target Set to openecu_grt.tlc to use
selection file Simulink Coder, or set to

Software overview

openecu_ert.tlc to use Embedded
Coder. Note that this may change
the active configuration; changes
to other configurations are not
automatically applied to the
selected one.
Language Set to C.
Language Set to C89/C90 (ANSI).
standard
Build process Generate Set to off.
code only
Package code Set to off.
and artifacts
ZIP file name Set to <empty>.
Toolchain Toolchain Select compiler for your target
settings ECU.
Build Set to Faster Builds.
configuration
Code Select Set to Unspecified.
generation objective
objectives
Check model Set to Off.
before
generating
code
Advanced Custom Set to <empty>.
parameters FFT library
callback
Custom Set to <empty>.
BLAS library
callback
Custom Set to <empty>.
LAPACK
library
callback
Post code Set to <empty>.
generation
command
Verbose build Set to on.
Retain .rtw file Set to on.
Profile TLC Set to off.
Enable TLC Set to off.
assertion
Start TLC Set to off.
coverage
when
generating
code

Software overview

Start TLC Set to off.
debugger
when
generating
code
TLC options Set to <empty>.
Show custom Set to off.
hardware app
in Simulink
Toolstrip
Show Set to off.
embedded
hardware app
in Simulink
Toolstrip
behavior
Use memcpy Set to on to improve code space.
for vector
assignment
Memcpy Set to 64.
threshold
Loop unrolling Set to 5.
threshold
Maximum Set to Inherit from target.
stack size
(bytes)
Advanced Inline Set to on.
signals
Signal Set to on.
storage reuse
block outputs
Reuse block Set to on.
outputs
Eliminate Set to on.
superfluous
temporary
variables
to initialise
floats and
doubles to 0.0
Remove Set to on.
code from
floating-point
to integer

Software overview

conversions
with
saturation ...
Remove Set to off.
code from
floating-point
to integer
conversions
that wraps ...
Buffer for Set to on.
reusable
subsystems
Stateflow state
configuration
for storing
Boolean data
Base storage Set to Native
type for Integer
automatically
created
enumerations
Code Generation Advanced Classic call Set to on (note: this option only
> Interface parameters interface appears when building for an
RTModel configuration).
Model pre-load and post-load hooks

The pre-load and post-load hooks are settings in a Simulink model which are executed
before the model is fully loaded and after the model has been fully loaded. OpenECU
uses these hooks to perform extra actions that Simulink does not normally perform.
These settings can be set using the following commands when the model is selected:
set_param(bdroot, 'preloadfcn', 'openecu_make_rtw_hook(''model_load'', ''mn'');')

set_param(bdroot, 'postloadfcn', 'openecu_make_rtw_hook(''model_loaded'', ''mn'');')
where mn is replaced by the name of the model.
If in doubt, it may be easier to create a new model using the
oe_create_model
command and copying the systems and blocks to this new model.
Model identification
OpenECU provides a put_Identification block which identifies the target hardware the
model will run on. Before a build can complete, this block must have been added to the
model. Without this block, a RTW build of the model will fail.
When adding a put_Identification block to a model for the first time, it is best to set the
block's target hardware parameter then save, close and reload the model. This ensures
that any other OpenECU block in the model is adjusted for the newly selected hardware
target.

Software overview
Continuous blocks
The OpenECU device relies on a discrete solver and therefore any block that relies on
a continuous solver will not work on OpenECU. Each of these blocks must be replaced
by a discrete equivalent. E.g., a continuous transfer function block to a discrete transfer
function.
Some MATLAB and Simulink tools exist to help perform these transformations, for
instance, the tustin approximation.
Computation load
The OpenECU device is based on a commercial engine controller and therefore uses
a commonly available processor to execute the model. Processing power is therefore a
resource that must be managed well and it is important to refactor your model so that
computation is spread over various model rates.
For instance, when reading a slow changing analogue input and processing its state, it is
often best to place the analogue input block to a model rate which is reflects how quickly
the analogue input can change. This avoids iterating portions of the model on a frequent
basis that produce similar values to previous iterations. If the slow changing analogue
input is subsequently used by a faster portion of the model, this can be accommodated
using Simulink blocks (an example of how to transfer information between different model
rates is given in the multi-rate demo, see Section 3.2, “Installed examples”).
OpenECU provides information about how long each of the model rates takes to
run as well as the percentage processor loading that can be viewed over CCP (see
Section 6.2.5, “Application and library task timing information”)
Create data dictionary

OpenECU requires information about display variables and calibration variables in order
to generate files required by calibration tools. This information is supplied to OpenECU
via a data dictionary. For further information, please see Section 4.2.2.2, “Data dictionary
files”.
4.8. Migrating between versions of Simulink

New simulation settings have been added by MathWorks as the MATLAB product has
evolved and when migrating an OpenECU model, these simulation settings need to be
updated accordingly. The settings in the following list of tables, appropriate to the version
being used, should be considered.
• Table 4.8, “Model Configuration Parameters for R2015b”
• Table 4.9, “Model Configuration Parameters for R2016a or R2016b”
• Table 4.10, “Model Configuration Parameters for R2017a or R2017b”
• Table 4.11, “Model Configuration Parameters for R2018a and R2018b”
• Table 4.12, “Model Configuration Parameters for R2020a”
• Table 4.13, “Model simulation settings for R2021b”
• Table 4.12, “Model Configuration Parameters for R2020a”
For R2015a, support has been added for Simulink data dictionaries. For further details, see
Section 4.2.2.2, “Data dictionary files”.

Chapter 5. Design and modelling
5.1. Introduction ..................................................................................................... 123
5.2. Design rules and guidelines ............................................................................. 123
5.2.1. Sampling rate rules ............................................................................... 123
5.2.2. Data storage rules ................................................................................ 124
5.2.3. Block properties .................................................................................... 124
5.2.4. Model appearance ................................................................................ 125
5.2.5. Naming rules ........................................................................................ 125
5.2.6. Logical operations ................................................................................. 127
5.2.7. Data type conversion ............................................................................ 129
5.1. Introduction
This chapter describes the processes involved in modelling your own strategies in Simulink,
and building the code. It also describes some modelling rules and guidelines that will make
it simpler to model and debug your designs.
5.2. Design rules and guidelines

This section explains how to use MATLAB and Simulink in the most efficient manner from the
point of view of designing OpenECU models. The points below are divided into 'rules', which
should be followed in every instance to avoid incorrect modelling techniques, and 'guidelines',
which are recommendations that will make your design and modelling process easier and
more efficient. Together, they also allow the Simulink models to act as a specification from
which C code can be handwritten, if required.
The process of auto-code generation from Simulink is very much dependent on these
rules, and the nature of the process necessarily introduces some design constraints. These
constraints are simply there, however, to ensure that the model you design will successfully
create the code you want running in the ECU.
OpenECU has many hundreds of man-years of automotive design experience using

Simulink, and these rules and guidelines have come about through rigorous cycles of
testing and analysis. Adhering to Pi's rules and guidelines will also make it
considerably easier to understand the nature of any support queries you may have at the
design and modelling level.
5.2.1. Sampling rate rules
• The fastest sampling rate found in your model will automatically be used as the angular
basis for all triggers (if angular rate functionality is enabled in the RTW options).
• All time based rates in the system must be multiples of the fastest rate interval (this includes
the angular rate).
• Subsystems should not be triggered unless they are to be executed in response to an

event. In particular, triggers must not be used to associate a subsystem with a task rate.
• If it is required to perform calculations at a different rate to the default rate, you must create
a further subsystem with a new rate. Different rates can be used at any position in the
whole library hierarchy.
• Where data flows into a subsystem with a different rate (and the data was generated
internally in the current library), you must resample the signal, or the model will not build

Design and modelling
in multitasking mode. Models can be single tasking, but to build it must be processed as
a multi-rate system i.e., multitasking mode. See the Simulink manual for information on
multitasking modes.
• If the signal comes from a block running at a faster rate, a Zero Order Hold block must be
the first thing connected to the inport of the subsystem. The sample time of the Zero Order
Hold must be set to correspond to the rate of the subsystem.
• When the signal comes from a block running at a slower rate, a unit delay block must be
used, with the sample time set to the slower rate. This appears inelegant, but is a Simulink
requirement for multi-rate systems. Note that although the unit delay must run at the slower
rate, the effect in the code is a delay by one step of the faster rate.
• During model development, the Sample Time Colours option is useful for identifying where
additional Zero Order Hold blocks are required, but isn't quite so helpful for the unit delay.
Inputs to triggered subsystems must be resampled according to the above rules. The effective
rate of the triggered subsystem for this purpose is the rate at which the trigger signal is
updated.
5.2.2. Data storage rules

• Avoid the use of data stores and from/goto tags to pass data around a hierarchy. Instead
use explicit wiring such that the source of data can easily be found. Data stores should not
be used to represent persistent storage because it is not obvious where they are written
to or read from, and they may be written in more than one place, with ill-defined results.
Instead use 1/z blocks, whose behaviour is well-defined and whose data flow is obvious.
5.2.3. Block properties

• Atomic property — For production auto-code generation, set the 'atomic' property of
subsystems to divide models into unit-testable C functions as required.
• Continuous Time blocks — No use of continuous time blocks is allowed. For some
targets the auto-code generator cannot produce code for these blocks, and for those for
which it can there is significant computational overhead. The blocks which are banned
under this rule are: Derivative, Integrator, Memory, State-Space, Transfer Fcn, Transport
Delay, Variable Transport Delay, Zero-Pole.
• Algebraic loops — The model cannot contain any algebraic loops. These occur when
the output of a calculation appears as one of its inputs. In many applications a variable is
updated and its value therefore depends on a previous value. In such cases a loop can be
avoided by inserting a unit delay (1/z) block. RTW cannot produce code if algebraic loops
exist. Where a unit delay block is used as above to avoid an algebraic loop it should be
shown flowing from right to left. Where a unit delay block is used for other purposes (such
as comparing successive values of a flow) it should be shown flowing left to right.
• Division by zero — Make division by zero, or overflow due to division by very small
numbers, impossible by constraining the divisor (denominator) to be a finite, non-zero
number. And as with all calculations, clip the output to be within its data-dictionary defined
range. (If the division is some part of a complex calculation, it is generally sufficient to clip
only the end result, before that is passed out of the subsystem (say) via a named, data
dictionary specified signal. If the signal is to be observable in unit tests, it should be clipped
within range unless it can be shown and commented to always be in range, given valid
inputs.) It is not sufficient to only clip the output of a divide operation, or ignore the result
if the divisor is very small, because allowing the erroneous divide operation to occur at
all may cause a machine exception on some platforms (and will produce a warning if run
in simulation).

• Switch blocks — When a Switch block is used, it should only be used as a logical switch.
If the control input is a 'real' type, the switching threshold will always be set to 0.5, because
the threshold is not printable. Where a threshold comparison is required, it should be shown
explicitly with a comparison block. See the section on Boolean signals, below.
• Absolute time — No use shall be made of absolute time. When a model has been
running for a long time, the absolute simulation time becomes so large that the time step is
smaller than the resolution of the (floating point) elapsed time. At this point the time simply
stops working. The following blocks are banned by this rule Repeating sequence, pulse
generator, ramp, clock, digital clock, chirp signal.
• Combinatorial logic — Avoid the use of the Combinatorial Logic block, and the S-R and
J-K flip-flop blocks which use it internally. Although useful, the embedded Logic block in
the flip-flop blocks causes a wastefully large RAM array to be generated in target code,
half of which is used to look up the second output which is normally terminated in any case.
Try to use primitive logic blocks and a 1/z instead or devise a simple library block.
5.2.4. Model appearance

The following guidelines should help you to keep your designs and models more
efficiently organised. Refer to the MAAB Control Algorithm Modeling Guidelines
(http://www.mathworks.com/solutions/automotive/standards/maab.html) for more complete
guidelines.
• Logical flow — Where possible a logical flow from top left to bottom right should be
adopted within each subsystem.
• Proportions — Create subsystems in the level above such that each has an aspect ratio
close to 1:1. Each diagram, whether Simulink or Stateflow, should be drawn with an aspect
ratio of around 1.6:1 to facilitate printing on A4 or US letter paper in landscape mode.
• Size — Use hierarchies to keep the number of blocks displayed on the screen at any one
time reasonable. It should not be necessary to use the scroll bars to navigate around a
single level at legible zoom. Similarly all diagrams should be legible when printed on A4.
The top-level model should be the only exception.
• Ambiguous wiring — There should be no instances where the routing of a line is

ambiguous. This can occur when Simulink overlays one line or corner on another. Lines
are allowed to cross (otherwise a coherent diagram would be impossible) but must never
be laid out so as to appear to cross when they don#t.
• Wire junctions — When lines are joined the junction blob must always appear at the point
where the lines intersect. If a line has junctions to both sides they must never be coincident.
Coincident junctions are hard to distinguish from crossing lines. The junctions should be
staggered by at least one grid space.
• Hidden default name — If a block retains its default name, the name should be hidden.
• Block names — Calibration constants are represented using the Simulink constant block
with the value field set to the name of the constant. The block name should be the same
as its value, but it should be hidden. The name matters because RTW uses it to generate
names in the code.
5.2.5. Naming rules

The OpenECU project makes use of a naming convention to help make names and variables
more readily understandable by humans. It is required that you adhere to this convention in

your own models to make them consistently comprehensive to anyone else who may use
your model (and to the Pi support engineers, should you need to talk to them about your
design).
All names consist of a prefix, a descriptive body, and an optional suffix, separated by
underscore characters:
Variable type letter

Determines the type of the variable,
in this case ‘c’ for calibration scalar.
mbec_ign_key_debounce_time
Prefix Name
Used to gather variables for the same Used to uniquely identify the variable by name.
group of functionality together.
E.g., mbe for ‘master base engine’, or
alt for ‘alternator control’
The prefix consists of three or four lower case letters, these being:
• A three letter prefix code identifying which group of functionality the named item belongs to.
• A single letter identifying the type of the named item (not used for displayable signals).
See Table 5.1, “Variable naming convention” for a list of types.
The item type letter is as follows:
Table 5.1. Variable naming convention
Named item type Type letter

Displayable signals (no type letter)
Constant scalars k
Calibration scalars c
Calibration maps m
Arrays v
Local variables l
Subsystems (task rate code)
Subsystem task rate codes are defined on a per-project basis.
The following conventions should be adhered to when designing variable names:
• A suffix is used on names of parameters of blocks such as lookup tables, where the
parameters have the same name as the block with a defined suffix appended.
• Names are case sensitive, but no reliance shall be placed on this. All names should be
lower case except where otherwise stated below.
• The sense of any boolean variables should be clear from the name of the variable.
• All names must be valid C language identifiers.
• Where there are multiple words in the descriptive body of a data name, the underscore
character '_# should be used to separate the words.

• Subsystems and Stateflow machines all have unique names. The name begins with the
library prefix followed by a one letter code to define the task rate associated with that
subsystem, and an underscore.
• Where there are multiple words in the descriptive body of a subsystem or Stateflow
machine name, each word should begin with a capital letter.
• Axes and data for lookup tables should be given the name of the table, followed by a suffix.
1-d lookup tables have two parameters as follows:
Table 5.2. 1-d map lookup naming convention
Simulink parameter Suffix Example

Vector of input values _x vaim_fuel_cell_temp_x
Vector of output values _z vaim_fuel_cell_temp_z
• 2-d lookup tables have three parameters as follows:
Table 5.3. 2-d map lookup naming convention
Simulink parameter Suffix Example

Row _x sffm_base_fuel_x
Column _y sffm_base_fuel_y
Table _z sffm_base_fuel_z
Given that it is unlikely the data will be manually edited in MATLAB, the drawing convention
above is adopted.
• If a constant is literal (not a calibration item), its name will be in upper case and need not
have the prefix. It is recommended, however, that the library prefix is retained (in upper
case) for literals which relate only to one feature.
• All calibration items and literals should be defined and have values assigned in the
MATLAB base workspace.
• Simulink ports are named as variables. Except for generic library blocks, the naming of
ports should be consistent throughout the entire model hierarchy, such that differently
named ports are never connected directly together.
5.2.6. Logical operations

Where a set of combinatorial logic is required to control events, it is generally neater and
clearer to build up the logic using the Simulink Logical Operator blocks than to attempt to
use Stateflow. Greater simplicity brings advantages in ease (and correctness and cost) of
implementation and reviewing.
For example, suppose we need to know the result of:
((A and B) or (C and D))
We could model this in Stateflow using the following node diagram:

Alternatively we could use Simulink blocks as follows:
In addition, the C-code generated by the Simulink blocks is clean and efficient compared
to the Stateflow version, though this is becoming less true with newer releases of Stateflow
Coder and RTW. See also the section on Boolean signals below.
Stateflow is useful when modelling state-based strategies. These can be very well
represented using the state chart notation, including the option of nested state machines.
However, mixing the flow chart nodes into transitions between states produces a messy and
confusing diagram. This is particularly true when actions are placed on transitions.

For this reason, state machines with flow nodes are to be avoided. A flow node may appear
as the entry point from an initial transition for the purpose of selecting one of a small number
of states when a chart (or particularly a sub-chart) is activated:
An analogous situation exists where a state has several exit conditions which share a
common part. If (and only if) the non-common parts are mutually exhaustive, the transitions
may be grouped through a flow node. The common part will be used as the condition to exit
the state to the node, then the remaining conditions will form the exits from the node.
In all cases where a flow node appears on a chart it will have a complete exhaustive set of
exit conditions. Thus the node is guaranteed to be transient, and will never cause Stateflow
to 'back up'.
Actions should be specified using the entry, during and exit attributes of states. If an action
is specified on a transition to a flow node, the behaviour is not intuitive, so these must be
avoided. Transition actions are allowed when it is not possible to achieve the desired result
using entry and exit only, but they should only appear on transitions directly from one state
to another.
To avoid confusion as to which transition out of a state takes priority, the conditions on the
transitions should be mutually exclusive.
Defensive programming practice requires that an action be defined for the case of a state
machine in an illegal or undefined state. The default action would be to re-initialise the state
machine via the initial transition. If this action is not appropriate then the diagram should be
annotated appropriately. This applies only to hand-coded projects, since it is not possible to
control Stateflow's handling of this condition.
5.2.7. Data type conversion

In MATLAB R11 and later, the real time workshop is capable of handling a variety of data
types, rather than just floating point. Conversions between data types can be achieved using
the Data Type Conversion block, while all arithmetic blocks require that all their inputs and
output are of the same type.

The use of type conversions is often required to interface between floating point strategy
models and sensor or actuator hardware on the target platform.
In practice, however, the data type handling is rather limited. Only floating point and integer
types are available, and there is no provision for fixed point values (or integers with scaling
factors) (except by use of the fixed-point blockset, but values from that cannot be used in
scaled form in Stateflow). Consequently it is not practical to use Simulink for automatically
generating code for a fixed point processor target, since it would be necessary to explicitly
model every scaling factor compensation. For example, take the following piece of maths:
If we were to implement this using integer arithmetic, we would not only have raw values
displayed in any scope blocks but we would also need to add scaling corrections and integer
size conversions to result in the following:
5.2.7.1. Boolean Signals and Plain Integers

The use of Simulink#s Boolean logic signals option is recommended. This causes RTW to
use an integer-based Boolean type wherever a Boolean signal is implicitly generated, e.g. as

the output from a logical operator block such as AND. This reduces RAM and CPU usage, and
causes more efficient code to be generated for switch blocks, replacing the usual comparison
against a threshold with a simple and fast if (boolean)... construct. (An error is issued if this
would be inconsistent with the switch threshold value set.)
Similarly, it may be appropriate to use integer types for some signals, e.g. when passing an
enumerated state variable. This saves RAM, reduces CPU use, and may remove the need
to make exact floating-point comparisons later. But see the section on Logical operators,
above; it is awkward to attempt to represent quantities which are naturally continuous (e.g.
a pressure) as scaled integers.
Note
There is no problem passing a Boolean or integer signal into Stateflow, so long as
Strong data typing is switched on in the Stateflow chart properties (otherwise, it expects
only floating-point inputs and outputs).
5.2.7.2. Floating point rules

The use of floating point arithmetic introduces certain potential issues. These are not specific
to Simulink but are general problems with floating point.
Avoid direct equality tests. Floating point results will be rounded, and tests for exact equality
are inherently risky.

Chapter 6. Software detail
6.1. OpenECU blockset .......................................................................................... 134
6.1.1. 1-d calibration map look-up and interpolation (put_Calmap1d) .................. 134
6.1.2. 2-d calibration map look-up and interpolation (put_Calmap2d) .................. 137
6.1.3. Application build date (psc_AppBuildDate) .............................................. 140
6.1.4. Application version (psc_AppVersion) ..................................................... 141
6.1.5. Analogue input — basic (pai_BasicAnalogInput) ...................................... 143
6.1.6. Analogue input — processed (pai_AnalogInput) ...................................... 144
6.1.7. Build model (prtw_Build) ........................................................................ 151
6.1.8. Boot code build date (psc_BootBuildDate) .............................................. 151
6.1.9. Boot code version (psc_BootVersion) ..................................................... 153
6.1.10. Boot code part number (psc_BootPartNumber) ...................................... 154
6.1.11. CAN bus status (pcx_BusStatus) .......................................................... 156
6.1.12. CAN configuration (pcx_CANConfiguration) ........................................... 158
6.1.13. CAN Baud Override (pcx_CANBaudOverride) ....................................... 159
6.1.14. CAN receive message (pcx_CANReceiveMessage) ............................... 161
6.1.15. CAN transmit message (pcx_CANTransmitMessage) ............................. 166
6.1.16. CANdb message receive (pcx_CANdb_ReceiveMessage) ...................... 170
6.1.17. CANdb transmit message (pcx_CANdb_TransmitMessage) .................... 175
6.1.18. CAN status — deprecated (pcx_CANStatus) ......................................... 180
6.1.19. CCP configuration (pcp_CCPConfiguration) .......................................... 181
6.1.20. CCP raster configuration (pcp_RasterConfig) ........................................ 185
6.1.21. CCP seed/key security (pcp_CCPSecurity) ........................................... 187
6.1.22. CCP inhibit reprogramming (pcp_CCPInhibitReprogramming) ................. 191
6.1.23. CCP CRO receive count (pcp_CCPRxCount) ........................................ 192
6.1.24. Compiler options (pcomp_CompileOptions) ........................................... 193
6.1.25. Configure auto-coder (RTW EC) (prtw_ConfigUsingRtwEc) .................... 198
6.1.26. Configure auto-coder (RTW RTMODEL) (prtw_ConfigUsingRtwRtmodel)
....................................................................................................................... 199
6.1.27. Configuration M5xx (pcfg_Config_M5xx) ............................................... 199
6.1.28. Debounce (put_Debounce) .................................................................. 203
6.1.29. DTC clear all (pdtc_ClearAll) ................................................................ 205
6.1.30. DTC clear all if active (pdtc_ClearAllIfActive) ......................................... 206
6.1.31. DTC clear all if inactive (pdtc_ClearAllIfInactive) .................................... 207
6.1.32. DTC diagnostic trouble code (pdtc_DiagnosticTroubleCode) ................... 208
6.1.33. DTC enable periodic lamp updates (pdtc_EnablePeriodicLampUpdates)
....................................................................................................................... 212
6.1.34. DTC memory update (pdtc_Memory) .................................................... 213
6.1.35. DTC table definition (pdtc_Table) ......................................................... 215
6.1.36. Digital input (pdx_DigitalInput) .............................................................. 216
6.1.37. Digital output (pdx_DigitalOutput) ......................................................... 218
6.1.38. Digital output monitor (pdx_Monitor) ..................................................... 220
6.1.39. Digital data input (pdd_DataInput) ........................................................ 223
6.1.40. Digital data output (pdd_DataOutput) .................................................... 225
6.1.41. Fault check (put_FaultCheck) ............................................................... 226
6.1.42. Frequency input (pdx_FrequencyInput) ................................................. 227
6.1.43. H-Bridge output (pdx_HBridgeOutput) ................................................... 230
6.1.44. J1939 configuration (pj1939_Configuration) ........................................... 233
6.1.45. J1939 channel configuration (pj1939_ChannelConfiguration) .................. 235
6.1.46. J1939 DM1 receive (pj1939_Dm1Receive) ............................................ 237
6.1.47. J1939 DM1 decode DTC (pj1939_Dm1DecodeDtc) ............................... 241
6.1.48. J1939 DM1 transmit (pj1939_Dm1Transmit) .......................................... 243
6.1.52. J1939 parameter group receive message (pj1939_PgReceive) ............... 253

Software detail
6.1.53. J1939 parameter group requested (pj1939_PgRequested) ..................... 260

6.1.54. J1939 parameter group transmit (pj1939_PgTransmit) ........................... 263
6.1.55. Link options (pcomp_LinkOptions) ........................................................ 267
6.1.56. Memory configuration (pmem_MemoryConfiguration) ............................. 270
6.1.57. Model identification (put_Identification) .................................................. 271
6.1.58. Non-volatile adaptive check-sum (pnv_AdaptiveChecksum) .................... 275
6.1.59. Non-volatile adaptive 1-d map look-up (pnv_AdaptiveMap1d) ................. 276
6.1.60. Non-volatile adaptive 2-d map look-up (pnv_AdaptiveMap2d) ................. 280
6.1.61. Non-volatile adaptive scalar (pnv_AdaptiveScalar) ................................. 284
6.1.62. Non-volatile adaptive array (pnv_Array) ................................................ 286
6.1.63. Non-volatile memory status (pnv_Status) .............................................. 289
6.1.64. Non-volatile file system access (pnv_File) ............................................. 291
6.1.65. Non-volatile filesystem flush (pnv_FileFlush) ......................................... 294
6.1.66. Non-volatile file information (pnv_FileStats) ........................................... 295
6.1.67. Non-volatile filesystem information (pnv_FilesystemInfo) ........................ 298
6.1.68. Internal RAM test error (psc_InternalRamTestError) ............................... 300
6.1.69. Internal RAM test progress (psc_InternalRamTestProgress) ................... 301
6.1.70. Internal ROM test error (psc_InternalRomTestError) .............................. 303
6.1.71. Internal ROM test progress (psc_InternalRomTestProgress) ................... 305
6.1.72. Platform code build date (psc_PlatformBuildDate) .................................. 306
6.1.73. Platform code version (psc_PlatformVersion) ........................................ 308
6.1.74. Platform code part number (psc_PlatformPartNumber) ........................... 309
6.1.75. Processor loading (psc_CpuLoading) .................................................... 311
6.1.76. PWM input measurement (pdx_PwmInput) ............................................ 313
6.1.77. PWM output — fixed frequency (pdx_PWMOutput) ................................ 318
6.1.78. PWM output — variable frequency (pdx_PWMVariableFrequencyOutput)
....................................................................................................................... 322
6.1.79. Range check (put_RangeCheck) .......................................................... 326
6.1.80. Reset module (put_Reset) ................................................................... 326
6.1.81. Reset count — stable (psc_ResetCount) ............................................... 328
6.1.82. Reset count — unstable (psc_UnstableResetCount) .............................. 330
6.1.83. Reprogramming code build date (psc_PrgBuildDate) ............................. 331
6.1.84. Reprogramming code version (psc_PrgVersion) .................................... 333
6.1.85. Reprogramming code part number (psc_PrgPartNumber) ....................... 334
6.1.86. Retrieve registry key (preg_RetrieveKey) .............................................. 336
6.1.87. Require platform version (put_RequirePlatformVersion) .......................... 344
6.1.88. Show Simulink's sample time colours (prtw_ShowSampleTimeColours)... 346
6.1.89. Secondary micro receive message (psmc_ReceiveMessage) ................. 346
6.1.90. Secondary micro transmit message (psmc_TransmitMessage) ............... 348
6.1.91. Signal gap detection (put_SignalGapDetection) ..................................... 349
6.1.92. Signal prepare — deprecated (put_SignalPrepare) ................................ 351
6.1.93. Signal validate (put_SignalValidate) ...................................................... 353
6.1.94. Slew rate check (put_SlewRateCheck) ................................................. 358
6.1.95. SPI communication fault count (psp_FaultCount) ................................... 359
6.1.96. Stack used (psc_StackUsed) ............................................................... 360
6.1.97. Task duration (pkn_TaskDuration) ........................................................ 362
6.1.98. Task period overrun (pkn_TaskPeriodOverrun) ...................................... 364
6.1.99. Time (real) (ptm_RealTime) ................................................................. 366
6.1.100. Time (Simulink) (ptm_SimulinkTime) ................................................... 368
6.1.101. Watchdog kick (psc_KickWatchdog) ................................................... 371
6.1.102. Vehicle to grid communication - Protocol Handshake
(pv2g_Protocol_Handshake_Message) ............................................................ 372
6.1.103. Vehicle to grid communication - DIN 70121 (pv2g_DIN_Message) ......... 377
(pv2g_ISO_15118_V1_Message) ..................................................................... 400
(pv2g_ISO_15118_V2_Message) ..................................................................... 432
6.1.106. Vehicle to grid connection management (pv2g_Connection) ................. 475

Software detail
6.1.107. Vehicle to grid connection information (pv2g_Link_Info) ........................ 476

6.2. Automatic ASAP2 entries ................................................................................. 479
6.2.1. Boot build information ............................................................................ 479
6.2.2. Reprogramming build information ........................................................... 480
6.2.3. Platform build information ...................................................................... 480
6.2.4. Application build information .................................................................. 481
6.2.5. Application and library task timing information ......................................... 482
6.2.6. Memory use information ........................................................................ 485
6.2.7. Memory error correction events .............................................................. 486
6.2.8. Floating point conditions ........................................................................ 486
6.2.9. J1939 related information ...................................................................... 487
6.2.10. Engine related information ................................................................... 488
6.3. OpenECU software versioning .......................................................................... 488
6.4. OpenECU commands ...................................................................................... 488
6.4.1. Documentation ...................................................................................... 488
6.4.2. Blockset ................................................................................................ 490
6.4.3. Model and build list actions ................................................................... 492
6.4.4. Model configuration and build ................................................................ 496
6.4.5. Change versions of OpenECU ............................................................... 502
6.4.6. Supporting tools .................................................................................... 504
6.1. OpenECU blockset

The following sub-sections describe the layout and working of each OpenECU block. Each
sub-section follows the same form, including diagrams of the block and its mask, a description
of its functionality and a description of the block's inports, outports and any parameters.
Some inports, outports and parameters have a valid numerical range or size of vector. If so,
the range and size information is given beside the object's description using internal notation.
Table 6.1. Interval notation
Notation Range
(x, y) x < value < y
[x, y) x <= value < y
(x, y] x < value <= y
[x, y] x <= value <= y
Some objects are not clipped to a range but folded into a range using modulo arithmetic and
where this occurs, the description includes details.
6.1.1. 1-d calibration map look-up and interpolation

(put_Calmap1d)
1-d map look-up and interpolation.
6.1.1.1. Supported targets

All targets
6.1.1.2. Required license

None (Main library). (See Section 1.4, “Licensed Features”.)

Software detail
6.1.1.3. Description
x:
x z(x)
z:
put_calmap1d
Looks up the inport x in the X-axis Data parameter, interpolates the corresponding elements
in the Z Data parameter, giving a corresponding z(x) as the output.
Some calibration tools provide a feature which shows the map in graphical or tabular form
together with the active interpolation point. OpenECU supports this feature by populating
the ASAP2 file with the signal name which corresponds to the x inport. To make this
feature work, the x signal must be a named DD entity with its storage class property set to
ExportedGlobal.
6.1.1.4. Inports
• x
The x-value at which a z-value is to be interpolated. May be a scalar or a vector.
Value type: Real

Calibratable: No
6.1.1.5. Outports
• z(x)
The value or values interpolated from parameter Z Data at x.
Value type: Real

Calibratable: No
6.1.1.6. Mask parameters
• X-axis Data
The name of the map's x axis (e.g. vftm_mymap_x, see Section "Naming rules"). There
must be two or more elements in this parameter and that must be the same as the number
of elements in parameter Z data. The values of X-axis Data must increase monotonically
but adjacent values may be the same.
Value type: Real

Calibratable: Yes, offline and online

Software detail
• Z Data
The name of the map's z axis (e.g. vftm_mymap_z, see Section "Naming rules"). There
of elements in X-axis Data.
Value type: Real

• Sample time
The periodicity of the block execution.
Range: [0.001, 3600] seconds
Value type: Real

Calibratable: No
6.1.1.7. Notes
• The Simulink look-up and pre-index blocks can be used instead of the put_Calmap1d
block. If a model uses the OpenECU data dictionary, then the axes and look-up data
dictionary items must adhere to the naming convention and cannot be shared between
look-up blocks. If a model uses the Simulink data dictionary, then the naming convention
is not required, and axes and look-up DDEs can be reused between look-up blocks.
– Note that other combinations are possible, see Section 4.2.2.2, “Data dictionary files”
for details.
– Note that in some cases, the Simulink look-up block can be slower to run than the
put_Calmap1d block.
– Note that when using Simulink look-up blocks with the Diab compiler, the following
warning message is emitted during model builds. The warning can be ignored.
'[model].c', line [line]: warning (dcc:1792):

trying to assign 'ptr to volatile' to 'ptr'
• The look-up and interpolation work as follows:
If the inport x value is less than the first element or larger than the last element of parameter
X-axis Data, the block outputs the first element or last element of parameter Z Data
respectively as outport z(x).
Warning
This effectively clips the output value as if it were looked up at the nearest defined
break-point, which differs from the behaviour of the standard Simulink look-up block
in older versions (e.g., Simulink R12).
Otherwise, if the inport x is equal to the value of one of the elements of parameter X-axis
Data, the block outputs the corresponding element of parameter Z Data as outport z(x).
Otherwise, if the inport x is equal to the value of more than one element of parameter X-axis
Data and the corresponding elements in parameter Z Data differ (causing a discontinuity
in the function), the earliest element in the parameter Z Data is output.
Otherwise, if the inport x is intermediate in value between two consecutive elements of

parameter Z data, the block interpolates linearly between the two corresponding elements

Software detail
in parameter Z data using the scale defined by parameter X-axis Data to obtain outport
z(x) value.
6.1.2. 2-d calibration map look-up and interpolation

(put_Calmap2d)
2-d map look-up and interpolation.

All targets

x x:
y: z(x,y)
z:
y
put_calmap2d
Looks up the input x and y in the X-axis Data and Y-axis Data parameters then interpolates
between the corresponding Z Data parameter elements, giving a corresponding z(x,y) as
output.
the ASAP2 file with the signal names which correspond to the x and y inports. To make
this feature work, the x and y signals must be named DD entities with their properties set
to ExportedGlobal.
6.1.2.4. Inports
• x
The x-value at which a z-value is to be interpolated. May be a scalar or a vector the same
size as inport y.
Value type: Real

Calibratable: No
• y
The y-value at which a z-value is to be interpolated. May be a scalar or a vector the same
size as inport x.
Value type: Real

Calibratable: No
6.1.2.5. Outports
• z(x,y)
The value or values interpolated from parameter Z Data at x and y.
Value type: Real

Software detail
Calibratable: No
• X-axis Data
of elements as columns in parameter Z Data. The values of X-axis Data must increase
monotonically but adjacent values may be the same.
Value type: Real

• Y-axis Data
The name of the map's y axis (e.g. vftm_mymap_y, see Section "Naming rules"). There
must be two or more elements in this parameter and that must be the same as the
number of elements as rows in parameter Z Data. The values of Y-axis Data must increase
monotonically but adjacent values may be the same.
Value type: Real

• Z Data
The name of the map's z matrix (e.g. vftm_mymap_z, see Section "Naming rules"). There
must be the same number of rows as elements in parameter Y-axis Data and number of
columns as elements in parameter X-axis Data.
Value type: Real

• Sample time
Value type: Real

Calibratable: No

Software detail
6.1.2.7. Notes
• The Simulink look-up and pre-index blocks can be used instead of the put_Calmap2d
block. If a model uses the OpenECU data dictionary, then the axes and look-up data
dictionary items must adhere to the naming convention and cannot be shared between
look-up blocks. If a model uses the Simulink data dictionary, then the naming convention
is not required, and axes and look-up DDEs can be reused between look-up blocks.
– Note that other combinations are possible, see Section 4.2.2.2, “Data dictionary files”
for details.
– Note that in some cases, the Simulink look-up block can be slower to run than the
put_Calmap2d block.
– Note that when using Simulink look-up blocks with the Diab compiler, the following
warning message is emitted during model builds. The warning can be ignored.
'[model].c', line [line]: warning (dcc:1792):

trying to assign 'ptr to volatile' to 'ptr'
• The look-up and interpolation work as follows:
If the value of inport x lies outside the range defined by the smallest and largest values
of parameter X-axis Data, it is altered until it meets that range (i.e. it is made equal to the
nearest x value which does occur in parameter X-axis Data). Similarly the value of inport
y is made to meet the range defined by the smallest and largest values in parameter Y-
axis Data.
Warning
This effectively clips the output value as if it were looked up at the nearest defined
break-point, which differs from the behaviour of the standard Simulink look-up block
in older versions (e.g., Simulink R12).
If the point (x, y) is coincident with one of the intersections of the X-axis Data and Y-axis
Data breakpoints (i.e. the value of inport x equals one of the values in parameter X-axis
Data and the value of inport y equals one of the values in parameter Y-axis Data), the block
outputs the corresponding element value of parameter Z Data with no interpolation. This
includes the outer boundary (and corners) of the area defined by the x and y axes. If more
than one point in either axis parameter equals the value of one of the inports, such that a
discontinuity is defined in the surface, the lowest-indexed parameter element is selected.
If the point (x, y) is coincident with a X-axis Data element but lies between Y-axis Data
elements, then the value output is linearly interpolated between the bounding points in the
y direction referenced to the x axis. If two or more values in parameter X-axis Data equal
the value of inport x, the lowest-indexed entry is used.
If the point (x, y) is coincident with a Y-axis Data element but lies between X-axis Data
elements, then the value output is linearly interpolated between the bounding points in the
x direction referenced to the y axis. If two or more values in Y-axis Data equal to the value
of inport y, the lowest-indexed entry is used.
If the point (x, y) is not coincident with any X-axis Data or Y-axis Data elements, the outport
z(x,y) is obtained by bi-linearly interpolating between the bounding points in the x and y
axes defined by the lower-indexed x and y elements.

Software detail
6.1.3. Application build date (psc_AppBuildDate)

Get the build date for the ECU's application.

All targets

year
month
day
psc_AppBuildDate
Gets the build date for the ECU's application. The build date can be used to distinguish
between different versions of the application.
6.1.3.4. Inports
• sim_year
Only used under simulation and when the parameter Provide simulation inports is ticked.
The outport year is set to the value of this inport for simulation purposes.
Range: [1970, 3000]
• sim_month
The outport month is set to the value of this inport for simulation purposes.
Range: [1, 12]
• sim_day
The outport day is set to the value of this inport for simulation purposes.
Range: [1, 31]
6.1.3.5. Outports
• year
The year the application was built. Under simulation, if the Provide simulation inports
parameter isn't ticked, the outport is set to the minimum of its range. The signal attached
to the outport must be set as ExportedGlobal.
Range: [1970, 3000]
• month
The month of the year the application was built. Under simulation, if the Provide simulation
inports parameter isn't ticked, the outport is set to the minimum of its range. The signal
attached to the outport must be set as ExportedGlobal.

Software detail
Range: [1, 12]
• day
The day of the month the application was built. Under simulation, if the Provide simulation
Range: [1, 31]
• Provide simulation inports
Tick to enable inports sim_year, sim_month and sim_day.
6.1.3.7. Notes
None.
6.1.4. Application version (psc_AppVersion)

Get the version information for the ECU's application.

All targets

major_ver
minor_ver
sub_minor_ver
psc_AppVersion
Gets the version information for the ECU's application. The version number is composed of
three fields, major, minor and sub-minor, typically written as major.minor.sub-minor.
The version can be used by the application for version control or diagnostics.
6.1.4.4. Inports
• sim_major_ver
The outport major_ver is set to the value of this inport for simulation purposes.

Software detail
Range: [0, 65535]
• sim_minor_ver
The outport minor_ver is set to the value of this inport for simulation purposes.
Range: [0, 65535]
• sim_sub_minor_ver
The outport sub_minor_ver is set to the value of this inport for simulation purposes.
Range: [0, 65535]
6.1.4.5. Outports
• major_ver
The major version number of the application. Under simulation, if the Provide simulation
Range: [0, 65535]
• minor_ver
The minor version number of the application. Under simulation, if the Provide simulation
Range: [0, 65535]
• sub_minor_ver
The sub-minor version number of the application. Under simulation, if the Provide
simulation inports parameter isn't ticked, the outport is set to the minimum of its range. The
signal attached to the outport must be set as ExportedGlobal.
Range: [0, 65535]
Tick to enable inports sim_major_ver, sim_minor_ver and sim_sub_minor_ver.
6.1.4.7. Notes
None.

Software detail
6.1.5. Analogue input — basic (pai_BasicAnalogInput)

Read an analogue input channel and convert to a voltage.

All targets

Channel: AIN (pin XA1)
sim_adc voltage
Sample time:
pai_BasicAnalogInput
This block reads a physical analogue channel identified to obtain a raw input value when run
on target hardware. When run in simulation, the block instead takes the value on its inport
as its raw value.
A raw value is the number obtained from the analogue-to-digital converter in the ECU device
scaled as if it had 10-bit resolution, such that 0 indicates the reference ground (0 V), -1023
indicates the lower reference voltage (-5V) and 1023 indicates the upper reference voltage
(5V).
Note
The worst case conversion time for all analogue-to-digital values is ~500µs. Thus, when
the software asks for an analogue-to-digital conversion, the analogue-to-digital value
may be up to 500µs old.
If the channel selected for this block is related to the IMU on the M250-00Z the range
of representation will be -10V to 10V for the gyroscope values and -20V to 20V for the
gyroscope angle values.
Selecting IMU channels on an M250 for which the IMU is not populated will have no
effect.
Note
Once read, the [-5, 5]V range must be scaled by the application to the range indicated
in the technical specification for the selected target.
6.1.5.4. Inports
• sim_adc
Only used under simulation when the parameter Provide simulation input? is ticked. The
outport voltage is written to the value of this inport scaled from A/D counts to a voltage.
Range: [-1023, 1023] A/D counts
Value type: Real

Software detail
6.1.5.5. Outports
• voltage
The raw input reading converted to a voltage assuming the input range is -5V to 5V. The
outport must then be scaled by the application to the range given for the channel in the
target's technical specification.
Range: [-5, 5] volts
Value type: Real
• Channel
The channel pin for this analogue input.
Value type: List

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
• Provide simulation input?
Tick to enable inport sim_adc.
Value type: Boolean

Calibratable: No
6.1.5.7. Notes
None.
6.1.6. Analogue input — processed (pai_AnalogInput)

Read an analogue input channel, convert to engineering units and fault check.

Software detail

All targets

analog_value
Channel: AIN (pin XA1)
Sample time:
Raw Units: ADC Counts
Transfer function (Map):

raw axis: [ ]
sim_raw_value eng. lookup: [ ] confirmed_faults
[Min/max eng. value]: [ ]
[Min/max raw value]: [ ]
Default eng. value:
Absolute slew rate limit:
Leaky bucket rise/fall/hyst: , ,
transient_fault_flag
pai_AnalogInput
This block reads a physical analogue channel identified to obtain a raw input value when run
on target hardware. When run in simulation, the block instead takes the value on its input
as its raw value.
Depending on the block's configuration, a raw value is either a measure of the voltage on the
processor's analog-input pin or the number obtained from the analogue-to-digital converter
in the ECU device scaled as if it had 10-bit resolution, such that 0 indicates the reference
ground (usually 0 volts) and 1023 indicates the upper reference voltage (usually 5 volts).
Note
The worst case conversion time for all analogue-to-digital values is ~500µs. Thus, when
the software asks for an analogue-to-digital conversion, the analogue-to-digital value
may be up to 500µs old.
If the channel selected for this block is related to the IMU on the M250-00Z the range
of representation will be -10V to 10V for the gyroscope values and -20V to 20V for the
gyroscope angle values.
Selecting IMU channels on an M250 for which the IMU is not populated will have no
effect.
When the Transfer function type is set to “Map”, the block converts the raw value into an
engineering value through a 1-d table look-up. When set to “Linear”, the block uses a linear
equation with a specified scale and offset to convert the raw value to engineering value.
An engineering value is the value which takes the physical units appropriate for a particular
input device, e.g. kPa for a pressure sensor. This is obtained from the raw value through
some appropriate transformation. As the user specifies the transformation in the mask, it is
the responsibility of the user to choose appropriate and consistent units.
This block provides range and slew fault checking for analogue inputs. Range checking is
performed for raw values as well as engineering values.
When any range or slew error is detected, the block initially yields the last good value held.
If the leaky bucket confirms a fault however, the default value is output instead.
Filtering of faults is achieved using a leaky bucket algorithm. A leaky bucket integrator is used
to decide when an input is confirmed as faulty as a function of its current state, which may
be only transiently in error. Here the bucket always has a total volume or depth of unity (1.0).

Software detail
When the input is deemed to be in error (e.g. out of range), water is poured into the bucket
at some rise rate. At all times water flows out of a leak in the bottom of the bucket with some
fall rate until it is empty. If the bucket should ever fill to the brim by reaching a depth greater
than or equal to 1.0, the input is confirmed as faulty. Should the bucket subsequently empty
to below its hysteresis depth, it is no longer confirmed as faulty.
6.1.6.4. Inports
• sim_raw_value
Only used under simulation. Under simulation, the value of this inport is used as the
analogue input A/D counts.
Range: [-1023, 1023] A/D counts, [-5, 5] Volts
Value type: Real

Calibratable: No
6.1.6.5. Outports
• analog_value
Engineering value of the analogue input conversion (see Transfer function for the
conversion), possibly clamped to the default value if any faults are active.
Value type: Real

Calibratable: No
• confirmed_faults
A vector of 5 outputs. if any are set, a confirmed fault condition is set.
Element Description Range

1 Raw output is below lower range limit. 0 or 1
2 Raw output is above upper range limit. 0 or 1
3 Slew rate fault for raw value. 0 or 1
4 Engineering output is below lower range limit. 0 or 1
5 Engineering output is above upper range limit. 0 or 1
Value type: Boolean

Calibratable: No
• transient_fault_flag
Whether the input value is currently faulty (e.g. out of range). A scalar flag.
Range: 0 or 1
Value type: Boolean

Calibratable: No

Software detail
• Channel
The channel pin for this analogue input.
Value type: List

Calibratable: No
• Raw data units
The units in which the raw analogue input data is read. Either 'ADC Counts' (default) or
'Volts'.
Value type: List

Calibratable: No
• Transfer function type
The type of transfer function to use when converting from raw units to engineering units.
Either 'Map' (default) or 'Linear'.
This enables or disables the following parameters:

Software detail
Parameter Map Linear

Transfer function raw axis Enabled Disabled
Transfer function engineering look-up Enabled Disabled
Transfer function scale Disabled Enabled
Transfer function x offset Disabled Enabled
Transfer function z offset Disabled Enabled
Value type: List

Calibratable: No
• Transfer function raw axis
Vector of breakpoints for z = f(x) raw value to engineering value look-up when Transfer
function type is set to Map.
Value type: Real

• Transfer function engineering look-up
Vector of data points for engineering value look-up when Transfer function type is set to
Map.
Value type: Real

• Transfer function scale
Scale of transfer function when Transfer function type is set to Linear. 'm' for z = m*(x +
a) + b
Value type: Real

• Transfer function x offset
Offset of transfer function when Transfer function type is set to Linear. 'a' for z = m*(x +
a) + b
Value type: Real

• Transfer function z offset
Offset of transfer function when Transfer function type is set to Linear. 'b' for z = m*(x +
a) + b
Value type: Real

• Default engineering value
Engineering value to be output if a fault condition is confirmed for this input.
Value type: Real

Software detail
• Separate min/max values?
Tick to separate min and max values into separate values, or combine into a vector.
This is accomplished by enabling or disabling the following parameters:
Parameter Unchecked Checked

Minimum engineering value, Maximum Enabled Disabled
engineering value
Minimum raw value, Maximum raw value Enabled Disabled
Minimum engineering value Disabled Enabled
Maximum engineering value Disabled Enabled
Minimum raw value Disabled Enabled
Maximum raw value Disabled Enabled
Value type: Boolean

Calibratable: No
• Minimum engineering value, Maximum engineering value
Vector of minimum and maximum permissible engineering values before input considered
faulty when Separate min/max values? is unchecked.
Value type: Real

• Minimum raw value, Maximum raw value
Vector of minimum and maximum permissible raw values before input considered faulty
when Separate min/max values? is unchecked.
Value type: Integer

• Minimum engineering value
Minimum permissible engineering values before input considered faulty when Separate
min/max values? is checked.
Value type: Real

• Maximum engineering value
Maximum permissible engineering values before input considered faulty when Separate
min/max values? is checked.
Value type: Real

• Minimum raw value
Minimum permissible raw values before input considered faulty when Separate min/max
values? is checked.

Software detail
Value type: Integer

• Maximum raw value
Maximum permissible raw values before input considered faulty when Separate min/max
values? is checked.
Value type: Integer

• Absolute raw slew rate limit
Maximum absolute rate of change of input calculated over one model iteration before input
considered faulty.
Range: [-inf, inf] A/D counts/sec, [-inf, inf] Volts/sec,
Value type: Real

• Leaky bucket rise rate
Rate at which leaky bucket is filled when input is faulty in some respect.
Range: [0, 1000] /sec
Value type: Integer

• Leaky bucket fall rate
Rate at which leaky bucket is emptied if it is not already empty.
Range: [0, 1000] /sec
Value type: Integer

• Leaky bucket hysteresis level
Level below which bucket depth must fall before fault is no longer considered faulty. If set
to a negative value, fault remains latched. As a special case, if the hysteresis depth is set
negative, should the input ever reach a confirmed fault state it remains "latched" there until
the ECU device is powered down.
Range: [-1, 1] unitless
Value type: Real

• Sample time
Value type: Real

Software detail
Calibratable: No
Tick to enable inport sim_raw_value.
Value type: Boolean

Calibratable: No
6.1.6.7. Notes
If a map name is given for the transfer function, both Transfer function raw axis and Transfer
function engineering look-up must be named (i.e., it is not possible to name one and give a
numerical vector for the other).
6.1.7. Build model (prtw_Build)

Start a model build.

All targets

Double click to
build model
A utility block to start a model build (equivalent to the keyboard shortcut CTRL-B when a
Simulink model window is in focus).
6.1.7.4. Inports
None.
6.1.7.5. Outports
None.

6.1.7.7. Notes
None.
6.1.8. Boot code build date (psc_BootBuildDate)

Get the build date for the ECU's boot code.

All targets

Software detail

year
month
day
psc_BootBuildDate
Gets the build date for the ECU's boot code. The build date can be used to distinguish
between different versions of the boot code.
6.1.8.4. Inports
• sim_year
Range: [1970, 3000]
• sim_month
Range: [1, 12]
• sim_day
Range: [1, 31]
6.1.8.5. Outports
• year
The year the boot code was built. Under simulation, if the Provide simulation inports
Range: [1970, 3000]
• month
The month of the year the boot code was built. Under simulation, if the Provide simulation
Range: [1, 12]
• day
The day of the month the boot code was built. Under simulation, if the Provide simulation
Range: [1, 31]

Software detail
6.1.8.7. Notes
None.
6.1.9. Boot code version (psc_BootVersion)

Get the version information for the ECU's boot code.

All targets

major_ver
minor_ver
sub_minor_ver
psc_BootVersion
Gets the version information for the ECU's boot code. The version number is composed of
three fields, major, minor and sub-minor, typically written as major.minor.sub-minor.
6.1.9.4. Inports
• sim_major_ver
Range: [0, 65535]
• sim_minor_ver
Range: [0, 65535]

Software detail
Range: [0, 65535]
6.1.9.5. Outports
• major_ver
The major version number of the boot code. Under simulation, if the Provide simulation
Range: [0, 65535]
• minor_ver
The minor version number of the boot code. Under simulation, if the Provide simulation
Range: [0, 65535]
• sub_minor_ver
The sub-minor version number of the boot code. Under simulation, if the Provide simulation
Range: [0, 65535]
6.1.9.7. Notes
None.
6.1.10. Boot code part number (psc_BootPartNumber)

Get the part number information for the ECU's boot code.

All targets

Software detail

group_id
group_letter
part_id
issue
psc_BootPartNumber
Gets the part number information for the ECU's boot code. The part number is composed of
four fields, group identification number, group identification letter, part identification number
and issue number, typically written as group_idgroup_letter-part_id Iss issue.
Example: 12T-168232 Iss 3 The part number can be used by the application for
diagnostics, tracking and identification.
6.1.10.4. Inports
• sim_group_id
The outport group_id is set to the value of this inport for simulation purposes.
Range: [0, 255]
• sim_group_letter
The outport group_letter is set to the value of this inport for simulation purposes.
Range: [0, 255]
• sim_part_id
The outport part_id is set to the value of this inport for simulation purposes.
Range: [0, 4294967295]
• sim_issue
The outport issue is set to the value of this inport for simulation purposes.
Range: [0, 65535]
6.1.10.5. Outports
• group_id
The Group Identification number of the part number of the boot code. Under simulation, if
the Provide simulation inports parameter isn't ticked, the outport is set to the minimum of
its range. The signal attached to the outport must be set as ExportedGlobal.
Range: [0, 255]
• group_letter
The Group Identification letter of the part number of the boot code. The value represents
the ASCII code of the letter. Under simulation, if the Provide simulation inports parameter
isn't ticked, the outport is set to the minimum of its range. The signal attached to the outport
must be set as ExportedGlobal.

Software detail
Range: [0, 255]
• part_id
The Part Identification number of the part number of the boot code. Under simulation, if
the Provide simulation inports parameter isn't ticked, the outport is set to the minimum of
its range. The signal attached to the outport must be set as ExportedGlobal.
Range: [0, 4294967295]
• issue
The Issue number of the part number of the boot code. Under simulation, if the Provide
Range: [0, 65535]
Tick to enable inports sim_group_id, sim_group_letter, sim_part_id and sim_issue.
6.1.10.7. Notes
None.
6.1.11. CAN bus status (pcx_BusStatus)

Provide information about the error status of a CAN bus.

All targets

Sample time: seconds bus_state
Provide simulation input: off
pcx_BusStatus
Provide the current error state of a CAN bus, one of error-active, error-passive or bus-off.
See the Bosch CAN specification from their web site (http://www.can.bosch.com) or the ISO
specification for more details.

Software detail
In addition to the usual CAN bus-off error handling performed by the CAN controller, when
a CAN bus-off condition is detected by the software, the software temporarily suspends
CAN message transmission. A transmission is then attempted periodically in order to check
whether the bus-off condition has been resolved. After the bus-off condition has been
resolved, the software resumes message transmission as normal.
6.1.11.4. Inports
• sim_bus_state
A dummy input for simulation purposes only. Set to zero to simulate an error-active state,
set to 1 to simulate an error-passive state, and set to 2 to simulate a bus-off state. Only
available if the mask parameter Provide simulation inputs is checked.
Value type: Integer

Calibratable: No
6.1.11.5. Outports
• bus_state
Set to zero if the CAN bus selected through mask parameter CAN Bus Identifier is in the
error-active state, set to 1 if in the error-passive state, and set to 2 if in the bus-off state.
Range: [0, 2]
Value type: Integer

Calibratable: No
• CAN Bus Identifier
Which CAN bus to provide error state information about.
Value type: List

Calibratable: No
• Sample time
Value type: Real

Calibratable: No

Software detail
• Provide simulation inputs
If selected then simulation inport sim_bus_state is made available.
Value type: Boolean

Calibratable: No
6.1.11.7. Notes
None.
6.1.12. CAN configuration (pcx_CANConfiguration)

Specify the configuration for a CAN bus.

All targets

Bit Rate: 100 kBps
pcx_CANConfiguration
Specify the baud rate for a CAN bus. Some OpenECU devices support more than one CAN
bus, in which case, more than one CAN configuration block is required to configure each.
6.1.12.4. Inports
None.
6.1.12.5. Outports
None.
• Bit Rate
The bit rate (or baud rate) of the can bus.
Range: 33.333, 50, 62.5, 83.333, 100, 125, 250, 500 or 1000 kBps
Value type: Real

Software detail
Calibratable: No
Which can bus the configuration applies to.
Value type: Integer

Calibratable: No
6.1.12.7. Notes
• Some ECUs include CAN bus termination internal to the ECU, whilst some do not. Where
CAN bus termination is not provided by the ECU, termination must be provided external
to the ECU. Robust CAN communication requires correct termination. No termination or
double termination can result in intermittent CAN messaging.
6.1.13. CAN Baud Override (pcx_CANBaudOverride)

Specify the baud and listen mode configuration for a CAN bus at runtime.

All targets

baud baud_error
CAN Bus: CAN A (pin YE4+YF4)
lom_active baud_match
pcx_CANBaudOverride
On application initialization or on a change of either of the inports, if the inport values are valid
settings, the CAN device will be stopped, configured to the inport settings, and restarted. The
baud setting will override any baud specified by pcx_CANConfiguration. The baud_match
outport will be set to 0 until a valid CAN message is received.
In listen-only mode, transmission is disabled, all error counters are frozen, and the module
operates in a CAN Error Passive mode. Only messages acknowledged by another CAN
station will be received.
To specify that the CAN Baud Override block shall not attempt to change the baud, a value of
"0" can be provided at the "baud" inport. This will be treated as an invalid baud and prevent
any configuration by the block.
Because reconfiguring a CAN device resets its message buffers and may interfere with
any open protocol sessions, CAN protocol communications such as CCP may need to be
restarted by the tool after device configuration.
6.1.13.4. Inports
• baud
The integer representation of a valid baud rate.
Desired Baud Integer Representation

33.333 kBps 33

Software detail
Desired Baud Integer Representation

50 kBps 50
62.5 kBps 62
83.333 kBps 83
100 kBps 100
125 kBps 125
250 kBps 250
500 kBps 500
1000 kBps 1000
Value type: Integer

Calibratable: No
• lom_active
An input of 0 will disable listen-only mode. Any other input will enable listen-only mode.
Value type: Boolean

Calibratable: No
6.1.13.5. Outports
• baud_error
0 if the CAN device is valid and the integer at the baud inport represents a valid baud,
1 otherwise.
If 1, no attempt has been made to reconfigure the CAN device and the previous
configuration persists. Because the configuration has not changed, baud_match will not
be reset.
Range: 0 or 1
Value type: Boolean
• baud_match
1 if a valid CAN message has been received at the current configuration, 0 otherwise.
Will be set to 1 on the reception of any CAN message, whether declared by the application
or not.
Range: 0 or 1
Value type: Boolean

Software detail
Which CAN bus the configuration applies to.
Value type: Integer

Calibratable: No
6.1.13.7. Notes
None.
6.1.14. CAN receive message

(pcx_CANReceiveMessage)
Receive a CAN message and unpack the message contents.

All targets

sim_error_flag Message ID: decimal error_flag
Length: bytes
Field Start Positions: [ ]
Field Widths: [ ]
Field Signs: [ ]
sim_rx_trig_flag Field Type Codes: [ ] rx_trig_flag
Sample Time: seconds
Use Extended ID: off
Provide Simulation Input: off
sim_overrun_flag overrun_flag
pcx_CANReceiveMessage
When a matching CAN message to this block is received, the block unpacks the message
contents into individual signals, as specified by the block mask parameters, and provides
them as outports. It is up to the application to provide an appropriate response (if one is
required).
The block can provide a time stamp of when the message was received (see block mask
parameter Provide Timestamp). The time stamp is a low accuracy time stamp, taken a short
period of time after the message is received. That period of time is variable depending on
the load of the processor and will therefore suffer jitter.
The pcx_CANdb_ReceiveMessage block provides a more convenient mechanism for

specifying CAN information.
Warning
The PCX feature takes precedence over the PJ1939 feature. If you configure the PCX
feature to receive a J1939 frame, the PJ1939 feature will not see the frame, and it
will not be processed by the platform. This especially causes problems when receiving
J1939 DM14 'Boot Load' commands.
6.1.14.4. Inports
• sim_error_flag
A dummy input for simulation purposes only; may be grounded if not required. The value
of outport error_flag in simulation.

Software detail
Value type: Boolean

Calibratable: No
• sim_rx_trig_flag
of outport rx_trig_flag in simulation.
Value type: Boolean

Calibratable: No
• sim_overrun_flag
of outport overrun_flag in simulation.
Value type: Boolean

Calibratable: No
• sim_timestamp
of the output timestamp in simulation. Only available if the mask parameter Provide
Timestamp is selected.
Value type: Integer
6.1.14.5. Outports
• error_flag
Set to 1 if some error has occurred which prevents CAN reception, or 0 otherwise.
Type Conditions setting outport error_flag to 1

run time the bus is in bus off state
run time the size of the most recently received message differs
from the one used in configuration
configuration the bus has not been configured
configuration message not configured, because too many receive
messages
Value type: Boolean

Calibratable: No
• rx_trig_flag
Set to 1 if message data has been received at this iteration without any error, or 0 otherwise.
Value type: Boolean

Calibratable: No
• overrun_flag
Set to 1 if more than one message with the same CAN message identifier has been
received in one model iteration, or 0 otherwise. If more than one message has been
received, the data from the latest message is used.
Value type: Boolean

Software detail
Calibratable: No
• timestamp
A low accuracy time stamp of when the message was last received, or zero if the message
has never been received. The time stamp is a free running microsecond timer, which
wraps to zero at its maximum (rather than saturating). Only available if the mask parameter
Provide Timestamp is selected.
Value type: Integer
• Message Identifier
The unique can identifier of the message to be received.
Range: [0, 2047] if standard identifier
Range: [0, 536870911] if extended identifier
Value type: Integer

Calibratable: No
• Message Length
The number of data bytes to be received.

Software detail
Range: [0, 8] bytes
Value type: Integer

Calibratable: No
• Field Start Bit Positions
A vector of bit numbers indicating the position at which each input Item begins in the CAN
message. 0 corresponds to the least significant bit of data byte 0 of the message and 63
to the most significant byte of data byte 7 of the message, assuming these exist. For items
whose bit length entry exceeds 7, the bit length must be one of: 0, 8, 16, 24, 32, 40, 48, 56.
Size: [1, 64] elements
Range: [0, 8], 16, 24, 32, 40, 48, 56 bit positions
Value type: Integer

Calibratable: No
• Field Widths
A vector of bit lengths indicating the number of bits used to transmit each input Item. The
following values are allowed: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 24 and 32.
Items of 8 bits or fewer may not be defined so as to straddle CAN byte boundaries.
Range: [1, 16], 24 or 32 bit width
Value type: Integer

Calibratable: No
• Field Signs
A vector of 1 or 0 values. Corresponding data items for which this is set 1 are received as
twos-complement signed numbers, or unsigned numbers otherwise.
Range: 0 or 1
Value type: Integer

Calibratable: No
• Type Codes
This block provides one data field input for each element in Field Start Positions, as follows:
Table 6.2. CAN block type codes

Type code Simulink data type
0 real_T (single floating point type)
1 default boolean (boolean or real_T depending on current setting of
Simulink Boolean logic signals setting)
2 signed 8 bit integer (int8_T)
3 unsigned 8 bit integer (uint8_T)

Software detail
Type code Simulink data type

Value type: Integer

Calibratable: No
• Field Mnemonics
A string containing a comma-separated list of names with which to label the simulation
input and CAN data output ports.
Value type: String

Calibratable: No
Which can bus the message will be received on.
Value type: Integer

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
• Use Extended Message Identifier?
If box is checked the 29 bit identifier is to be used, otherwise the 11 bit standard identifier
is to be used.
Value type: Boolean

Calibratable: No
• Provide Timestamp
If selected then inport sim_timestamp and outport timestamp are made available.
Value type: Boolean

Calibratable: No
• Provide Simulation Input?
If selected then dummy inputs for each of the outport can message signals, such as
sim_signal_name, are provided by the block.
Value type: Boolean

Calibratable: No
6.1.14.7. Notes
• Unused signals in a CAN message need not be specified in the Field Start Bit Positions
parameter.
• Not all OpenECU modules have both CAN buses populated (see Section A.1, “ECU
hardware reference documentation” for details about each device).

Software detail
• If the error_flag outport is asserted due to a mismatch in message size, the data outports
will still contain data from the most recently received message.
• If the block shows unnamed outports, it is likely that one or more of the block fields is
incorrect. Check the fields for mistakes and correct them.
• The restrictions involving alignment of data items with 8 or more bits can be overcome
by combining the smaller data items from the CAN message into larger data items using
some Simulink math blocks, or by using the pcx_CANdb_ReceiveMessage block.
• All data is unpacked in Motorola byte ordering (MS byte first, LS byte last). The order
of byte unpacking can be overcome by combining the smaller data items from the
CAN message into larger data items using some Simulink math blocks, or by using the
pcx_CANdb_ReceiveMessage block.
6.1.15. CAN transmit message

(pcx_CANTransmitMessage)
Pack a CAN message with data then transmit it.

All targets

Message ID: decimal
Length: bytes
Field Start Positions: [ ]
Field Widths: [ ]
sim_error_flag Field Signs: [ ] error_flag
Field Type Codes: [ ]
Use Extended ID: off
Provide Simulation Output: off
pcx_CANTransmitMessage
When a message is to be transmitted, the block packs each of the signal inports into the
message, as specified by the block mask parameters, and transmits the message.
The pcx_CANdb_TransmitMessage block provides a more convenient mechanism for

specifying CAN information.
6.1.15.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
• sim_request_count
of outport request_count in simulation. Only available if the mask parameter Provide
Transmission Status is selected.
Value type: Integer

Software detail
• sim_overwrite_count
of outport overwrite_count in simulation. Only available if the mask parameter Provide
Value type: Integer
• sim_ack_count
A dummy input for simulation purposes only; may be grounded if not required. The
value of outport ack_count in simulation. Only available if the mask parameter Provide
Value type: Integer
6.1.15.5. Outports
• error_flag
Set to 1 if some error has occurred which prevents CAN transmission, otherwise set to 0.

run time the message has been queued waiting for a transmit
buffer to become available
configuration message not configured, because too many transmit
messages
Value type: Boolean

Calibratable: No
• request_count
A free running count of the application requests to transmit a message. The counter wraps
to zero at its maximum. Only available if the mask parameter Provide Transmission Status
is selected.
Value type: Integer
• overwrite_count
A free running count of message overwrites. An overwrite occurs when the application
requests transmission of a message prior to successful transmission of data from a
previous request for that message. (For instance, if the CAN bus is heavily loaded and
the transmission rate is high, the CAN controller may not be able to transmit the message
before the application requests it is sent again, possibly with different data control from
the previous request). Only available if the mask parameter Provide Transmission Status
is selected.
Value type: Integer
• ack_count
A free running count of message transmissions successfully made by the CAN controller
(i.e., those transmit messages which were acknowledged by at least one CAN node on
the bus, not including the transmitting node). Only available if the mask parameter Provide

Software detail
Value type: Integer
• Message Identifier
The unique can identifier of the message to be transmitted.
Value type: Integer

Calibratable: No
• Message Length
The number of data bytes to be transmitted.
Range: [0, 8] bytes
Value type: Integer

Calibratable: No
• Field Start Bit Positions
A vector of bit numbers indicating the position at which each input Item begins in the CAN
message. 0 corresponds to the least significant bit of data byte 0 of the message and 63

Software detail
to the most significant byte of data byte 7 of the message, assuming these exist. For items
whose bit length entry exceeds 7, the bit length must be one of: 0, 8, 16, 24, 32, 40, 48, 56.
Range: [0, 8], 16, 24, 32, 40, 48, 56 bit positions
Value type: Integer

Calibratable: No
• Field Widths
A vector of bit lengths indicating the number of bits used to transmit each input Item. The
following values are allowed: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 24 and 32.
Items of 8 bits or fewer may not be defined so as to straddle CAN byte boundaries.
Range: [1, 16], 24 or 32 bit width
Value type: Integer

Calibratable: No
• Field Signs
A vector of 1 or 0 values. Corresponding data items for which this is set 1 are transmitted
as twos-complement signed numbers, or unsigned numbers otherwise.
Range: 0 or 1
Value type: Integer

Calibratable: No
• Type Codes
This block provides one data field input for each element in Field Start Positions, as given
in Table 6.2, “CAN block type codes”.
Value type: Integer

Calibratable: No
• Field Mnemonics
input and CAN data output ports.
Value type: String

Calibratable: No
Which can bus the message will be transmitted on.
Value type: List

Calibratable: No
• Use Extended Message Identifier?
If box is checked the 29 bit identifier is to be used, otherwise the 11 bit standard identifier
is to be used.

Software detail
Value type: Boolean

Calibratable: No
• Provide Transmission Status
If selected then outports request_count, overwrite_count and ack_count, and their

corresponding simulation inports, are made available.
Value type: Boolean

Calibratable: No
• Provide Simulation Output?
If selected then dummy outputs for each of the inport can message signals, such as
Value type: Boolean

Calibratable: No
6.1.15.7. Notes
• Unused signals in a CAN message need not be specified in the Field Start Bit Positions
parameter.
• If the block shows unnamed inports, it is likely that one or more of the block fields is
incorrect. Check the fields for mistakes and correct them.
• The restrictions involving alignment of data items with 8 or more bits can be overcome
by combining the smaller data items from the CAN message into larger data items using
some Simulink math blocks, or by using the pcx_CANdb_TransmitMessage block.
• All data is packed in Motorola byte ordering (MS byte first, LS byte last). The order
of byte packing can be overcome by combining the smaller data items from the CAN
message into larger data items using some Simulink math blocks, or by using the
pcx_CANdb_TransmitMessage block.
6.1.16. CANdb message receive

(pcx_CANdb_ReceiveMessage)
Receive a CAN message, the identifier and contents of which are defined by a Vector CANdb
file.

All targets

sim_error_flag error_flag
CANdb file:
Message name:
sim_rx_trig_flag Sample Time: seconds rx_trig_flag
Expected checksum type: None
pcx_CANdb_ReceiveMessage

Software detail
When a matching message to this block is received, the block unpacks the message contents
into individual signals, as specified by the CANdb information, and provides them as outports
in engineering units.
A CANdb file is a database of information regarding CAN nodes and CAN bus messages
(more information regarding this format can be found by visiting the web site of Vector
CANtech, Inc.). The database is edited using custom tools which make creation and
maintenance of message information easier.
For each message, the database stores information like the message identifier, whether the
identifier is standard or extended, what signals the message contains, etc.. For each signal,
the database stores the start bit position, the bit length, bit ordering etc.. This block provides
access to this information using the textual names assigned in the database, making the
blocks easier to create and maintain (in contrast to the pcx_CANReceiveMessage block).
The block can provide a time stamp of when the message was received (see block mask
parameter Provide Timestamp). The time stamp is a low accuracy time stamp, taken a short
period of time after the message is received. That period of time is variable depending on
the load of the processor and will therefore suffer jitter.
Warning
6.1.16.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
of outport rx_trig_flag in simulation.
Value type: Boolean

Calibratable: No
of outport overrun_flag in simulation.
Value type: Boolean

Calibratable: No
• sim_timestamp
A dummy input for simulation purposes only; may be grounded if not required. The value of
outport timestamp in simulation. Only available if the mask parameter Provide Timestamp
is selected.

Software detail
Value type: Integer
• sim_checksum_err
of outport checksum_err in simulation. Only available if the mask parameter Checksum
Type is not None.
Value type: Boolean
6.1.16.5. Outports
• error_flag
Set to 1 if some error has occurred which prevents CAN reception, or 0 otherwise.

run time the size of the most recently received message differs
from the one used in configuration
configuration message not configured, because too many receive
messages
Value type: Boolean

Calibratable: No
• rx_trig_flag
Value type: Boolean

Calibratable: No
• overrun_flag
Set to 1 if more than one message with the same CAN message identifier has been
received in one model iteration, or 0 otherwise. If more than one message has been
received, the data from the latest message is used.
Value type: Boolean

Calibratable: No
• timestamp
A low accuracy time stamp of when the message was last received, or zero if the message
has never been received. The time stamp is a free running microsecond timer, which
wraps to zero at its maximum (rather than saturating). Only available if the mask parameter
Provide Timestamp is selected.
Value type: Integer
• checksum_err
Set TRUE if the most recently received message failed checksum validation or FALSE
otherwise. Only available if the mask parameter Checksum Type is not None.
Value type: Boolean

Software detail
• CANdb file
The name of the candb file; can be relative to the model directory (i.e., the current
workspace directory) or absolute. Only textual CANdb files are accepted (see restrictions
in the notes section below).
Value type: String

Calibratable: No
• Message Name
The name of the message to receive. The name must be specified in the CANdb file
and must match case (e.g., message name EngineRPM is different from message name
enginerpm).
Value type: String

Calibratable: No
• Signal Names
A comma separated list of signal names to unpack from the message (e.g.,
"name1,name2" without the quotes). An empty list of names to unpack is supported, in
which case the block shows no additional outports. This mode can be used to detect
the presence of a message on the CAN bus without decoding any of the CAN message
contents.
Value type: String

Calibratable: No
• Output All Message Signals

Software detail
If selected then all signals from the message are created as outports (similarly simulation
inports if required), if unselected then only those signals in the signal names field are
created as outports.
If this field is ticked and the dialog closed, next time this field is unticked, the signal names
field will contain the complete list of signals. This mechanism is useful when filling in the
dialog for the first time but you are unsure of the field names (e.g., open block, fill in CANdb
file name, message name, CAN bus and sample time, then tick this field, close the dialog,
then select the block again, untick this field, then edit the list of required signals).
Value type: Boolean

Calibratable: No
• Output Raw Signal Values?
If selected, a second set of outports are created for the message signals, each set to the
raw integer value extracted from the CAN message prior to being scaled into engineering
units.
Value type: Boolean

Calibratable: No
• Clip Signals To Engineering Limits?
If selected, each outport (except for the raw signal outports) is clipped to the limits for that
signal defined by the CANdb file.
Value type: Boolean

Calibratable: No
• Display Signal Units?
If selected then each of the can message outport signals (and simulation inport signals)
show their engineering units, if the CANdb file defines those units.
Value type: Boolean

Calibratable: No
Which can bus the message will be received on.
Value type: Integer

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
• Provide Timestamp
Value type: Boolean

Calibratable: No

Software detail
• Checksum Type
A drop-down selection of the type of checksum to expect in the last raw message byte,
computed over all of the preceding raw bytes in the message (even if they are not used
by any signals). The default is None, and the other currently supported option is the 8-
bit CRC defined by SAE-J1850. If used, the outport checksum_err is filled accordingly. In
simulation, the value from inport sim_checksum_err is passed through.
Value type: List

Calibratable: No
• Provide Simulation Input?
If selected then dummy inputs for each of the outport can message signals, such as
Value type: Boolean

Calibratable: No
6.1.16.7. Notes
• Unused signals in a CAN message need not be specified in the Signal Names parameter.
• If the error_flag outport is asserted due to a mismatch in message size, the data outports
will still contain data from the most recently received message.
• If the block does not show expected signals as outports, it is likely that one or more of the
block fields is incorrect. Check the fields for mistakes and correct them.
• Vector do not release the file format of CANdb files, so this block reads CANdb files as
best it can. When reading the CANdb file, if it cannot understand the file format, the block
will not show the request outports. Update the diagram to find out what the problem is.
• If the block does not show the signal outports expected, there is probably a mistake in
the CANdb file name or one of the signal names. Update the diagram to find out what the
error is.
• The CANdb blocks do not support extended signal multiplexing. If extended signal
multiplexing is present in the CANdb file, then the block will not be able to interpret the file.
6.1.17. CANdb transmit message

(pcx_CANdb_TransmitMessage)
Transmit a CAN message, the identifier and contents of which are defined by a Vector CANdb
file.

All targets


Software detail
CANdb file:
Message name:
sim_error_flag Bus ID: CAN A (pin YE4+YF4) error_flag
Checksum in last byte: None
Provide simulation output: off
pcx_CANdb_TransmitMessage
When a message is to be transmitted, the block encodes each of the signal inports into the
message, as specified by the CANdb information, and transmits the message.
A CANdb file is a database of information regarding CAN nodes and CAN bus messages
(more information regarding this format can be found by visiting the web site of Vector
CANtech, Inc.). The database is edited using custom tools which make creation and
maintenance of message information easier.
For each message, the database stores information like the message identifier, whether the
identifier is standard or extended, what signals the message contains, etc.. For each signal,
the database stores the start bit position, the bit length, bit ordering etc.. This block provides
access to this information using the textual names assigned in the database, making the
blocks easier to create and maintain (in contrast to the pcx_CANTransmitMessage block).
Warning
In some cases, the CAN database will contain messages with multiplexed signals (more
than one signal is defined in a message with the same bit position and length). In order
to use such a message, the user must pre-select only one of the signals to transmit.
To do this, refer to Input All Message Signals?.
6.1.17.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
• sim_request_count
of outport request_count in simulation. Only available if the mask parameter Provide
Value type: Integer
• sim_overwrite_count
of outport overwrite_count in simulation. Only available if the mask parameter Provide
Value type: Integer
• sim_ack_count
A dummy input for simulation purposes only; may be grounded if not required. The
value of outport ack_count in simulation. Only available if the mask parameter Provide

Software detail
Value type: Integer
6.1.17.5. Outports
• error_flag
Set to 1 if some error has occurred which prevents CAN transmission, otherwise set to 0.

run time the message has been queued waiting for a transmit
buffer to become available
configuration message not configured, because too many transmit
messages
Value type: Boolean

Calibratable: No
• request_count
A free running count of the application requests to transmit a message. The counter wraps
to zero at its maximum. Only available if the mask parameter Provide Transmission Status
is selected.
Value type: Integer
• overwrite_count
A free running count of message overwrites. An overwrite occurs when the application
requests transmission of a message prior to successful transmission of data from a
previous request for that message. (For instance, if the CAN bus is heavily loaded and
the transmission rate is high, the CAN controller may not be able to transmit the message
before the application requests it is sent again, possibly with different data control from
the previous request). Only available if the mask parameter Provide Transmission Status
is selected.
Calibratable: No
• ack_count
A free running count of message transmissions successfully made by the CAN controller
(i.e., those transmit messages which were acknowledged by at least one CAN node on
the bus, not including the transmitting node). Only available if the mask parameter Provide
Value type: Integer

Software detail
• CANdb file
The name of the candb file; can be relative to the model directory (i.e., the current
workspace directory) or absolute. Only textual CANdb files are accepted (see restrictions
in the notes section below).
Value type: String

Calibratable: No
• Message Name
The name of the message to transmit. The name must be specified in the CANdb file
and must match case (e.g., message name EngineRPM is different from message name
enginerpm).
Value type: String

Calibratable: No
• Signal Names
A comma separated list of signal names to pack into the message (e.g., "name1,name2"
without the quotes). An empty list of names is supported, in which case the block shows
no additional outports.
Value type: String

Calibratable: No
• Input All Message Signals?
If selected then all signals from the message are created as inports (similarly simulation
outports if required), if unselected then only those signals in the signal names field are
created as inports.

Software detail
If this field is ticked and the dialog closed, next time this field is unticked, the signal names
field will contain the complete list of signals. This mechanism is useful when filling in the
dialog for the first time but you are unsure of the field names (e.g., open block, fill in CANdb
file name, message name and CAN bus, then tick this field, close the dialog, then select
the block again, untick this field, then edit the list of required signals).
Value type: Boolean

Calibratable: No
• Clip Signals To Engineering Limits?
If selected then each signal shall be clipped to their engineering limits.
Value type: Boolean

Calibratable: No
• Display Signal Units?
If selected then each of the can message inport signals (and simulation outport signals)
show their engineering units, if the CANdb file defines those units.
Value type: Boolean

Calibratable: No
Which can bus the message will be transmitted on.
Value type: List

Calibratable: No
• Provide Transmission Status
If selected then outports request_count, overwrite_count and ack_count, and their

corresponding simulation inports, are made available.
Value type: Boolean

Calibratable: No
• Checksum type
A drop-down selection of the type of checksum to apply to the last raw byte in the message,
computed over all of the preceding raw bytes in the message (even if they are not used
by any signals). The default is None, and the other currently supported option is the 8-bit
CRC defined by SAE-J1850.
Value type: List

Calibratable: No
• Provide Simulation Output?
If selected then dummy outports for each of the outport can message signals are provided
by the block.
Value type: Boolean

Calibratable: No
6.1.17.7. Notes
• Unused signals in a CAN message need not be specified in the Signal Names parameter.

Software detail
• If the block does not show expected signals as inports, it is likely that one or more of the
block fields is incorrect. Check the fields for mistakes and correct them.
• Vector do not release the file format of CANdb files, so this block reads CANdb files as
best it can. When reading the CANdb file, if it cannot understand the file format, the block
will not show the request inports. Update the diagram to find out what the problem is.
• If the block does not show the signal inports expected, there is probably a mistake in the
CANdb file name or one of the signal names. Update the diagram to find out what the
error is.
• The CANdb blocks do not support extended signal multiplexing. If extended signal
multiplexing is present in the CANdb file, then the block will not be able to interpret the file.
6.1.18. CAN status — deprecated (pcx_CANStatus)

Provide information about CAN bus off status.

All targets

can0_bus_off
Sample time: seconds

can1_bus_off
pcx_CAN_Status
Provide the bus off state of each CAN bus as an outport. A CAN bus goes bus off
when sufficient errors have been detected by the CAN transceiver. See the Bosch CAN
specification from their web site (http://www.can.bosch.com) or the ISO specification for more
details.
When CAN bus off condition is detected, CAN transmission activity is suspended. A
transmission is then tempted periodically in order to check whether bus off condition has
been resolved. After bus off condition is resolved, transmission resumes as normal.
6.1.18.4. Inports
• sim_can0_bus_off
Only used during simulation. Set to 1 to simulate a CAN bus off state for CAN bus 0, zero
otherwise. Only available if the mask parameter Provide simulation input is checked.
Value type: Boolean

Calibratable: No
• sim_can1_bus_off
Only used during simulation. Set to 1 to simulate a CAN bus off state for CAN bus 1, zero
otherwise. Only available if the mask parameter Provide simulation input is checked.
Value type: Boolean

Calibratable: No

Software detail
6.1.18.5. Outports
• can0_bus_off
Set to 1 if can bus 0 is currently bus off, 0 otherwise.
Value type: Boolean

Calibratable: No
• can1_bus_off
Set to 1 if can bus 1 is currently bus off, 0 otherwise.
Value type: Boolean

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
• Provide simulation input
If selected then simulation inputs for each of the can bus off outports are provided by the
block.
Value type: Boolean

Calibratable: No
6.1.18.7. Notes
This block became deprecated in version 1.8.4 and will be removed in a future version of
the software. Please change to use the Section 6.1.11, “CAN bus status (pcx_BusStatus)”
block.
6.1.19. CCP configuration (pcp_CCPConfiguration)

This block configures the way OpenECU handles any CAN Calibration Protocol (CCP)
messages it receives.

Software detail

All targets

CAN receive ID: 1785
CAN station address: 0
CAN bus ID: CAN A (pin YE4+YF4)
CCP enabled: on
pcp_CCPConfiguration
The CAN Calibration Protocol (CCP) is a CAN based messaging system designed to allow
tools to access information in real-time. For more details, refer to ASAM Standards: ASAM
MCD: MCD 1a at the ASAM Web site (http://www.asam.de).
This block configures OpenECU's CCP settings. The user can choose the transmit and
receive CAN message identifiers, the CCP station address and the CAN bus communications
will take place over. The block also configures whether CCP communications can take place
when the ECU is in application mode running the model.
If the block is absent from the model, CCP communications is disabled when the model is
running. CCP communications are still possible when OpenECU is being reprogrammed.
6.1.19.4. Inports
None.
6.1.19.5. Outports
None.
• Receive message identifier
A unique CAN message identifier for CCP CRO messages.

Software detail
Range: [0, 2047] or [0, 536870911] when Use CRO extended ID? (29 bit) is selected.
Value type: Integer

Calibratable: No
• Transmit message identifier
A unique CAN message identifier for CCP DTO messages.
Range: [0, 2047] or [0, 536870911] when Use DTO extended ID? (29 bit) is selected.
Value type: Integer

Calibratable: No
• Station address
The station address for CCP sessions. OpenECU will only communicate using CCP if a
session is opened using this station address. This feature is often used for connecting
multiple CCP devices to the same CAN bus using the same CRO and DTO identifiers.
Range: [0, 255]
Value type: Integer

Calibratable: No
• CAN bus identifier
Which can bus CCP communications will occur on.
Value type: List

Calibratable: No
• Enable CCP during model execution?
If checked, then CCP communications is enabled while the model is running. If unchecked,
CCP communications is disabled while the model is running. In either case, CCP
communications is enabled when reprogramming OpenECU.
Warning
By not checking this option, reprogramming mode can only be entered with FEPS
applied. The ECU will not be able to be re-flashed without FEPS.
Value type: Boolean

Calibratable: No
• Use CRO extended ID? (29 bit)
If checked, then 29 bit CAN identifiers for CCP receive messages will be supported the
range being [0, 536870911]. If unchecked, then CCP will support 11 bit CAN identifiers
the range being [0, 2047].
Value type: Boolean

Calibratable: No
• Use DTO extended ID? (29 bit)
If checked, then 29 bit CAN identifiers for CCP transmit messages will be supported the
range being [0, 536870911]. If unchecked, then CCP will support 11 bit CAN identifiers
the range being [0, 2047].

Software detail
Value type: Boolean

Calibratable: No
6.1.19.7. Notes
• CCP communications can only be configured for one CAN bus. OpenECU does not support
CCP on more than one CAN bus.
• It is possible to connect OpenECU to a CAN bus with other nodes that also communicate
using CCP (including other OpenECU devices):
CAN bus
CCP device
OpenECU (possibly another
OpenECU)
CCP settings CCP settings
CRO ID: 1785 CRO ID: 1787

DTO ID: 1784 DTO ID: 1786
Station ID: 0 Station ID: 0
Here, both devices use different CRO and DTO message identifiers. This is enough to
uniquely identify each device. Note that although each device has a station address of
zero, because all CRO and DTO identifiers are unique, the station addresses could be
any value.
CAN bus
CCP device
OpenECU (possibly another
OpenECU)
CCP settings CCP settings
CRO ID: 1785 CRO ID: 1785

DTO ID: 1784 DTO ID: 1784
Station ID: 0 Station ID: 1
Here, both devices use the same CRO and DTO message identifiers so the station address
is used to distinguish between CCP devices.
Section B.3.3, “Configuring two OpenECUs on the same CAN bus with ATI Vision” details
how to connect ATI Vision and two ECUs for the first time. The procedure is similar for
other tools.
• If no configuration block exists in the model, CCP communications are disabled when the
model is running. When reprogramming, the following default settings are used:

Software detail
Table 6.3. CCP defaults

CCP setting Default value
CRO message identifier 1785
DTO message identifier 1784
Station address 0
CAN bus identifier CAN 0 or CAN A
a
CAN bus baud-rate 250kBps or 500kBps
a
The default baud-rate for CCP will depend on which version of firmware was flashed into the ECU. Standard
ECUs (such as M220-000 or M250-000) typically use 500 kBps default baud rate, but note that the M461-000
uses 250 kBps. Refer to Section 6.3, “OpenECU software versioning” for details.
• If a configuration block exists in the model but CCP communications are disabled then
when reprogramming, the CCP settings from the configuration block are used.
• If the hardware does not support the CAN bus selected, CCP communications will cease
while the model is running and while reprogramming. In this case, the OpenECU device
must be returned to Pi for reconditioning.
• The platform software supports version 2.1 of the CCP standard (Table F.1, “Supported
CCP commands” shows which commands are implemented).
Warning
OpenECU does not adhere to all the message timing characteristics listed by the
CCP standard all the time (especially when the model being run pushes the CPU
loading closer to 100%). Some calibration tools may raise an error or warning if it
does not receive a rely to a command within a time
• If the OpenECU module is not communicating to the calibration tool after a recently build
model is flashed onto the ECU, then try following Appendix G, CCP troubleshooting guide
to recover the ECU.
6.1.20. CCP raster configuration (pcp_RasterConfig)

This block configures CCP DAQ rasters.

All targets

Name: ''
Desc: ''
Size:
Rate: (sec)
pcp_RasterConfig
The CAN Calibration Protocol (CCP) is a CAN based messaging system designed to allow
tools to access information in real-time. For more details, refer to ASAM Standards: ASAM
MCD: MCD 1a at the ASAM Web site (http://www.asam.de).

Software detail
Calibration tools can request the ECU transmit data on a periodic basis. OpenECU supports
grouping data into at most 8 data acquisition lists (DAQs). The size and rate of each of these
DAQs can be adjusted by this block.
Note
If there are no pcp_RasterConfig blocks in the application then the following default
configuration is applied.
M220 M560
M221 M580
M250 M670
M460
M461
Rate (milliseconds) Size Size
10 15 30
100 15 30
200 15 30
1000 15 30
6.1.20.4. Inports
None.
6.1.20.5. Outports
None.
• Name
A unique name for the CCP DAQ raster. The name is written to the ASAP2 file and used
by the calibration tool to identify the raster.
Value type: String

Software detail
Calibratable: No
• Description
A description of the CCP DAQ raster's use.
Value type: String

Calibratable: No
• Size
The number of ODTs for the CCP DAQ raster. The total number of ODTs across
pcp_RasterConfig blocks must not exceed the range given below. For instance, on the
M670, it is permissible to have two pcp_RasterConfig blocks each with a size of 127. But
adding a third pcp_RasterConfig with a size of 1 brings the total to 255, which exceeds
the limit.
Range: [1, 254]
Value type: Integer

Calibratable: No
• Transmission rate
The suggested period between transmission of the CCP DAQ raster. Some calibration
tools will use the suggested period (e.g., INCA) whilst other calibration tools will ignore the
suggest period and allow the user to vary the transmission rate on the fly (e.g., Vision).
One of 0.005, 0.010, 0.030, 0.050, 0.100, 0.200, 0.500, 1.000 seconds
Value type: Real

Calibratable: No
6.1.20.7. Notes
None.
6.1.21. CCP seed/key security (pcp_CCPSecurity)

Control whether seed/key security is required for CCP calibration, data acquisition and/or
reprogramming.

All targets

Calibration security: off
Data acquisition security: off
Programming security: off
pcp_CCPSecurity
To prevent third parties recalibrating or reprogramming modules, manufacturers typically

enable CCP seed/key security for production modules. This requires a valid seed/key
exchange to take place with the calibration tool, where the module generates a seed (usually

Software detail
at random) and the calibration tool must respond with the correct key value corresponding
to that seed, calculated by a secret algorithm known to the module and the calibration tool.
Brute-force attacks are deterred by applying a significant delay (usually 10s) after each
incorrect key before a further attempt may be made.
To ensure that CCP seed/key security is also used during reprogramming mode, the functions
used to generate the seed (if required) and validate the key are copied to non-volatile storage
by the application. The reprogramming mode software retrieves the functions from non-
volatile storage, and copies them to RAM for execution.
CCP privilege levels are defined as: calibration; data acquisition; and programming. From
the calibration tool it is necessary to gain access to calibration before carrying out data
acquisition; and likewise it is necessary to gain access to calibration before carrying out
programming. Note however that data acquisition and programming privilege levels are
independent: it is possible to read variables without being able to reprogram the module,
and vice versa.
CCP seed/key security is a standard feature of the protocol; however configuring it on

different calibration/programming tools requires some knowledge of that tool's operation.
Support will currently only be given for CCP seed/key security on PiSnoop (see Section B.2,
“PiSnoop”), Vector CANape (see Section B.5, “Vector CANape”), and ATI Vision (see
Section B.3, “ATI Vision”).
Seed generator function

The seed generator function must be of the form:
void seed_generator(const U8 privilege_level, U8 *const seed)
privilege_level specifies the privilege level for which a seed is being requested.
Values are fixed by the CCP standard as:
• 0x01 (1): Calibration
• 0x02 (2): Data acquisition
• 0x40 (64): Programming
seed is a four-byte array. This will initially contain values generated by a 32-bit random
number algorithm within the OpenECU platform. The seed generator function may
choose to leave these values intact, or may choose to set its own values in the seed
array.
Key validator function

The key validator function must be of the form:
BOOL key_validator(const U8 privilege_level, const U8 *const seed,

const U8 *const key, const U8 key_size)
privilege_level specifies the privilege level for which a seed is being requested.
seed is a four-byte array containing the last seed value passed to the calibration tool.
key is an array of up to six bytes whose length is specified by key_size. This contains
the key passed back by the calibration tool.
The CCP 2.1 specification for the CCP_UNLOCK command has a six-byte field for the
key, although in practice most implementations only use four bytes. The contents of the
remaining bytes are often undefined, so the key validator must take care to match the
expected seed-key algorithm.

Software detail
The function must return TRUE if the key is valid for the seed, or FALSE if it is not.
Implementing seed/key functions

Because the seed generator and key validator functions will be relocated and run
during reprogramming mode, it is ESSENTIAL that these functions do NOT access
any global or static storage OR call any functions. If this is not the case, relocating
and invoking the function in reprogramming mode will have unexpected consequences,
because the function will read/write/execute memory at addresses which are not valid
when in reprogramming mode. These consequences may include stuck outputs resulting
in physical damage to hardware or electrical damage to the ECU, and/or complete
permanent disablement of the ECU.
Diab implementation considerations

If the application is built using the Diab compiler, then the file containing these
functions should be specified for compilation as normal. It is frequently the case that
seed/key functions are supplied only as object or library code for security reasons,
in which case the file must have been compiled with PowerPC variable bit length
(VLE) instructions.
GCC implementation considerations

If the application is built using GCC, then the file containing these functions must
also contain section attribute specifiers to place the code in sections that correspond
to the names of the security functions. The attribute specifiers must be applied to the
function prototypes in the form:
void seed_generator(const U8 privilege_level, U8 *const seed)

__attribute__ ((section (".seed_generator")));
It is frequently the case that seed/key functions are supplied only as object or library
code for security reasons, in which case the file must have been compiled without
PowerPC variable bit length (VLE) instructions.
6.1.21.4. Inports
None.
6.1.21.5. Outports
None.

Software detail
The CAN bus for which CCP security will be implemented. A pcp_CCPConfiguration block
must also exist in the design which configures CCP for this CAN bus. If this does not exist,
an error will be reported.
Value type: List

Calibratable: No
• Security required
Whether CCP seed/key security is required for this CCP privilege level.
Value type: Boolean

Calibratable: No
• ECU seed generator function (optional)
If required, the name of the C function which generates the seed value. If this is not
specified, a random 4-byte value will be generated by the OpenECU platform and used
as a seed instead.
Value type: String

Calibratable: No
• ECU key validator function
The name of the C function which validates the key value transmitted by the calibration
tool. If this is not specified, an error will be reported.
Value type: String

Calibratable: No
• ASAP security DLL (optional)
If required, the name of the DLL supplying the key generation algorithm for the calibration
tool. This will typically only be required if the RTW build is required to generate ASAP2
(A2L) files to configure the calibration tool. If this is not specified, security will not be
configured in the A2L files, although typically the user will still be able to configure security
manually from within the calibration tool.
Value type: String

Calibratable: No
• ASAP security DLL function (optional)
If required, the name of the function within the DLL supplying the key generation algorithm.
If unspecified, this will default to using the ASAP1A/ASAP2 standard function name
ASAP1A_CCP_ComputeKeyFromSeed. Note that some calibration tools do not permit the
function name to be specified; see the relevant section for the calibration tool to be used
for further details.
Value type: String

Calibratable: No
• Algorithm development mode (unsecure)
Whether the ECU should ignore security algorithms when reprogramming mode is entered
as a result of the module powering up with FEPS applied.
This option allows a security algorithm to be tested without the risk of putting the ECU in a
state where it cannot be reprogrammed. Otherwise, an error in the security algorithm will
necessitate returning the ECU to Pi for servicing.

Software detail
Value type: Boolean

Calibratable: No
6.1.21.7. Notes
The file(s) containing seed generator and key validator functions must be referenced by the
model. In Simulink, select the "Custom Code" option (found alongside other code generation/
RTW model build options; the menu item depends on MATLAB version). If these functions
are provided as uncompiled C, add the files to the list of "Include list of additional: Source
files". If these functions are provided as precompiled object or library files (as is frequently
done for security reasons), add them to the list of "Include list of additional: Libraries". RTW
will then compile (if necessary) and link these files as part of the build.
Note that if incorrect function names are specified for seed generator or key validator
functions, if the functions do not have the correct prototype, or if the relevant files are not
compiled/linked in the model, then the build will fail at the link stage. If this occurs, check that
function names and file names are specified correctly.
6.1.22. CCP inhibit reprogramming

(pcp_CCPInhibitReprogramming)
Control whether reprogramming can occur via CCP when the application is running.

All targets

Inhibit
inhibit
Reprogramming
pcp_CCPInhibitReprogramming
It is often useful to be able to disallow reprogramming of the module when performing certain
actions, e.g., controlling an engine. Use this block to specify when reprogramming is allowed.
When disallowed, the following CCP operations will not be honoured (but other implemented
CCP operations are; see Table F.1, “Supported CCP commands” for a complete list of
supported CCP commands):
CCP Command Identifier

CLEAR_MEMORY 16
SELECT_CAL_PAGE 17
PROGRAM 24
MOVE 25
DIAG_SERVICE 32
ACTION_SERVICE 33
PROGRAM_6 34

Software detail
If the block is not included by an application in a model, then reprogramming is allowed by

default.
Warning
If the application is configured to inhibit reprogramming it may require the module to
be powered up with FEPS applied in order to re-flash the module.
6.1.22.4. Inports
• inhibit
Set to 0 to allow reprogramming, set to 1 to disallow reprogramming.
Value type: Boolean

Calibratable: No
6.1.22.5. Outports
None.
6.1.22.7. Notes
This block replaces the previous mechanism for inhibiting reprogramming via the automatic
ASAP2 entry mpl_inhibit_reprog. This ASAP2 entry is no longer available.
6.1.23. CCP CRO receive count (pcp_CCPRxCount)

Get the number of CCP CRO messages received since the last reset.

All targets

sim_count rx_count
Provide simulation input: on
pcp_CCPRxCount
The platform CCP drivers keep track of various statistics, including the number of CRO
messages received by the driver.

Software detail
6.1.23.4. Inports
• sim_count
Only used during simulation. The value of this inport will be passed to rx_count. Only
available if the mask parameter Provide simulation input is checked.
Range: [0, 4294967295] messages
Value type: Integer
6.1.23.5. Outports
• rx_count
The number of CRO messages this module has received since the last reset. This value
will wrap around when 2^32 messages have been received.
Range: [0, 4294967295] messages
Value type: Integer
• Sample time
Value type: Real

Calibratable: No
• Provide simulation input
If selected then simulation inport sim_count is made available.
Value type: Boolean

Calibratable: No
6.1.23.7. Notes
6.1.24. Compiler options (pcomp_CompileOptions)

Specify or append compiler options when building a model.

Software detail

All targets

Compiler option mode:
Use default options
pcomp_CompileOptions
After RTW has generated code for a model, a compiler converts the code into a binary image
suitable for the ECU to execute. Which compiler to use is chosen through the RTW Compiler
Selection option.
The compiler converts the model code into a binary image using various transformations,
some of which can be modified via command line options to the compiler. The
pcomp_CompileOptions block selects whether to use the default compiler options supplied
with OpenECU, to add additional options to the default options, or to replace the default
options altogether.
Warning
Alteration of the compiler options may lead to a model which fails to build, or a model
which will not run on the target ECU or which may run initially but fail later on. When
reporting a failure through technical support, please specify any changed compiler
options as this may help resolve the issue more quickly.
Diab 5.5.1.0
The default compiler options for the WindRiver Diab 5.5.1.0 compiler are:
Option Use
-c produce an object file only — do not attempt to link (OpenECU
compiles each source file separately, then links each together,
this is a required option)
-DREAL_T=float define RTW's real_T to be of 'float' type — this matches the
hardware most closely and provides good performance,
switching to 'double' will cause library incompatibility and slow
down the model significantly
-g3 generate debug information as much as possible given the
optimisations selected
-O turn on the compiler optimiser to reduce the binary image size
and increase the run time efficiency
-ew1551 suppress errors about volatile qualification mismatch between
RTW functions and calibrations
-Xaddr- ask the compiler to address all small data objects using
sconst=0x11 absolute addressing (i.e., not relative addressing via r2 or r13)
because the address range of the calibration data is too large
for relative addressing — defensive measure only; not strictly
necessary because the -Xsmall-const option makes sure no
data object is classed as small.

Software detail
Option Use
-Xbss-common- ask the compiler to ensure that there is only one declaration of
off a variable (without initialisation) — ensure there are no separate
objects for the same variable in different modules
-Xdouble-avoid ask the compiler to generate 32-bit floating point constants
rather than 64-bit floating point constants to reduce size and
increase run time efficiency
-Xenum-is-int ensure that C and C++ objects link using the same data type
for enumerations — although not strictly necessary (and
OpenECU does not yet support C++ code), it may be an issue
for customer linked code
-Xforce- lint like option to ensure all functions have been declared with
prototypes a prototype — i.e., ensure we don't fall into the trap of implicit
function declarations which don't match the actual function
declaration
-Xieee754- request that the compiler match, as closely as possible, the
pedantic IEEE754 floating-point specification
-Xkeep- ask the compiler to keep the binary image representation —
assembly-file useful for diagnosing compiler problems
-Xkeywords=0x08 allow the use of the non-standard packed keyword to achieve
better use of memory in some data structures
-Xkill- avoid a bug in some versions of the Diab C compiler which
reorder=0x08 incorrectly applies peep-hole optimisation to instructions which
should not be transposed in the binary image
-Xmin-align=1 allow the compiler to place some packed data on address
boundaries which are not natural for some data types
-Xname- ask the compiler to place all calibration variables in the same
const=.cal_sec memory section for simple linking
-Xpass-source ask the compiler to output C source intermixed with the
assembly instructions — useful for diagnosing compiler
problems
-Xsmall-const=0 ask the compiler to avoid placing data objects in the small const
data area (see also, -Xaddr-sconst)
-Xstrict-eabi ensure the compiler does not generate stswi and lswi
instructions
-Xstsw-slow ensure correct calling procedure for architecture across different
object code — although not strictly required at the moment, this
defines the object interface for other object code that may be
linked to the final model e.g., custom code
-t... selects the processor for the target ECU (target-specific)
Diab 5.8.0.0
The default compiler options for the WindRiver Diab 5.8.0.0 compiler are the same as
Diab 5.5.1.0.
Diab 5.9.0.0
Diab 5.5.1.0.
Diab 5.9.4.8
Diab 5.5.1.0.

Software detail
Diab 5.9.6.7
Diab 5.5.1.0.
All Diab compilers

The build mechanism also adds the following WindRiver Diab compiler options. These
options cannot be changed.
Option Use
-t... set to -tPPCE200Z3VEF for the M220, M221, M250, M460 and
M461 or set to -tPPCE200Z7VEF for the M550 and M670 —
selects the processor for the target ECU
GCC 4.7.3
Option Use
-c produce an object file only — do not attempt to link (OpenECU
compiles each source file separately, then links each together,
this is a required option)
-DREAL_T=float define RTW's real_T to be of 'float' type — this matches the
hardware most closely and provides good performance,
switching to 'double' will cause library incompatibility and slow
down the model significantly
-fkeep-static- emit variables declared static const when optimization isn't
consts turned on, even if the variables aren't referenced
-funsigned-char matching the default signed-ness of char for the Diab compiler
and the platform library files
-fno-common controls the placement of uninitialized global variables —
specifies that the compiler should place uninitialized global
variables in the data section of the object file, rather than
generating them as common blocks
-g3 generate debug information as much as possible given the
optimisations selected
-G 8 put global and static objects less than or equal to num bytes
into the small data or BSS sections instead of the normal data
or BSS sections. The default value of num is 8. The -msdata
option must be set to one of 'sdata' or 'use' for this option to
have any effect. All modules should be compiled with the same
-G num value. Compiling with different values of num may or
may not work — if it doesn't the linker gives an error message --
incorrect code is not generated.
-mcpu=e500mc selects the type of RX CPU to be targeted
-meabi align the stack to an 8-byte boundary
-memb set the PPC EMB bit in the ELF flags header to indicate that
'eabi' extended relocations are used
-mno- generate code that does not allow a static executable to be
relocatable relocated to a different address at run time. A simple embedded
PowerPC system loader should relocate the entire contents
of .got2 and 4-byte locations listed in the .fixup section, a table
of 32-bit addresses generated by this option
-mno- generates a .fixup section to allow static executables to be
relocatable-lib relocated at run time

Software detail
Option Use
-mregnames generate 'in', 'loc', and 'out' register names for the stacked
registers
-msdata put small initialized const global and static data in the '.sdata2'
section, which is pointed to by register r2. Put small initialized
non-const global and static data in the '.sdata' section, which
is pointed to by register r13. Put small uninitialized global and
static data in the '.sbss' section, which is adjacent to the '.sdata'
section
-O turn on the compiler optimiser to reduce the binary image size
and increase the run time efficiency
-pass-exit- return with the numerically highest error produced by any phase
codes returning an error indication. The C front end returns 4 if an
internal compiler error is encountered
-x c use the C language when compiling
-Wno-attributes do not warn if an unexpected __attribute__ is used, such as
unrecognized attributes, function attributes applied to variables,
etc. This will not stop errors for incorrect use of supported
attributes
-Wa,-aln ask the compiler to keep the binary image representation —
useful for diagnosing compiler problems
All compilers
The build mechanism also adds the following compiler options. These options cannot
be changed.
Option Use
-D... various RTW required macro definitions
-DCFG_... defines the ECU the model is targeted at
-I... various include paths for source files (model based, RTW
based, compiler based and OpenECU based)
Note
Its outside the scope of this User Guide to explain all the different compiler options in
detail and their resulting affect on the ECU binary image. Please refer to appropriate
compiler User Guide for more information.
Note
Alteration of the compiler options may remove options which work around known bugs
in the compiler. For a list of known bugs which affect OpenECU, see Section 2.5.7.2,
“Known defects”.
Note
Various settings must be confirmed before the compiler is accessible to OpenECU.
See the MATLAB command oe_check_compiler for more details.

Software detail
6.1.24.4. Inports
None.
6.1.24.5. Outports
None.
• Mode
Whether to use the default compiler options, whether to add compiler options to the default
options, or whether to replace the default options altogether.
Value type: List

Calibratable: No
• Compiler options
The options to add to the default compiler options, or to replace the default options, as
selected by parameter Mode.
Value type: String

Calibratable: No
6.1.24.7. Notes
None.
6.1.25. Configure auto-coder (RTW EC)

(prtw_ConfigUsingRtwEc)
Configure Simulink to use the Embedded Coder auto-coder.

All targets

Double click to
configure model
using RTW-EC (ERT)

Software detail
A utility block to switch the current active configuration set of RTW options for the RTW
Embedded Coder auto-coder. See Section 4.3.2, “Auto-coders” for more.
6.1.25.4. Inports
None.
6.1.25.5. Outports
None.

6.1.25.7. Notes
None.
6.1.26. Configure auto-coder (RTW RTMODEL)

(prtw_ConfigUsingRtwRtmodel)
Configure Simulink to use the Simulink Coder RTMODEL auto-coder.

All targets

Double click to
configure model
using RTW (RTMODEL)
A utility block to switch the current active configuration set of RTW options for the RTW
RTMODEL auto-coder. See Section 4.3.2, “Auto-coders” for more.
6.1.26.4. Inports
None.
6.1.26.5. Outports
None.

6.1.26.7. Notes
None.
6.1.27. Configuration M5xx (pcfg_Config_M5xx)

Specific configuration for the M560 and M580 target ECU.

Software detail

All targets

M5xx configuration
pcfg_Config_M5xx
The pcfg_Config_M5xx block configures frequency and PWN-capable pins to set the
resolution of frequency and pwm-based inputs and outputs on these pins.
If the block is not present in a model, then the platform software configures the pins to the
default slow clock setting.
For MIOS-controlled digital I/O, a global eMIOS peripheral clock can be configured to a slow
clock of 400 KHz or a fast clock of 1.6 MHz. On each channel or channel group, this global
clock can be further divided by 1, 2, 3, or 4.
Each timer is a free running 16-bit counter. With a timer frequency of (Ft), the minimum signal
frequency (Fs) that can be captured is 1/((2^16)*(1/Ft))
The minimum timeout frequency for a channel is equal to its minimum signal frequency. If
a timeout below this frequency is requested, the timeout will be set to the minimum signal
frequency.
As the signal frequency increases, the resolution of the measured signal decreases. The
resolution is determined by (Ft/((Ft/Fs)-1))-Fs
Selectable Timebases at Global Frequency = 400 KHz
Channel Prescaler Resultant Timebase Minimum Resolution at

Measurable Signal 10 KHz Signal
Frequency Frequency
Global Frequency/4 100 KHz 2 Hz 1111 Hz
Global Frequency 400 KHz 7 Hz 256 Hz
Selectable Timebases at Global Frequency = 1.6 MHz
Channel Prescaler Resultant Timebase Minimum Resolution at

Measurable Signal 50 KHz Signal
Frequency Frequency
Global Frequency 1600 KHz 25 Hz 1612 Hz

Software detail
6.1.27.4. Inports
None.
6.1.27.5. Outports
None.
• Global Frequency
The global frequency for the eMIOS peripheral.
Value type: List

Calibratable: No
• Clock select: DOT (pin XH3)
The clock speed for H-bridge output pin XH3. Pin XH3 and XH2 must have the same
selection.
Value type: List

Software detail
Calibratable: No
The clock speed for H-bridge output pin XH2. Pin XH3 and XH2 must have the same
selection.
Value type: List

Calibratable: No
The clock speed for H-bridge output pin XH1. Pin XH1 and XG1 must have the same
selection.
Value type: List

Calibratable: No
• Clock select: DOT (pin XG1)
The clock speed for H-bridge output pin XH1. Pin XH1 and XG1 must have the same
selection.
Value type: List

Calibratable: No
• Clock select: DOT (pin ZB4)
The clock speed for PWM output pin ZB4.
Value type: List

Calibratable: No
• Clock select: DIN (pin XF1)
The clock speed for PWM input pin XF1.
Value type: List

Calibratable: No
• Clock select: DIN (pin XF4)
The clock speed for PWM input pin XF4.
Value type: List

Calibratable: No
• Clock select: DOT (pin YB2)
The clock speed for PWM output pin YB2.
Value type: List

Calibratable: No
• Clock select: DOT (pin YK3)
The clock speed for PWM output pin YK3.
Value type: List

Calibratable: No
• Clock select: Monitor (d) (pin XD4)

Software detail
The clock speed for the digital monitor of pin XD4. When used as a digital monitor, this
should be set to the same selection as Internal (PWM freq 0F).
Value type: List

Calibratable: No
• Clock select: Internal (PWM freq 0C)
The clock speed for H-Bridge output pins ZH1+ZH2 and ZH3+ZH4.
Value type: List

Calibratable: No
• Clock select: Internal (PWM freq 0F)
The clock speed for PWM output pins YE1, YE2, YE3, YD3, and XD4.
Value type: List

Calibratable: No
• Clock select: Internal (PWM freq 1A)
The clock speed for PWM output pins YD2, YC1, YC2, YC3, YB1, and XD1 and the digital
monitors associated with these pins.
Value type: List

Calibratable: No
• Clock select: DOT (pin ZG4)
The clock speed for PWM output pin ZG4 and PWM input pins ZB2 and ZB3. Pins ZB2
and ZB3 can only measure frequencies greater than the signal frequency of ZG4.
Value type: List

Calibratable: No
• Clock select: Internal (PWM freq 1F)
The clock speed for PWM output pin ZA4.
Value type: List

Calibratable: No
6.1.27.7. Notes
None.
6.1.28. Debounce (put_Debounce)

Output a new value of the debounced state only if the transient state has remained constant
for a number of cycles.

All targets


Software detail
transient_state debounced_state
put_Debounce
This block debounces the transient state over a number of cycles to produce a steady state
output. The debounced state output only changes to reflect the transient state input if the
input has remained steady for a number of cycles.
Unlike other blocks, the debounce is expressed in block iterations, rather than a time period.
This makes the block more appropriate for debouncing state based signals than time based
signals.
6.1.28.4. Inports
• transient_state
Transient state to debounce.
Value type: Boolean

Calibratable: No
6.1.28.5. Outports
• debounced_state
The debounced state. On the first iteration, the internal debounced state is set to the input
transient_state.
Value type: Boolean

Calibratable: No
• Debounce wait cycles
The number of block iterations (cycles) for which the input has to be steady before the
output follows it.
Range: [0, 65535] cycles
Value type: Integer

6.1.28.7. Notes
None.

Software detail
6.1.29. DTC clear all (pdtc_ClearAll)

Set all DTCs referred to by the table identifier parameter, to the clear state, if the clear state
is supported by the DTC.

All targets

Table:
clear
pdtc_ClearAll
For the DTCs with matching type to the parameter DTC type in the DTC table specified
by parameter DTC table identifier, this block sets the DTC state to clear. See the
pdtc_DiagnosticTroubleCode and pdtc_DiagnosticTroubleCodeExt blocks for details about
the states each type of DTC can have.
Freeze frame data associated with the cleared DTCs is also cleared. Monitor (DME and
DTE) data is also cleared other than persistent data which is never cleared (e.g. numerators
and denominators). As the platform does not know which DME/DTE objects are associated
with which DTCs in an application, it is assumed that the table being cleared applies to all
emissions-relevant monitors.
This is suitable for running in response to a J1939 DM11 request in OBD systems.
6.1.29.4. Inports
• clear
Set to 1 to force the state of each DTC, with matching type to that specified by parameter
DTC type, to clear. Otherwise, set to 0 for no change in DTC states.
Value type: Boolean

Calibratable: No
6.1.29.5. Outports
None.

Software detail
• DTC table identifier
The name of the DTC table to act on (there must be a corresponding named table specified
in a pdtc_Table block in the model).
Value type: String

Calibratable: No
• DTC type
A drop-down selection of the type of DTC to act on in the DTC table specified by parameter
DTC table identifier.
Value type: List

Calibratable: No
6.1.29.7. Notes
None.
6.1.30. DTC clear all if active (pdtc_ClearAllIfActive)

is supported by the DTC, and if the DTC state is currently active.

All targets

Table:
clear
pdtc_ClearAllIfActive
For the DTCs with matching type to the parameter DTC type in the DTC table specified by
parameter DTC table identifier, this block sets the DTC state to clear, if the DTC state is
currently active. See the pdtc_DiagnosticTroubleCode and pdtc_DiagnosticTroubleCodeExt
blocks for details about the states each type of DTC can have.
Freeze frame data associated with the DTCs cleared is also erased, but not monitor data.
For OBD systems, see also pdtc_ClearAll.
6.1.30.4. Inports
• clear
DTC type, to clear if it is currently active. Otherwise, set to 0 for no change in DTC states.
Value type: Boolean

Calibratable: No
6.1.30.5. Outports
None.

Software detail
Value type: String

Calibratable: No
• DTC type
Value type: List

Calibratable: No
6.1.30.7. Notes
None.
6.1.31. DTC clear all if inactive (pdtc_ClearAllIfInactive)

is supported by the DTC, and if the DTC state is currently inactive.

All targets

Table:
clear
pdtc_ClearAllIfInactive
For the DTCs with matching type to the parameter DTC type in the DTC table
specified by parameter DTC table identifier, this block sets the DTC state to clear,
if the DTC state is currently inactive. See the pdtc_DiagnosticTroubleCode and
pdtc_DiagnosticTroubleCodeExt blocks for details about the states each type of DTC can
have.

Software detail
Freeze frame data associated with the DTCs cleared is also erased, but not monitor data.
This is intended to be used in response to a J1939 DM3 request, which but the standard
warns that that service is not intended for clearing diagnostic data in regulated OBD products.
See also pdtc_ClearAll.
6.1.31.4. Inports
• clear
DTC type, to clear if it is currently inactive. Otherwise, set to 0 for no change in DTC states.
Value type: Boolean

Calibratable: No
6.1.31.5. Outports
None.
Value type: String

Calibratable: No
• DTC type
Value type: List

Calibratable: No
6.1.31.7. Notes
None.
6.1.32. DTC diagnostic trouble code

(pdtc_DiagnosticTroubleCode)
Set the state and auxiliary data about a diagnostic trouble code.

Software detail

All targets

active
active
lamp_malfunction
SPN:
lamp_red FMI: state
CM:
lamp_amber
count
lamp_protect
pdtc_DiagnosticTroubleCode
A diagnostic trouble code (DTC) is a unique indicator used to remember the state of a fault.
The model determines if the conditions for signalling the fault are satisfied or not, and passes
this information to the pdtc_DiagnosticTroubleCode block. Whether the fault is active or not,
is maintained by the block while the model is running and across power cycles (see the
pdtc_Memory block for more details).
There is only one type of DTC at the moment, more may be added in the future.
J1939 DTC
The J1939 DTC maintains a fault state and a count of the how many times the DTC has
become active. The J1939 DTC states follow this state diagram:
Figure 6.1. J1939 DTC states
if inport ‘active’ = 0 if inport ‘active’ = 1
if inport ‘active’ = 1
clear active
1 2
inactive
The DTC starts in the clear state (or whichever state was recalled from non-volatile
memory during power up, see the pdtc_Memory block for more details), and remains in
this state until the inport active becomes 1. The block then changes the DTC state to
active and remains in this state until the inport active becomes zero. And so on.

Software detail
Outwith this diagram pictured above, the DTC state can be forcefully set to
clear through the use of the pdtc_ClearAll block, or pdtc_ClearAllIfActive block, or
pdtc_ClearAllIfInactive block.
If the DTC cannot be recalled from non-volatile memory (which includes the first time the
ECU is powered up), then the J1939 DTC is initialised as follows:
DTC information Initial value

State Clear
Count 0
Lamp malfunction 3
Lamp red 3
Lamp amber 3
Lamp protect 3
6.1.32.4. Inports
• active
Set to 1 if the dtc is active, set to zero otherwise. Available only if the parameter DTC type
is J1939 DTC.
Range: 0 or 1
Value type: Boolean
• lamp_malfunction
Set to desired lamp state (0 is Slow Flash, 1 is Fast Flash, 2 is On, 3 is Off). Available only
if the parameter DTC type is J1939 DTC.
Range: [0, 3]
Value type: Integer
• lamp_red
Range: [0, 3]
Value type: Boolean
• lamp_amber
Range: [0, 3]
Value type: Boolean
• lamp_protect
Range: [0, 3]

Software detail
Value type: Boolean
6.1.32.5. Outports
• active.
Set to 1 if the dtc is in the active state, set to zero otherwise. Available only if the parameter
DTC type is J1939 DTC.
Value type: Boolean
• state
Set to the value of the current DTC state (see the DTC types descriptions for a list of states
and values). Available only if the parameter DTC type is J1939 DTC.
Value type: List
• count
A count of the number of times a DTC has changed to the active state. Available only if
the parameter DTC type is J1939 DTC.
Range: [0, 127]
Value type: Integer
The name of the DTC table to store this DTC in (there must be a corresponding named
table specified in a pdtc_Table block in the model).
Value type: String

Calibratable: No
• DTC type
A drop-down selection of the type of the DTC.

Software detail
Value type: List

Calibratable: No
• Suspect parameter number
The value of the SPN for this DTC. The parameters Suspect parameter number, Failure
mode indicator and Conversion method uniquely identify the DTC. Available only if the
parameter DTC type is J1939 DTC.
Range: [0, 524287]
Value type: Integer

Calibratable: No
• Failure mode indicator
The value of the FMI for this DTC. The parameters Suspect parameter number, Failure
Range: [0, 31]
Value type: Integer

Calibratable: No
• Conversion method
The value of the CM for this DTC. The parameters Suspect parameter number, Failure
Range: 0 or 1
Value type: Integer

Calibratable: No
6.1.32.7. Notes
None.
6.1.33. DTC enable periodic lamp updates

(pdtc_EnablePeriodicLampUpdates)
Allows an application to enable or disable periodic processing of the pdtc lamp status.

All targets

enable
pdtc_EnablePeriodicLampUpdates

Software detail
By default, the platform software will periodically determine the appropriate lamp status by
examining the state of all DTCs in all tables. For applications with a large number of DTCs,
this processing can take a significant amount of time.
This block allows an application to programmatically disable and enable this processing.
6.1.33.4. Inports
• enable
Set to 0 to disable periodic lamp updates, 1 to re-enable them. Note: Changing the value
to 0 while the lamps are currently being processed will not interrupt that processing, but
take effect at the next iteration of the DTC processing task.
Range: 0 or 1
Value type: Boolean

Calibratable: No
6.1.33.5. Outports
None.

6.1.33.7. Notes
If an application does not need to disable periodic lamp updates, this block is not required.
If this block is not present in a model, periodic lamp updates will always be performed.
6.1.34. DTC memory update (pdtc_Memory)

Retain the DTC tables in non-volatile storage across power cycles.

All targets

sim_store_up_to_date
store_up_to_date
commit_dtcs
pdtc_Memory
The pdtc_Memory block stores the DTC table data in non-volatile memory. On start-up, the
block attempts to retrieve the DTC table data prior to running the model. While the model is
running, the time at which the DTC table is stored back to non-volatile memory is determined
by the model itself.
The DTC table data is check-summed using a 16-bit CRC. Failure to match the check-sum
against the table data on start-up means that the data cannot be recovered. In this case,
DTC table data is reverted to the default start-up conditions for each type of DTC (see the
pdtc_DiagnosticTroubleCode and pdtc_DiagnosticTroubleCodeExt blocks for specifics).
The target non-volatile memory is provided in two ways: either through storage that requires
an external power source when the ECU is powered down (battery backed RAM storage),

Software detail
or not (Flash storage). See the technical specification for details on which storage type is
supported by each target.
This block is used to update the check-sum and write the DTC table data to non-volatile
store. When the inport commit_dtcs is set to 1, the block pauses execution of the model,
calculates the DTC table data check-sum, stores the DTC table data in non-volatile memory,
then continues execution of the model.
Note
When the block pauses the model execution, the length of pause depends on the store
location. Storage in battery backed RAM will result in a short pause, storage to Flash
will result in a longer pause.
Old DTC data is reused so long as it has the expected total data size and was written
by an application with the same user-specified version number. Otherwise the values
revert to defaults. If the usage of DTC blocks has changed in a new software version,
increase the application sub-minor version number to ensure that any old values are
not used, as they may not map appropriately to the blocks in the new model even if
the total data size happens to match.
It is important to trigger the commit and not update any diagnostic trouble code thereafter
before shutting down the ECU. If diagnostic trouble code data is modified after the check-
sum has been updated, and the ECU shuts down, next time it powers up, diagnostic trouble
code data will revert to default.
To ensure the check-sum is up to date before shutting down the ECU, the store_up_to_date
outport provides an indication of whether the check-sum is correct or not. If not, shutdown
of the module can be prevented (if conditions are appropriate) and the store updated (by
setting the commit_dtcs inport to 1).
6.1.34.4. Inports
• sim_store_up_to_date
Simulation value for the outport store_up_to_date.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• commit_dtcs
Set to 1 to update the check-sum for the DTC tables and to write the result to non-volatile
memory. Set to zero otherwise.
Range: 0 or 1
Value type: Boolean

Calibratable: No
6.1.34.5. Outports
• store_up_to_date
Set to 1 if the check-sum and DTC table data match, set to zero otherwise.
Range: 0 or 1

Software detail
Value type: Boolean

Calibratable: No
• Storage location
A drop-down of memory storage locations for the DTC table data.
Value type: List

Calibratable: No
6.1.34.7. Notes
None.
6.1.35. DTC table definition (pdtc_Table)

Declares a table of diagnostic trouble codes (DTCs), that can be referred to by other blocks
that wish to refer to a group of DTCs.

All targets

Table:
Description:
pdtc_Table
The pdtc_Table groups together DTCs into one table. The table can then be worked on by
other blocks (for instance, the pdtc_ClearAll block or the pj1939_Dm1Transmit block) and
stored in non-volatile memory (see the pdtc_Memory block).
6.1.35.4. Inports
None.
6.1.35.5. Outports
None.

Software detail
The name of the DTC table (there must not be another pdtc_Table block with the same
identifier in the model).
Value type: String

Calibratable: No
• DTC table description
A textual description of the DTC table used for documentation purposes only.
Value type: String

Calibratable: No
6.1.35.7. Notes
None.
6.1.36. Digital input (pdx_DigitalInput)

Output the state of a digital input pin after debounce logic.

M560-000 and M560-000

Channel: DIN (pin XD1)
Inversion: off
sim_state Set dead time: debounced_state
Reset dead time:
Sample time: 0
pdx_DigitalInput
The digital input block reads a raw input digital value of 0 if the pin identified by the mask
parameter Channel is at a logic low state or 1 if the pin is at a logic high state. The block is
also capable of inverting and debouncing a signal.
If the mask parameter inversion is set to 1 then a logical NOT operation is applied to the input
value before further processing. Otherwise it is passed through unchanged.

Software detail
Debouncing can be achieved by setting mask parameters Set dead time and Reset dead
time. On the first iteration of the block, the debounced_state outport is set to the value of the
digital input (or the sim_state inport under simulation).
6.1.36.4. Inports
• sim_state
Only used in simulation. when the model is simulated, the outport debounced_state is set
to the value of this inport.
Range: 0 or 1
Value type: Boolean

Calibratable: No
6.1.36.5. Outports
• debounced_state
1 if the raw input digital value has been high for at least Set dead time, 0 if the raw input
digital value has been low for at least Reset dead time.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• Channel
The channel pin for this digital input.
Value type: List

Calibratable: No
• Inversion
If inversion is ticked then a logical NOT operation is applied to the input value before further
processing.

Software detail
Value type: Boolean

Calibratable: No
• Set dead time
The time the input will have to be high, before the block switches its output from 0 to 1. A
value of zero is acceptable. A negative value has the same effect as a zero value.
Value type: Real

• Reset dead time
The reset dead time is the time the input will have to be low, before the block switches its
output from 1 to 0. A value of zero is acceptable. A negative value has the same effect
as a zero value.
Value type: Real

• Sample time
Value type: Real

Calibratable: No
Tick to enable inport sim_state.
Value type: Boolean

Calibratable: No
6.1.36.7. Notes
Selecting IMU channels on an M250 for which the IMU is not populated will have no effect.
6.1.37. Digital output (pdx_DigitalOutput)

Set the output channel pin high or low.

M560-000 and M560-000

state
Channel: DOT (pin XD4)
Inversion: off sim_state
Default value:
fault
pdx_DigitalOutput
The digital output block causes the channel pin to be taken high or low depending on the
state inport at every model iteration.

Software detail
The channel logical state can be inverted with respect to the input in order to achieve the
desired logical output state by setting the mask parameter Inversion.
The block also has a mechanism to set the output to a default value in two situations: at
start-up; or if the fault indicator is active. The default output value is mapped directly to the
channel pin logical state and is never inverted.
6.1.37.4. Inports
• state
Place a 1 here to set the output channel pin high, place a 0 here to set the output channel
pin low.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• fault
Place a 1 here to force the block to use the default value for the channel pin state, otherwise
place a 0 here to force the block to use the inport state as the channel pin state.
Range: 0 or 1
Value type: Boolean

Calibratable: No
6.1.37.5. Outports
• sim_state
Only used in simulation. this outport is set to the requested channel pin state (i.e., state
or the default state).
Range: 0 or 1
Value type: Boolean

Calibratable: No
• Channel
The channel pin for this digital output.

Software detail
Value type: List

Calibratable: No
• Inversion
Inverts the mapping of the input value to the channel pin. If inversion is set to 1 then a
logical NOT operation is applied to the input value before further processing.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• Default state
This sets the output to the default state in two situations: at start-up time, before this block
has been executed in the first model iteration; and if a fault indicator is associated with
the output and the fault is active. The value is mapped directly to the channel pin logical
state and is never inverted.
Range: 0 or 1
Value type: Boolean

• Provide simulation output?
Tick to enable outport sim_state.
Value type: Boolean

Calibratable: No
6.1.37.7. Notes
Selecting IMU channels on an M250 for which the IMU is not populated will have no effect.
6.1.38. Digital output monitor (pdx_Monitor)

Monitor the response of a digital output.

None at the moment

sim_valid valid
Channel: Monitor (d) (pin Y37)

sim_rise_failure_count Rise time-out: us rise_failure_count
Sample time: sec
sim_fall_failure_count fall_failure_count
pdx_Monitor
This block allows an application to determine whether or not the state of a digital output has
changed as requested within the expected response time. It works by recording the time
at which the output function requests a change of state, and then reading the actual state

Software detail
observed on the feedback input at a specific time later. If the actual state does not match the
expected state, then a failure is noted. Independent counts of failures to fall and failures to
rise are maintained and made available to the application via the outputs from this block.
The block is only available for certain low-side outputs and there are important differences
between the falling edge and rising edge cases.
Falling edge: When a low-side output is activated, it is connected to ground within the ECU,
and the potential on the pin should drop rapidly to ground potential. Under normal conditions,
the time for the potential to fall is largely independent of the load on the pin. Failure of the
potential to drop within the expected time indicates a low resistance path to a higher potential
on the pin. This will result in a large current draw, causing the output device to get hot and
turn off. If the platform software detects that the monitor feedback has not gone low within
the expected time, it deactivates the output. The time threshold for the output to go low is
hard-coded within the platform software. (See the technical specification of the target ECU
for details.)
Rising edge: When a low-side output is de-activated, it is disconnected within the ECU, and
the potential on the pin should move in the direction of the high-side potential. How fast it
does so will depend on the resistance between the pin and the high-side potential, i.e. the
resistance of the load. Therefore the time threshold must be specified by the application via
the Rise time-out mask parameter of this block. If the potential fails to rise within the expected
time, this may indicate an open circuit on the pin, or a short-circuit to ground. Advice on what
thresholds to set for different loads is given in the technical specification of the target ECU.
The platform software takes no independent action in the case of such a fault being detected
beyond reporting the fault count to the application.
Support for this block is restricted to certain types of output. Currently only PWM
outputs (using the pdx_PWMOutput or pdx_PWMVariableFrequencyOutput blocks) support
monitoring (and only on those channels that have the necessary internal feedback signals).
If the block is used with some other function on the corresponding output channel, then the
valid outport will return 0 (FALSE).
Note that output monitoring will occur on those channels that support it, where possible,
regardless of whether or not the application includes a pdx_Monitor block. This means
that outputs will be disabled if the corresponding monitor channels fail to go low within the
expected time. The only case where such intervention will not take place is if the output
function used does not support monitoring.
6.1.38.4. Inports
• sim_valid
Only used under simulation. Under simulation, the value of this inport is passed through
to the valid outport.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• sim_rise_failure_count
to the rise_failure_count outport.
Range: [0, 16777215]
Value type: Integer

Calibratable: No

Software detail
• sim_fall_failure_count
to the fall_failure_count outport.
Range: [0, 16777215]
Value type: Integer

Calibratable: No
6.1.38.5. Outports
• valid
Set to 0 when there is a configuration error, most probably due to an output function being
used on this channel that does not support monitoring.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• rise_failure_count
A count of the number of times that the output state did not go high within the time specified
by the Rise time-out mask parameter, since the ECU was powered on or reset.
Range: [0, 16777215]
Value type: Integer

Calibratable: No
• fall_failure_count
A count of the number of times that the output state did not go low within the allowed time,
since the ECU was powered on or reset.
Range: [0, 16777215]
Value type: Integer

Calibratable: No
• Channel

Software detail
The channel pin to monitor.
Value type: List

Calibratable: No
• Rise time-out
The time within which the potential on the output pin is expected to go high after the output
is deactivated.
Range: [0, 2000000] microseconds
Value type: Real

• Sample time
Value type: Real

Calibratable: No
Tick to enable simulation inports sim_valid, sim_rise_failure_count and

sim_fall_failure_count.
Value type: Boolean

Calibratable: No
6.1.38.7. Notes
None.
6.1.39. Digital data input (pdd_DataInput)

Read the value of a digital data input.

All targets

Channel: TCP Status (internal)
sim_value value
Sample time: []
pdd_DataInput
The digital data input block is a generic interface for reading a input channel that specifies
numerical integer data. The units and interpretation of the value depends on the Channel
being read.
6.1.39.4. Inports
• sim_value

Software detail
outport value is written using the value of this inport.
Range: [-2147483648, 2147483647].
Value type: Integer
6.1.39.5. Outports
• value
The value of the digital data read from the specified channel.
Range: [-2147483648, 2147483647].
Value type: Integer
• Channel
The channel for this input.
Value type: List

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
Tick to enable inport sim_value.
Value type: Boolean

Calibratable: No
6.1.39.7. Notes
None.

Software detail
6.1.40. Digital data output (pdd_DataOutput)

Write a value to a digital data output.

All targets

Channel: RTC CTD timer data (internal / serial)
input_data
Default value: 0
pdd_DataOutput
The digital data output block is a generic interface for writing to a output channel that specifies
numerical integer data. The units and interpretation of the value depends on the Channel
being written to.
6.1.40.4. Inports
• value
The value of the digital data to write to the specified channel.
Range: [-2147483648, 2147483647].
Value type: Integer
6.1.40.5. Outports
None.
• Channel
The channel for this output.
Value type: List

Calibratable: No
6.1.40.7. Notes
None.

Software detail
6.1.41. Fault check (put_FaultCheck)

Debounce a transient fault signal into a confirmed fault signal using a leaky bucket algorithm.

All targets

transient_fault confirmed_fault
put_FaultCheck
Debouncing of a transient fault signal is achieved using a leaky bucket algorithm. A leaky
bucket integrator is used to decide when an input is confirmed as faulty as a function of its
current state, which may be only transiently in error.
The bucket always has a total volume or depth of unity (1.0). When the input is deemed to
be in error (e.g. out of range), water is poured into the bucket at some rise rate. At all times
water flows out of a leak in the bottom of the bucket with some fall rate until it is empty. If
the bucket should ever fill to the brim by reaching a depth greater than or equal to 1.0, the
input is confirmed as faulty. Should the bucket subsequently empty to below its hysteresis
depth, it is no longer confirmed as faulty.
6.1.41.4. Inports
• transient_fault
Transient fault signal to check.
Range: 0 or 1 (no fault, fault)
6.1.41.5. Outports
• confirmed_fault
Result of processing transient_fault through a leaky bucket algorithm over a number of

block iterations.
Range: 0 or 1 (no fault, fault)

Software detail
• Leaky bucket rise rate
Rate at which leaky bucket is filled when input is faulty in some respect.
Range: [0, 1000] /sec
• Leaky bucket fall rate
Rate at which leaky bucket is emptied if it is not already empty.
Range: [0, 1000] /sec
• Leaky bucket hysteresis level
Level below which bucket depth must fall before fault is no longer considered faulty. If set
to a negative value, fault remains latched. As a special case, if the hysteresis depth is set
negative, should the input ever reach a confirmed fault state it remains "latched" there until
the ECU device is powered down.
Range: [-inf, inf] unitless
• Sample time
Value type: Real

Calibratable: No
6.1.41.7. Notes
None.
6.1.42. Frequency input (pdx_FrequencyInput)

Output the last measured frequency.

Software detail

All targets

sim_timed_out timed_out
Channel: DIN (pin XF1)
Time out: Hz
Sample time:
sim_frequency frequency
pdx_FrequencyInput
The frequency measurement block, measures the duration of each pulse in a pulse train from
an input signal and determines the frequency of that pulse. The last measured frequency is
provided as an outport.
If a frequency has not been measured (because a complete signal pulse has not yet
occurred), then the corresponding frequency outport is clamped to zero.
If the input signal does not complete a pulse for longer than the block's timeout value, then the
timed_out outport of the block is set. When a timeout occurs, the frequency outport remains
at its last known value.
6.1.42.4. Inports
• sim_timed_out
Only used in simulation. Place 1 here to simulate a time out, 0 otherwise.
Range: 0 or 1
Value type: Boolean
• sim_frequency
Only used in simulation. Place the frequency in hertz here to simulate the last measured
frequency. A measurement of zero hertz indicates that no measurement is available.
Value type: Real
6.1.42.5. Outports
• timed_out
1 if the input signal has not completed a pulse within the mask parameter timeout period
at the point of sampling (see the mask parameter section below), 0 otherwise.
Range: 0 or 1
Value type: Boolean
• frequency
The last measured frequency in hertz, or 0 if no measurement has been taken (regardless
of the state of outport timed_out). The range of the frequency is limited in various ways.
• The range of the frequency that can be measured is limited by the filter circuitry of the
input pin.

Software detail
• The lowest measurable frequency is limited by the filter circuitry and the size of the
corresponding processor timer for a channel. Any input frequency below the documented
limit, is reported as timed-out.
• The highest measurable frequency is limited by the filter circuitry and the resolution
of the corresponding processor timer for a channel. In general, the block reports the
frequency of the filtered signal and the input filtering forms an upper limit. However, as
the frequency increases, the resolution of measurement decreases.
Details of the input pin's filtering and processor timing can be found in an ECU's technical
specification.
Range: [0.5, ...] Hz (for all targets)
Value type: Real
• Channel
The input pin sourcing the signal to measure.
Value type: List

Calibratable: No
• Time out
The period of time in hertz after which if no complete pulse has been measured, the outport
timed_out is set to 1.
Range: [0.5, 10000] Hz (for all targets)
Value type: Real

• Sample time
Value type: Real

Calibratable: No

Software detail
If selected then create simulation inports for each of the outport message signals.
Value type: Boolean

Calibratable: No
6.1.42.7. Notes
None.
6.1.43. H-Bridge output (pdx_HBridgeOutput)

Drives the H-Bridge channel pins according to a mode at a variable frequency and duty-cycle.

All targets

mode
Channels : DOT (pin A17+A46)

Initial mode: No drive
frequency
Initial frequency:
Initial duty cycle:
duty_cycle
pdx_HbridgeOutput
The H-Bridge output block drives a load connected between the two ECU pins in the desired
mode. Four modes are provided allowing the H-Bridge output to have no drive (all switches
open), brake (high-side switches closed), forward or reverse (one side is connected to high-
side while the other is PWM'ed to ground at a programmable frequency and duty-cycle).
Warning
To avoid unexpected behavior, H-bridges should be set to NO DRIVE mode before
flashing the ECU. This can be done by commanding the actuators to NO DRIVE any
time the engine is not turning.
The duty-cycle used in forward and reverse mode is defined as the proportion of time where
the load is driven (low-side switch is grounded).
The block supports 0% and 100% duty cycles.
Note
Some of the PWM output channels do not produce an accurate waveform when the
duty cycle is either very small (e.g., 0.5%) or very large (e.g., 99.5%). All H-bridge
output channels cope with 0% and 100% duty cycles correctly.
For the M250 target specifically, in order to avoid shoot-through and damage to the
ECU when the mode switches, a 100us dead-time is inserted in the PWM signal for
one task cycle at the beginning of mode-transition. Additionally, this dead-time insertion

Software detail
will only occur if the duty cycle that is commanded has a low time of less than 100us.
For this reason, it will not be possible to command a 100% duty cycle during mode-
transition for one task period. See diagram below for further detail.
Figure 6.2. Output of H-Bridge during mode transition

Application task
requests mode change Application task requests
from No-drive to Forwards same mode, Forwards
100us
A30
A1
A30 is requested to have a high duty cycle, After one task iteration is complete and
but it is extended to 100 microsecond off the mode is unchanged, the duty cycle is
time (dead time) for one task duration. restored (dead-time removed).
Correspondingly, A1 would have 100% duty cycle, but is forced

to 100 microseconds dead time for the same task Iteration.
6.1.43.4. Inports
• mode
Mode in which the H-bridge will operate.
Range: [0, 3] respectively for No Drive / Brake / Forward / Reverse.
Value type: Integer
• frequency
Frequency of the PWM signal
Range: [0.5, 10000] Hz (for M220, M250, M560, M580 and M670 targets)
Value type: Real
• duty-cycle
Ratio of the drive time to the signal cycle time.
Range: [0, 1] duty-cycle
Value type: Real

Calibratable: No
6.1.43.5. Outports
None.

Software detail
• Channels
The pair of input pins sourcing the signal to measure.
Value type: List

Calibratable: No
• Initial mode
The initial mode of operation used whilst the application is initialising.
Range: [No Drive, Brake, Forward, Reverse] (for M220, M250, M560, M580 and M670
targets)
Value type: List

Calibratable: No
• Initial frequency
The initial frequency used whilst the application is initialising.
Range: [0.5, 10000] Hz (for M220, M250, M560, M580 and M670 targets)
Value type: Real

Calibratable: Yes, offline
• Initial duty cycle
The initial duty cycle used whilst the appplication is initialising.
Value type: Real

6.1.43.7. Notes
None.

Software detail
6.1.44. J1939 configuration (pj1939_Configuration)

Configure the ECU for J1939 communications.

All targets

The J1939 messaging protocol is a CAN based messaging system designed to pass
information between vehicle network ECUs in real-time. For more details, refer to SAE J1939
(and sub-parts 21, 71, 73, 81) at the SAE Web site (http://www.sae.org).
The blockset supports a subset of the J1939 specification:
• Handles requests for PGs by filtering out PGNs the model does not handle and returning
NACK messages.
• Handles reception and transmission of J1939 messages, in a similar way to the existing
pcx_CANReceiveMessage and pcx_CANTransmitMessage blocks.
• Handles the transport protocol (J1939/21) for sending long messages (up to 1785 bytes
in length).
• Handles some of the diagnostic requirements (J1939/73) for sending and receiving lists of
diagnostic trouble codes (DM1 and DM2 messages). This includes support in the blockset
for diagnostic trouble codes (see Section 4.6.6, “Fault support”).
• Handles the network protocol (J1939/81) as if the ECU and the rest of the network have
fixed network nodes.
Note
This may be extended in the future to include dynamic network addressing.
The pj1939_Configuration block configures the ECU's behaviour when handling J1939
messages. This block configures parameters that adjust the amount of memory set aside for
processing J1939 messages.
The pj1939_Configuration block is used in conjunction with one or more

pj1939_ChannelConfiguration block to configure the actual hardware interfaces and node
addresses.
A pj1939_Configuration must be present in the model to enable J1939 support.
6.1.44.4. Inports
None.
6.1.44.5. Outports
None.

Software detail
• Size of J1939 message buffers
The number of bytes for each J1939 message buffer. In some networks, the maximum
length of any received or transmitted J1939 message will be smaller than the maximum
J1939 length of 1785 bytes. This parameter allows the modeller to reduce the amount of
RAM allocated to J1939 messages, and therefore increase the RAM allocated to other
functions of the ECU.
Range: [8, 1785]
Value type: Integer

Calibratable: No
• Number of simultaneous transport receive messages
The number of long (transport) messages than can be received simultaneously. The
smaller the number, the more RAM is allocated to other functions of the ECU.
These receive buffers are shared among all J1939 channels.
Range: [1, 20]
Note
The larger the number, the more transport messages can be received at the same
time. However, the larger the number, the more likely it is that it will not be possible
for the ECU to adhere to the J1939 transport timeouts and some message receives
may fail.
Value type: Integer

Calibratable: No
• Number of simultaneous transport transmit messages
The number of long (transport) messages than can be transmitted simultaneously. The
smaller the number, the more RAM is allocated to other functions of the ECU.
These transmit buffers are shared among all J1939 channels.
Range: [1, 20]
Note
The larger the number, the more transport messages can be transmitted at the same
time. However, the larger the number, the more likely it is that it will not be possible

Software detail
for the ECU to adhere to the J1939 transport timeouts and some message transmits
may fail.
Value type: Integer

Calibratable: No
• Number of receive/transmit buffers
The number of receive and transmit buffers per channel used to store J1939 CAN data
between processing of J1939 messages (which occurs every 5 milliseconds).
Note that this is a count for each defined J1939 channel.
Range: [1, 100]
Value type: Integer

Calibratable: No
• DM7 Request buffer size
The maximum number of DM7 test entries that may be stored in the buffer, upon receipt
of DM7 request messages.
This buffer is shared across all J1939 channels.
Range: [1, 10]
Value type: Integer

Calibratable: No
• Use common multi-frame priority
A checkbox to enable the use of a common multi-frame priority. This priority overrides
the priorities for all DM transmit blocks for multi-frame message responses. (Single frame
responses are unaffected.) It does not affect any priorities passed to instances of the
pj1939_PgTransmit block.
This setting applies to all J1939 channels.
Value type: Boolean

Calibratable: No
• Common multi-frame priority
The value of the common multi-frame priority. Only available when the mask parameter
checkbox Use common multi-frame priority is ticked.
This setting applies to all J1939 channels.
Range: [0, 7]
Value type: Integer

Calibratable: No
6.1.44.7. Notes
6.1.45. J1939 channel configuration

(pj1939_ChannelConfiguration)
Configure a J1939 communications channel.

Software detail

All targets

OpenECU can support J1939 on any or all of the available CAN interfaces on an ECU. The
pj1939_ChannelConfiguration block creates a J1939 channel to associate J1939 operations
with a particular CAN interface. Each Individual J1939 operation specifies the J1939 channel
with which the operation is associated.
The J1939_ChannelConfiguration block assigns a logical channel number to a particular

CAN bus and configures the J1939 node name associaetd with that channel. Only one
channel may be associated with a particular CAN interface.
See the pj1939_Configuration block for information about shared configuration items.
A model must have at least one pj1939_ChannelConfiguration block to utilize J1939.
6.1.45.4. Inports
None.
6.1.45.5. Outports
None.
• Channel ID
The application-defined channel identifier.
Value type: Integer

Calibratable: No
A drop-down selection of CAN buses available for J1939 messaging.
Value type: List

Software detail
Calibratable: No
• Source node address
The J1939 network node address for this ECU.
The automatically generated calibration parameter for this is pj1939c_node_addr_0.
Range: [0, 253]
Value type: Integer

• Source node name
The name of the source ECU, given as a vector of 8 elements. The node name excludes
the self-configuration field (see parameter Source self-configuring).
Element 1: Industry group (Range: [0, 7]).
Element 2: Vehicle system instance (Range: [0, 15]).
Element 3: Vehicle system (Range: [0, 127]).
Element 4: Function (Range: [0, 255]).
Element 5: Function instance (Range: [0, 31]).
Element 6: ECU instance (Range: [0, 7]).
Element 7: Manufacturer code (Range: [0, 2047]).
Element 8: Identify number (Range: [0, 2097151]).
Value type: Integer

Calibratable: No
• Source self-configuring?
Set if this ECU can self-configure its network address, clear if this ECU will remain at a
fixed address.
NOTE: self-configuring addresses are not currently supported.
Value type: Boolean

Calibratable: No
6.1.45.7. Notes
6.1.46. J1939 DM1 receive (pj1939_Dm1Receive)

Indicates if a J1939/73 DM1 message has been received and decodes the contents of the
lamp status.

All targets


Software detail
sim_rx_trig_flag rx_trig_flag
Channel: 0
sim_lamp_malfunction
Source address: [] lamp_malfunction
Sample time: -1
sim_lamp_red lamp_red
sim_lamp_amber lamp_amber
sim_lamp_protect lamp_protect
pj1939_Dm1Receive
A J1939/73 DM1 message is a variable length message, transmitted by a network node to

the global network address. The DM1 message contents detail any active diagnostic trouble
codes and lamp status. As the message is variable in length, direct blockset support is
provided (rather than relying on the pj1939_PgReceive block).
The application model may request the DM1 message or rely on the other J1939 node to
transmit the DM1 message periodically. This block does not make a request for the DM1
message.
6.1.46.4. Inports
The simulation value for the outport rx_trig_flag.
Value type: Boolean

Calibratable: No
• sim_error_flag
The simulation value for the outport error_flag.
Value type: Boolean

Calibratable: No
The simulation value for the outport overrun_flag.
Value type: Boolean

Calibratable: No
• sim_lamp_malfunction
The simulation value for the outport lamp_malfunction.
Value type: Integer

Calibratable: No
• sim_lamp_red
The simulation value for the outport lamp_red.
Value type: Integer

Calibratable: No
• sim_lamp_amber
The simulation value for the outport lamp_amber.
Value type: Integer

Calibratable: No

Software detail
• sim_lamp_protect
The simulation value for the outport lamp_protect.
Value type: Integer

Calibratable: No
• sim_timestamp
The simulation value for the outport timestamp. Available only if the mask parameter
Provide timestamp is selected.
Value type: Integer
6.1.46.5. Outports
• error_flag
Set to 1 if an error in receive processing relevant to this message has occurred.
Value type: Boolean

Calibratable: No
• rx_trig_flag
Set to 1 if a DM1 message matching the source address has been received since the last
time the block was evaluated, 0 otherwise.
Value type: Boolean

Calibratable: No
• overrun_flag
Set to 1 if more than one DM1 messages matching the source address have been received
since the last time the block was evaluated, 0 otherwise.
Value type: Boolean

Calibratable: No
The state value of the malfunction lamp.
Range: [0, 3] (0 is Slow Flash, 1 is Fast Flash, 2 is On, 3 is Off)
Value type: Integer

Calibratable: No
• lamp_red
The state value of the red lamp.
Value type: Integer

Calibratable: No
• lamp_amber
The state value of the amber lamp.

Software detail
Value type: Integer

Calibratable: No
• lamp_protect
The state value of the protect lamp.
Value type: Integer

Calibratable: No
• timestamp
The time when the last valid message was received. Strictly this gives the time when
the message was assembled from the possibly multiple CAN packets, and has a
resolution of 50 ms. The timestamp is a free-running microsecond timer that wraps to zero
approximately every 70 minutes. Available only if the mask parameter Provide timestamp
is selected.
Range: [0, 4294967295] us
Value type: Integer
• J1939 Channel
The logical J1939 channel on which the message will arrive. Must be a channel declared
with a pj1939_ChannelConfiguration block.
Value type: Integer

Calibratable: No
• Source address
The source J1939 network address of the message to be received.
Range: 0 or 253
Value type: Integer

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
• Provide timestamp

Software detail
Value type: Boolean

Calibratable: No
6.1.46.7. Notes
None.
6.1.47. J1939 DM1 decode DTC

(pj1939_Dm1DecodeDtc)
Decodes the contents of the last received J1939-73 DM1 message based on specified DTC
data.

All targets

Channel: 0
sim_active SPN: [] active
FMI: []
CM: []
Source address: []
sim_oc oc
Sample time: -1
pj1939_Dm1DecodeDtc
The active/not active status of a specified DTC as reported by another unit via J1939 DM1
messages can be monitored using this block. The outputs are updated each time a new
DM1 message is received. Use the pj1939_Dm1Receive block to determine when a DM1
message is received.
6.1.47.4. Inports
• sim_active
The simulation value for the outport active.
Value type: Boolean

Calibratable: No
• sim_oc
The simulation value for the outport oc.
Value type: Integer

Calibratable: No
6.1.47.5. Outports
• active
Set to 1 if the DTC is active, 0 otherwise.
Value type: Boolean

Calibratable: No

Software detail
• oc
The occurrence count of the DTC (as specified by the parameters Suspect parameter
number, Failure mode indicator and Conversion method).
Range: [0, 127]
Value type: Integer

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
mode indicator and Conversion method uniquely identify the DTC.
Range: [0, 524287]
Value type: Integer

Calibratable: No
Range: [0, 31]
Value type: Integer

Calibratable: No
Range: 0 or 1
Value type: Integer

Calibratable: No
• Source address

Software detail
The source J1939 network address of the message.
Range: 0 or 253
Value type: Integer

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
6.1.47.7. Notes
None.
6.1.48. J1939 DM1 transmit (pj1939_Dm1Transmit)

Transmit a J1939-73 DM1 message containing the DTCs with an active state from a DTC
table.

All targets

sim_error_flag
sim_transport_errors error_flag
force_transmission
Channel: 0
Table:
priority
dest_addr
transport_errors
use_dest_addr
pj1939_Dm1Transmit
A J1939-73 DM1 message is a variable length message, transmitted by a network node to

the global network address. The DM1 message contents detail any active diagnostic trouble
codes. As the message is variable in length, direct blockset support is provided (rather than
relying on the pj1939_PgTransmit block).
When the block iterates, the DTC table is inspected for active and previously active DTCs. If
any differ since the last time the block iterated, a DM1 message could be sent. The J1939-73
specification explains how the periodic transmission of this message varies in relation to DTC
activation state changes, as a need to limit J1939 network bandwidth.
Excerpt from J1939/73 specification, on transmission rate:

A DM1 message shall be transmitted, regardless of the presence or absence
of any DTC, once every second and on state change. To prevent a high
message rate due to intermittent faults that have a very high frequency, it is
recommended that no more than one state change per DTC per second be
transmitted. For example, if a fault has been active for 1 second or longer,
and then becomes inactive, a DM1 message shall be transmitted to reflect
this state change. If a different DTC changes state within the 1 second
update period, a new DM1 message is transmitted to reflect this new DTC.

Software detail
6.1.48.4. Inports
• sim_error_flag
The simulation inport for the error_flag outport.
Value type: Boolean

Calibratable: No
• sim_transport_errors
Simulation value of the outport transport_errors.
Value type: Integer

Calibratable: No
• force_transmission
Set to 1 to force the transmission of a DM1 message, set to zero otherwise.
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
J1939 priority of the DM1 message to be transmitted.
Range: [0, 7]
Value type: Integer

Calibratable: No
• dest_addr
J1939 destination address for the DM1 message (This could be the source address of the
corresponding PGN request, or the global address (255) if the request was sent to the
global address). If use_dest_addr is false or a PDU2 message is shorter than 9 bytes, this
value is ignored and the message is sent to the global address.
Range: [0, 255]
Value type: Integer

Calibratable: No
• use_dest_addr
Whether to send the DM1 to a specified destination address. If false (0), the message will
always be sent to the global address. Set to true (1) to allow the message to be sent to a
specific destination address, such as the source address of a PGN request.
Range: 0 or 1.
Value type: Boolean

Calibratable: No
6.1.48.5. Outports
• error_flag
Software detail
Set to 1 when the DM1 message could not be buffered for transmission, or if a previous
request to send a DM1 message has not completed.
Value type: Boolean

Calibratable: No
• transport_errors
Saturated count of transport errors (timeout or aborts) for this message.
Range: [0, 255]
Value type: Integer

Calibratable: No
• J1939 Channel
The logical J1939 channel on which to transmit. Must be a channel declared with a
pj1939_ChannelConfiguration block.
Value type: Integer

Calibratable: No
Value type: String

Calibratable: No
6.1.48.7. Notes
In order to meet the requirement of sending a periodic DM1 message every second, when
there is one or more active DTCs, it is necessary to set the block sample rate to 1 second
or less. The rate must be an integer factor of 1 second.

Indicates if a J1939-73 DM2 message has been received and decodes the contents of the
lamp status.

Software detail

All targets

sim_rx_trig_flag rx_trig_flag
Channel: 0
sim_lamp_malfunction
Source address: [] lamp_malfunction
Sample time: -1
sim_lamp_red lamp_red
sim_lamp_amber lamp_amber
sim_lamp_protect lamp_protect
pj1939_Dm2Receive
A J1939-73 DM2 message is a variable length message, transmitted by a network node to the
global network address. The DM2 message contents detail any previously active diagnostic
trouble codes and lamp statuses. As the message is variable in length, direct blockset support
is provided (rather than relying on the pj1939_PgReceive block).
The application model must request the DM2 message. This block does not make a request
for the DM2 message.
6.1.49.4. Inports
• sim_error_flag
The simulation value for the outport error_flag.
Value type: Boolean

Calibratable: No
The simulation value for the outport rx_trig_flag.
Value type: Boolean

Calibratable: No
The simulation value for the outport overrun_flag.
Value type: Boolean

Calibratable: No
• sim_lamp_malfunction
The simulation value for the outport lamp_malfunction.
Value type: Integer

Calibratable: No
• sim_lamp_red
The simulation value for the outport lamp_red.
Value type: Integer

Calibratable: No

Software detail
• sim_lamp_amber
The simulation value for the outport lamp_amber.
Value type: Integer

Calibratable: No
• sim_lamp_protect
The simulation value for the outport lamp_protect.
Value type: Integer

Calibratable: No
• sim_timestamp
Value type: Integer
6.1.49.5. Outports
• error_flag
Set to 1 if an error in receive processing relevant to this message has occurred.
Value type: Boolean

Calibratable: No
• rx_trig_flag
Set to 1 if a DM2 message matching the source address has been received since the last
time the block was evaluated, 0 otherwise.
Value type: Boolean

Calibratable: No
• overrun_flag
Set to 1 if more than one DM2 messages matching the source address have been received
since the last time the block was evaluated, 0 otherwise.
Value type: Boolean

Calibratable: No
The state value of the malfunction lamp.
Value type: Integer

Calibratable: No
• lamp_red
The state value of the red lamp.
Value type: Integer

Calibratable: No

Software detail
• lamp_amber
The state value of the amber lamp.
Value type: Integer

Calibratable: No
• lamp_protect
The state value of the protect lamp.
Value type: Integer

Calibratable: No
• timestamp
is selected.
Range: [0, 4294967295] us
Value type: Integer
• J1939 Channel
Value type: Integer

Calibratable: No
• Source address
The source J1939 network address of the message to be received.
Range: 0 or 253
Value type: Integer

Calibratable: No
• Sample time

Software detail
Value type: Real

Calibratable: No
Value type: Boolean

Calibratable: No
6.1.49.7. Notes
None.

data.

All targets

Channel: 0
sim_previously_active SPN: [] previously_active
FMI: []
CM: []
Source address: []
sim_oc oc
Sample time: -1
pj1939_Dm2DecodeDtc
The previously active/not previously active status of a specified DTC as reported by another
unit via J1939 DM2 messages can be monitored using this block. The outputs are updated
each time a new DM2 message is received. Use the pj1939_Dm2Receive block to determine
when a DM2 message is received.
6.1.50.4. Inports
• sim_active
The simulation value for the outport previously_active.
Value type: Boolean

Calibratable: No
• sim_oc
The simulation value for the outport oc.
Value type: Integer

Calibratable: No
6.1.50.5. Outports
• previously_active
Set to 1 if the DTC was previously active, 0 otherwise.

Software detail
Value type: Boolean

Calibratable: No
• oc
The occurrence count of the DTC (as specified by the parameters Suspect parameter
number, Failure mode indicator and Conversion method).
Range: [0, 127]
Value type: Integer

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
Range: [0, 524287]
Value type: Integer

Calibratable: No
Range: [0, 31]
Value type: Integer

Calibratable: No
Range: 0 or 1
Value type: Integer

Software detail
Calibratable: No
• Source address
Range: 0 or 253
Value type: Integer

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
6.1.50.7. Notes
None.

Transmit a J1939/73 DM2 message containing the DTCs with a previously active state from
a DTC table.

All targets

sim_error_flag
transmit
Channel: 0
Table:
priority
dest_addr
transport_errors
use_dest_addr
pj1939_Dm2Transmit
A J1939/73 DM2 message is a variable length message, transmitted by a network node to the
global network address. The DM2 message contents detail any previously active diagnostic
trouble codes. As the message is variable in length, direct blockset support is provided (rather
than relying on the pj1939_PgTransmit block).
6.1.51.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No

Software detail
Value type: Integer

Calibratable: No
• transmit
Set to 1 to transmit a DM2 message, set to zero otherwise.
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• dest_addr
Range: [0, 255]
Value type: Integer

Calibratable: No
• use_dest_addr
Range: 0 or 1.
Value type: Boolean

Calibratable: No
6.1.51.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
Range: [0, 255]
Value type: Integer

Software detail
Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
Value type: String

Calibratable: No
6.1.51.7. Notes
None.
6.1.52. J1939 parameter group receive message

(pj1939_PgReceive)
Extract the data contents from a received J1939 message.

All targets

Channel: 0
sim_rx_trig_flag PDU datapage: [] rx_trig_flag
PDU format: []
Message length: [] bytes
Field start positions: [ ]
sim_overrun_flag Field widths: [ ] overrun_flag
Field signs: [ ]
Field packings: [ ]
sim_source_addr Sample time: -1 source_addr
sim_dest_addr dest_addr
pj1939_PgReceive

Software detail
When a matching J1939 message to this block is received, the block unpacks the message
contents into individual signals, as specified by the block mask parameters, and provides
them as outports.
Warning
6.1.52.4. Inports
• sim_error_flag
Simulation value for the outport error_flag.
Value type: Boolean

Calibratable: No
Simulation value for the outport rx_trig_flag.
Value type: Boolean

Calibratable: No
Simulation value for the outport overrun_flag.
Value type: Boolean

Calibratable: No
• sim_source_addr
Simulation value for the outport source_addr.
Value type: Integer

Calibratable: No
• sim_dest_addr
Simulation value for the outport dest_addr.
Value type: Integer

Calibratable: No
• sim_timestamp
Value type: Integer
• sim_fields
A set of simulation inports for the corresponding outports fields. Available if there is at least
one field and the parameter Provide simulation input? is selected.
Value type: Integer

Software detail
Calibratable: No
6.1.52.5. Outports
• error_flag
Set to 1 if some error has occurred which prevents CAN reception, or 0 otherwise. Errors
which prevent reception are: CAN bus detected as bus-off, or the length of the received
J1939 message does not match the Message length parameter.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• rx_trig_flag
Set to 1 if the block has detected reception of the J1939 message since the last iteration
of this block, set to zero otherwise.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• overrun_flag
Set to 1 if the block has detected reception of the same J1939 message more than once
between iterations of this block.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• source_addr
Range: [0, 253] or 255
Value type: Integer

Calibratable: No
• dest_addr
The destination J1939 network address of the message.
Range: [0, 253] or 255
Value type: Integer

Calibratable: No
• timestamp
is selected.
Range: [0, 4294967295] us

Software detail
Value type: Integer
• fields
An outport for each field specified in the block.
Value type: Real

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
• PDU datapage
The pdu datapage value of the PGN of the J1939 message to receive.
Range: 0 or 1
Value type: Integer

Calibratable: No
• PDU format

Software detail
The pdu format value of the PGN of the J1939 message to receive.
Range: [0, 255]
Value type: Integer

Calibratable: No
• PDU specific
The pdu specific value of the PGN of the J1939 message to receive. If the PDU format
parameter is less than 240, then this parameter is not available for editing and does not
form part of the PGN.
Range: [0, 255]
Value type: Integer

Calibratable: No
• Message length
The length of the data bytes in the message to be received.
Range: [0, 1785]
Value type: Integer

Calibratable: No
• Field start positions
A vector of bit numbers indicating the start position of each field in the CAN message.
Field start positions correspond to the message data bytes as follows:
Data byte Bit number

LS MS LS
1 8 7 6 5 4 3 2 1
2 16 15 14 13 12 11 10 9
... ...
1785 14280 14279 14278 14277 14276 14275 14274 14273
MS MS LS
where byte 1 corresponds to the first received data byte in the first CAN
message for the J1939 message. This numbering scheme matches the
J1939 specification but differs from the existing CAN blocks. Although this
may cause some confusion when both blocks are used in the same model,
it will help reduce mistakes when using the J1939 blockset with the J1939
specification of message contents.
Value type: Integer

Calibratable: No
• Field widths
A vector of bit lengths indicating the number of bits allocated to each field.
Range: [1, 32] bits
A field which starts at bit 5 and has 10 bits of width is identified as follows:

Software detail

1 8 7 6 5 - - - -
2 - - 14 13 12 11 10 9
Value type: Integer

Calibratable: No
• Field signs
A vector of zero or one values, corresponding to each field. Fields for which this is set 1
are received as twos-complement signed numbers, or unsigned numbers otherwise.
Range: 0 or 1
Value type: Integer

Calibratable: No
• Field packing
are received as MS packing, or LS packing otherwise.
Range: 0 or 1
J1939 message fields are generally packed LS byte first, so the field which
starts at bit 5 and has 10 bits of width, would be interpreted as:
MS LS
Data byte 2 Data byte 1
- - - - - - 14 13 12 11 10 9 8 7 6 5
s s s s s s x x x x x x x x x x
where 'x' is the corresponding bit taken from the J1939 message data
bytes, and 's' is the sign extension of the data. In this case, bit 14 may be
considered the sign bit, if the data in the J1939 message data is signed.
However, if the J1939 message field was packed MS byte first, the bits
would be interpreted as:
MS LS
- - - - - - 6 5 14 13 12 11 10 9 8 7
Value type: Integer

Calibratable: No
• Field mnemonics
field inports and message field outports.

Software detail
Range: 0 or 1
Value type: String

Calibratable: No
If selected then create simulation inports (sim_fields) for each of the outport message
signals (fields).
Value type: Boolean

Calibratable: No
Value type: Boolean

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
6.1.52.7. Notes
• Unused fields in a J1939 message need not be specified in the Field start positions
parameter.
• If the block shows unnamed outports, or if the field outports are not shown, it is likely that
one or more of the block's parameter fields is incorrect. Check the parameter fields for
mistakes and correct them.
• The following example illustrates the least significant (LS) and most significant (MS) byte
ordering in J1939 messages. The message is received as follows:
MS LS
Byte 1 2 3 4 5 6
Message 11 10 FF FF 20 21
(hex)
where the first parameter is in LS byte format, starts at bit 0, is 16 bits wide and unsigned,
and the second parameter is in MS byte format, starts at bit 32, and is also 16 bit wide
and unsigned.
Parameter 1 is unpacked using LS byte formatting giving 0x1011. The LS byte is unpacked
from the LS byte of its position within the message (byte 1) giving 0x11, and the MS byte
is unpacked from the MS byte of its position within the message (byte 2) giving 0x10.
Parameter 2 is unpacked using MS byte formatting giving 0x2021. The LS byte is unpacked
from the MS byte of its position within the message (byte 6) giving 0x21, and the MS byte
is unpacked from the MS byte of its position within the message (byte 5) giving 0x20.

Software detail
6.1.53. J1939 parameter group requested

(pj1939_PgRequested)
Determine whether a Parameter Group (PG) has been requested by another J1939 network
node.

All targets

sim_requested requested
Channel: 0
PDU datapage: []
sim_source_addr PDU format: [] source_addr
Sample time: -1
pj1939_PgRequested
The pj1939_PgRequested block captures all J1939/21 Request PGN messages directed at
the ECU and determines if the model must respond to any of them. If the model is configured
to do so (by use of this block), then the model must implement an appropriate action or
response. If the model is not configured to do so, then the ECU will respond with a NACK
(if it is appropriate to do so).
The PGN to match against any J1939 request message, is specified by parameters PDU
datapage, PDU format and PDU specific. If a matching PGN has been requested, then
the outport requested is set to 1. The PGN must not be duplicated in more than one
pj1939_PgRequest block.
Requests for DM1, DM2, DM3, DM4, DM5, DM6, DM11, DM12, DM20, DM21,
DM23, DM24, DM25, DM26, DM27, DM28, DM29, DM31, DM32, DM34, DM41,
DM42, DM43, DM44, DM45, DM46, DM47, DM48, DM49, DM50, DM51 and
DM52 messages are handled by the model using this block. The application
modeller must then provide the necessary logic to handle the request using
the corresponding pdtc_ClearAllIfActive, pdtc_ClearAllIfInactive, pj1939_Dm1Transmit,
pj1939_Dm2Transmit, pj1939_Dm4Transmit, pj1939_Dm5Transmit, pj1939_Dm8Transmit,
pj1939_Dm10Transmit, pj1939_Dm20Transmit, pj1939_Dm21Transmit,
pj1939_Dm24Transmit, pj1939_Dm25Transmit, pj1939_Dm26Transmit,
pj1939_Dm30Transmit, pj1939_Dm32Transmit, pj1939_Dm34Transmit, and
pj1939_TransmitDtcDm blocks.
6.1.53.4. Inports
• sim_requested
Simulation value for the inport requested.
Value type: Boolean

Calibratable: No
• sim_source_addr
Simulation value for the inport source_addr.
Value type: Integer

Software detail
Calibratable: No
• sim_dest_addr
Simulation value for the inport dest_addr. Available only if the parameter PDU format is
less than 240.
Value type: Integer

Calibratable: No
• sim_timestamp
Value type: Integer
6.1.53.5. Outports
• requested
Set to 1 if the pgn defined by the parameters PDU datapage, PDU format and PDU specific
matches a request message.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• source_addr
The source J1939 network address of the request message.
Range: [0, 253] or 255
Value type: Integer

Calibratable: No
• dest_addr
The destination J1939 network address of the request message. Available only if the
parameter PDU format is less than 240.
Range: [0, 253] or 255
Value type: Integer

Calibratable: No
• timestamp
is selected.
Range: [0, 4294967295] us
Value type: Integer

Software detail
• J1939 Channel
The logical J1939 channel on which the request will arrive. Must be a channel declared
Value type: Integer

Calibratable: No
• PDU datapage
The pdu datapage value of the PGN to match against a J1939 request message.
Range: 0 or 1
Value type: Integer

Calibratable: No
• PDU format
The pdu format value of the PGN to match against a J1939 request message.
Range: [0, 255]
Value type: Integer

Calibratable: No
• PDU specific
The pdu specific value of the PGN to match against a J1939 request message. If the PDU
format parameter is less than 240, then this parameter is not available for editing and does
not form part of the PGN.
Range: [0, 255]
Value type: Integer

Calibratable: No

Software detail
• Sample time
Value type: Real

Calibratable: No
Value type: Boolean

Calibratable: No
6.1.53.7. Notes
None.
6.1.54. J1939 parameter group transmit

(pj1939_PgTransmit)
Construct the contents of a J1939 message, and attempt to transmit it.

All targets

sim_error_flag
Channel: 0
PDU datapage: []
PDU format: []
priority Message length: [] bytes
Field start positions: [ ]
Field widths: [ ]
dest_addr
transport_errors
use_dest_addr
pj1939_PgTransmit
When a J1939 message is to be transmitted, the block packs each of the signal inports into
the message, as specified by the block mask parameters, and transmits the message.
6.1.54.4. Inports
• sim_error_flag
Simulation value of the outport error_flag.
Value type: Boolean

Calibratable: No
Value type: Integer

Calibratable: No

Software detail
• priority
The priority of the J1939 message to transmit.
Range: [0, 7]
Value type: Integer

Calibratable: No
6.1.54.5. Outports
• error_flag
Set to 1 when there an a problem transmitting the message, set to zero otherwise.
Value type: Boolean

Calibratable: No
Range: [0, 255]
Value type: Integer

Calibratable: No
• J1939 Channel

Software detail
Value type: Integer

Calibratable: No
• PDU datapage
The pdu datapage value of the PGN of the J1939 message to transmit.
Range: 0 or 1
Value type: Integer

Calibratable: No
• PDU format
The pdu format value of the PGN of the J1939 message to transmit.
Range: [0, 255]
Value type: Integer

Calibratable: No
• PDU specific
The pdu specific value of the PGN of the J1939 message to transmit. If the PDU format
parameter is less than 240, then this parameter is not available for editing and does not
form part of the PGN.
Range: [0, 255]
Value type: Integer

Calibratable: No
• Message length
The length of the data bytes in the message to transmit. Maximum size is the smaller of
maximum range or buffer size.
Range: [0, 1785]
Value type: Integer

Calibratable: No
• Field start positions
A vector of bit numbers indicating the start position of each field in the CAN message.
Field start positions correspond to the message data bytes as follows:

LS MS LS
1 8 7 6 5 4 3 2 1
2 16 15 14 13 12 11 10 9
... ...
1785 14279 14278 14277 14276 14275 14274 14273 14272
MS MS LS

Software detail
where byte 1 corresponds to the first received data byte in the first CAN
message for the J1939 message. This numbering scheme matches the
J1939 specification but differs from the existing CAN blocks. Although this
may cause some confusion when both blocks are used in the same model,
it will help reduce mistakes when using the J1939 blockset with the J1939
specification of message contents.
Value type: Integer

Calibratable: No
• Field widths
A vector of bit lengths indicating the number of bits allocated to each field.
Range: [1, 32] bits
A field which starts at bit 5 and has 10 bits of width is identified as follows:

1 8 7 6 5 - - - -
2 - - 14 13 12 11 10 9
Value type: Integer

Calibratable: No
• Field packing
are transmitted as MS packing, or LS packing otherwise.
Range: 0 or 1
J1939 message fields are generally packed LS byte first, so the field which
starts at bit 5 and has 10 bits of width, would be interpreted as:
MS LS
- - - - - - 14 13 12 11 10 9 8 7 6 5
However, if the J1939 message field was packed MS byte first, the bits
would be interpreted as:
MS LS
- - - - - - 6 5 14 13 12 11 10 9 8 7

Software detail
Value type: Integer

Calibratable: No
• Field mnemonics
A string containing a comma-separated list of names with which to label the message field
inports.
Range: 0 or 1
Value type: String

Calibratable: No
6.1.54.7. Notes
• Unused fields in a J1939 message need not be specified in the Field start positions
parameter (bits in unused fields are set to 1 for transmission).
• If the block shows unnamed inports, or if the field inports are not shown, it is likely that
one or more of the block's parameter fields is incorrect. Check the parameter fields for
mistakes and correct them.
• The following example illustrates the least significant (LS) and most significant (MS) byte
ordering in J1939 messages. Given two parameters:
MS LS
Byte 1 2
Parameter 1 (hex) 10 11
Parameter 2 (hex) 20 21
the first parameter is packed into the J1939 message in LS byte format, starting at bit 0, is
16 bits wide and unsigned, and the second parameter is packed in MS byte format, starting
at bit 32, and is also 16 bit wide and unsigned.
MS LS
Byte 1 2 3 4 5 6
Message 11 10 FF FF 20 21
(hex)
Parameter 1 has been packed using LS byte formatting. The LS byte of 0x1011 (0x11)
has been packed into the LS byte of its position within the message (byte 1), and the MS
byte of 0x1011 (0x10) has been packed into the MS byte of its position within the message
(byte 2).
Parameter 2 is packed using MS byte formatting. The LS byte of 0x2021 (0x21) has been
packed into the MS byte of its position within the message (byte 6), and the MS byte of
0x2021 (0x20) has been packed into the MS byte of its position within the message (byte 5).
Bytes 2 and 3 are not used and are therefore set with all bits at 1.
6.1.55. Link options (pcomp_LinkOptions)

Specify or append linker options when building a model.

All targets

Software detail

Link options mode:
Use default options
pcomp_LinkOptions
After RTW has generated code for a model, a compiler converts the code into a binary image
suitable for the ECU to execute. Which compiler to use is chosen through the RTW Compiler
Selection option.
The compiler's linker combines each of the compiled source code files into a binary image
using various transformations, some of which can be modified via command line options to
the compiler. The pcomp_LinkOptions block selects whether to use the default linker options
supplied with OpenECU, to add additional options to the default options, or to replace the
default options altogether.
Warning
Alteration of the linker options may lead to a model which will not build, or a model
which will not run on the target ECU or which may run initially but fail later on. When
reporting a failure through technical support, please specify any changed linker options
as this may help resolve the issue more quickly.
All Diab compilers

The default linker options for all WindRiver Diab compilers are:
Option Use
-f65535 fill unused memory regions with set bits — this mirrors the
functionality of some post-processing build scripts
-lc ask the linker to include part of the standard C library
-lm ask the linker to include the math part of the standard C library
-m2 ask the linker to produce a map file with a particular layout —
essential for some post-processing of the build files
-t... set to -tPPCE200Z3VEF for the M220, M221, M250, M460 and
M461 or set to -tPPCE200Z7VEF for the M550 and M670 —
selects the processor for the target ECU
-Xcheck- ask the linker to check that memory regions and data within
overlapping those regions, do not overlap
-Xelf ask the linker to generate an ELF object file format — essential
for some post-processing of the build files
GCC 4.7.3 Compiler

The default linker options for the GCC compiler are:
Option Use
-M print a link map to the standard output
-lgcc ask the linker to try and link against libgcc.a

Software detail
Option Use
-lc ask the linker to include part of the standard C library
-lm ask the linker to include the math part of the standard C library
--check- ask the linker to check section addresses after they have been
sections assigned to see if there are any overlaps
--emit-stub- label linker stubs with a local symbol that encodes the stub type
syms and destination
-cref output a cross reference table. If a linker map file is being
generated, the cross reference table is printed to the map file.
Otherwise, it is printed on the standard output
-m elf32ppc emulate the elf32ppc linker
Note
Its outside the scope of this User Guide to explain all the different linker options in detail
and their resulting affect on the ECU binary image. Please refer to appropriate compiler
User Guide for more information.
Note
Alteration of the linker options may remove options which work around known bugs
in the compiler. For a list of known bugs which affect OpenECU, see Section 2.5.7.2,
“Known defects”.
6.1.55.4. Inports
None.
6.1.55.5. Outports
None.
• Mode
Whether to use the default linker options, whether to add linker options to the default
options, or whether to replace the default options altogether.
Value type: List

Software detail
Calibratable: No
• Linker options
The options to add to the default linker options, or to replace the default options, as selected
by parameter Mode.
Value type: String

Calibratable: No
6.1.55.7. Notes
None.
6.1.56. Memory configuration

(pmem_MemoryConfiguration)
Configure the memory allocation.

All targets

Memory Configuration:
Configuration A
pmem_MemoryConfiguration
Various configurations are available for dividing the available volatile and non-volatile
memory between use for code, calibration and general RAM.
6.1.56.4. Inports
None.
6.1.56.5. Outports
None.
• Memory configuration

Software detail
A list of the memory configurations available for this target. See Memory configurations for
details of the memory configurations available for different targets.
Value type: List

Calibratable: No
6.1.56.7. Notes
None.
6.1.57. Model identification (put_Identification)

The model identification block specifies which ECU hardware to target and information to be
recorded in the built model image.

All targets

Strategy Identification
Description:
Version: ..
ECU type: M560
ECU part number: 01T-070018-000
Issue number: []
Copyright:
put_Identification
The model identification block is usually placed in the top level Simulink diagram of the model.
It contains a mask entry which can be used to display a description of the model.
The model identification block also specifies the following information which is recorded in
the built model image:
• model version numbers (major, minor and sub-minor);
• copyright description.
In the case of the copyright description, the information is placed in the model image and
the calibration image.
The model identification block also selects the target hardware the model will expect to run on.
This parameter should be selected when the model is first created. Changing the parameter
later on has consequences (see the Notes section for the put_Identification block for more
details).
6.1.57.4. Inports
None.
6.1.57.5. Outports
None.

Software detail
• ECU type
Specifies the name of the ECU that the model will run on. Selection of the ECU type
changes the possible inputs and outputs on other blocks. The parameter should be
selected at the start of the model but if it must be changed later (for instance, moving
to another hardware platform to reduce costs) then consult the Notes section for the
put_Identification block for more details.
Value type: List

Calibratable: No
• Part Number
Specifies the hardware part number that appears on the ECU casing, followed by a hyphen
and a three-character suffix. This suffix denotes the option. Only those options that require
special software support are explicitly listed. If the option is not explicitly listed, then option
000 should be selected.
Value type: List

Calibratable: No
• Issue Number
Specifies the issue or revision number of the ECU that the model will run on. This is the first
number that appears after the hardware part number on the label of the ECU. For example,
if "2m4" appears after the hardware part number, then the issue number to be entered is 2.
Value type: Integer

Calibratable: No

Software detail
• Pin naming
Specifies the type of names used for pin and channel identification. Generic pin naming
uses the following terms for each pin.
Table 6.4. Generic pin naming convention

Name Description
AIN Analogue input
AOT Analogue output
DIN Digital input
DOT Digital output
Monitor Feedback signal from output driver circuitry
Powertrain pin naming uses a scheme that shortens the typical application naming given
in the target specification tables linked to in Section A.1, “ECU hardware reference
documentation”. The default selection for this drop-down is Powertrain pin naming to
maintain backwards compatibility with existing models.
Value type: List

Calibratable: No
• Name
Specifies the name of the model/application. The name has no functional effect on the
model but is used when generating ASAP2 files and in response to the CCP EXCHANGE-
ID message.
The name can include tokens which are automatically converted during model build.
Tokens are single words starting and ending in the “%” character. For instance, the string
“Application for %target%” contains one token named target, which is converted to
the target ECU name during a model build. The following table lists the available tokens:
Token Replacement
%copyright% Replaced with the string from the Copyright parameter.
%target% Replaced with a string representing the ECU target and option.
%ver-major% Replaced with the string from the Major version number
parameter.
%ver-minor% Replaced with the string from the Minor version number
parameter.
%ver-subminor% Replaced with the string from the Sub-minor version number
parameter.
Value type: String

Calibratable: No
• Description
Specifies a description of the model. The description is displayed in the block. The
description has no functional effect on the model.
Value type: String

Calibratable: No
• Major version number

Software detail
Specifies the major version number of the model. This has no functional effect on
the model. The version can be read from the target at run time by displaying the
mpl_app_ver_major automatic ASAP2 entry.
Range: [0, 255]
Value type: Integer

Calibratable: No
• Minor version number
mpl_app_ver_minor automatic ASAP2 entry.
Range: [0, 255]
Value type: Integer

Calibratable: No
• Sub-minor version number
mpl_app_ver_subminor automatic ASAP2 entry.
Range: [0, 255]
Value type: Integer

Calibratable: No
• Copyright
Specifies a copyright text that is embedded in the built model image and calibration.
Value type: String

Calibratable: No
6.1.57.7. Notes
• The Description parameter text can usually be split into multiple lines to make it more
readable. As the edit box of the description provides for a single line only, a new line can
be inserted by added the characters \n where a new line is required.
• Changing the ECU type parameter affects which inputs and outputs are selectable in other
blocks. This is also a risk when changing the parameters Part Number and Issue Number.
If a model contains such blocks, then when the target hardware is changed, the inputs and
outputs change when the model is next loaded or when a block is updated. If a change
in hardware is necessary, then the user should work out how the inputs and outputs will
change between hardware targets, then open the model, change the hardware selection,
save and close the model, then reload the model and modify each block input or output
appropriately.
Accidental changes to the hardware target may leave the block inputs and outputs in an
undefined state.

Software detail
6.1.58. Non-volatile adaptive check-sum

(pnv_AdaptiveChecksum)
Store adaptive data.

All targets

Adaptive Data Checksum
calc_checksum
pnv_adaptive_checksum
Adaptive data can be modified from the default values of scalar, 1-d or 2-d maps, or arrays
while the model is running, and recalled next time the model is started. The method depends
on the ECU and its configuration options:
• In most ECUs, adaptive data is stored in flash. This is retained when the ECU is unpowered.
In either case, a checksum is used to validate the data at start-up time. If the checksums
match at start-up, the adaptive data is retained from the previous power cycle, otherwise
the adaptive data is reverted to default. In most ECUs, the data is also reverted to default
if the stored data size or application version number are incompatible with the current build
of software.
This block is used to force the stored data to be updated. When the inport calc_checksum
transitions from 0 to 1, the block pauses execution of the model, calculates the checksum
and stores the adaptive data, then continues execution of the model. In the case of battery-
backed RAM, that merely involves computing the new checksum, but in the case of flash the
memory is physically reprogrammed. Real-time execution will be briefly affected.
If using battery-backed storage, it is important to trigger the adaptive checksum update

and not update adaptive data thereafter before shutting down the ECU. If adaptive data is
modified after the checksum has been updated, and the ECU shuts down, next time it powers
up, adaptive data will revert to default. (For flash, it will revert to the last saved data.)
To ensure the battery-backed checksum is up to date before shutting down the ECU, the
pnv_Status block provides an indication of whether the checksum is correct or not. If not,
shutdown of the module can be prevented (if conditions are appropriate) and the checksum
updated. That block also indicates if the last flash save was successful.
Note
Flash memory wears out over time, and after a minimum number of checksum
updates, the Flash memory is more likely to forget information each time the checksum
is updated. For this reason, Flash is only programmed when adaptive data has
changed since the last checksum update (either through an adaption operation or reset
operation).
See the technical specification for each ECU for information about the Flash capabilities
of each ECU.
Old adaptive data is reused so long as it has the expected total data size and was
written by an application with the same user-specified version number. Otherwise the

Software detail
values revert to defaults. If the usage of adaptive blocks has changed in a new software
version, increase the application sub-minor version number to ensure that any old
values are not used, as they may not map appropriately to the blocks in the new model
even if the total data size happens to match.
6.1.58.4. Inports
• calc_checksum
Transition from 0 to 1 to cause the adaptive data to be saved; no save takes place
otherwise.
Value type: Boolean

Calibratable: No
6.1.58.5. Outports
None.
• Sample time
Value type: Real

Calibratable: No
6.1.58.7. Notes
None.
6.1.59. Non-volatile adaptive 1-d map look-up

(pnv_AdaptiveMap1d)
Adaptive 1-d map look-up and interpolation.

All targets


Software detail
x
adapt_increment x:
Adaptive z: adapted_z
adapt
reset
pnv_adaptive_map1d
Looks up the inport x in the X-axis Data (default) parameter, interpolates the corresponding
elements in the Adaptive Z Data (default) parameter, giving a corresponding adapted_z as
the output.
The adaptive 1-d look-up block is similar to the OpenECU put_Calmap1d block, except that
the z-axis look-up values can change over time under control of the model and be recovered
from non-volatile memory when the model starts. If the adaptive values cannot be recovered
at start-up, or if the model is simulated, the default values are used before any adaption
takes place.
The battery backed non-volatile memory requires a small amount of power overall, i.e., much
less than powering the ECU normally.
The adaptive data is check-summed using a 16-bit CRC. Failure to match the check-sum
against the adaptive data on start-up means that the data cannot be recovered. In this case,
or if the model is simulated, adaptive data is reverted to the default value specified when
the model was built.
Warning
Unlike R12 Simulink maps, 1-d and 2-d maps in OpenECU do not extrapolate beyond
the limits of the input axis or axes. OpenECU calibration maps should be used for all
maps that form part of an OpenECU build.
the ASAP2 file with the signal name which corresponds to the x inport. To make this
feature work, the x signal must be a named DD entity with its storage class property set to
ExportedGlobal.
6.1.59.4. Inports
• x
The x-value at which a z-value is to be adapted then interpolated. May be a scalar or a

vector. If the inport is attached to a vector, the size of the vector must match the size of
any vector attached to another inport.
Value type: Real

Calibratable: No
• adapt_increment
The increment to the current adapted value. The increment is only used when the inports
adapt and reset are conditioned correctly. May be a scalar or a vector. If the inport is
attached to a vector, the size of the vector must match the size of any vector attached to
another inport.

Software detail
Value type: Real

Calibratable: No
• adapt
1 if the current adapted value should be adjusted, 0 otherwise. If the inport reset is 1, no
adaption will occur (even if inport adapt is 1). May be a scalar or a vector. If the inport is
another inport.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• reset
1 if the current adapted value should be reset to Adaptive Z Data (default), 0 otherwise.
May be a scalar or a vector. If the inport is attached to a vector, the size of the vector must
match the size of any vector attached to another inport.
Range: 0 or 1
Value type: Boolean

Calibratable: No
6.1.59.5. Outports
• adapted_z
The adapted value or values interpolated from parameter Adaptive Z Data (default) at the
value or values for inport x.
Value type: Real

Calibratable: No
• X-axis Data (default)
of elements in parameter Adaptive Z Data (default). The values of this parameter must
increase monotonically and adjacent values must not be the same.

Software detail
Value type: Real

• Adaptive Z Data (default)
The name of the map's z axis (e.g. vftm_mymap_zsee Section "Naming rules"). There
of elements in X-axis Data (default). The adaptive block reverts to these values when the
reset inport is asserted or when the block data is unrecoverable during power initialisation
of the ECU.
Value type: Real

• Sample time
Value type: Real

Calibratable: No
6.1.59.7. Notes
• The build process generates a corresponding ASAP2 entry to the adaptive parameter
that can be accessed via a calibration tool. The name of this entry has a fifth character
'a', i.e., given the default parameter name vtfm_mymap_z, an ASAP2 entry with name
vtfma_mymap_z is generated. Note that this implies that only a single adaptive parameter
can exist per named default parameter.
Warning
If two or more blocks refer to the same named item in the Adaptive Z Data (default)
field, these blocks will independently adapt the same adaptive parameter.
The reset, adaption, look-up and interpolation work as follows:
Possible reset
If the inport reset is 1, the block reverts the Adaptive Z Data (default) parameter data to
the block's defaults and sets the output from a look-up and interpolation.
Possible adaption
If a reset has not occurred and the inport adapt is 1, then the Adaptive Z Data (default)
parameter data is altered as follows before setting the output from a look-up and
interpolation.
zb
za
xa xb

Software detail
xa and xb bound inport x (see exceptions below), za and zb are the corresponding elements
of the parameter Adaptive Z Data (default).
When the software adapts the 1-d look-up table, the Adaptive Z Data (default) is modified
as follows:
If the inport x is less than xa and xa is the first element in the X-axis Data (default) parameter
then the software treats xb as the same element as xa, zb as the same element as za and
performs the adaption calculation with interpl as 0.
If the inport x is greater than xb and xb is the last element in the X-axis Data (default)
parameter then the software treats xa as the same element as xb, za as the same element
as zb and performs the adaption calculations with interpl as 1.
Look-up and interpolation
Works as the put_Calmap1d block.
6.1.60. Non-volatile adaptive 2-d map look-up

(pnv_AdaptiveMap2d)
Adaptive 2-d map look-up and interpolation.

All targets

x
y
x:
y:
adapt_increment adapted_z
Adaptive z:
adapt
reset
pnv_adaptive_map2d
Looks up the input x and y in the X-axis Data (default) and Y-axis Data (default) parameters,
interpolates between the corresponding Adaptive Z Data (default) parameter elements, giving
a corresponding adapted_z as output.
The adaptive 2-d look-up block is similar to the OpenECU put_Calmap2d block, except that
the z-axis look-up values can change over time under control of the model and be recovered
from non-volatile memory when the model starts. If the adaptive values cannot be recovered
at start-up, or if the model is simulated, the default values are used before any adaption
takes place.

Software detail
The adaptive data is check-summed using a 16-bit CRC. Failure to match the check-sums on
start-up means that the data cannot be recovered. In this case, or if the model is simulated,
adaptive data is reverted to the default value specified when the model was built.
Warning
Unlike R12 Simulink maps, 1-d and 2-d maps in OpenECU do not extrapolate beyond
the limits of the input axis or axes. OpenECU calibration maps should be used for all
maps that form part of an OpenECU build.
the ASAP2 file with the signal names which correspond to the x and y inports. To make
this feature work, the x and y signals must be named DD entities with their properties set
to ExportedGlobal.
6.1.60.4. Inports
• x
The x-value at which a z-value is to be adapted then interpolated. May be a scalar or a

Value type: Real

Calibratable: No
• y
The y-value at which a z-value is to be adapted then interpolated. May be a scalar or a

Value type: Real

Calibratable: No
• adapt_increment
adapt and reset are conditioned correctly. May be a scalar or a vector. If the inport is
another inport.
Value type: Real

Calibratable: No
• adapt
adaption will occur (even if inport adapt is 1). May be a scalar or a vector. If the inport is
another inport.

Software detail
Range: 0 or 1
Value type: Boolean

Calibratable: No
• reset
1 if the current adapted value should be forced to Adaptive Z Data (default), 0 otherwise.
May be a scalar or a vector. If the inport is attached to a vector, the size of the vector must
match the size of any vector attached to another inport.
Range: 0 or 1
Value type: Boolean

Calibratable: No
6.1.60.5. Outports
• adapted_z
The adapted value or values interpolated from parameter Adaptive Z Data (default) at the
values for inports x and y.
Value type: Real

Calibratable: No
• X-axis Data (default)
must be two or more elements in this parameter and that must be the same as the
number of elements as columns in parameter Adaptive Z Data (default). The values of this
parameter must increase monotonically and adjacent values must not be the same.
Value type: Real

Calibratable: No
• Y-axis Data (default)
The name of the map's y axis (e.g. vftm_mymap_y, see Section "Naming rules"). There

Software detail
of elements as rows in parameter Adaptive Z Data (default). The values of this parameter
must increase monotonically and adjacent values must not be the same.
Value type: Real

Calibratable: No
• Adaptive Z Data (default)
The name of the map's z matrix (e.g. vftm_mymap_z, see Section "Naming rules"). There
must be the same number of rows as elements in parameter Y-axis Data (default) and
number of columns as elements in parameter X-axis Data (default).
Value type: Real

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
6.1.60.7. Notes
'a', i.e., given the default parameter name vtfm_mymap_z, an ASAP2 entry with name
vtfma_mymap_z is generated. Note that this implies that only a single adaptive parameter
Warning
If two or more blocks refer to the same named item in the Adaptive Z Data (default)
The reset, adaption, look-up and interpolation work as follows:
Possible reset
If the inport reset is 1, the block reverts the Adaptive Z Data (default) parameter data to
the block's defaults and sets the output from a look-up and interpolation.
Possible adaption
If a reset has not occurred and the inport adapt is 1, then the Adaptive Z Data (default)
parameter data is altered as follows before setting the output from a look-up and
interpolation.
yb
zab zbb
ya
zaa zba
xa xb

Software detail
xa and xb bound x (see exceptions below), ya and yb bound y (see exceptions below), zaa ,
zab, zba and zbb are the corresponding elements in the parameter Adaptive Z Data (default).
When the software adapts the 2-d look-up table, the Adaptive Z Data (default) is modified
as follows:
If the inport x is less than xa and xa is the first element in the X-axis Data (default) parameter
then the software shall treat xb as the same element as xa, zab as the same element as zaa
and perform the adaption calculation with interplx as 0.
If the inport x is greater than xb and xb is the last element in the X-axis Data (default)
parameter then the software shall treat xa as the same element as xb, zaa as the same
element as zab and perform the adaption calculation with interplx as 1.
Similar restrictions apply for the y inport.
Look-up and interpolation
Works as the put_Calmap1d block.
6.1.61. Non-volatile adaptive scalar

(pnv_AdaptiveScalar)
Non-volatile adaptive scalar block.

All targets


Software detail
adapt_increment
Adaptive Scalar:
adapt adapted_scalar
reset
pnv_adaptive_scalar
The adaptive scalar block is similar to the standard constant block provided by Simulink,
except that the constant can change over time under control of the model and be recovered
from non-volatile memory when the model starts. If the value cannot be recovered at start-
up, or if the model is simulated, the default values are used before any adaption takes place.
6.1.61.4. Inports
• adapt_increment
adapt and reset are conditioned correctly.
Value type: Real

Calibratable: No
• adapt
adaption will occur (even if inport adapt is 1).
Range: 0 or 1
Value type: Boolean

Calibratable: No
• reset
1 if the current adapted value should be reset to Adaptive Scalar (default), 0 otherwise.
Range: 0 or 1
Value type: Boolean

Calibratable: No
6.1.61.5. Outports
• adapted_scalar
The adapted value of the Adaptive Scalar (default) parameter.
Value type: Real

Calibratable: No

Software detail
• Adaptive Scalar (default)
The name of the default adapted scalar output value (e.g., vftc_myscalar). The adaptive
block reverts to this value when the reset inport is asserted or when the block data is
unrecoverable during power initialisation of the ECU.
Value type: Real

• Sample time
Value type: Real

Calibratable: No
6.1.61.7. Notes
'a', i.e., given the default parameter name vftc_myscalar, an ASAP2 entry with name
vftca_myscalar is generated. Note that this implies that only a single adaptable value
Warning
If two or more blocks refer to the same named item in the Adaptive Scalar (default)
6.1.62. Non-volatile adaptive array (pnv_Array)

Adaptive array non-volatile storage.

All targets


Software detail
n
valid_n
u
Array:
change
u'
reset
pnv_array
Sets outport u' to the value of the adapted array indexed by inport n. Before outport u is set,
the value of indexed adapted array can be changed to inport u.
6.1.62.4. Inports
• n
The nth element in the array to modify.
Range: [0, number of elements in array - 1]
Value type: Integer

Calibratable: No
• u
The value to write to the nth element of the array. The type of this inport is the same as
the type of the parameter Array Data (default).
Value type: Real

Calibratable: No
• change
1 if the nth element of the array should be change to inport u, 0 otherwise. If the inport
reset is 1, no change will occur (even if inport change is 1).
Range: 0 or 1
Value type: Boolean

Calibratable: No
• reset
1 to change the array to the values of the Array Data (default) parameter, 0 otherwise.
Range: 0 or 1
Value type: Boolean

Calibratable: No

Software detail
6.1.62.5. Outports
• valid_n
1 if inport n refers to an element in the array, 0 if inport n is larger than the number of
array elements.
Value type: Boolean

Calibratable: No
• u'
The value of the nth element of the array, possibly after the array has been changed. The
type of this outport is the same as the type of the parameter Array Data (default).
Value type: Real

Calibratable: No
• whole_array
The current values of all elements of the array, possibly after the array has been changed,
output as a vector. The type of this outport is the same as the type of the parameter Array
Data (default). This outport is only present when the Output entire array contents? mask
parameter checkbox is ticked.
Value type: Dynamically Typed

Calibratable: No
• Array Data (default)
The name of the DDE for the array (e.g. vftv_array, see Section "Naming rules"). An
array can contain one or more elements. The type of the array dictates the type of inport
u and outport u'.
Value type: Real

• Output entire array contents?
Tick this checkbox to create an outport from the block to output the entire array contents.
Value type: Boolean

Calibratable: No
• Sample time

Software detail
Value type: Real

Calibratable: No
6.1.62.7. Notes
'a', i.e., given the default parameter name vtfv_array, an ASAP2 entry with name
vtfva_array is generated. Note that this implies that only a single adaptive parameter
Warning
If two or more blocks refer to the same named item in the Array Data (default) field,
these blocks will independently adapt the same adaptive parameter.
6.1.63. Non-volatile memory status (pnv_Status)

Provide information about the state of non-volatile memories.

All targets

sim_ram_adaptive_checksum_ok ram_adaptive_checksum_ok
NV Status
Flash Storage: off
sim_flash_adaptive_checksum_ok flash_adaptive_checksum_ok
pnv_status
The non-volatile status block details the state of all non-volatile memories. For most ECUs,
only flash storage is present.
6.1.63.4. Inports
• sim_ram_adaptive_checksum_ok
Value passed through to outport ram_adaptive_checksum_ok when running the model

under simulation. Has no effect when running on the target ECU.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• sim_flash_adaptive_checksum_ok
Value passed through to outport flash_adaptive_checksum_ok when running the model

under simulation. Has no effect when running on the target ECU.

Software detail
Range: 0 or 1
Value type: Boolean

Calibratable: No
6.1.63.5. Outports
• ram_adaptive_checksum_ok
1 if the battery-backed RAM adaptive data check-sum is valid and up to date, 0 otherwise.
If the adaptive data check-sum is invalid or inconsistent with the data stored in the battery
backed RAM at model start up, the adaptive data is reverted to default - see help on the
following adaptive data blocks: adaptive checksum, scalar, 1-d or 2-d maps, or arrays.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• flash_adaptive_checksum_ok
1 if the adaptive data check-sum is valid either at start up or after a NVM update, 0
otherwise. If the adaptive data check-sum is invalid at model start up, the adaptive data is
reverted to default - see help on the following adaptive data blocks: adaptive checksum,
scalar, 1-d or 2-d maps, or arrays.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
• Store adaptives in flash?
Store adaptives in flash memory if ticked.
Value type: Boolean

Calibratable: No

Software detail
6.1.63.7. Notes
None.
6.1.64. Non-volatile file system access (pnv_File)

Provide access to the non-volatile filesystem

All targets

read
write operation_successful
File Identifier:
delete
user_metadata_to_write
read_data
data_to_write
pnv_file
The filesystem feature is responsible for the non-volatile storage of data in flash memory
whilst the ECU is turned off. It is sufficiently flexible to cope not just with the existing and
planned storage needs of the platform, but also with as yet unknown and application-specific
needs. To achieve this it emulates the operations of a simple disk drive, with operations to
read, write and delete files at run time. The platform may use one file to store DTC states
and another for adaptive parameter values, etc. Applications may create and manipulate new
files for their own purposes through the pnv_file block.
The pnv_File block provides the ability to read, write, and delete a restricted set of files in
the non-volatile filesystem. These user files are identified by a numeric file identifier. Files
that are written with the pnv_File block can be retained across multiple application builds
and versions. The companion blocks, pnv_file_stats, pnv_filesystem_info, and pnv_file_flush
provide other functionality that is related to the management user files.
Warning
Filesystem access is an advanced feature that is distinct from the non-volatile array
and adaptive functionality.
The other non-volatile features impose build time constraints that prevent over-
allocation of non-volatile memory. This ensures that all platform features that use
non-volatile memory can function at full capacity without overrunning the non-volatile
memory that is available on the ECU.
They also impose run time constraints that automatically remove non-volatile data
from applications that do not match the signature of the application that is currently
running on the ECU. This prevents the usable non-volatile memory from becoming
filled to capacity with files that are not useful to the current application. Without these
protections a situation could arise wherein there is not enough space in non-volatile
memory to store adaptives, non-volatile arrays, diagnostic trouble codes, diagnostic
freeze frames, or data for other features that require non-volatile memory.
Access to the filesystem through the pnv_File block provides advanced options
for retaining data for the life of the ECU. This functionality does not include the
aforementioned protections. The application design and implementation must ensure

Software detail
that non-volatile memory is not over allocated and that unnecessary files are cleaned
up appropriately.
The signal width of the data_to_write port determines the size of the user file. Preexisting
user files can only be read if they have a file size that matches the size specified in the
application. User files can be deleted and overwritten regardless of the size of the preexisting
file. Information about the file on disc can be obtained from the pnv_file_stats block
The presence of a pnv_file block in an application indicates that the application will take
responsibility for managing a file with the indicated identifier. If any user file exist on disk and
does not have a corresponding pnv_file block in the application then the platform will delete
it during application initialization.
Read, Write, and Delete operations are triggered by a rising edge on the corresponding port.
Reads are accomplished synchronously. Write and delete operations are asynchronous.
If the file exists and a read operation is requested, then the operation_successful output will
be set to 1. The results of a read operation are available immediately on the read_data output.
If the file does not exist, then the operation_successful port will be set to 0.
If the file exists and a delete operation is requested, then the operation_successful output will
be set to 1. If it does not exist, the output will be set to 0. The read_data output is not changed
during a delete operation. The delete operation will continue in the background. The status
can be determined using the pnv_file_stats block, or the delete can be forced to complete
immediately through the use of the pnv_file_flush block.
If a write operation is requested, then the write will be initiated using the data supplied to
the user_metadata_to_write and data_to_write ports. The operation_successful port will be
set to 1 if the write was queued successfully and set to 0 if it was not queued successfully.
The read_data outport will remain unchanged. The write will continue in the background.
The status can be determined using the pnv_file_stats block, or the write can be forced to
complete immediately through the use of the pnv_file_flush block.
Warning
If the write and read inports are set to 1 at the same time, the block will return an error.
6.1.64.4. Inports
• read
Attempts to read a file on a rising edge.
Range: [0, 1]
Value type: Boolean

Calibratable: No
• write
Attempts to queue a file write on a rising edge.
Range: [0, 1]
Value type: Boolean

Calibratable: No
• delete
Attempts to queue a file delete on a rising edge.

Software detail
Range: [0, 1]
Value type: Boolean

Calibratable: No
• user_metadata_to_write
16-bit metadata to write to a file. Since the metadata is a fixed size, it can be read by the
pnv_file_stats block to obtain data about an existing file on disk without reading the entire
file contents. This inport is only used during write operations. The write is asynchronous,
and the data is not held in an intermediate buffer. If the data may change before the write
completes, then it should be latched in the application.
Range: [0, 65535]
Value type: Integer

Calibratable: No
• data_to_write
A multiplexed signal that contains all of the data to write to the file. This inport is only
used during write operations. The write is asynchronous, and the data is not held in an
intermediate buffer. If the data may change before the write completes, then it should be
latched in the application.
Value type: Dynamically typed

Calibratable: No
6.1.64.5. Outports
• operation_successful
Identifies if the previous operation was successful. If the operation was successful then the
output will be set to 1, otherwise it will be set to 0. See the block description for more details
Value type: Boolean

Calibratable: No
• read_data
Provides a multiplexed signal of all data read from the file. The outport is only updated as
a result of a successful read operation.
Value type: Dynamically Typed

Calibratable: No

Software detail
• File Identifier
The identifier of the user file managed by the block.
Range: [0, 31]
Value type: Integer

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
6.1.64.7. Notes
6.1.65. Non-volatile filesystem flush (pnv_FileFlush)

Forces the completion of all queued file write and delete operations

All targets

flush
pnv_file_flush
The block forces the completion of all file write or delete operations that have been queued.
It guarantees that all file writes will be completed in the same model iteration that the inport
is provided a rising edge signal.
Warning
This block suspends normal application execution until it returns. It is suitable only for
calling as part of a managed power-down operation, or in applications with no hard
real-time constraints.
6.1.65.4. Inports
• flush
Initiates the file flush operation on a transition from 0 to 1.
Range: [0, 1]
Value type: Boolean

Calibratable: No

Software detail
6.1.65.5. Outports
None.
• Sample time
Value type: Real

Calibratable: No
6.1.65.7. Notes
6.1.66. Non-volatile file information (pnv_FileStats)
Provide information about a user file stored to the non-volatile filesystem

All targets

file_exists
size_bytes
revision
this_build_wrote
File Identifier:
get_file_stats this_ver_wrote
major_version
minor_version
subminor_version
user_metadata
pnv_file_stats
The pnv_File block provides information about the user files that are stored in the non-volatile
filesystem. These user files are identified by a numeric file identifier.
6.1.66.4. Inports
• get_file_stats
Fetches file information and updates the outports if set to 1.
Range: [0, 1]
Value type: Boolean

Calibratable: No

Software detail
6.1.66.5. Outports
• file_exists
Identifies the presence of the file in the non-volatile filesystem. 1 if the file exits, 0 otherwise.
Range: [0, 1]
Value type: Boolean

Calibratable: No
• size_bytes
The size of the actual useful data contained in the file, excluding any overhead or padding.
Range: [0, 262143] bytes
Value type: Integer

Calibratable: No
• revision
The revision of the overall filesystem at which the file was written. A change to this number
following a write operation indicates that the write was successful and the new data is
stored to disk.
Range: [0, 65535]
Value type: Integer

Calibratable: No
• this_build_wrote
Whether this file was written by software matching the build timestamp of the currently
executing application software. 1 if the timestamp matches, 0 otherwise.
Range: [0, 1]
Value type: Boolean

Calibratable: No
• this_ver_wrote
Whether this file was written by software matching the build version number (e.g. 2.3.17)
of the currently executing application software. 1 if the version matches, 0 otherwise.
Range: [0, 1]
Value type: Boolean

Calibratable: No
• major_version
The major version number of the application software build responsible for the last write
of this file, e.g. 2 in version 2.7.13.
Range: [0, 255]
Value type: Integer

Calibratable: No
• minor_version

Software detail
The minor version number of the application software build responsible for the last write
of this file, e.g. 7 in version 2.7.13.
Range: [0, 255]
Value type: Integer

Calibratable: No
• subminor_version
The sub-minor version number of the application software build responsible for the last
write of this file, e.g. 13 in version 2.7.13.
Range: [0, 255]
Value type: Integer

Calibratable: No
• user_metadata
Data provided by the client when the file was written. This can be used for example to
define a use-specific layout version, such that the client can interpret old files correctly if
the format has changed. This is kept separate from the actual file data.
Range: [0, 65535]
Value type: Integer

Calibratable: No
• File Identifier
The identifier of the user file managed by the block.
Range: [0, 31]
Value type: Integer

Calibratable: No
• Sample time
Value type: Real

Software detail
Calibratable: No
6.1.66.7. Notes
6.1.67. Non-volatile filesystem information
(pnv_FilesystemInfo)
Provide information about the overall non-volatile filesystem

All targets

byte_capacity
bytes_used
bytes_bad
lifetime_erases
user_files
platform_files
failed_writes
discarded_files
corrupted_files
pnv_filesystem_info
The pnv_File block obtains statistical information on the current state of the non-volatile
filesystem
6.1.67.4. Inports
None.
6.1.67.5. Outports
• byte_capacity
The total raw space available for file storage. This includes the overhead of storing
metadata and padding.
Range: [0, 262143]
Value type: Integer

Calibratable: No
• bytes_used
The total raw space currently used by files, metadata and padding.
Range: [0, 262143]
Value type: Integer

Calibratable: No
• bytes_bad
The total space which has been found to contain invalid data or for which flash
programming operations failed. This is reset to zero on power-up, and then any invalid
data found already present in the system contributes to this total before any file writes are
attempted.

Software detail
Range: [0, 262143]
Value type: Integer

Calibratable: No
• lifetime_erases
The total number of times that a flash erase operation has been started on any block
allocated to the filesystem.
Range: [0, 16777215]
Value type: Integer

Calibratable: No
• user_files
The number of valid, completely written files currently present in the filesystem belonging
to the application.
Range: [0, 32]
Value type: Integer

Calibratable: No
• platform_files
The number of valid, completely written files currently present in the filesystem with
platform-reserved IDs.
Range: [0, 65535]
Value type: Integer

Calibratable: No
• failed_writes
The number of times since the most recent power-on that the system failed to successfully
write a file.
Range: [0, 32767]
Value type: Integer

Calibratable: No
• discarded_files
The number of times since the most recent power-on that the system ignored a file it found
on disk because its directory space was already full. As different versions of the file may
be found on disk, this may be larger than the number of unique files which were discarded.
Range: [0, 32767]
Value type: Integer

Calibratable: No
• corrupted_files
The number of files that have been detected by runtime processing to be corrupt since
power-on.
Range: [0, 32767]

Software detail
Value type: Integer

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
6.1.67.7. Notes
6.1.68. Internal RAM test error

(psc_InternalRamTestError)
Get the recoverable error information for the ECU's free running internal RAM test.

None at the moment

error_detected
error_address
psc_InternalRamTestError
Gets the recoverable error status of the ECU's internal RAM test as well as the address of
the last error.
6.1.68.4. Inports
• sim_error_detected
The outport error_detected is set to the value of this inport for simulation purposes.
Range: [0, 1]

Software detail
• sim_error_address
The outport error_address is set to the value of this inport for simulation purposes.
Range: [0, 4294967295]
6.1.68.5. Outports
• error_detected
1 when a recoverable memory test error has been detected, 0 otherwise. Under simulation,
if the Provide simulation inports parameter isn't ticked, the outport is set to the minimum
of its range. The signal attached to the outport must be set as ExportedGlobal.
Range: [0, 1]
• error_address
The internal memory address where a recoverable error has been detected. The outport
is only valid if error_detected is 1. Under simulation, if the Provide simulation inports
Range: [0, 4294967295]
• Sample time
Tick to enable inports sim_error_detected and sim_error_address.
6.1.68.7. Notes
Unrecoverable memory test errors are reported by the put_Reset block.
6.1.69. Internal RAM test progress

(psc_InternalRamTestProgress)
Get the progress information for the ECU's free running internal RAM test.

Software detail

None at the moment

start_address
end_address
current_address
psc_InternalRamTestProgress
Gets the start address, end address, and current address of the ECU's internal RAM test.
The test checks a fixed number of internal memory segments during each iteration of the
model. The test starts over once it reaches the end address.
6.1.69.4. Inports
• sim_start_address
The outport start_address is set to the value of this inport for simulation purposes.
Range: [0, 4294967295]
• sim_end_address
The outport end_address is set to the value of this inport for simulation purposes.
Range: [0, 4294967295]
• sim_current_address
The outport current_address is set to the value of this inport for simulation purposes.
Range: [0, 4294967295]
6.1.69.5. Outports
• start_address
The first address of the internal memory test. Under simulation, if the Provide simulation
Range: [0, 4294967295]
• end_address
The last address of the internal memory test. Under simulation, if the Provide simulation
Range: [0, 4294967295]
• current_address

Software detail
The current address of the internal memory test. Under simulation, if the Provide simulation
Range: [0, 4294967295]
• Sample time
Tick to enable inports sim_start_address, sim_end_address and sim_current_address.
6.1.69.7. Notes
None.
6.1.70. Internal ROM test error

(psc_InternalRomTestError)
Get the recoverable error information for the ECU's free running internal ROM test.

None at the moment

error_detected
error_address
psc_InternalRomTestError
Gets the recoverable error status of the ECU's internal ROM test as well as the address of
the last error.
6.1.70.4. Inports
• sim_error_detected

Software detail
The outport error_detected is set to the value of this inport for simulation purposes.
Range: [0, 1]
• sim_error_address
The outport error_address is set to the value of this inport for simulation purposes.
Range: [0, 4294967295]
6.1.70.5. Outports
• error_detected
1 when a recoverable memory test error has been detected, 0 otherwise. Under simulation,
Range: [0, 1]
• error_address
The internal memory address where a recoverable error has been detected. The outport
is only valid if error_detected is 1. Under simulation, if the Provide simulation inports
Range: [0, 4294967295]
• Sample time
Tick to enable inports sim_error_detected and sim_error_address.
6.1.70.7. Notes
Unrecoverable memory test errors are reported by the put_Reset block.

Software detail
6.1.71. Internal ROM test progress

(psc_InternalRomTestProgress)
Get the progress information for the ECU's free running internal ROM test.

None at the moment

start_address
end_address
current_address
psc_InternalRomTestProgress
Gets the start address, end address, and current address of the ECU's internal ROM test.
The test checks a fixed number of internal memory segments during each iteration of the
model. The test starts over once it reaches the end address.
6.1.71.4. Inports
• sim_start_address
The outport start_address is set to the value of this inport for simulation purposes.
Range: [0, 4294967295]
• sim_end_address
The outport end_address is set to the value of this inport for simulation purposes.
Range: [0, 4294967295]
• sim_current_address
The outport current_address is set to the value of this inport for simulation purposes.
Range: [0, 4294967295]
6.1.71.5. Outports
• start_address
The first address of the internal memory test. Under simulation, if the Provide simulation
Range: [0, 4294967295]
• end_address
The last address of the internal memory test. Under simulation, if the Provide simulation

Software detail
Range: [0, 4294967295]
• current_address
The current address of the internal memory test. Under simulation, if the Provide simulation
Range: [0, 4294967295]
• Sample time
Tick to enable inports sim_start_address, sim_end_address and sim_current_address.
6.1.71.7. Notes
None.
6.1.72. Platform code build date

(psc_PlatformBuildDate)
Get the build date for the ECU's platform code.

All targets

year
month
day
psc_PlatformBuildDate
Gets the build date for the ECU's platform code. The build date can be used to distinguish
between different versions of the platform code.

Software detail
6.1.72.4. Inports
• sim_year
Range: [1970, 3000]
• sim_month
Range: [1, 12]
• sim_day
Range: [1, 31]
6.1.72.5. Outports
• year
The year the platform code was built. Under simulation, if the Provide simulation inports
Range: [1970, 3000]
• month
The month of the year the platform code was built. Under simulation, if the Provide
Range: [1, 12]
• day
The day of the month the platform code was built. Under simulation, if the Provide
Range: [1, 31]

Software detail
6.1.72.7. Notes
None.
6.1.73. Platform code version (psc_PlatformVersion)

Get the version information for the ECU's platform code.

All targets

major_ver
minor_ver
sub_minor_ver
psc_PlatformVersion
Gets the version information for the ECU's platform code. The version number is composed
of three fields, major, minor and sub-minor, typically written as major.minor.sub-minor.
6.1.73.4. Inports
• sim_major_ver
Range: [0, 65535]
• sim_minor_ver
Range: [0, 65535]
Range: [0, 65535]
6.1.73.5. Outports
• major_ver
The major version number of the platform code. Under simulation, if the Provide simulation

Software detail
Range: [0, 65535]
• minor_ver
The minor version number of the platform code. Under simulation, if the Provide simulation
Range: [0, 65535]
• sub_minor_ver
The sub-minor version number of the platform code. Under simulation, if the Provide
Range: [0, 65535]
6.1.73.7. Notes
None.
6.1.74. Platform code part number

(psc_PlatformPartNumber)
Get the part number information for the ECU's platform code.

All targets

group_id
group_letter
part_id
issue
psc_PlatformPartNumber

Software detail
Gets the part number information for the ECU's platform code. The part number is composed
of four fields, group identification number, group identification letter, part identification number
and issue number, typically written as group_idgroup_letter-part_id Iss issue.
Example: 12T-168232 Iss 3 The part number can be used by the application for
diagnostics, tracking and identification.
6.1.74.4. Inports
• sim_group_id
Range: [0, 255]
Range: [0, 255]
• sim_part_id
Range: [0, 4294967295]
• sim_issue
Range: [0, 65535]
6.1.74.5. Outports
• group_id
The Group Identification number of the part number of the platform code. Under simulation,
Range: [0, 255]
• group_letter
The Group Identification letter of the part number of the platform code. The value
represents the ASCII code of the letter. Under simulation, if the Provide simulation inports
Range: [0, 255]
• part_id
The Part Identification number of the part number of the platform code. Under simulation,

Software detail
Range: [0, 4294967295]
• issue
The Issue number of the part number of the platform code. Under simulation, if the Provide
Range: [0, 65535]
6.1.74.7. Notes
None.
6.1.75. Processor loading (psc_CpuLoading)

Get the average processor loading for the running application.

All targets

loading
psc_CpuLoading
Determines the load on the main processor over the last 50 milliseconds and the maximum
load since the ECU was powered on (or last reset).
The load is calculated as the time used by any running task or interrupt over a 50 millisecond
window, expressed as a percentage. The calculation is an estimate as the 50 millisecond
window can extend over a wider duration if the processor is heavily loaded. As the 50
millisecond window does not synchronise with the model rate tasks, some aliasing can occur
as well (for instance, one 50 millisecond window may contain only a small percentage of work
done by the model, while another window may contain a higher percentage).

Software detail
There is no provision to change the window duration for the loading calculation.
6.1.75.4. Inports
• sim_loading
The outport loading is set to the value of this inport for simulation purposes.
Range: [0, 100] %
Value type: Real
6.1.75.5. Outports
• loading
The processor loading over the last 50 milliseconds or the maximum processor loading
seen since the ECU powered on (or reset). Under simulation, if the Provide simulation
inports parameter isn't ticked, the outport is set to the minimum of its range.
Range: [0, 100] %
Value type: Real
• Output mode
Whether the loading outport is set to the processor loading over 50 milliseconds, or the
maximum loading since power on (or reset).
Value type: List

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
Tick to enable inport sim_loading.

Software detail
Value type: Boolean

Calibratable: No
6.1.75.7. Notes
None.
6.1.76. PWM input measurement (pdx_PwmInput)

Measure a PWM signal and derive the frequency and duty cycle.

All targets

sim_timed_out timed_out
sim_timeout_count timeout_count
sim_duty_cycle duty_cycle
sim_freq Channel: DIN (pin XF1) freq

Time out:
Sample time:
sim_first_duration first_duration
sim_second_duration second_duration
sim_period_count period_count
sim_pin_state pin_state
pdx_PwmInput
The input block measures a PWM signal and performs a number of operations:
Frequency measurement
The block measures the time of each high and low (or low and high) pulse to determine
the frequency of the input signal.
First pulse Second pulse
time time
Input signal
active low if
invert is 0
Cycle time (1/Frequency)
First pulse Second pulse

time time
Input signal
active high if
invert is 1 Cycle time (1/Frequency)
Whether the block measures a low pulse followed by a high pulse, or a high pulse
followed by a low pulse is determined by the Invert block parameter.
Pulse measurement
The block measures the durations of the first and second pulses and derives the duty
cycle (first pulse time divided by the cycle time). Very small duty cycles (less than 1% or
greater than 99%) will not be measured accurately or at all.

Software detail
Period count
The block accumulates the count of complete periods modulo 16777216. The application
calculated difference of counts between iterations of the block could be used to diagnose
unexpected changes in the signal.
Input signal
Cycle/period count 0 1 2
Start of Start of Start of

period period period
Timeout check
The block measures the period duration and determines whether the signal has taken
longer than the Time out duration. The block accumulates the count of time out events,
and provides an outport to indicate if the signal is timed out when the block iterates.
Input signal
Time out count 0 1 2
Block iterates Signal Signal Block iterates

no timeout yet times out times out time out count is 2 and
recorded signal shown as not
currently timed out
6.1.76.4. Inports
• sim_timed_out
Only used in simulation. Place 1 here to simulate a time out, zero otherwise.
Range: 0 or 1
Value type: Boolean
• sim_timeout_count
Only used in simulation. Place a count here to simulate the count of time outs in the input
signal.
Range: [0, 16777215]
Value type: Integer
• sim_duty_cycle
Only used in simulation. Place a duty cycle here to simulate the duty cycle of the last
measured period.
Value type: Real

Software detail
• sim_freq
Only used in simulation. Place a frequency in Hz here to simulate the frequency of the
last measured period.
Value type: Real
• sim_first_duration
Only used in simulation. Place a duration in microseconds here to simulate the first pulse
from the last measured period.
Value type: Integer
• sim_second_duration
Only used in simulation. Place a duration in microseconds here to simulate the second
pulse from the last measured period.
Value type: Integer
• sim_period_count
Only used in simulation. Place a count here to simulate the count of periods seen in the
input signal.
Range: [0, 16777215]
Value type: Integer
• sim_pin_state
Only used in simulation. Place a zero or 1 here to simulate the pin state sample.
Range: 0 or 1
Value type: Boolean
6.1.76.5. Outports
• timed_out
1 if a complete period has not been measured for the timeout given by the mask parameter
Time out, zero otherwise.
Range: 0 or 1
Value type: Boolean
• timeout_count
A count of the time outs, wrapped modulo 16777216.
NOTE: timeout_count is not supported on M5xx targets
Range: [0, 16777215]
Value type: Integer

Software detail
• duty_cycle
Ratio of the first pulse duration to the period, or zero if no measurement has been taken.
Value type: Real

Calibratable: No
• freq
Frequency of the last measured period, or zero if no measurement has been taken. The
range of the frequency is limited in various ways.
• The range of the frequency that can be measured is limited by the filter circuitry of the
input pin.
• The lowest measurable frequency is limited by the filter circuitry and the size of the
corresponding processor timer for a channel. Any input frequency below the documented
limit, is reported as timed-out.
• The highest measurable frequency is limited by the filter circuitry and the resolution
of the corresponding processor timer for a channel. In general, the block reports the
frequency of the filtered signal and the input filtering forms an upper limit. However, as
the frequency increases, the resolution of measurement decreases.
Details of the input pin's filtering and processor timing can be found in an ECU's technical
specification.
Range: [0.5, ...] Hz
Value type: Real
• first_duration
The duration of the first pulse from the last measured period, or zero if no measurement
has been taken.
Value type: Integer
• second_duration
The duration of the second pulse from the last measured period, or zero if no measurement
has been taken.
Value type: Integer
• period_count
A count of the periods, wrapped modulo 16777216.
NOTE: period_count is not supported on M5xx targets
Range: [0, 16777215]
Value type: Integer

Calibratable: No
• pin_state

Software detail
Set to 1 if the input signal is high when the block iterates, set to zero if the input signal is
low when the block iterates.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• Channel
The input pin sourcing the signal to measure.
Value type: List

Calibratable: No
• Invert
Whether the first pulse in the period will be high (option unticked) or low (option ticked). This
option does not consider any inversion performed by the hardware, the user must do so.
Value type: Boolean

Calibratable: No
• Time out
The period of time after which if no complete period has been measured, the outport
timed_out is set to 1.
Range: [0.5, 10000] Hz
Value type: Real

• Sample time
Value type: Real

Calibratable: No

Software detail
If selected then create simulation inports for each of the outport message signals.
Value type: Boolean

Calibratable: No
6.1.76.7. Notes
None.
6.1.77. PWM output — fixed frequency

(pdx_PWMOutput)
Pulse the output channel pin at a fixed frequency and variable duty cycle.

All targets

duty_cycle Inversion: off
Default duty cycle:
Initial duty cycle: sim_duty_cycle
Frequency: Hz
Offset: ms
fault
[Min/max dutycycle]:
pdx_PWMOutput
The PWM output block causes the channel output pin to oscillate at a desired frequency and
duty cycle. The duty cycle is the High time divided by the Cycle time.
The actual state of the output pin is determined by the polarity of the pin. Some outputs
are low-side only, some are high-side only, and some are software selectable. For software
selectable pins, the polarity of the output can be selected by using the pdx_DigitalOutput
block with the DOT select-high-side signal for the associated pin. Refer to the technical
specification section for details on which pins support which polarities on each target.
Regardless of polarity, if the output is non-inverted, the output pin will be active during the
High time and the output pin will be off (high impedance) during the Low time. If the output
is inverted, the output will be active during the Low time and off during the High time.
High time
Output channel signal

Low time
High time
Inverted output channel signal
Low time

Software detail
This block calculates the output duty cycle as:
output duty cycle = Minimum duty cycle + (Maximum duty cycle - Minimum duty cycle) *
duty_cycle
If the Minimum duty cycle is 0 and the inport duty_cycle is 0, the output channel state is set
low and does not oscillate. When the Maximum duty cycle is 1 and the inport Duty_cycle is
1, the output channel state is set high and does not oscillate.
The block supports 0% and 100% duty cycles, where the output signal no longer pulses. A
0% duty cycle is defined as High time equals zero and 100% duty cycle is defined as Low
time equals zero.
The channel output pin state can be inverted in order to achieve the desired logical output
state.
The channel output can be offset from other PWM channels of the same frequency. The
{Offset} parameter is used to delay the start of the PWM cycle, so that the PWM pulse will
not occur at the same time as other PWM signals of the same frequency.
Other channel (with same

frequency) signal
Channel signal
Offset delay time
If the inport fault input is nonzero, then the output is set to the default duty cycle mask
parameter. The default duty cycle is never inverted and can only be set to zero or one so care
should be taken to chose the appropriate value to disable the output during a fault condition.
6.1.77.4. Inports
• duty_cycle
Ratio of the high time to the signal cycle time.
Value type: Real

Calibratable: No
• fault
Place a 1 here to force the block to use the default duty cycle for the output, 0 otherwise.
Range: 0 or 1
Value type: Boolean

Calibratable: No
6.1.77.5. Outports
• sim_duty_cycle
Only used in simulation. this outport is set to the requested duty cycle (i.e., duty_cycle
or the default duty cycle).

Software detail
Value type: Real

Calibratable: No
• Channel
The channel pin for this pwm output.
Value type: List

Calibratable: No
• Inversion
Inverts the mapping of the input value to the channel pin. If inversion is ticked then a logical
NOT operation is applied to the output state.
Value type: Boolean

Calibratable: No
• Default duty cycle
This value is used if fault is active. The value is mapped directly to the output channel
and is never inverted. Care should be taken to choose the appropriate value to drive the
output off.
Range: 0 or 1 duty-cycle
Value type: Real

The duty cycle that is output before the block has first been executed. This value is used
in a similar way to Default duty cycle in that it is never inverted, however it can be set
anywhere in the range 0 to 1.

Software detail
Value type: Real

• Frequency
The frequency of the pwm signal.
Range: [0.5, 10000] Hz
Value type: Real

• Offset
The desired phase offset, in milliseconds, of the PWM output, relative to other PWM output
channels that have been configured with the same frequency.
Range: [0, 2000] ms (for the M250, M460 targets)
Value type: Real

• Minimum duty cycle
Must be in the range 0 to (Maximum duty cycle - 0.1).
Value type: Real

• Maximum duty cycle
Must be in the range (Minimum duty cycle + 0.1) to 1.0.
Value type: Real

Tick to enable outport sim_duty_cycle.
Value type: Boolean

Calibratable: No
6.1.77.7. Notes
• The resolution of the PWM channels depends on the output device (specified in the
hardware target tables in Section A.1, “ECU hardware reference documentation”). Some
channels have better resolution that others.
• Some of the PWM output channels do not produce an accurate wave form when the duty
cycle is either very small (e.g., 0.5%) or very large (e.g., 99.5%). All PWM output channels
cope with 0% and 100% duty cycles correctly.
For the M250 target specifically, in order to avoid shoot-through and damage to the ECU
when the mode switches, a 100us dead-time is inserted in the PWM signal for one task

Software detail
cycle at the beginning of mode-transition. Additionally, this dead-time insertion will only
occur if the duty cycle that is commanded has a low time of less than 100us. For this
reason, it will not be possible to command a 100% duty cycle during mode-transition for
one task period.
6.1.78. PWM output — variable frequency

(pdx_PWMVariableFrequencyOutput)
Pulse the output channel pin at a variable frequency and duty cycle.

All targets

duty_cycle Channel: DOT (pin XD4)
Inversion: off sim_duty_cycle
Default duty cycle:
frequency Initial duty cycle:
Initial frequency: Hz
Offset: ms
sim_frequency
fault [Min/max dutycycle]:
pdx_PWMVariableFrequencyOutput
The PWM output block causes the channel output pin to oscillate at a desired frequency and
duty cycle. A duty cycle is the High time divided by the Cycle time.
High time
Output channel signal

Low time
High time
Inverted output channel signal
Low time
This block calculates the output duty cycle as:
output duty cycle = Minimum duty cycle + (Maximum duty cycle - Minimum duty cycle) *
duty_cycle
If the Minimum duty cycle is 0 and the inport duty_cycle is 0, the output channel state is set
low and does not oscillate. When the Maximum duty cycle is 1 and the inport Duty_cycle is
1, the output channel state is set high and does not oscillate.
The block supports 0% and 100% duty cycles, where the output signal no longer pulses. A
0% duty cycle is defined as High time equals zero and 100% duty cycle is defined as Low
time equals zero.

Software detail
The channel output pin state can be inverted in order to achieve the desired logical output
state.
If the inport fault input is nonzero, then the output is set to the default duty cycle mask
parameter (the default duty cycle is never inverted).
6.1.78.4. Inports
• duty_cycle
Ratio of the high time to the signal cycle time.
Value type: Real
• frequency
Frequency of the signal.
Range: [0.5, 10000] Hz
Value type: Real
• fault
Place a 1 here to force the block to use the default frequency and duty cycle for the output,
0 otherwise.
Range: 0 or 1
Value type: Real
6.1.78.5. Outports
• sim_duty_cycle
Only used in simulation. this outport is set to the processed duty cycle (i.e., duty_cycle or
Initial duty cycle).
Value type: Real
• sim_frequency
Only used in simulation. This outport is set to the processed frequency.
Value type: Real

Software detail
• Channel
The channel pin for this pwm output.
Value type: List

Calibratable: No
• Inversion
Inverts the mapping of the input value to the channel pin. If inversion is set to 1 then a
logical NOT operation is applied to the output state.
Value type: Boolean

Calibratable: No
• Default duty cycle
This is the duty cycle of the channel when inport fault is set. The duty cycle is mapped
directly to the output channel and is not inverted by parameter Inversion.
Value type: Real

The duty cycle of the channel signal before the block has first been executed. This duty
cycle is inverted if the mask parameter Inversion is set to 1.
Value type: Real

• Initial frequency

Software detail
The frequency of the PWM signal before the block first iterates.
Range: [0.5, 10000] Hz
Value type: Real

• Offset
The desired phase offset, in milliseconds, of the PWM output, relative to other PWM output
channels that have been configured with the same frequency.
Range: [0, 2000] ms (for the M250, M460 targets)
Value type: Real

• Minimum duty cycle
Must be in the range 0 to (Maximum duty cycle - 0.1).
Value type: Real

• Maximum duty cycle
Must be in the range (Minimum duty cycle + 0.1) to 1.0.
Value type: Real

Tick to enable outport sim_duty_cycle and sim_frequency.
Value type: Boolean

Calibratable: No
6.1.78.7. Notes
• The resolution of the PWM channels depends on the output device (specified in the
hardware target tables in Section A.1, “ECU hardware reference documentation”). Some
channels have better resolution that others, notably the MIOS channels.
• Some of the PWM output channels do not produce an accurate wave form when the duty
cycle is either very small (e.g., 0.5%) or very large (e.g., 99.5%). All PWM output channels
cope with 0% and 100% duty cycles correctly.
For the M250 target specifically, in order to avoid shoot-through and damage to the ECU
when the mode switches, a 100us dead-time is inserted in the PWM signal for one task
cycle at the beginning of mode-transition. Additionally, this dead-time insertion will only
occur if the duty cycle that is commanded has a low time of less than 100us. For this
reason, it will not be possible to command a 100% duty cycle during mode-transition for
one task period.

Software detail
6.1.79. Range check (put_RangeCheck)

Range check the input and provide fault information from the range check.

All targets

u
max_range_fault
max_value
min_range_fault
min_value
put_RangeCheck
6.1.79.4. Inports
• u
Value to range check.
• max_value
A value of u greater than this causes the outport max_range_fault to become set.
• min_value
A value of u less than this causes the outport min_range_fault to become set.
6.1.79.5. Outports
• max_range_fault
Set to 1 if inport u is greater than inport max_value, otherwise set to 0.
• min_range_fault
Set to 1 if inport u is less than inport max_value, otherwise set to 0.
6.1.79.7. Notes
None.
6.1.80. Reset module (put_Reset)

Provide reset information and a mechanism to reset the ECU.

Software detail

All targets

power_reset
watchdog_reset
access_reset
fp_reset
Module
force_reset
Reset mem_reset
forced_reset
unknown_reset
boot_duration
put_Reset
Allow the user to force the module to reset. Provide information about the previous reset
event including how long the module took to start iterating the model.
6.1.80.4. Inports
• force_reset
Set to 1 to cause the ECU to reset, 0 otherwise. The reset is occurs as soon as the block
iterates and causes the ECU to boot as if from power up. If the FEPS module pin is held
high, the ECU will start reprogramming mode and not start the model.
Range: 0 or 1
6.1.80.5. Outports
• power_reset
Set to 1 if the last reset event was from a power up event, 0 otherwise.
• watchdog_reset
Set to 1 if the last reset event was due to the ECU's processor watchdog, 0 otherwise.
• access_reset
Set to 1 if the last reset event was due to incorrect software in the model or platform
accessing a memory area in the controller that did not exist, 0 otherwise.
• fp_reset
Set to 1 if the last reset event was due to incorrect software in the model that attempted
to manipulate a floating point value in a way the ECU's processor determined as invalid,
0 otherwise.
• mem_reset
Set to 1 if the last reset event was due to an unrecoverable corruption of internal memory,
0 otherwise. The cause of a reset that occurs as a result of memory corruption may not
always be identified by software. If the cause cannot be identified by the platform software,
then the reset will be reported by the unknown_reset outport.
• forced_reset

Software detail
Set to 1 if the last reset event was due to a forced model reset, 0 otherwise.
• unknown_reset
Set to 1 if the last reset event could not be determined, 0 otherwise.
• boot_duration
A rough indication of how long the module took to boot (i.e., from processor start to starting
the first model iteration) in seconds. Only if the version of boot is sufficient (version 1.0.7
or greater) will this outport contain a value. If the boot version is not sufficient, the outport
is set to zero.
Note
The duration from power up to processor start is not part of boot_duration. It varies
based on the environmental conditions but is usually around 40ms to 80ms in
duration. The boot duration will increase as the calibration size increases.
6.1.80.7. Notes
• The block replaces the use of the automatic ASAP2 entry mpl_rsr. mpl_rsr is no longer
available.
6.1.81. Reset count — stable (psc_ResetCount)

Get the free running count of the number of powered resets.

All targets

reset_count
psc_ResetCount
Get the free running count of the number of powered resets since power on. The count is
reset upon power cycle.

Software detail
6.1.81.4. Inports
• sim_count
Only used under simulation and when the parameter Provide simulation inputs is ticked.
The outport reset_count is set to the value of this inport for simulation purposes.
Range: 0 to 4294967295.
6.1.81.5. Outports
• reset_count
The number of resets since the ECU was powered on. Under simulation, if the Provide
simulation inputs parameter isn't ticked, the outport is set to the minimum of its range.
Range: 0 to 4294967295.
• access_reset
Set to 1 if the last reset event was due to incorrect software in the model or platform
accessing a memory area in the controller that did not exist, 0 otherwise.
• fp_reset
Set to 1 if the last reset event was due to incorrect software in the model that attempted
to manipulate a floating point value in a way the ECU's processor determined as invalid,
0 otherwise.
• mem_reset
Set to 1 if the last reset event was due to an unrecoverable corruption of internal memory,
0 otherwise.
• forced_reset
Set to 1 if the last reset event was due to a forced model reset, 0 otherwise.
• unknown_reset
Set to 1 if the last reset event could not be determined, 0 otherwise.
• boot_duration
A rough indication of how long the module took to boot (i.e., from processor start to starting
the first model iteration) in seconds. Only if the version of boot is sufficient (version 1.0.7
or greater) will this outport contain a value. If the boot version is not sufficient, the outport
is set to zero.
Note
The duration from power up to processor start is not part of boot_duration. It varies
based on the environmental conditions but is usually around 40ms to 80ms in
duration. The boot duration will increase as the calibration size increases.

Software detail
• Sample time
Value type: Real

Calibratable: No
Tick to enable inport sim_count.
6.1.81.7. Notes
None.
6.1.82. Reset count — unstable

(psc_UnstableResetCount)
Get the count of the number of unstable powered resets.

All targets

unstable_reset_count
psc_UnstableResetCount
Get the limited counter of the number of powered resets that occur within 60 seconds of
initialisation. It is cleared once the application been running for at least 60 seconds. If the
unstable reset counter reaches a threshold defined in the platform, then the module will be
forced in to reprogramming mode.
6.1.82.4. Inports
• sim_count

Software detail
The outport unstable_reset_count is set to the value of this inport for simulation purposes.
Range: 0 to 4.
6.1.82.5. Outports
• unstable_reset_count
The number of unstable resets since the ECU was powered on. Under simulation, if the
Provide simulation inputs parameter isn't ticked, the outport is set to the minimum of its
range.
Range: 0 to 4.
• Sample time
Value type: Real

Calibratable: No
6.1.82.7. Notes
None.
6.1.83. Reprogramming code build date

(psc_PrgBuildDate)
Get the build date for the ECU's reprogramming code.

All targets


Software detail
year
month
day
psc_PrgBuildDate
Gets the build date for the ECU's reprogramming code. The build date can be used to
distinguish between different versions of the reprogramming code.
6.1.83.4. Inports
• sim_year
Range: [1970, 3000]
• sim_month
Range: [1, 12]
• sim_day
Range: [1, 31]
6.1.83.5. Outports
• year
The year the reprogramming code was built. Under simulation, if the Provide simulation
Range: [1970, 3000]
• month
The month of the year the reprogramming code was built. Under simulation, if the Provide
Range: [1, 12]
• day
The day of the month the reprogramming code was built. Under simulation, if the Provide
Range: [1, 31]

Software detail
6.1.83.7. Notes
None.
6.1.84. Reprogramming code version (psc_PrgVersion)

Get the version information for the ECU's reprogramming code.

All targets

major_ver
minor_ver
sub_minor_ver
psc_PrgVersion
Gets the version information for the ECU's reprogramming code. The version number
is composed of three fields, major, minor and sub-minor, typically written as
major.minor.sub-minor. The version can be used by the application for version control
or diagnostics.
6.1.84.4. Inports
• sim_major_ver
Range: [0, 65535]
• sim_minor_ver
Range: [0, 65535]

Software detail
Range: [0, 65535]
6.1.84.5. Outports
• major_ver
The major version number of the reprogramming code. Under simulation, if the Provide
Range: [0, 65535]
• minor_ver
The minor version number of the reprogramming code. Under simulation, if the Provide
Range: [0, 65535]
• sub_minor_ver
The sub-minor version number of the reprogramming code. Under simulation, if the Provide
Range: [0, 65535]
6.1.84.7. Notes
None.
6.1.85. Reprogramming code part number

(psc_PrgPartNumber)
Get the part number information for the ECU's reprogramming code.

All targets

Software detail

group_id
group_letter
part_id
issue
psc_PrgPartNumber
Gets the part number information for the ECU's reprogramming code. The part number
is composed of four fields: group identification number, group identification letter, part
identification number and issue number, typically written as group_idgroup_letter-
part_id Iss issue. Example: 12T-168232 Iss 3 The part number can be used by
the application for diagnostics, tracking and identification.
6.1.85.4. Inports
• sim_group_id
Range: [0, 255]
Range: [0, 255]
• sim_part_id
Range: [0, 4294967295]
• sim_issue
Range: [0, 65535]
6.1.85.5. Outports
• group_id
The Group Identification number of the part number of the reprogramming code. Under
simulation, if the Provide simulation inports parameter isn't ticked, the outport is set to the
minimum of its range. The signal attached to the outport must be set as ExportedGlobal.
Range: [0, 255]
• group_letter
The Group Identification letter of the part number of the reprogramming code. The value
represents the ASCII code of the letter. Under simulation, if the Provide simulation inports

Software detail
Range: [0, 255]
• part_id
The Part Identification number of the part number of the reprogramming code. Under
simulation, if the Provide simulation inports parameter isn't ticked, the outport is set to the
minimum of its range. The signal attached to the outport must be set as ExportedGlobal.
Range: [0, 4294967295]
• issue
The Issue number of the part number of the reprogramming code. Under simulation, if the
Provide simulation inports parameter isn't ticked, the outport is set to the minimum of its
range. The signal attached to the outport must be set as ExportedGlobal.
Range: [0, 65535]
6.1.85.7. Notes
None.
6.1.86. Retrieve registry key (preg_RetrieveKey)

Given a key, search the registry for the corresponding data.

All targets

available
Key:
ECU upper-word
serial number
upper_serial_num
preg_RetrieveKey

Software detail
Given a key, selected through the Registry key mask parameter, the block searches through
the ECU's registry to retrieve the key's data. If the key was found then the available outport
is set to 1 and the remaing outports set to the key's data. If the key was not found then the
available outport is set to zero.
Note
Not all ECUs are programmed with registry data. Older ECUs, do not contain registry
data.
The registry contains a checksum. Failure of checksum verification results in the

registry being unavailable.
6.1.86.4. Inports
• sim_available
The outport available is set to the value of this inport for simulation purposes.
Range: 0 or 1
Value type: Boolean
• sim_upper_serial
The outport upper_serial_num is set to the value of this inport for simulation purposes.
Range: [0, 4294967295]
Value type: Integer
• sim_lower_serial
The outport lower_serial_num is set to the value of this inport for simulation purposes.
Range: [0, 4294967295]
Value type: Integer
• sim_shift
The outport shift is set to the value of this inport for simulation purposes.
Range: [1, 3]
Value type: Integer
• sim_day
Range: [1, 31]
Value type: Integer
• sim_month

Software detail
Range: [1, 12]
Value type: Integer
• sim_year
Range: [1970, 3000]
Value type: Integer
• sim_prefix
The outport prefix is set to the value of this inport for simulation purposes.
Range: [0, 99]
Value type: Integer
• sim_id
The outport id is set to the value of this inport for simulation purposes.
Range: ['A', 'Z'] ASCII character
Value type: Integer
• sim_part
The outport part is set to the value of this inport for simulation purposes.
Range: [0, 999999]
Value type: Integer
• sim_issue
Range: [0, 255]
Value type: Integer
• sim_mod
The outport mod is set to the value of this inport for simulation purposes.
Range: [0, 255]
Value type: Integer
• sim_fpart_a

Software detail
The outports fpart_a are set to the value of these inports for simulation purposes.
Range: [0, 65535]
Value type: Integer
• sim_fpart_b
The outports fpart_b are set to the value of these inports for simulation purposes.
Range: [0, 65535]
Value type: Integer
• sim_fid_a
The outport fid_a is set to the value of this inport for simulation purposes.
Range: ['A', 'Z'] ASCII characters
Value type: Integer
• sim_fid_b
The outport fid_b is set to the value of this inport for simulation purposes.
Value type: Integer
• sim_build_type_a
The outport build_type_a is set to the value of this inport for simulation purposes.
Value type: Integer
• sim_build_type_b
The outport build_type_b is set to the value of this inport for simulation purposes.
Value type: Integer
6.1.86.5. Outports
• available
Whether the key could be retrieved or not. Under simulation, if the Provide simulation
inports parameter isn't ticked, the outport is set to zero. The signal attached to the outport
Range: 0 or 1

Software detail
Value type: Boolean
• upper_serial_num
The most significant 32 bits of the ECU's serial number. Outport available if the Registry key
mask parameter is set to ECU upper-word serial number. Under simulation, if the Provide
simulation inports parameter isn't ticked, the outport is set to zero. The signal attached to
the outport must be set as ExportedGlobal.
Range: [0, 4294967295]
Value type: Integer
• lower_serial_num
The least significant 32 bits of the ECU's serial number. Outport available if the Registry key
mask parameter is set to ECU lower-word serial number. Under simulation, if the Provide
Range: [0, 4294967295]
Value type: Integer
• shift
The team shift at the point of manufacture. Outport available if the Registry key mask
parameter is set to ECU date of manufacture. Under simulation, if the Provide simulation
Range: [1, 3]
Value type: Integer
• day
The day of the month at the point of manufacture. Outport available if the Registry key mask
parameter is set to ECU date of manufacture. Under simulation, if the Provide simulation
Range: [1, 31]
Value type: Integer
• month
The month of the year at the point of manufacture. Outport available if the Registry key
mask parameter is set to ECU date of manufacture. Under simulation, if the Provide
Range: [1, 12]
Value type: Integer
• year
The year at the point of manufacture. Outport available if the Registry key mask parameter
is set to ECU date of manufacture. Under simulation, if the Provide simulation inports

Software detail
parameter isn't ticked, the outport is set to zero. The signal attached to the outport must
be set as ExportedGlobal.
Range: [1970, 3000]
Value type: Integer
• prefix
The prefix of the engineering part number, e.g., 01 from 01T-068165. Outport available if
the Registry key mask parameter is set to ECU date of manufacture. Under simulation, if
the Provide simulation inports parameter isn't ticked, the outport is set to zero. The signal
Range: [0, 99]
Value type: Integer
• id
The letter of the engineering part number, e.g., T from 01T-068165. Outport available if
the Registry key mask parameter is set to ECU date of manufacture. Under simulation, if
the Provide simulation inports parameter isn't ticked, the outport is set to zero. The signal
Value type: Integer
• part
The remainder of the engineering part number, e.g., 068165 from 01T-068165. Outport
available if the Registry key mask parameter is set to ECU date of manufacture. Under
simulation, if the Provide simulation inports parameter isn't ticked, the outport is set to zero.
The signal attached to the outport must be set as ExportedGlobal.
Range: [0, 999999]
Value type: Integer
• issue
The ECU's PCB issue number, representing the PCB design. Outport available if the
Registry key mask parameter is set to ECU PCB issue and modification number. Under
Range: [0, 255]
Value type: Integer
• mod
The ECU's PCB modification number, representing hand modifications to the PCB to match
the PCB design intent. Outport available if the Registry key mask parameter is set to ECU
PCB issue and modification number. Under simulation, if the Provide simulation inports
parameter isn't ticked, the outport is set to zero. The signal attached to the outport must
be set as ExportedGlobal.
Range: [0, 255]
Value type: Integer

Software detail
• fpart_a
The pre numerical part to the factory part number, which represents a detailed build
specification for the ECU. Outport available if the Registry key mask parameter is set to
ECU factory part number. Under simulation, if the Provide simulation inports parameter
isn't ticked, the outport is set to zero. The signal attached to the outport must be set as
ExportedGlobal.
Range: [0, 65535]
Value type: Integer
• fpart_b
The post numerical part to the factory part number, which represents a detailed build
specification for the ECU. Outport available if the Registry key mask parameter is set to
ECU factory part number. Under simulation, if the Provide simulation inports parameter
isn't ticked, the outport is set to zero. The signal attached to the outport must be set as
ExportedGlobal.
Range: [0, 65535]
Value type: Integer
• fid_a
The first letter identifier that separates the pre and post factory part number. Outport
available if the Registry key mask parameter is set to ECU factory part number. Under
Value type: Integer
• fid_b
The second letter identifier that separates the pre and post factory part number. Outport
available if the Registry key mask parameter is set to ECU factory part number. Under
Value type: Integer
• build_type_a
The first letter of a two letter identifier representing the factory part number build type.
Outport available if the Registry key mask parameter is set to ECU factory part number.
Under simulation, if the Provide simulation inports parameter isn't ticked, the outport is set
to zero. The signal attached to the outport must be set as ExportedGlobal.
Value type: Integer
• build_type_b
The second letter of a two letter identifier representing the factory part number build type.
Outport available if the Registry key mask parameter is set to ECU factory part number.

Software detail
Under simulation, if the Provide simulation inports parameter isn't ticked, the outport is set
to zero. The signal attached to the outport must be set as ExportedGlobal.
Value type: Integer
• Registry key
A drop down to specify the registry key to retrieve.
ECU upper-word serial number

The upper-word serial number is a 32-bit positive integer. Serial
numbers across different families of ECUs do not overlap.
ECU lower-word serial number

The lower-word serial number is a 32-bit positive integer. Serial
numbers across different families of ECUs do not overlap.
ECU date of manufacture

The date is composed as (shift) dd:mm:yy, where the shift identifies
the team involved in the manufacturing process.
ECU engineering part number

The engineering part number matches the pattern: prefix letter
engineering-part-number. For instance, the engineering part number
assigned to the M250-000 is 01T068165, where 01 represents the
prefix, T represents the letter and 068165 represents the engineering
part number.
ECU PCB issue and modification number

The issue level represents a specific design of PCB. Changes to the
issue level may have an effect on the platform library.
The modification level represents what changes were performed to

the PCB after manufacturing to correct issue level design mistakes.
Changes to the modification level should not have an effect on the
platform library.
ECU factory part number

The identifier for the build specification used to create the ECU,
matching the pattern value letter value, e.g., 450FT1024.

Software detail
ECU factory part number build type

An indication of the build type, usually appended to the factory
part number, e.g., 450FT1024-E2, where E2 indicates second spec.
engineering build.
Value type: List

Calibratable: No
Tick to enable simulation inports.
Value type: Boolean

Calibratable: No
6.1.86.7. Notes
None.
6.1.87. Require platform version

(put_RequirePlatformVersion)
Stop a model build if the wrong version of the OpenECU platform is selected.

All targets

Requires version:
put_RequirePlatformVersion
Restrict the versions of OpenECU platform that a model can be build against. This block can
restrict the platform to a specific version, before or after a specific version, or to be between
two versions.
More than one put_RequirePlatformVersion block may be added to a model to refine the
restriction conditions.
If there are no put_RequirePlatformVersion blocks in a model, the model may be built against
any version of platform (whether the build completes successfully will depend on which
version of the platform the model was created with — e.g., a model created with features
from a newer version of the platform may not build using an older version of the platform).
Note
In order for this block to function fully, the model postloadfcn property must be set
according to the section Model pre-load and post-load hooks.
6.1.87.4. Inports
None.

Software detail
6.1.87.5. Outports
None.
• Check
A drop-down of methods for restricting the version of platform to use when building.
Value type: List

Calibratable: No
• Version
The literal text of the version number (e.g., 1.5.0) that the platform must equal in order
to be able to build the model. Only available when the Check parameter is set to Single
version.
Value type: Text

Calibratable: No
• Before version
The literal text of the version number (e.g., 1.5.0) that the platform come before (not
inclusive) in order to be able to build the model. Only available when the Check parameter
is set to Before version.
Value type: Text

Calibratable: No
• After version
The literal text of the version number (e.g., 1.5.0) that the platform come after (not
inclusive) in order to be able to build the model. Only available when the Check parameter
is set to After version.
Value type: Text

Calibratable: No
• From version
The literal text of the version number (e.g., 1.5.0) that the platform come before (inclusive)
in order to be able to build the model. Only available when the Check parameter is set to
Range of versions.
Value type: Text

Calibratable: No

Software detail
• To version
The literal text of the version number (e.g., 1.5.0) that the platform come after (inclusive)
in order to be able to build the model. Only available when the Check parameter is set to
Range of versions.
Value type: Text

Calibratable: No
6.1.87.7. Notes
None.
6.1.88. Show Simulink's sample time colours

(prtw_ShowSampleTimeColours)
Turn on Simulink's sample time colours.

All targets

Double click to show
sample time colours
A utility block to turn on Simulink's sample time colouring. Double click on the block to turn
on sample time colours.
6.1.88.4. Inports
None.
6.1.88.5. Outports
None.

6.1.88.7. Notes
None.
6.1.89. Secondary micro receive message

(psmc_ReceiveMessage)
Read user application message from secondary micro

All targets

Software detail

rx_flag
Expected Msg Length: 15

actual_length
Sample time: 0.01
data
psmc_ReceiveMessage
6.1.89.4. Inports
None.
6.1.89.5. Outports
• rx_flag
Range: 0 or 1
Value type: Boolean

Calibratable: No
• actual_length
Actual length of message read by block. if less than Expected message length, additional
bytes of data will be 0.
Range: [0, 251]
Value type: Integer
• data
Array of bytes of length Expected message length of the data that was read.
Range: [0, 255]
Value type: Integer

Software detail
• Expected message length
The expected length in bytes of the data in the message to be read.
Range: [0, 251]
Value type: Integer

Calibratable: No
6.1.89.7. Notes
None.
6.1.90. Secondary micro transmit message

(psmc_TransmitMessage)
Write user application message to secondary micro

All targets

tx_trigger
Message Length: 15
data
psmc_TransmitMessage
6.1.90.4. Inports
• tx_trigger
Set to 1 to trigger transmit of user application message to secondary microcontroller.
Range: 0 or 1
Value type: Boolean
• data
Array of bytes of length Message length of the data to transmit.
Range: [0, 255]
Value type: Integer
6.1.90.5. Outports
None.

Software detail
• Message length
the length in bytes of the data in the message to be sent.
Range: [0, 251]
Value type: Integer

Calibratable: No
6.1.90.7. Notes
None.
6.1.91. Signal gap detection (put_SignalGapDetection)

Determine discontinuities in CAN message reception.

All targets

u
Start up timeout periods: 1
u_invalid_code
Loss of communication periods: 1
start_count
put_SignalGapDetection
Determine whether the application:
• is receiving a CAN message regularly (code 8); or
• has yet to receive a CAN message (code 5); or
• has not received a CAN message within the required start-up period (code 6); or
• has stopped receiving the CAN message (code 7).
The block will start monitoring the status of inport u (whether a CAN message was received
this model iteration or not) when the inport start_count is 1. For as long inport u is zero (no
message received), the block will output code 5.

Software detail
If the block observes that it has not received a single CAN message within the required
module start-up period, the block will output code 6.
If the application has received at least a single CAN message within the required start-
up period, but has then subsequently not received a new message for the pre-defined
consecutive number of missed message periods, the block will output code 7.
For as long as the block is receiving CAN messages, the block will output code 8.
These output codes can be fed into the Section 6.1.93, “Signal validate (put_SignalValidate)”
block to provide further fault detection.
6.1.91.4. Inports
• u
Set to 1 if the message was received this iteration, 0 otherwise.
• start_count
Set to 1 to cause the block to monitor the u inport, 0 otherwise.
6.1.91.5. Outports
• u_invalid_code
Result of monitoring when the CAN message was received over time (inport u). See the
table in the notes section for a complete list of the codes.
Range: [5, 8]
• Number of message periods for module timeout at start-up
The number of message periods the block will wait after inport start_count has been set
to 1, before reporting that it has not received a CAN message within this required period.
Range: [0, 255] periods
• Number of message periods for module timeout
The number of message periods the block will wait, with inport u set to 0, before reporting
that it has stopped receiving the CAN message.
Range: [0, 255] periods

Software detail
6.1.91.7. Notes
• The possible error codes (see also Table 6.7, “CAN signal validate error codes.”) are
enumerated as:
Table 6.5. CAN signal gap error codes

Invalid code Description
5 The application has yet to receive the first CAN message (of a
particular ID).
6 The application has not received a single CAN message (of a particular
ID) within the defined start-up timeout period.
7 The application has received at least one message (of a particular
ID) within the start-up timeout period, but has then subsequently not
received a new message for a pre-defined number of message periods.
8 The put_SignalGapDetection block is receiving the CAN message
within timeout periods.
6.1.92. Signal prepare — deprecated

(put_SignalPrepare)
Prepare signals for CAN transmission.

All targets

u Error Value: []
Unavailable Value: []
Minimum Value: []
Maximum Value: [] y
Scale Factor: []
Offset Value: []
u_invalid_code Output Type: (int8)
put_SignalPrepare
The signal prepare block converts from engineering value to integer form. The input value is
checked against minimum and maximum parameters and clipping may occur when the result
is copied into one of the possible integer data types of the output port.
It is common to find a CAN specification that designates values for CAN signals as in error
or unavailable. Although not always the case, typically the highest values are used (e.g., in
an unsigned 8 bit quantity that can range from 0 to 255, typically 254 and 255 signify that the
signal is unavailable or in error). This block directly supports this concept.
Minimum and maximum limits (in engineering units) are also defined for each CAN signal, and
an engineering value outside this range is set to a value which indicates error to the receiving
CAN node. This block directly supports checking for out of range engineering values.
And while many quantities are transmitted in integer format that corresponds to the value in
engineering units, many other fields have scale and offset values. This block directly supports
converting the engineering value to a scaled integer value as:
can_signal_value y = (u - Offset value) / Scale factor

Software detail
6.1.92.4. Inports
• u
Value to convert from the application. The blocks accepts a data type of uint8, int32
and real_T.
• u_invalid_code
Defines the validity of the input u. See Table 6.6, “CAN signal prepare invalid codes.” for
a complete list of codes.
Range: [0, 8]
6.1.92.5. Outports
• y
The value of u after being prepared for CAN transmission.
• Error value
The value which is to be output on y if the inport u_invalid_code is equal to 1.
Range: [-2147483647, 2147483647]
• Unavailable value
The value which is to be output on y if the inport u_invalid_code is equal to 2, 5, 6, 7 or 8.
Range: [-2147483647, 2147483647]

Software detail
• Minimum value
The smallest value of u that is valid. The data type of this parameter is the same as the
input u.
• Maximum value
The largest value of u that is valid, The data type of this parameter is the same as the
input u.
• Scale factor
Conversion factor applied to u to convert it from engineering units to an integer form. A

value of 1 should be used if no scaling is required.
• Offset value
Offset factor applied to u to convert it from engineering units to an integer form. The data
type is in engineering units. A value of 0 should be used if there is no offset.
• Output type
A drop down of possible types for inport u.
6.1.92.7. Notes
• The possible error codes are enumerated as:
Table 6.6. CAN signal prepare invalid codes.

Error code Description
0, 3, 4 The block implements both conversion of the input engineering value
to a scaled integer and clipping of the result, according to mask
parameters setting.
1 The output value is forced to be equal to the mask error value.
2 or >4 The output value is forced to be equal to the mask unavailable value.
This block became deprecated in version 3.0.0 and will be removed in a future version of
the software.
6.1.93. Signal validate (put_SignalValidate)

Validate and scale received CAN signal values.

All targets

y
u Error Value: []
Unavailable Value: []
Minimum Value: []
Maximum Value: []
Default Value: [] invalid_flag
Scale Factor: []
Offset Value: []
Error Delay Cycles: []
u_invalid_code Output Type: (double)
y_invalid_code
put_SignalValidate

Software detail
The signal validate block performs validation checks on a supplied input value (usually from
a received CAN message). It checks for the input data being unavailable or in error, applies
a linear transfer function, performs clipping, then casts the output to a user selected type.
It is common to find a CAN specification that designates values for CAN signals as in error
or unavailable. Although not always the case, typically the highest values are used (e.g., in
an unsigned 8 bit quantity that can range from 0 to 255, typically 254 and 255 signify that the
signal is unavailable or in error). This block directly supports this concept.
Minimum and maximum limits (in engineering units) are also defined for each CAN signal,
and received data outside those limits typically indicates an error (in transmitting module
behaviour, or CAN communications). This block directly supports checking for out of range
engineering values.
And while many quantities are transmitted in integer format that corresponds to the value in
engineering units, many other fields have scale and offset values. This block directly supports
converting the scaled integer value to an engineering value as:
engineering_value = (Scale factor * u) + Offset value
When an error is detected, if the block has previously output a valid value, it will continue
to output the previous valid value while the error condition persists for a number of delayed
cycles, after which, if the error persists, the default value is output.
6.1.93.4. Inports
• u
The raw input value requiring validation.
• u_invalid_code
A code that defines the status of the inport u. The block acts on an error code of 5, 6, 7,
or 8 (see Table 6.7, “CAN signal validate error codes.”).
Range: [0, 8]
6.1.93.5. Outports
• y
The clean output value after validation.
• invalid_flag
0 if the outport y_invalid_code is 0; 1 otherwise.
Range: 0 or 1
• y_invalid_code
A value indicating the manner in which the input is invalid (see below for a table of error
codes).
Range: [0, 8]

Software detail
• Error value
The value which indicates the input is in error. It is internally converted to int32 data type.
Range: [-2147483647, 2147483647]
• Unavailable value
The value which indicates the input is unavailable. It is internally converted to int32 data
type.
Range: [-2147483647, 2147483647]
• Minimum value
The smallest post-scaling value that is valid.
• Maximum value
The largest post-scaling value that is valid.
• Default value
The value to be substituted if necessary.
• Scale factor

Software detail
Conversion factor from integer to engineering units. A value of 1 should be used if no

scaling is required.
• Offset value
Offset value to convert from integer to engineering units, in engineering units. A value of
0 should be used if no offset is required.
• Error delay cycles
An integer number of block executions; the number of cycles before any error condition
is output. May be zero, in which case error conditions are output immediately the block
executes.
Range: [0, 65535]
• Output type
A drop down of possible types for outport y.
6.1.93.7. Notes
• The possible error codes are enumerated as:
Table 6.7. CAN signal validate error codes.

u_invalid_code y_invalid_code Description
8 0 The block
implements
both
conversion
of the input
scaled
integer
value to an
engineering
value and
clipping of
the result,
according
to the mask
parameters
setting.
8 4 The block
implements
conversion
of the input
scaled
integer
value to an
engineering
value. The
output
has been
clipped
to the
maximum
value

Software detail

detailed in
the block
mask.
8 3 The block
implements
conversion
of the input
scaled
integer
value to an
engineering
value. The
output
has been
clipped
to the
minimum
value
detailed in
the block
mask.
8 2 The output
value is set
to mask
default
value
because the
input value
is equal
to mask
unavailable
value.
8 1 The output
value is set
to mask
default
value
because the
input value
is equal to
mask error
value.
5, 6, 7 equal to u_invalid_code The output
value is set
to mask
default
value
because of
the input
invalid
code.
<5 or >8 2 The output
value is set
to mask

Software detail

default
value
because of
the input
invalid
code.
6.1.94. Slew rate check (put_SlewRateCheck)

Set the outport slew_fault if the rate of change of inport u is too great.

All targets

u slew_fault
put_SlewRateCheck
Compares the value of inport u between the current and previous model iterations and
determines if the absolute difference exceeds the slew rate limit.
6.1.94.4. Inports
• u
Value to slew check.
6.1.94.5. Outports
• slew_fault
Set to 1 if the absolute difference between inport u at this model iteration and the previous
model iterate is greater than the parameter Absolute raw slew rate limit, 0 otherwise. On
the first model iteration, the block outputs 0.
Range: 0 or 1

Software detail
• Absolute raw slew rate limit
Maximum absolute rate of change of input calculated over one model iteration before input
considered faulty.
Range: [-inf, inf] /sec
Value type: Real
• Sample time
Value type: Real

Calibratable: No
6.1.94.7. Notes
None.
6.1.95. SPI communication fault count

(psp_FaultCount)
Interface to read the number of SPI transmit errors on a given device since initialisation.

All targets

Device: CJ125-A
sim_count count
Sample time:
psp_FaultCount
Certain SPI devices support the ability to validate their communication with the main
processor. If a fault occurs in the communication, the platform will track the error. This block
allows the number of detected errors to be reported to the application.
6.1.95.4. Inports
• sim_count
outport count is written using the value of this inport.
Range: [0, 255] counts.
Value type: Real

Calibratable: No
6.1.95.5. Outports
• count

Software detail
The number of SPI faults reported for the specified device.
Range: [0, 255] counts.
Value type: Real

Calibratable: No
• Device
The SPI device for which to read the fault count.
Value type: List

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
Value type: Boolean

Calibratable: No
6.1.95.7. Notes
The counter Value will saturate at 255. This value is only cleared by resetting the ECU.
6.1.96. Stack used (psc_StackUsed)

Get the maximum number of bytes used by the stack since power on (or reset).

All targets


Software detail
used_bytes
psc_StackUsed
Gets the number of bytes used by the application model and platform library since the ECU
was last powered on (or reset). The stack is shared area of RAM used to store temporary
information, such as calculations and function call parameters.
The total stack size allocated to the application model and platform library can be adjusted
through the RTW options, see System stack size. It is important to allocate sufficient
stack space for the worst case function call tree through the application and platform code
otherwise the ECU may not behave as expected. While developing a model, keep a track of
the stack size used and, as the usage grows, grow the system stack size appropriately.
Note
The ECUs are configured by the platform software to reset when the stack overflows
its allocation. The reset prevents the ECU from behaving unexpectedly.
When using RTW as the model auto-coder, be aware that RTW has two ways of allocating
model data.
• RTW can statically allocate the data, which means that the model data is allocated to a
fixed address in memory and not to the stack. This form of allocation is preferred because
at run time the stack usage will be low, and if the model becomes too large for the ECU's
memory, the model will fail to build completely.
Unselect the RTW Enable local block outputs option to have RTW statically allocate model
data.
• RTW can dynamically allocate the data to the stack. This means that the stack use can
vary significantly at run time and the system stack size will need to be larger. This form of
allocation is not preferred because to guarantee that the stack will not overflow will require
detailed analysis of the RTW generated code.
Select the RTW Enable local block outputs option to have RTW dynamically allocate model
data to the stack.
6.1.96.4. Inports
• sim_used_bytes
The outport used_bytes is set to the value of this inport for simulation purposes.
Range: 0 to system stack size specified in System stack size.
6.1.96.5. Outports
• used_bytes
The number of used bytes from the system stack size since the ECU was powered on (or
reset). Under simulation, if the Provide simulation inputs parameter isn't ticked, the outport
is set to the minimum of its range.
Range: 0 to system stack size specified in System stack size.

Software detail
• Sample time
Value type: Real

Calibratable: No
Tick to enable inport sim_used_bytes.
6.1.96.7. Notes
None.
6.1.97. Task duration (pkn_TaskDuration)

Get the last measured or maximum duration for a given model rate (task).

All targets

duration
pkn_TaskDuration
Each rate in a model is represented by a task. A task contains all the functionality to iterate
that model rate. Simulink has a specific scheme for executing each task to simulate the model
on the host PC, or to run the model on a target ECU. While arbitrarily large models can be
run on the host PC, where the model is not run in real time, there is a limit to the size of model
that can be executed on the target ECU. The psc_TaskDuration block provides feedback on
how long each task takes to run and can be used to indicate whether all tasks run in real
time or not.
The task duration excludes the time taken for other tasks to run and includes the time taken
during platform interrupts. For instance, in a model which has a 5 millisecond and a 10

Software detail
millisecond rate, the task duration measurement of the 10 millisecond task will not include
any time taken up by an interrupting 5 millisecond task. But, in the same time frame, if the
platform handled some interrupts for CAN messaging and angular functionality, then the time
taken to service the interrupts is included.
Together with the psc_CpuLoading block, the psc_TaskDuration block can provide an
indication of where the majority of the processing to run the model takes place, useful when
attempting to optimise the model. It is useful to record the output of both these blocks across
the lifetime of the model development — a graph of these values against time will quickly
show if the model will become too large for the ECU as development progresses.
6.1.97.4. Inports
• sim_duration
The outport duration is set to the value of this inport for simulation purposes.
6.1.97.5. Outports
• duration
The last measured duration of the model rate task, or the maximum duration seen for that
task since the ECU was powered on (or reset). Under simulation, if the Provide simulation
inputs parameter isn't ticked, the outport is set to the minimum of its range.
• Output mode
Whether the outport duration is set to the last measured task duration or the maximum
task duration seen since the ECU was powered on (or reset).
• Sample time (task)
The periodicity of the model rate to measure.

Software detail
• Sample time (block)
The periodicity of the block. The task and block sample time allow the model rate task
measurement to occur independently from the task itself.
Tick to enable inport sim_duration.
6.1.97.7. Notes
None.
6.1.98. Task period overrun (pkn_TaskPeriodOverrun)

Get the count of overruns for a given model rate (periodic task).

All targets

overruns
skips
pkn_TaskPeriodOverrun
Each rate in a model is represented by a task. A task contains all the functionality to iterate
that model rate. Simulink has a specific scheme for executing each task to simulate the model
on the host PC, or to run the model on a target ECU. While arbitrarily large models can be
run on the host PC, where the model is not run in real time, there is a limit to the size of
model that can be executed on the target ECU in real time. The pkn_TaskPeriodOverrun
block provides feedback on how many times a model rate (periodic) task has overrun its rate,
or how many times the task has been skipped when it should have been run.
For example, if a model contains a 5 millisecond rate then the pkn_TaskPeriodOverrun block
counts the number of times the 5 millisecond model rate task becomes ready to run when the
5 millisecond task is already running (overrun), or how many times the task becomes ready
to run, but has not been started since the last time it was made ready to run (skipped).
A model rate task may overrun its period or skip its period for a number of reasons:
• The quantity and type of blocks required to execute every period is too much for the target
ECU to achieve.
• A higher priority model rate task or tasks (those with shorter periods) uses up processor
time that the lower priority model rate tasks require to complete within their period.
Together with the psc_CpuLoading block, and the pkn_TaskDuration block, the
pkn_TaskPeriodOverrun block can provide an indication of where the majority of the model
processing takes place, useful when attempting to optimise the model. It is useful to record
the output of these blocks across the lifetime of the model development — a graph of these

Software detail
values against time will help to indicate if the model will become too large for the ECU as
development progresses.
6.1.98.4. Inports
• sim_overruns
The outport overruns is set to the value of this inport for simulation purposes.
Range: [0, 255] counts
• sim_skips
The outport skips is set to the value of this inport for simulation purposes.
6.1.98.5. Outports
• overruns
The saturated counts of periodic overruns for the model rate task since the ECU was
powered on (or reset). Under simulation, if the Provide simulation inputs parameter isn't
ticked, the outport is set to the minimum of its range.
Value type: integer
• skips
The saturated counts of periodic skips for the model rate task since the ECU was powered
on (or reset). Under simulation, if the Provide simulation inputs parameter isn't ticked, the
outport is set to the minimum of its range.
Value type: integer
• Sample time (task)
The periodicity of the model rate to measure.
Value type: float

Software detail
Calibratable: No
• Sample time (block)
The periodicity of the block. The task and block sample time allow the model rate task
measurement to occur independently from the task itself.
Value type: float

Calibratable: No
Tick to enable inport sim_overruns.
Value type: boolean
6.1.98.7. Notes
None.
6.1.99. Time (real) (ptm_RealTime)

Output the time since the model started (absolute), or output the time since the last time the
block executed (relative).

All targets

Time base: Seconds
time
Mode: Relative
ptm_RealTime
Output the current time (absolute), or output the time since the last time the block executed
(relative). Time is tracked in two ways: for host simulation — using Simulink's task timing;
and for target execution — using the ECU's operating system timers.
When run under simulation, this block has the same behaviour as the Simulink Time block,
see Section 6.1.100, “Time (Simulink) (ptm_SimulinkTime)”.
When run on target, this block reads the time from the ECU's operating system. The ECU's
operating system utilises a high resolution timer to provide microsecond, millisecond and
second results, any of which can be selected as the block output using the drop-down option.
When the block is iterated, the time outport is the latest reading from the high resolution timer.
The ptm_RealTime block can be configured to provide an absolute time or a relative time.
The absolute time is the time at which the block is iterated since the start of the model (after
power on, or reset). The relative time is time since the block was last iterated, or if the block
has never iterated before, the time since the start of the model.
To understand the absolute time configuration, consider a simple model with two model rates,
5ms and 10ms. The 5ms model rate contains a ptm_RealTime block configured for absolute
time, and to work in microseconds. The block is iterated at times A, C and D.

Software detail
Figure 6.3. Example time-line to explain the ptm_RealTime block
5ms model rate
10ms model rate
time
0 1 2 3 4 5 6 7 8 9 10 11
A B C D E
A. At time A, the ptm_RealTime block sets time outport value to around 250 microseconds
(the time since the model started).
C. At time C, the ptm_RealTime block sets time outport value to around 5250 microseconds.
D. At time D, the ptm_RealTime block sets time outport value to around 10250 microseconds.
And to understand the relative time configuration, consider the same model where the 10ms
model rate contains a ptm_RealTime block configured for relative time. The block is iterated
at times B and E.
B. At time B, the ptm_RealTime block sets time outport value to around 1330 microseconds
(the time since the model started as there has been no iteration of the block prior to time B).
E. At time E, the ptm_RealTime block sets time outport value to around 10000 microseconds,
being the difference between time E and B. The precise value will vary depending on the
influence of higher-priority tasks and interrupt work.
The description above uses the term “around x milliseconds” because of task jitter. Task jitter
occurs when the length of time a task takes to complete varies each time the task runs. As
an example, consider a task that has some logic implemented by the auto-coder as an if-else
statement. If in different iterations of the model task different parts of the if-else statement run,
and if the processing which occurs for those parts differs, then each part will take a different
amount of time to complete and the overall task duration will vary. If the ptm_RealTime block
occurs after the if-else logic then the time output by the block will vary.
Warning
The type of outport time is an unsigned 32-bit integer, which limits the range of time
this block can represent.
Resolution Maximum duration

Microseconds approx. 71 minutes
Milliseconds approx. 49 days
Seconds approx. 136 years
32
The value for both absolute and relative time are provided modulo 2 . It is up to the
application to take care of the wrap around caused by the modulo.
6.1.99.4. Inports
None.
6.1.99.5. Outports
• time

Software detail
The current real-time taken from the ECU's operating system timer, as either an absolute
time since the model started, or as a relative time since the last time the block was iterated
(or the start of the model if the block has not been iterated before).
32
Range: [0, inf] modulo 2 , seconds, milliseconds, or microseconds
• Time base
The resolution and units of the outport time, as seconds, milliseconds or microseconds.
• Output mode
Whether the value of outport time is absolute or relative.
• Sample time
Value type: Real

Calibratable: No
6.1.99.7. Notes
None.
6.1.100. Time (Simulink) (ptm_SimulinkTime)

Output the time since the model started (absolute), or output the time since the last time the
block executed (relative).

All targets


Software detail
Time base: Seconds
time
Mode: Relative
ptm_SimulinkTime
Output the current Simulink task time (absolute), or output the time since the last time the
block executed (relative). Time is tracked using Simulink's task timers for both host simulation
and target execution.
This block reads the time from the Simulink's task timers. Simulink task timers track the time
each task should run at the resolution of the quickest model rate. For instance, if there were
two model rates, 5ms and 10ms, then the resolution of the Simulink task timer for each model
rate would be 5ms. The block converts these timers to microsecond, millisecond or second
resolution, as required by parameter Time base. When the block is iterated, the time outport
is the timer for the current model rate task.
The ptm_SimulinkTime block can be configured to provide an absolute time or a relative time.
The absolute option is the Simulink task time at which the block is iterated since the start
of the model (after power on, or reset). The relative option is the Simulink task time since
the block was last iterated, or if the block has never iterated before, the Simulink task time
since the start of the model.
To understand the absolute time configuration, consider a simple model with two model
rates, 5ms and 10ms. The 5ms model rate contains a ptm_SimulinkTime block configured
for absolute time. The block is iterated at times A, C and D.
Figure 6.4. Example time-line to explain the ptm_SimulinkTime block
5ms model rate
10ms model rate
time
0 1 2 3 4 5 6 7 8 9 10 11
A B C D E
A. At time A, the ptm_SimulinkTime block sets time outport value to 0 milliseconds (the time
since the model started). Note that the time matches the start of the model rate task and
not the current time. If the current time is required then see the ptm_RealTime block.
C. At time C, the ptm_SimulinkTime block sets time outport value to 5 milliseconds.
D. At time D, the ptm_SimulinkTime block sets time outport value to 10 milliseconds.
And to understand the relative time configuration, consider the same model where the 10ms
model rate contains a ptm_SimulinkTime block configured for relative time. The block is
iterated at times B and E.
B. At time B, the ptm_SimulinkTime block sets time outport value to 0 milliseconds (the time
since the model started as there has been no iteration of the block prior to time B).
E. At time E, the ptm_SimulinkTime block sets time outport value to 10 milliseconds.
In the last example at time B, the 10ms Simulink task timer is zero rather 0.5 milliseconds.
The Simulink task timer is zero because Simulink would like to start both the 5ms and 10ms
model rate tasks at the same time, time zero. Because the ECU's operating system runs the

Software detail
quickest rate task first, the 10ms model rate task starts after the 5ms model rate task has
completed.
If the 10ms model rate task were to take longer and the 5ms model rate task ran more quickly,
for example, every 2ms, then the task sequence over time looks different:
2ms model rate
10ms model rate
time
0 1 2 3 4
A B C D
A. At time A, the ptm_SimulinkTime block sets time outport value to 0 milliseconds.
B. At time B, the ptm_SimulinkTime block sets time outport value to 0 milliseconds.
C. At time C, even though the 10ms task has not yet completed, the 2ms model rate task
ran and Simulink updated timer for that task. The ptm_SimulinkTime block therefore sets
time outport value to 2 milliseconds.
D. At time D, the 10ms model rate task has not yet completed and the Simulink task timer
remains at zero. The ptm_SimulinkTime block therefore sets time outport value to 0
milliseconds.
Warning
The type of outport time is an unsigned 32-bit integer, which limits the range of time
this block can represent.
Resolution Maximum duration

Microseconds approx. 71 minutes
Milliseconds approx. 49 days
Seconds approx. 136 years
32
The value for both absolute and relative time are provided modulo 2 . It is up to the
application to take care of the wrap around caused by the modulo.
Simulink may generate code to maintain its task timers using a type which cannot
represent the full range of the outport time. In this case, the Simulink task timers may
saturate rather than wrap around due to the modulo. Again, it is up to the application
to address this condition.
For more information about Simulink's task timers see the MathWorks' documentation
for RTW.
6.1.100.4. Inports
None.
6.1.100.5. Outports
• time

Software detail
The current simulink task time, as either an absolute time since the model started, or as
a relative time since the last time the block was iterated (or the start of the model if the
block has not been iterated before).
32
Range: [0, inf] modulo 2 , seconds, milliseconds, or microseconds
• Time base
The resolution and units of the outport time, as seconds, milliseconds or microseconds.
• Output mode
Whether the value of outport time is absolute or relative.
• Sample time
6.1.100.7. Notes
None.
6.1.101. Watchdog kick (psc_KickWatchdog)

Kick the processor watchdog to avoid reset.

All targets

kick
psc_KickWatchdog

Software detail
A watchdog is a timer that causes a processor reset when the timer exceeds a maximum
duration. By kicking the watchdog on a periodic basis, the processor reset never occurs.
A simple scheme to utilise the watchdog kicks the watchdog on a periodic basis. A more
complex scheme might kick the watchdog only if the software appears to be performing the
correct functionality (for instance, if two independent measurements of the same quantity
show a large discrepancy).
The psc_KickWatchdog block causes the processor watchdog timer to clear thus avoiding a
reset. Each ECU has a fixed watchdog duration.
Target ECU Watchdog duration Maximum kick period

a
M110, M220, M221, [~419, ~838] milliseconds 200 milliseconds
M250, M460, M461
a
M560, M580, M670 [~508, ~1016] milliseconds 200 milliseconds
a
The range reflects the configuration of the processor's watchdog, which uses two time out periods before resetting
the processor.
If no psc_KickWatchdog block is present in the model then the watchdog will be kicked by
the platform automatically at the maximum period for the target ECU.
6.1.101.4. Inports
• kick
Set to 1 to cause watchdog timer to clear (no reset), set to zero to allow the watchdog timer
to continue to increase (reset will occur when timer exceeds the duration).
Range: 0 or 1
6.1.101.5. Outports
None.
6.1.101.7. Notes
None.
6.1.102. Vehicle to grid communication - Protocol

Handshake (pv2g_Protocol_Handshake_Message)
Send or receive a supportedAppProtocol vehicle to grid communication message.

All targets


Software detail
transmit
DIN_70121_enable
ISO_15118_v1_enable
Vehicle to grid request message:

ISO_15118_v2_enable error
supportedAppProtocolReq
DIN_70121_priority
ISO_15118_v1_priority
pv2g_Protocol_Handshake_Message
This block implements the protocol handshake messages, supportedAppProtocol, allowing

the EVCC and SECC to negotiate the protocol of all further vehicle to grid communication
messages during the charging session.
Separate instances of the block are necessary for each message type. Only the inports and
outports that are relevant to the selected message are shown.
A description of each message is described in the table below:
Table 6.8. Protocol handshake messages

Message Description
supportedAppProtocolReq Populate the transmit message structure
for a supported application protocol
request. Before starting the application
layer message exchange, an appropriate
application layer protocol including its
version shall be negotiated between the
EVCC and the SECC.
supportedAppProtocolRes Receive the supportedAppProtocolRes
message containing the protocol
selected by the SECC. Depending on
the protocol selected, the application
should use only the pv2g_DIN_Message,
pv2g_ISO_15118_V1_Message, or
pv2g_ISO_15118_V2_Message blocks
for all further communication during the
charging session.
6.1.102.4. Inports
• transmit
If this inport is asserted when the model is iterated, then the corresponding vehicle to grid
message will be transmitted.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• DIN_70121_enable
This signal indicates that the DIN 70121 protocol shall be added to the supported protocol
list.
The DIN 70121 protocol uses:

ProtocolNamespace = "urn:din:70121:2012:MsgDef",
VersionNumberMajor = 2,
VersionNumberMinor = 0,

Software detail
SchemaID = 10.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• ISO_15118_v1_enable
This signal indicates that the ISO 15118 v1 protocol shall be added to the supported
protocol list.
The ISO 15118 v1 protocol uses:

ProtocolNamespace = "urn:iso:15118:2:2013:MsgDef",
SchemaID = 20.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• ISO_15118_v2_enable
This signal indicates that the ISO 15118 v2 protocol shall be added to the supported
protocol list.
The ISO 15118 v2 protocol uses:

ProtocolNamespace = "urn:iso:15118:2:2015:MsgDef",
SchemaID = 30.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• DIN_70121_priority
This signal indicates the EVCC's desired relative priority of the DIN 70121 protocol, if
enabled. Priority equal to 1 indicates the highest priority, and priority equal to 20 indicates
the lowest priority.
Range: [1, 20]
Value type: Integer

Calibratable: No
• ISO_15118_v1_priority
This signal indicates the EVCC's desired relative priority of the ISO 15118 v1 protocol, if
Range: [1, 20]
Value type: Integer

Calibratable: No
• ISO_15118_v2_priority

Software detail
This signal indicates the EVCC's desired relative priority of the ISO 15118 v2 protocol, if
Range: [1, 20]
Value type: Integer

Calibratable: No
6.1.102.5. Outports
• error
Set to true if there was a problem processing the inputs.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• receive flag
Set to true if the message was received.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• ResponseCode
Response Code indicating the acknowledgment status of any of the V2G messages
received by the SECC.
value Description
0 OK_SuccessfulNegotiation - signals a successful protocol
negotiation
1 OK_SuccessfulNegotiationWithMinorDeviation - signals that a
minor version deviation applies
2 Failed_NoNegotiation - indicates that the protocol negotiation
was not successful
Value type: Enumeration

Calibratable: No
• DIN_70121_selected
This signal indicates that the SECC has determined that the DIN 70121 protocol shall be
used for this charging session.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• ISO_15118_v1_selected
This signal indicates that the SECC has determined that the ISO 15118 v1 protocol shall
be used for this charging session.

Software detail
Range: 0 or 1
Value type: Boolean

Calibratable: No
• ISO_15118_v2_selected
This signal indicates that the SECC has determined that the ISO 15118 v2 protocol shall
be used for this charging session.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• Vehicle to grid message
The vehicle to grid request or response message. The inports and outports of the block
will be reconfigured according to the table below for this parameter selection.
Selection Inports Outports

supportedAppProtocolReq transmit error
DIN_70121_enable
ISO_15118_v1_enable
ISO_15118_v2_enable
DIN_70121_priority
supportedAppProtocolRes receive flag
ResponseCode
DIN_70121_selected
ISO_15118_v1_selected
ISO_15118_v2_selected
Value type: List

Calibratable: No
• Sample Time (sec)
Value type: Real

Calibratable: No

Software detail
6.1.102.7. Notes
None.
6.1.103. Vehicle to grid communication - DIN 70121

(pv2g_DIN_Message)
Send or receive a DIN 70121 vehicle to grid communication message.

All targets


transmit error
DIN_SessionSetupReq
pv2g_DIN_Message
This block implements the protocol DIN SPEC 70121, allowing the application to send and
receive vehicle grid communication messages. The application can use these messages to
make requests to a charging station and receive responses from the station.
Table 6.9. DIN messages

Message Description
DIN_SessionSetupReq By using the SessionSetupReq message
the EV establishes a V2G Communication
Session
DIN_SessionSetupRes By using the SessionSetupRes the SECC
responds to an SessionSetupReq. With the
SessionSetup Response the EVSE notifies
the EV with an enclosed response code,
whether establishing a new session was
successful or not.
DIN_ServiceDiscoveryReq By sending the ServiceDiscoveryReq
message, the EVCC triggers the SECC to
send information about all services offered
by the SECC.
DIN_ServiceDiscoveryRes After receiving the ServiceDiscoveryReq
message of the EVCC, the SECC sends the
ServiceDiscoveryRes message. In case of a
successful service discovery, the response
lists all available services of the SECC for
the defined criteria. In case the service

Software detail
Message Description
discovery failed, the service list is empty
and the response code indicates potential
reasons.
DIN_ServicePaymentSelectionReq This request message transports the
information on the selected services and on
how the all the selected services are paid.
DIN_ServicePaymentSelectionRes With this message, the SECC informs the
EVCC whether the selected services and
payment option were accepted.
DIN_ContractAuthenticationReq By sending the ContractAuthenticationReq
message to the SECC, the EVCC provides
the contract certificate to SECC to identify
a private key which is used for tarrif table
signature. This message is optional.
DIN_ContractAuthenticationRes After receiving the
ContractAuthenticationReq message
from the EVCC, the SECC sends the
ContractAuthenticationRes message as an
acknowledgement status and EVSE status
to the EVCC.
DIN_ChargeParameterDiscoveryReq By sending the
ChargeParameterDiscoveryReq message
the EVCC provides its charging parameters
to the SECC. This message provides status
information about the PEV and additional
charging parameters, like estimated energy
amounts for recharge and the point in time
for the end of charge.
DIN_ChargeParameterDiscoveryRes With the ChargeParameterDiscoveryRes
message the SECC provides applicable
charge parameters from the grid's
perspective. Next to general charge
parameters of the EVSE this optionally
includes further information on cost
over time, cost over demand, cost over
consumption, or a combination of these.
The term cost refers to any kind of cost
specified in this version of the standard and
is not limited to monetary costs. Based on
this cost information the PEV may optimize
its charge for the requested amount of
energy.
DIN_DC_EVChargeParameter Provides an interface to the
DC_EVSEChargeParameter of the
ChargeParameterDiscoveryRes message.
DIN_SAScheduleList Provides an interface to access
the SAScheduleList returned in the
ChargeParameterDiscoveryRes response.
DIN_CableCheckReq With the CableCheckReq message, the
PEV asks the EVSE to perform a cable
check, which includes an isolation test,
before charging.

Software detail
Message Description
DIN_CableCheckRes After receiving the CableCheckReq
message of the PEV the EVSE sends the
CableCheckRes message informing the
PEV about result of its cable check and
EVSE status.
DIN_Pre-ChargeReq With the PreChargeReq message the
EVCC asks the EVSE to apply certain
values for output voltage and output current.
Since the contactors of the PEV are open
during Pre-Charging, the actual current
flow from the EVSE to the PEV will be
very small, i.e., in most cases smaller than
the requested output current. The EVCC/
SECC may use several Pre-Charging
Request/Response message pairs in order
to precisely adjust the EVSE output voltage
to the PEV RESS voltage measured inside
the PEV.
DIN_Pre-ChargeRes After receiving the PreChargeReq
message of the EVCC the EVSE sends
the PreChargeRes message informing the
PEV about EVSE status and present EVSE
output voltage.
DIN_PowerDeliveryReq By sending the PowerDeliveryReq message
the EVCC requests the EVSE to switch
power on and transmits the charging profile
it will follow during the charging process.
DIN_PowerDeliveryRes After receiving the PowerDeliveryReq
message of the EVCC the SECC sends
the PowerDeliveryRes message including
information if power will be available.
DIN_CurrentDemandReq By sending the CurrentDemandReq
message the PEV requests a certain current
from EVSE. Also the target voltage and
current are transferred.
DIN_CurrentDemandRes After receiving the CurrentDemandReq
message from the EVCC the SECC sends
the CurrentDemandRes message informing
the PEV about EVSE status and present
EVSE output voltage and current.
DIN_WeldingDetectionReq The EVCC sends the WeldingDetectionReq
message to obtain from the EVSE the
voltage value measured by the EVSE at its
output.
DIN_WeldingDetectionRes After receiving the WeldingDetectionReq
message from the EVCC, the EVSE sends
the WeldingDetectionRes informing the
PEV about the EVSE status and the present
EVSE output voltage.
DIN_SessionStopReq By sending the SessionStopReq message
the EVCC requests termination of the
charging process.

Software detail
Message Description
DIN_SessionStopRes After receiving the SessionStopReq
message from the EVCC the SECC sends
the SessionStopRes message informing the
EVCC if terminating the charging process
was successful.
6.1.103.4. Inports
• transmit
Range: 0 or 1
Value type: Boolean

Calibratable: No
• tuple_index
Specifies the index of the tuple in the SAScheduleList that the block will report.
Range: [0, 2]
Value type: Integer

Calibratable: No
• BulkChargingComplete_enable
If set to TRUE, the optional message element, BulkChargingComplete, is added to the

message. Otherwise the message element is removed.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• BulkChargingComplete
Optional element:
If set to TRUE, the vehicle indicates that bulk charge is complete.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• BulkSOC
Optional element:
State of charge at which the vehicle considers a fast charge process to be complete.
Range: [0, 100] Percent, or -1 to disable optional message element
Value type: Integer

Calibratable: No
• ChargingComplete
If set to TRUE, the vehicle indicates that full charge is complete.

Software detail
Range: 0 or 1
Value type: Boolean

Calibratable: No
• ChargingProfileEntryMaxPower
Optional element:
A vector of values specifying the maximum power in Watts consumed by the vehicle within
the current charging profile entry.
Size: [1, 24] entries

Range: [-32768, 32767] Watts
Value type: Integer

Calibratable: No
• ChargingProfileEntryStart
Optional element:
A vector of values specifying the times when chargingProfileEntry starts to be valid. Offset
in seconds from NOW.

Range: [0, 4294967295] seconds
Value type: Integer

Calibratable: No
• EVCabinConditioning_enable
If set to TRUE, the optional message element, EVCabinConditioning, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVCabinConditioning
Optional element:
Vehicle Cabin Conditioning, The vehicle is using energy from the DC supply to heat or cool
the passenger compartment
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVEnergyCapacity_enable
If set to TRUE, the optional message element, EVEnergyCapacity, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVEnergyCapacity

Software detail
Optional element:
Maximum energy capacity supported by the vehicle
Range: [-32768000, 32767000] Wh
Value type: Real

Calibratable: No
• EVEnergyRequest_enable
If set to TRUE, the optional message element, EVEnergyRequest, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVEnergyRequest
Optional element:
Amount of energy requested by the vehicle
Range: [-32768000, 32767000] Wh
Value type: Real

Calibratable: No
• EVErrorCode
Indicates the EV internal status
value Description
0 Default value, when EV has no Error detected
1 Battery Temperature Inhibit, Battery too hot/cold to accept
charge
2 Vehicle Shift Position, Vehicle is not in Park
3 Charger Connector Lock Fault, Vehicle has not detected the
Charge cord connector locked into the inlet or a failure exists
where connector cannot be unlocked from the charging inlet
4 Vehicle RESS Malfunction, Any non-recoverable fault or error
condition of the Vehicle RESS.
5 Charging Current Differential, Indication that vehicle has stopped
the Communication Session after detecting that the charging
station is not able to maintain an output current that fulfills the
current request.
6 Charging Voltage Out Of Range, Indication that vehicle has
stopped the Communication Session after detecting that the
RESS is either under or above the normal operating voltage
range
7 Reserved
8 Reserved
9 Reserved

Software detail
value Description
10 Charging System Incompatibility, if the vehicle determines
that the charging station is incompatible. Using this value is
optional; as an alternative, the vehicle can use EVReady in
DC_EVStatusType equal to "FALSE"
11 No Data. Only used when vehicle has not yet determined its
operating state.

Calibratable: No
• EVMaximumCurrentLimit_enable
If set to TRUE, the optional message element, EVMaximumCurrentLimit, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVMaximumCurrentLimit
Optional element:
Maximum current supported by the vehicle.
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVMaximumPowerLimit_enable
If set to TRUE, the optional message element, EVMaximumPowerLimit, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVMaximumPowerLimit
Optional element:
Maximum power supported by the vehicle.
Range: [-32768000, 32767000] W
Value type: Real

Calibratable: No
• EVMaximumVoltageLimit_enable
If set to TRUE, the optional message element, EVMaximumVoltageLimit, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No

Software detail
• EVMaximumVoltageLimit
Optional element:
Maximum voltage supported by the vehicle.
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No
• EVReady
If set to TRUE, the vehicle is ready to charge.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVRequestedEnergyTransferType
Identifies the energy transfer type for charging.
value Description
0 AC single phase core - Not used in the scope of DIN SPEC
70121.
1 AC three phase core - Not used in the scope of DIN SPEC
70121.
2 DC core - EV asks for DC charging using the core pins of
an IEC 62196-3 Configuration CC connector (corresponding
to an IEC 62196-2 Type 1 connector) or of an IEC 62196-3
Configuration DD connector (corresponding to an IEC 62196-2
Type 2 connector)
3 DC extended - EV asks for DC charging using the extended
pins of an IEC 62196-3 Configuration EE or Configuration FF
connector
4 DC combo core - Not used in the scope of DIN SPEC 70121.
5 DC unique - Not used in the scope of DIN SPEC 70121.

Calibratable: No
• EVRESSConditioning_enable
If set to TRUE, the optional message element, EVRESSConditioning, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVRESSConditioning
Optional element:
The vehicle is using energy from the DC charger to condition the RESS to a target
temperature
Software detail
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVRESSSOC
State of charge of the vehicle's battery
Range: [0, 100] Percent
Value type: Integer

Calibratable: No
• EVTargetCurrent
Instantaneous current requested by the EV.
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVTargetVoltage
Target voltage requested by the EV.
Range: [-32768000, 32767000] V
Value type: Integer

Calibratable: No
• FullSOC
State of charge at which the vehicle considers the battery fully charged.
Value type: Integer

Calibratable: No
• ProfileEntry_count
Identifies the number of charging profile entries that have been provided in the
ChargingProfileEntryStart and ChargingProfileEntryMaxPower parameters.
Range: [0, 24], if set to 0, the optional message element is removed.
Value type: Integer

Calibratable: No
• ReadyToChargeState
If set to TRUE, signals that the vehicle is ready for full energy transfer.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• RemainingTimetoBulkSOC_enable

Software detail
If set to TRUE, the optional message element, RemainingTimetoBulkSOC, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• RemainingTimetoBulkSOC
Optional element:
Estimated or calculated time until bulk charge is complete.
Range: [-32768000, 32767000] seconds
Value type: Real

Calibratable: No
• RemainingTimeToFullSOC_enable
If set to TRUE, the optional message element, RemainingTimeToFullSOC, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• RemainingTimeToFullSOC
Optional element:
Estimated or calculated time until full charge is complete.
Range: [-32768000, 32767000] seconds
Value type: Real

Calibratable: No
• SAScheduleTupleID (in)
Unique identifier within a charging session referring to the selected SAScheduleTuple

element from the SAScheduleListType.
Range: [-32768, 32767]
Value type: Integer

Calibratable: No
• SelectedServiceID
Service ID of the service selected by the EVCC
Range: [0, 65535]
Value type: Integer

Calibratable: No
6.1.103.5. Outports
• data_valid
Indicates whether data is available to be read at the specified index.

Software detail
Range: 0 or 1
Value type: Boolean

Calibratable: No
• error
Range: 0 or 1
Value type: Boolean

Calibratable: No
• receive flag
Range: 0 or 1
Value type: Boolean

Calibratable: No
• tuple_available
Indicates that the tuple at the specified SASchedule list index is available.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• DateTimeNow_present
Identifies the presence of the DateTimeNow parameter.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• DateTimeNow
Optional element:
Timestamp of the current SECC time using the Unix Time Stamp format, of seconds
elapsed since the Unix epoch of 00:00:00 UTC on 1 January 1970.
Range: [-2147483648, 2147483647] seconds
Note
This signal returns a signed 32 bit number which allows the maximum representable
data to be 03:14:07 UTC 2038-01-19.
Value type: Integer

Calibratable: No
• DC_EVSEChargeParameter_present
Identifies the presence of the DC_EVSEChargeParameter and its sub-parameters which

are used by the SECC for initiating the target setting process for DC charging.

Software detail
If set to TRUE, the application should unpack the value of the DC_EVSEChargeParameter
separately by calling the block with the Vehicle to grid message parameter set to
"DIN_DC_EVChargeParameter".
Range: 0 or 1
Value type: Boolean

Calibratable: No
• DC_EVSEStatus_present
Identifies the presence of the DC_EVSEStatus parameter which includes the

EVSEIsolationStatus_present, EVSEIsolationStatus, and EVSEStatusCode parameters.
If set to FALSE, these parameters should be ignored.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EnergyTransferType
Identifies the energy transfer type for charging.
value Description
0 AC single phase core - Not used in the scope of DIN SPEC
70121.
1 AC three phase core - Not used in the scope of DIN SPEC
70121.
2 DC core - EV asks for DC charging using the core pins of
an IEC 62196-3 Configuration CC connector (corresponding
to an IEC 62196-2 Type 1 connector) or of an IEC 62196-3
Configuration DD connector (corresponding to an IEC 62196-2
Type 2 connector)
3 DC extended - EV asks for DC charging using the extended
pins of an IEC 62196-3 Configuration EE or Configuration FF
connector
4 DC combo core - Not used in the scope of DIN SPEC 70121.
5 DC unique - Not used in the scope of DIN SPEC 70121.

Calibratable: No
• EVSECurrentLimitAchieved
If set to TRUE, the EVSE has reached its current limit.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSECurrentRegulationTolerance_present
Identifies the presence of the EVSECurrentRegulationTolerance parameter.
Range: 0 or 1

Software detail
Value type: Boolean

Calibratable: No
• EVSECurrentRegulationTolerance
Optional element:
Absolute magnitude of the regulation tolerance of the EVSE.
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVSEEnergyToBeDelivered_present
Identifies the presence of the EVSEEnergyToBeDelivered parameter.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSEEnergyToBeDelivered
Optional element:
Amount of energy to be delivered by the EVSE.
Range: [-32768000, 32767000] Wh
Value type: Real

Calibratable: No
• EVSEID_length
Identifies the length of the valid data in the EVSEID parameter.
Range: [0, 32] entries
Value type: Integer

Calibratable: No
• EVSEID
A vector of values indicating an ID that uniquely identifies the EVSE. The format of this
message element is defined in DIN SPEC 91286.

Range: [0, 255]
Value type: Integer

Calibratable: No
• EVSEIsolationStatus_present
Identifies the presence of the EVSEIsolationStatus parameter.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSEIsolationStatus

Software detail
Optional element:
Indicates the isolation condition
value Description
0 Invalid - DC Supply may transmit this enumeration at startup
before measurement has been confirmed.
1 Valid - Isolation measurement confirms the system is within the
Valid region above thresholds
2 Warning - Isolation has detected a measurement below the
Warning level threshold.
3 Fault - Isolation has detected a measurement below the Fault
level threshold.

Calibratable: No
• EVSEMaximumCurrentLimit_present
Identifies the presence of the EVSEMaximumCurrentLimit parameter.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSEMaximumCurrentLimit
Optional element:
Maximum current the EVSE can deliver
Range: [-32768000, 32767000] A
Value type: Integer

Calibratable: No
• EVSEMaximumPowerLimit_present
Identifies the presence of the EVSEMaximumPowerLimit parameter.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSEMaximumPowerLimit
Optional element:
Maximum power the EVSE can deliver
Range: [-32768000, 32767000] W
Value type: Integer

Calibratable: No
• EVSEMaximumVoltageLimit_present
Identifies the presence of the EVSEMaximumVoltageLimit parameter.
Range: 0 or 1

Software detail
Value type: Boolean

Calibratable: No
• EVSEMaximumVoltageLimit
Optional element:
Maximum voltage the EVSE can deliver
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No
• EVSEMinimumCurrentLimit
Minimum current the EVSE can deliver with the expected accuracy
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVSEMinimumVoltageLimit
Minimum voltage the EVSE can deliver with the expected accuracy.
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVSEPeakCurrentRipple
Peak-to-peak magnitude of the current ripple of the EVSE.
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVSEPowerLimitAchieved
If set to TRUE, the EVSE has reached its power limit.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSEPresentCurrent
Present output current of the EVSE.
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVSEPresentVoltage
Present voltage of EVSE

Software detail
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No
• EVSEProcessing
Parameter indicating that the EVSE has finished the processing that was initiated after the
request message or that the EVSE is still processing at the time the response message
was sent.
value Description
0 finished
1 ongoing

Calibratable: No
• EVSEStatusCode
Indicates the internal state of the EVSE.
value Description
0 EVSE_NotReady - Not authorized, StandBy, on maintenance
1 EVSE_Ready - Standard value used during normal operation
2 EVSE_Shutdown - Charger Shutdown, Customer Initiated
Shutdown
3 EVSE_UtilityInterruptEvent - Utility Interrupt Event, Utility or
Equipment operator has requested a temporary reduction in load.
4 EVSE_IsolationMonitoringActive - After the Charging Station has
confirmed HV isolation internally, it will remain in this state until
the cable isolation integrity is checked
5 EVSE_EmergencyShutdown - Charging System Incompatibility,
Emergency Shutdown or "E-Stop" button pressed at charging
station
6 EVSE_Malfunction - A non-recoverable charger fault has
occurred (Isolation Failure, etc.)
7 Reserved 8
8 Reserved 9
9 Reserved A
10 Reserved B
11 Reserved C

Calibratable: No
• EVSEVoltageLimitAchieved
If set to TRUE, the EVSE has reached its voltage limit.
Range: 0 or 1

Software detail
Value type: Boolean

Calibratable: No
• FreeService
If true, indicates that the service can be used free of charge.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• PMax
A vector of maximum amount of power to be drawn from the EVSE outlet the vehicle is
connected to.

Range: [-32768, 32767] Watts
Value type: Integer

Calibratable: No
• PMaxScheduleEntry_count
Identifies the number of PMaxScheduleEntry elements that are available in

TimeInterval_start, TimeInterval_duration, and PMax parameters.
Range: [0, 5]
Value type: Integer

Calibratable: No
• PMaxScheduleID
Unique identifier for an element of type PMaxScheduleType across a charging session
Range: [-32768, 32767]
Value type: Integer

Calibratable: No
• ResponseCode
value Description
0 OK - Indicates if the processing of the request message was
successful and no specific ResponseCodeType is defined for the
current state.
1 OK_NewSessionEstablished - Indicates processing of the
SessionSetupReq message was successful and a different
SessionID is contained in the response message than the
SessionID in the request message.
2 OK_OldSessionJoined - Indicates processing of the
SessionSetupReq message was successful and the same
SessionID as used in the request message is contained in the
response message.

Software detail
value Description
3 OK_CertificateExpiresSoon - Not used for DC charging.
4 FAILED - Indicates the processing of the request message was
not successful and no specific "responseCodeType" is defined
for the current error case.
5 FAILED_SequenceError - Indicates the EVSE has received an
unexpected request message.
6 FAILED_ServiceIDInvalid - Not used for DC charging.
7 FAILED_UnknownSession - Indicates the SessionID in the
request message does not fit to the EVSE provided SessionID
during SessionSetupRes.
8 FAILED_ServiceSelectionInvalid - Indicates
the SelectedServiceID contained in the
ServicePaymentSelectionReq is not not offered by the SECC.
9 FAILED_PaymentSelectionInvalid - Indicates
the SelectedPaymentOption contained in the
ServicePaymentSelectionReq message was not part of the
offered PaymentOptions of ServiceDiscoveryRes.
10 FAILED_CertificateExpired - Not used for DC charging.
11 FAILED_SignatureError - Indicates the validation of the Security
element in the message header failed.
12 FAILED_NoCertificateAvailable - Not used for DC charging.
13 FAILED_CertChainError - Not used for DC charging.
14 FAILED_ChallengeInvalid - Not used for DC charging.
15 FAILED_ContractCanceled - Not used for DC charging.
16 FAILED_WrongChargeParameter - Indicates if the contents
of ChargeParameterDiscoveryReq message is not valid, e.g.,
wrong parameter set is provided, one or multiple parameters
cannot be interpreted.
17 FAILED_PowerDeliveryNotApplied - Indicates the EVSE is not
able to deliver energy
18 FAILED_TariffSelectionInvalid - Indicates the charging profile
in the PowerDeliveryReq message contains a SAtupleID which
was not contained in the 'SASchedules' attribute provided in
'ChargeParameterDiscoveryRes'.
19 FAILED_ChargingProfileInvalid - Indicates the charging profile
in the PowerDeliveryReq message violates a power limitation
provided in 'ChargeParameterDiscoveryRes'.
20 FAILED_EVSEPresentVoltageToLow - Not used for DC
charging.
21 FAILED_MeteringSignatureNotValid - Not used for DC charging.
22 FAILED_WrongEnergyTransferType - The vehicle requested
energy transfer does not match what the DC Supply is able to
deliver.

Calibratable: No
• SAScheduleList_size

Software detail
Identifies the number of SAScheduleList elements that are available in the

The application should unpack the value of each SAScheduleList element separately by
calling the block with the Vehicle to grid message parameter set to "DIN_SAScheduleList".
Range: [0, 3]
Value type: Integer

Calibratable: No
• SAScheduleTupleID

Range: [-32768, 32767]
Value type: Integer

Calibratable: No
• ServiceCategory
Category of a service, corresponds to the defined services, derived from the base service.
value Description
0 EVCharging
1 Internet
2 ContractCertificate
3 OtherCustom

Calibratable: No
• ServiceID
Unique identifier of the service
Range: [0, 65535]
Value type: Integer

Calibratable: No
• TimeInterval_duration
A vector of duration of the interval, in seconds.

Value type: Integer

Calibratable: No
• TimeInterval_start
A vector of start of the interval, in seconds from NOW.


Software detail
Value type: Integer

Calibratable: No

DIN_SessionSetupReq transmit error
DIN_SessionSetupRes receive flag
ResponseCode
EVSEID
EVSEID_length
DateTimeNow_present
DateTimeNow
DIN_ServiceDiscoveryReq transmit error
DIN_ServiceDiscoveryRes receive flag
ResponseCode
ServiceID
ServiceCategory
FreeService
EnergyTransferType
DIN_ServicePaymentSelectionReqtransmit error
SelectedServiceID
DIN_ServicePaymentSelectionRes receive flag
ResponseCode
DIN_ContractAuthenticationReq transmit error
DIN_ContractAuthenticationRes receive flag
ResponseCode
EVSEProcessing
DIN_ChargeParameterDiscoveryReq
transmit error
EVRequestedEnergyTransferType
EVReady
EVCabinConditioning_enable
EVCabinConditioning
EVRESSConditioning_enable
EVRESSConditioning
EVErrorCode
EVRESSSOC
EVMaximumCurrentLimit

Software detail

EVMaximumPowerLimit_enable
EVMaximumPowerLimit
EVMaximumVoltageLimit
EVEnergyCapacity_enable
EVEnergyCapacity
EVEnergyRequest_enable
EVEnergyRequest
FullSOC
BulkSOC
DIN_ChargeParameterDiscoveryRes receive flag
ResponseCode
EVSEProcessing
SAScheduleList_size
DC_EVSEChargeParameter_present
DIN_DC_EVChargeParameter data_valid
EVSEIsolationStatus_present
EVSEIsolationStatus
EVSEStatusCode
EVSEMaximumCurrentLimit
EVSEMaximumPowerLimit_present
EVSEMaximumPowerLimit
EVSEMaximumVoltageLimit
EVSEMinimumCurrentLimit
EVSEMinimumVoltageLimit
EVSECurrentRegulationTolerance_present
EVSECurrentRegulationTolerance
EVSEPeakCurrentRipple
EVSEEnergyToBeDelivered_present
EVSEEnergyToBeDelivered
DIN_SAScheduleList tuple_index tuple_available
SAScheduleTupleID
PMaxScheduleID
PMaxScheduleEntry_count
TimeInterval_start
TimeInterval_duration
PMax
DIN_CableCheckReq transmit error
EVReady
EVCabinConditioning
EVRESSConditioning
EVErrorCode
EVRESSSOC
DIN_CableCheckRes receive flag
ResponseCode
EVSEIsolationStatus
EVSEStatusCode
EVSEProcessing
DIN_Pre-ChargeReq transmit error
EVReady
EVCabinConditioning

Software detail

EVRESSConditioning
EVErrorCode
EVRESSSOC
EVTargetVoltage
EVTargetCurrent
DIN_Pre-ChargeRes receive flag
ResponseCode
EVSEIsolationStatus
EVSEStatusCode
EVSEPresentVoltage
DIN_PowerDeliveryReq transmit error
ReadyToChargeState
SAScheduleTupleID (in)
ProfileEntry_count
ChargingProfileEntryStart
ChargingProfileEntryMaxPower
EVReady
EVCabinConditioning
EVRESSConditioning
EVErrorCode
EVRESSSOC
BulkChargingComplete_enable
BulkChargingComplete
ChargingComplete
DIN_PowerDeliveryRes receive flag
ResponseCode
DC_EVSEStatus_present
EVSEIsolationStatus
EVSEStatusCode
DIN_CurrentDemandReq transmit error
EVReady
EVCabinConditioning
EVRESSConditioning
EVErrorCode
EVRESSSOC
EVTargetCurrent
EVMaximumVoltageLimit_enable
EVMaximumCurrentLimit_enable
EVMaximumPowerLimit
ChargingComplete
RemainingTimeToFullSOC_enable
RemainingTimeToFullSOC

Software detail

RemainingTimetoBulkSOC_enable
RemainingTimetoBulkSOC
EVTargetVoltage
DIN_CurrentDemandRes receive flag
ResponseCode
EVSEIsolationStatus
EVSEStatusCode
EVSEPresentVoltage
EVSEPresentCurrent
EVSECurrentLimitAchieved
EVSEVoltageLimitAchieved
EVSEPowerLimitAchieved
EVSEMaximumVoltageLimit_present
EVSEMaximumCurrentLimit_present
DIN_WeldingDetectionReq transmit error
EVReady
EVCabinConditioning
EVRESSConditioning
EVErrorCode
EVRESSSOC
DIN_WeldingDetectionRes receive flag
ResponseCode
EVSEIsolationStatus
EVSEStatusCode
EVSEPresentVoltage
DIN_SessionStopReq transmit error
DIN_SessionStopRes receive flag
ResponseCode
Value type: List

Calibratable: No
Value type: Real

Calibratable: No
6.1.103.7. Notes
None.

Software detail

(pv2g_ISO_15118_V1_Message)
Send or receive a ISO 15118 v1 vehicle to grid communication message.

All targets


transmit error
ISOv1_SessionSetupReq
pv2g_ISO_15118_V1_Message
This block partially implements the protocol ISO 15118-2:2014 (edition 1), allowing the
application to send and receive vehicle grid communication messages. The application can
use these messages to make requests to a charging station and receive responses from
the station.
Note
The platform does not support the AC charging parameters/messages, Plug and
Charge (PnC), or Transport Layer Security (TLS).
Table 6.10. ISO v1 messages

Message Description
ISOv1_SessionSetupReq By using the SessionSetupReq
message the EVCC establishes a V2G
Communication Session.
ISOv1_SessionSetupRes By using the SessionSetupRes the SECC
responds to a SessionSetupReq. With the
SessionSetupRes the SECC notifies the
EVCC with an enclosed ResponseCode,
whether establishing a new session or
joining a previous Communication Session
was successful or not.
ISOv1_ServiceDiscoveryReq By sending the ServiceDiscoveryReq
message the EVCC triggers the SECC to
by the SECC. Furthermore, the EVCC can
limit for particular services by using the
service scope and service type elements.

Software detail
Message Description
ISOv1_ServiceDiscoveryRes After receiving the ServiceDisoveryReq
message of the EVCC the SECC sends the
discovery failed the service list is empty
and the ResponseCode indicates potential
reasons.
ISOv1_ServiceList Unpack the Service Discovery Response
message ServiceList parameter.
ISOv1_ServiceDetailReq By sending the ServiceDetailReq message
the EVCC requests the SECC to send
specific additional information about
services offered by the EVSE. This
message is optional.
ISOv1_ServiceDetailRes After receiving the ServiceDetailReq
message of an EVCC the SECC sends the
ServiceDetailRes message and provides
details about services. This message is
optional.
ISOv1_ServiceParameterList Unpack the ServiceDetailRes message's
ServiceParameterList parameter.
This block retrieves the specific
parameter for a specific service given
two indices. The parameter_set_index
retrieves a ParameterSet from the
ServiceParameterList while the
parameter_index gets the specific
parameter from this parameter set.
This block has six different data type
outputs, however only one of them will
be populated and output (i.e. one of
boolValue, byteValue, shortValue, intValue,
physicalValue, or stringValue).
ISOv1_PaymentServiceSelectionReq This request message transports the
how all the selected services are paid.
ISOv1_PaymentServiceSelectionRes With this message the SECC informs the
payment option were accepted. Depending
on the selected payment additional
messages (PaymentDetails message pair)
are exchanged.
ISOv1_AuthorizationReq If a generated challenge was sent by
the SECC in a previous message, the
EVCC sends back this challenge and
the respective signature. Otherwise, the
message is empty.
ISOv1_AuthorizationRes Finally, the SECC verifies the challenge
signature (and the certificate with its
chain if not done before) and sends the

Software detail
Message Description
corresponding authorization response
message.
ISOv1_ChargeParameterDiscoveryReq By sending the
ChargeParameterDiscoveryReq message
the EVCC provides its charging parameters
to the SECC. This message provides status
information about the EV and additional
charging parameters, like estimated
energy amounts for recharging the vehicle,
capabilities of the EV charging system and
the point in time the vehicle operator intends
to leave the EVSE.
ISOv1_ChargeParameterDiscoveryRes With the ChargeParameterDiscoveryRes
consumption or a combination of these. The
term cost refers to any kind of cost specified
in this version of the standard and is not
limited to monetary costs. Based on this
cost information the EV may optimize its
charging schedule for the requested amount
of energy.
ISOv1_DC_EVChargeParameter Unpack the ChargeParameterDiscoveryRes
message, DC_EVSEChargeParameter
parameter.
ISOv1_SAScheduleList Unpack the ChargeParameterDiscoveryRes
message, SAScheduleList parameter.
ISOv1_SalesTariffList Unpack the ChargeParameterDiscoveryRes
message, SalesTariff parameter.
ISOv1_CableCheckReq The CableCheckReq asks for the cable
check status of the EVSE and e.g. tells the
EVSE if the connector is locked on EV side
and if the EV is ready to charge.
ISOv1_CableCheckRes After receiving the CableCheckReq from the
EVCC the SECC sends the CableCheckRes
informing the EVCC about result of cable
check and EVSE status.
ISOv1_Pre-ChargeReq Pre charge is used for adjusting the EVSE
output voltage to the EV battery voltage.
The PreChargeReq is used to start the Pre
Charge process from EV side.
ISOv1_Pre-ChargeRes After receiving the PreChargeReq from the
EVCC the SECC sends the PreChargeRes
informing the EV about the EVSE status
and the present EVSE output voltage.
ISOv1_PowerDeliveryReq By sending the PowerDeliveryReq the
EVCC requests the SECC to provide
power on and transmits the ChargingProfile

Software detail
Message Description
the EVCC will follow during the charging
process.
ISOv1_PowerDeliveryRes After receiving the PowerDeliveryReq
ISOv1_CurrentDemandReq By sending the CurrentDemandReq the EV
requests a certain current from the EVSE.
Also the target voltage, current and voltage
difference are transferred.
ISOv1_CurrentDemandRes After receiving the CurrentDemandReq
from the EVCC the SECC sends the
CurrentDemandRes informing the EV about
the EVSE status and the present EVSE
output voltage and current.
ISOv1_WeldingDetectionReq By sending the WeldingDetectionReq the
EV requests welding detection on EVSE
side.
ISOv1_WeldingDetectionRes After receiving the WeldingDetectionReq
Welding Detection Response informing the
EV about the EVSE status and the present
ISOv1_SessionStopReq By sending the SessionStopReq the
EVCC requests termination of the charging
process.
ISOv1_SessionStopRes After receiving the SessionStopReq
of the EVCC the SECC sends the
SessionStopRes informing the EVCC if
terminating the charging process was
successful.
6.1.104.4. Inports
• list_index
Specifies the index of the Service list to access
Range: [0, 7]
Value type: Integer

Calibratable: No
• parameter_index
Specifies the index of the Parameter within the ParameterSet to access
Range: [0, 15]
Value type: Integer

Calibratable: No
• parameter_set_index
Specifies the index of the ParameterSet within the ServiceParameterList to access

Software detail
Range: [0, 4]
Value type: Integer

Calibratable: No
• transmit
Range: 0 or 1
Value type: Boolean

Calibratable: No
• tuple_index
Range: [0, 2]
Value type: Integer

Calibratable: No

Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:
Range: 0 or 1
Value type: Boolean

Calibratable: No
• BulkSOC
Optional element:
Value type: Integer

Calibratable: No
• ChargeProgress
This message element is used to request the EVSE to fulfill all conditions that the energy
transfer can start as soon as the EV onboard system begins to retrieve energy without any
further action to be taken.

Software detail
value Description
0 Start
1 Stop
2 Renegotiate

Calibratable: No
Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:

Range: [-32768000, 32767000] Watts
Value type: Real

Calibratable: No
Optional element:

Value type: Integer

Calibratable: No
• ChargingSession
Indicates the intention of the EVCC to either pause or terminate a V2G Communication
Session
value Description
0 Terminate
1 Pause

Calibratable: No
• ConsumptionCost_index
Specifies the index of the ConsumptionCost list to access.
Range: [0, 2]

Software detail
Value type: Integer

Calibratable: No
• DepartureTime
This signal is used to indicate when the vehicle intends to finish the charging process.
Offset in seconds from the point in time of sending this message. A value of 0 disables
the optional message element
Value type: Integer

Calibratable: No
• EVEnergyCapacity_enable
If set to TRUE, the optional message element, EVEnergyCapacity, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVEnergyCapacity
Optional element:
Maximum energy capacity supported by the vehicle
Range: [-32768000, 32767000] Wh
Value type: Real

Calibratable: No
• EVEnergyRequest_enable
If set to TRUE, the optional message element, EVEnergyRequest, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVEnergyRequest
Optional element:
Amount of energy requested by the vehicle
Range: [-32768000, 32767000] Wh
Value type: Real

Calibratable: No
• EVErrorCode
Indicates the EV internal status
value Description
0 Default value, when EV has no Error detected

Software detail
value Description
1 Battery Temperature Inhibit, Battery too hot/cold to accept
charge
2 Vehicle Shift Position, Vehicle is not in Park
3 Charger Connector Lock Fault, Vehicle has not detected the
Charge cord connector locked into the inlet or a failure exists
where connector cannot be unlocked from the charging inlet
4 Vehicle RESS Malfunction, Any non-recoverable fault or error
condition of the Vehicle RESS.
5 Charging Current Differential, Indication that vehicle has stopped
the Communication Session after detecting that the charging
station is not able to maintain an output current that fulfills the
current request.
6 Charging Voltage Out Of Range, Indication that vehicle has
stopped the Communication Session after detecting that the
RESS is either under or above the normal operating voltage
range
7 Reserved
8 Reserved
9 Reserved
10 Charging System Incompatibility, if the vehicle determines
that the charging station is incompatible. Using this value is
optional; as an alternative, the vehicle can use EVReady in
DC_EVStatusType equal to "FALSE"
11 No Data. Only used when vehicle has not yet determined its
operating state.

Calibratable: No
• EVMaximumCurrentLimit_enable
If set to TRUE, the optional message element, EVMaximumCurrentLimit, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVMaximumCurrentLimit
Optional element:
Maximum current supported by the vehicle.
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVMaximumPowerLimit_enable
If set to TRUE, the optional message element, EVMaximumPowerLimit, is added to the


Software detail
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVMaximumPowerLimit
Optional element:
Maximum power supported by the vehicle.
Range: [-32768000, 32767000] W
Value type: Real

Calibratable: No
• EVMaximumVoltageLimit_enable
If set to TRUE, the optional message element, EVMaximumVoltageLimit, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No
• EVReady
If set to TRUE, the vehicle is ready to charge.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVRESSSOC
State of charge of the vehicle's battery
Value type: Integer

Calibratable: No
• EVTargetCurrent
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No

Software detail
• EVTargetVoltage
Range: [-32768000, 32767000] V
Value type: Integer

Calibratable: No
• FullSOC
State of charge at which the vehicle considers the battery fully charged.
Value type: Integer

Calibratable: No
Identifies the number of charging profile entries that have been provided in the
ChargingProfileEntryStart and ChargingProfileEntryMaxPower parameters.
Value type: Integer

Calibratable: No
• RemainingTimetoBulkSOC_enable
If set to TRUE, the optional message element, RemainingTimetoBulkSOC, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• RemainingTimetoBulkSOC
Optional element:
Range: [-32768000, 32767000] seconds
Value type: Real

Calibratable: No
• RemainingTimeToFullSOC_enable
If set to TRUE, the optional message element, RemainingTimeToFullSOC, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• RemainingTimeToFullSOC
Optional element:
Estimated or calculated time until full charge is complete.

Software detail
Range: [-32768000, 32767000] seconds
Value type: Real

Calibratable: No
• RequestedEnergyTransferMode
Selected energy transfer mode for charging that is requested by the EVCC.
value Description
0 AC single phase core - AC single phase charging according to
IEC 62196.
1 AC three phase core - AC three phase charging according to IEC
62196.
2 DC core - DC charging according to IEC 62196 on the core pins.
3 DC extended - DC charging using the extended pins of an IEC
62196-3 Configuration EE or Configuration FF connector.
4 DC combo core - DC charging using the core pins of an IEC
5 DC unique - DC charging using a dedicated DC coupler.

Calibratable: No
• SalesTariffEntry_index
Specifies the index of the SalesTariffEntry list to access.
Range: [0, 4]
Value type: Integer

Calibratable: No
• SASchedule_tuple_index
Specifies the index of the SASchedule list to access.
Range: [0, 2]
Value type: Integer

Calibratable: No

Range: [0, 255]
Value type: Integer

Calibratable: No
• SelectedServiceID
Service ID of the service selected by the EVCC
Range: [0, 65535]

Software detail
Value type: Integer

Calibratable: No
• ServiceID (in)
This element identifies a service which has been offered by the SECC in the
ServiceDiscoveryRes message.
Range: [0, 65535]
Value type: Integer

Calibratable: No
• ServiceScope_length (in)
This parameter defines the length of the array of characters defined in the ServiceScope
(in) parameter.
Range: [0, 64] entries, if set to 0, the optional message element is removed.
Value type: Integer

Calibratable: No
• ServiceScope (in)
This optional parameter is an array of ASCII characters that allows the EVCC to filter the
list of returned services from the SECC.

Range: [0, 255]
Value type: Integer

Calibratable: No
6.1.104.5. Outports
• data_valid
Range: 0 or 1
Value type: Boolean

Calibratable: No
• error
Range: 0 or 1
Value type: Boolean

Calibratable: No
• index_valid
Range: 0 or 1
Value type: Boolean

Calibratable: No

Software detail
• receive flag
Range: 0 or 1
Value type: Boolean

Calibratable: No
• tuple_available
Range: 0 or 1
Value type: Boolean

Calibratable: No
• ConsumptionCost_length
Indicates the number of ConsumptionCost entries that have been populated by the SECC.
Value type: Integer

Calibratable: No
• ConsumptionCostStartValue
This signal indicates the lowest level of consumption that defines the starting point
of specified consumption block (by index ConsumptionCost_index). The block interval
extends to the start of the next interval.
Range: [-32768000, 32767000]
Value type: Real

Calibratable: No
• Cost_length
Indicates the number of different types of costs that are relevant to the Consumption block
specified by ConsumptionCost_index.
Value type: Integer

Calibratable: No
• CostAmount
A vector of the estimated or actual cost per kWh of each cost in the Consumption block.
The cost kind is defined by the same index of the CostKind parameter.
Range: [0, 4294967295000] kWh
Value type: Real

Calibratable: No
• CostKind
A vector of the kind of cost for each Cost in the Consumption block. The cost amount is
defined by the same index of the CostAmount parameter.

Software detail
value Description
0 relativePricePercentage
1 RenewableGenerationPercentage
2 CarbonDioxideEmission

Calibratable: No

"ISOv1_DC_EVChargeParameter".
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EnergyTransferMode_size
Identifies the size of the valid data in the EnergyTransferMode parameter.
Value type: Integer

Calibratable: No
• EnergyTransferMode
Available charging types or methods supported by the EVSE.
value Description
0 AC single phase core - AC single phase charging according to
IEC 62196.
1 AC three phase core - AC three phase charging according to IEC
62196.
2 DC core - DC charging according to IEC 62196 on the core pins.
3 DC extended - DC charging using the extended pins of an IEC
4 DC combo core - DC charging using the core pins of an IEC
5 DC unique - DC charging using a dedicated DC coupler.

Calibratable: No
Range: 0 or 1

Software detail
Value type: Boolean

Calibratable: No
Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:
Range: [-32768000, 32767000] Wh
Value type: Real

Calibratable: No
• EVSEID_length
Value type: Integer

Calibratable: No
• EVSEID
message element is defined in ISO 15118-2:2014.

Range: [0, 255]
Value type: Integer

Calibratable: No
• EVSEIsolationStatus_present

Software detail
Identifies the presence of the EVSEIsolationStatus parameter.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSEIsolationStatus
Optional element:
Indicates the isolation condition
value Description
0 Invalid - DC Supply may transmit this enumeration at startup
before measurement has been confirmed.
1 Valid - Isolation measurement confirms the system is within the
Valid region above thresholds
2 Warning - Isolation has detected a measurement below the
Warning level threshold.
3 Fault - Isolation has detected a measurement below the Fault
level threshold.
4 No IMD - The EVSE does not contain an IMD and therefore
cannot carry out an isolation test.

Calibratable: No
Identifies the presence of the EVSEMaximumCurrentLimit parameter.
Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:
Range: [-32768000, 32767000] A
Value type: Integer

Calibratable: No
Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:

Software detail
Range: [-32768000, 32767000] W
Value type: Integer

Calibratable: No
Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No
• EVSEMinimumCurrentLimit
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVSEMinimumVoltageLimit
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVSENotification
This signal is used by the SECC to influence the behavior of the EVCC. This parameter
contains an action that the SECC wants the EVCC to perform. The requested action is
expected by the EVCC until the time provided in EVSENotificationMaxDelay. If the target
time is not in the future, the EVCC is expected to perform the action immediately. During
normal operation this value is usually set to "None".
value Description
0 None
1 StopCharging
1 ReNegotiation

Calibratable: No
• EVSENotificationMaxDelay

Software detail
This signal is used by the SECC to indicate the time until it expects the EVCC to react on
the action request indicated in the EVSENotification parameter.
Value type: Integer

Calibratable: No
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
Range: 0 or 1
Value type: Boolean

Calibratable: No
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No
• EVSEProcessing
was sent.
value Description
0 Finished
1 Ongoing
2 Ongoing_WaitingForCustomerInteraction

Calibratable: No
• EVSEStatus_present

Software detail
Identifies the presence of the DC_EVSEStatus parameter which includes

the EVSENotificationMaxDelay, EVSENotification, EVSEIsolationStatus_present,
EVSEIsolationStatus, and EVSEStatusCode parameters. If set to FALSE, these
parameters should be ignored.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSEStatusCode
Indicates the internal state of the EVSE.
value Description
0 EVSE_NotReady - Not authorized, StandBy, on maintenance
1 EVSE_Ready - Standard value used during normal operation
2 EVSE_Shutdown - Charger Shutdown, Customer Initiated
Shutdown
3 EVSE_UtilityInterruptEvent - Utility Interrupt Event, Utility or
Equipment operator has requested a temporary reduction in load.
4 EVSE_IsolationMonitoringActive - After the Charging Station has
confirmed HV isolation internally, it will remain in this state until
the cable isolation integrity is checked
5 EVSE_EmergencyShutdown - Charging System Incompatibility,
Emergency Shutdown or "E-Stop" button pressed at charging
station
6 EVSE_Malfunction - A non-recoverable charger fault has
occurred (Isolation Failure, etc.)
7 Reserved 8
8 Reserved 9
9 Reserved A
10 Reserved B
11 Reserved C

Calibratable: No
• EVSETimeStamp_present
Identifies the presence of the EVSETimeStamp parameter.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSETimeStamp
Optional element:
Range: [-2147483648, 2147483647] seconds

Software detail
Note
data to be 03:14:07 UTC 2038-01-19.
Value type: Integer

Calibratable: No
Range: 0 or 1
Value type: Boolean

Calibratable: No
• FreeService
If true, indicates that the service can be used free of charge.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• NumEPriceLevels_present
Identifies the presence of the NumEPriceLevels parameter.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• NumEPriceLevels
Optional element:
This signal is used to define the overall number of distinct price levels used across all
provided SalesTariff elements.
Range: [0, 255]
Value type: Integer

Calibratable: No
• Parameter_IntegerValue
If the parameter data type is one of boolValue, byteValue, shortValue or intValue it will be
returned as a signed 32-bit value through this signal. The underlying type is available as
an enum in the ParameterType parameter.
Range: [-2147483648, 2147483647]
Value type: Integer

Calibratable: No
• Parameter_PhysicalValue

Software detail
If the parameter data type is physicalValue it will be returned as a 32-bit floating point value
through this signal. The underlying type is available as an enum in the ParameterType
parameter.
Range: [-32768000, 32767000]
Value type: Real

Calibratable: No
• Parameter_String_length
If the parameter data type is stringValue it will be returned as an array of bytes with
the length set through this signal. The underlying type is available as an enum in the
ParameterType parameter.
Value type: Integer

Calibratable: No
• Parameter_StringValue
the value set through this signal. The underlying type is available as an enum in the

Range: [0, 255]
Value type: Integer

Calibratable: No
• ParameterName_length
Identifies the length of the valid data in the ParameterName parameter.
Range: [0, 51]
Value type: Integer

Calibratable: No
• ParameterName
Human readable name of the parameter being retrieved..

Range: [0, 255]
Value type: Integer

Calibratable: No
• ParameterSet_length
Actual number of Parameter elements in the ParameterSet.
Value type: Integer

Calibratable: No
• ParameterSetID

Software detail
This element is used to select a specific parameter set for a specific ServiceID when
selecting a service using the PaymentServiceSelectionReq message.
Range: [0, 65535]
Value type: Integer

Calibratable: No
• ParameterType
value Description
0 boolValue
1 byteValue
2 shortValue
3 intValue
4 physicalValue
5 stringValue

Calibratable: No
• PaymentOptions_size
Identifies the size of the valid data in the PaymentOptions parameter.
Value type: Integer

Calibratable: No
• PaymentOptions
This element includes the list of payment options an SECC offers to the EVCC indicating
what method could be chosen to pay for the services. The EVCC can only select one
payment method for all services used by the EVCC.
value Description
0 Contract
1 ExternalPayment

Calibratable: No
• PMax
connected to.

Range: [-32768000, 32767000] Watts
Value type: Integer

Calibratable: No

Software detail

Range: [0, 5]
Value type: Integer

Calibratable: No
• ResponseCode
value Description
current state.
response message.
4 FAILED - Indicates the processing of the request message was
not successful and no specific "responseCodeType" is defined
for the current error case.
5 FAILED_SequenceError - Indicates the EVSE has received an
unexpected request message.
6 FAILED_ServiceIDInvalid - Not used for DC charging.
7 FAILED_UnknownSession - Indicates the SessionID in the
request message does not fit to the EVSE provided SessionID
during SessionSetupRes.
8 FAILED_ServiceSelectionInvalid - Indicates
the SelectedServiceID contained in the
ServicePaymentSelectionReq message is not offered by the
SECC.
9 FAILED_PaymentSelectionInvalid - Indicates
the SelectedPaymentOption contained in the
ServicePaymentSelectionReq message was not part of the
offered PaymentOptions of ServiceDiscoveryRes.
10 FAILED_CertificateExpired - Not used for DC charging.
11 FAILED_SignatureError - Indicates the validation of the Security
element in the message header failed.
12 FAILED_NoCertificateAvailable - Not used for DC charging.
13 FAILED_CertChainError - Not used for DC charging.
14 FAILED_ChallengeInvalid - Not used for DC charging.
15 FAILED_ContractCanceled - Not used for DC charging.

Software detail
value Description
16 FAILED_WrongChargeParameter - Indicates if the contents
of ChargeParameterDiscoveryReq message is not valid, e.g.,
wrong parameter set is provided, one or multiple parameters
cannot be interpreted.
17 FAILED_PowerDeliveryNotApplied - Indicates the EVSE is not
able to deliver energy
18 FAILED_TariffSelectionInvalid - Indicates the charging profile
in the PowerDeliveryReq message contains a SAtupleID which
was not contained in the 'SASchedules' attribute provided in
'ChargeParameterDiscoveryRes'.
19 FAILED_ChargingProfileInvalid - Indicates the charging profile
in the PowerDeliveryReq message violates a power limitation
provided in 'ChargeParameterDiscoveryRes'.
20 FAILED_MeteringSignatureNotValid
21 FAILED_NoChargeServiceSelected
22 FAILED_WrongEnergyTransferMode - The vehicle requested
energy transfer does not match what the DC Supply is able to
deliver.
23 FAILED_ContactorError
24 FAILED_CertificateNotAllowedAtThisEVSE
25 FAILED_CertificateRevoked

Calibratable: No
• SalesTariff_length
Indicates the number of SalesTariff entries that have been populated by the SECC.
The application should unpack the value of each SalesTariff entry separately by calling the
block with the Vehicle to grid message parameter set to "ISOv1_SalesTariffList".
Value type: Integer

Calibratable: No
• SalesTariff_present
Indicates that the SalesTariff parameter in the response message has been populated by
EVSE.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• SalesTariffDescription_length
Actual number of elements in the SalesTariffDescription parameter. If output is set to 0,

the description is empty and should be ignored.

Software detail
Range: [0, 33]
Value type: Integer

Calibratable: No
• SalesTariffDescription
Optional element:
A vector of human readable title/short description text of the sales tariff (e.g. for HMI display
purposes).

Range: [0, 255]
Value type: Integer

Calibratable: No
• SalesTariffEntryDuration
This signal defines the duration of the interval of how long the SalesTariffEntry being
indexed by SalesTariffEntry_index is valid for, in seconds.
Value type: Integer

Calibratable: No
• SalesTariffEntryEPriceLevel_present
Indicates that the SalesTariffEntryEPriceLevel parameter has been received.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• SalesTariffEntryEPriceLevel
Optional element:
This signal is used to define the price level of the SalesTariffEntry being indexed by
SalesTariffEntry_index. Small values for this parameter represent a cheaper TariffEntry,
large values represent more expensive TariffEntry.
Range: [0, 255]
Value type: Integer

Calibratable: No
• SalesTariffEntryStart
This signal defines the start of the interval of when the SalesTariffEntry being indexed by
SalesTariffEntry_index is valid from, in seconds.
Value type: Integer

Calibratable: No
• SalesTariffID
This signal is used to uniquely identify one sales tariff. A sales tariff ID remains a unique
identifier for one schedule throughout a charging session.

Software detail
Range: [0, 255]
Value type: Integer

Calibratable: No

The application should unpack the value of each SAScheduleList element separately
by calling the block with the Vehicle to grid message parameter set to
"ISOv1_SAScheduleList".
Range: [0, 3]
Value type: Integer

Calibratable: No

Range: [-32768, 32767]
Value type: Integer

Calibratable: No
• ServiceCategory
Category of a service, corresponds to the defined services, derived from the base service.
value Description
0 EVCharging
1 Internet
2 ContractCertificate
3 OtherCustom

Calibratable: No
• ServiceID
Range: [0, 65535]
Value type: Integer

Calibratable: No
• ServiceList_size
Actual number of elements in the ServiceList parameter. If this value is 0 then the
ServiceList parameter is not present and should be ignored.
The application should unpack the value of each ServiceList parameter separately by
calling the block with the Vehicle to grid message parameter set to "ISOv1_ServiceList".

Software detail
Value type: Integer

Calibratable: No
• ServiceName_length
Actual number of elements in the ServiceName parameter. If this value is 0 then the
ServiceName element is not present and ServiceName should be ignored.
Value type: Integer

Calibratable: No
• ServiceName_size
Actual number of elements in the ServiceName parameter. If this value is 0 then the
ServiceName element is not present and ServiceName should be ignored.
Value type: Integer

Calibratable: No
• ServiceName
Optional element:
Human readable service name of the service being retrieved.

Range: [0, 255]
Value type: Integer

Calibratable: No
• ServiceParameterSet_length
Actual number of elements in the ServiceParameterList parameter. If the output is 0, the

list is empty and should be ignored.
The application should unpack the value of each ServiceParameterList parameter

"ISOv1_ServiceParameterList".
Value type: Integer

Calibratable: No
• ServiceParameterSet_Sizes
A vector of array lengths of each parameter in each parameter set.

(i.e holds the array length of ServiceDetailRes -> ServiceParameterList -> ParameterSet
-> Parameter)

Value type: Integer

Calibratable: No

Software detail
• ServiceScope_length
Actual number of elements in the ServiceScope parameter. If this value is 0 then the
ServiceScope is not present and should be ignored.
Value type: Integer

Calibratable: No
• ServiceScope_size
Actual number of elements in the ServiceScope parameter. If this value is 0 then the
ServiceScope is not present and should be ignored.
Value type: Integer

Calibratable: No
• ServiceScope
Optional element:
Provides additional information about the usage of the retrieved service.

Range: [0, 255]
Value type: Integer

Calibratable: No

Value type: Integer

Calibratable: No

Value type: Integer

Calibratable: No

Software detail

ISOv1_SessionSetupReq transmit error
ISOv1_SessionSetupRes receive flag
ResponseCode
EVSEID
EVSEID_length
EVSETimeStamp_present
EVSETimeStamp
ISOv1_ServiceDiscoveryReq transmit error
ServiceScope (in)
ServiceScope_length (in)
ISOv1_ServiceDiscoveryRes receive flag
ResponseCode
PaymentOptions
PaymentOptions_size
ServiceID
ServiceName
ServiceName_length
ServiceCategory
ServiceScope
ServiceScope_length
FreeService
EnergyTransferMode
EnergyTransferMode_size
ServiceList_size
ISOv1_ServiceList list_index index_valid
ServiceID
ServiceName
ServiceName_size
ServiceCategory
ServiceScope
ServiceScope_size
FreeService
ISOv1_ServiceDetailReq transmit error
ServiceID (in)
ISOv1_ServiceDetailRes receive flag
ResponseCode

Software detail

ServiceID
ServiceParameterSet_length
ServiceParameterSet_Sizes
ISOv1_ServiceParameterList parameter_set_index index_valid
parameter_index ParameterSetID
ParameterSet_length
ParameterName
ParameterName_length
ParameterType
Parameter_IntegerValue
Parameter_PhysicalValue
Parameter_StringValue
Parameter_String_length
ISOv1_PaymentServiceSelectionReq
transmit error
SelectedServiceID
ISOv1_PaymentServiceSelectionRes receive flag
ResponseCode
ISOv1_AuthorizationReq transmit error
ISOv1_AuthorizationRes receive flag
ResponseCode
EVSEProcessing
ISOv1_ChargeParameterDiscoveryReq
transmit error
RequestedEnergyTransferMode
DepartureTime
EVReady
EVErrorCode
EVRESSSOC
EVMaximumPowerLimit
EVEnergyCapacity_enable
EVEnergyCapacity
EVEnergyRequest_enable
EVEnergyRequest
FullSOC
BulkSOC
ISOv1_ChargeParameterDiscoveryRes receive flag
ResponseCode
EVSEProcessing
SAScheduleList_size
ISOv1_DC_EVChargeParameter data_valid
EVSENotificationMaxDelay
EVSENotification
EVSEIsolationStatus
EVSEStatusCode
EVSEMinimumCurrentLimit
EVSEMinimumVoltageLimit

Software detail

ISOv1_SAScheduleList tuple_index tuple_available
SAScheduleTupleID
TimeInterval_start
PMax
SalesTariff_present
SalesTariff_length
ISOv1_SalesTariffList SASchedule_tuple_index data_valid
SalesTariffEntry_index SalesTariffID
ConsumptionCost_index SalesTariffDescription
SalesTariffDescription_length
NumEPriceLevels_present
NumEPriceLevels
SalesTariffEntryStart
SalesTariffEntryDuration
SalesTariffEntryEPriceLevel_present
SalesTariffEntryEPriceLevel
ConsumptionCost_length
ConsumptionCostStartValue
Cost_length
CostKind
CostAmount
ISOv1_CableCheckReq transmit error
EVReady
EVErrorCode
EVRESSSOC
ISOv1_CableCheckRes receive flag
ResponseCode
EVSENotification
EVSEIsolationStatus
EVSEStatusCode
EVSEProcessing
ISOv1_Pre-ChargeReq transmit error
EVReady
EVErrorCode
EVRESSSOC
EVTargetVoltage
EVTargetCurrent
ISOv1_Pre-ChargeRes receive flag
ResponseCode
EVSENotification
EVSEIsolationStatus
EVSEStatusCode
EVSEPresentVoltage

Software detail
ISOv1_PowerDeliveryReq transmit error

ChargeProgress
ProfileEntry_count
EVReady
EVErrorCode
EVRESSSOC
ChargingComplete
ISOv1_PowerDeliveryRes receive flag
ResponseCode
EVSEStatus_present
EVSENotification
EVSEIsolationStatus
EVSEStatusCode
ISOv1_CurrentDemandReq transmit error
EVReady
EVErrorCode
EVRESSSOC
EVTargetCurrent
EVMaximumVoltageLimit_enable
EVMaximumCurrentLimit_enable
EVMaximumPowerLimit
ChargingComplete
RemainingTimeToFullSOC_enable
RemainingTimeToFullSOC
RemainingTimetoBulkSOC_enable
RemainingTimetoBulkSOC
EVTargetVoltage
ISOv1_CurrentDemandRes receive flag
ResponseCode
EVSENotification
EVSEIsolationStatus
EVSEStatusCode
EVSEPresentVoltage
EVSEPresentCurrent

Software detail

EVSEID
EVSEID_length
SAScheduleTupleID
ISOv1_WeldingDetectionReq transmit error
EVReady
EVErrorCode
EVRESSSOC
ISOv1_WeldingDetectionRes receive flag
ResponseCode
EVSENotification
EVSEIsolationStatus
EVSEStatusCode
EVSEPresentVoltage
ISOv1_SessionStopReq transmit error
ChargingSession
ISOv1_SessionStopRes receive flag
ResponseCode
Value type: List

Calibratable: No
Value type: Real

Calibratable: No
6.1.104.7. Notes
None.

(pv2g_ISO_15118_V2_Message)
Send or receive a ISO 15118 v2 vehicle to grid communication message.

All targets


Software detail

transmit error
ISOv2_SessionSetupReq
pv2g_ISO_15118_V2_Message
This block partially implements the Committee Draft (CD) of protocol ISO 15118-20 (edition
2) circulated on 2017-03-24, allowing the application to send and receive vehicle grid
communication messages. The application can use these messages to make requests to a
charging station and receive responses from the station.
Note
The ISO 15118-20 standard is still in progress and has not become an international
standard at the time of blockset implementation. It is expected that changes to the
final draft of the standard will require blockset changes once complete. In addition,
the platform does not support the AC charging parameters/messages, Plug and
Charge (PnC), Wireless Power Transfer (WPT), Automatic Connection Device (ACD)
or Transport Layer Security (TLS).
Table 6.11. ISO v2 messages

Message Description
ISOv2_Set_DisplayParameters Configure the optional DisplayParameters
element for messages CurrentDemandReq
and DC_BidirectionalControlReq
ISOv2_SessionSetupReq By using the SessionSetupReq
message the EVCC establishes a V2G
communication session.
ISOv2_SessionSetupRes By using the SessionSetupRes the SECC
responds to a SessionSetupReq. With the
SessionSetupRes the SECC notifies the
EVCC with an enclosed ResponseCode,
whether establishing a new session or
joining a previous communication session
was successful or not.
ISOv2_ServiceDiscoveryReq By sending the ServiceDiscoveryReq
message the EVCC triggers the SECC to
by the SECC. Furthermore, the EVCC can
limit for particular services by using the
service scope and service type elements.
ISOv2_ServiceDiscoveryRes After receiving the ServiceDisoveryReq
message of the EVCC the SECC sends the
discovery failed the service list is empty

Software detail
Message Description
and the ResponseCode indicates potential
reasons.
ISOv2_ServiceDetailReq By sending the ServiceDetailReq message
the EVCC requests the SECC to send
specific additional information about
services offered by the EV supply
equipment. This message is optional.
ISOv2_ServiceDetailRes After receiving the ServiceDetailReq
message of an EVCC the SECC sends the
ServiceDetailRes message and provides
details about services. This message is
optional.
ISOv2_ServiceParameterList Unpack the ServiceDetailRes message's
ServiceParameterList parameter.
ISOv2_PaymentServiceSelectionReq This request message transports the
how all the selected services are paid
ISOv2_PaymentServiceSelectionRes With this message the SECC informs the
payment option were 2249 accepted.
ISOv2_AuthorizationReq If a generated challenge was sent by
the SECC in a previous message, the
EVCC sends back this challenge and
the respective signature. Otherwise, the
message is empty.
ISOv2_AuthorizationRes Finally, the SECC verifies the challenge
signature (and the certificate with its
chain if not done before) and sends the
corresponding authorization response
message.
ISOv2_DC_ChargeParameterDiscoveryReq By sending the
DC_ChargeParameterDiscoveryReq
message the EVCC provides its charging
parameters to the SECC. This message
provides status information about the EV
and additional charging parameters, like
estimated energy amounts for recharging
the vehicle, capabilities of the EV charging
system, and the point in time the vehicle
operator intends to leave the EVSE. This
block shall be used if the EVCC wants to
start a DC charge service, as this block
populates the DC_EVChargeParameter
field of the ChargeParameterDiscoveryReq
message. If the EVSE instead, wants to
start a DC Bidirectional charge service, the
ISOv2_Bidirectional_ChargeParameterDiscoveryReq
block shall be used.
By sending the
Bidirectional_ChargeParameterDiscoveryReq
message the EVCC provides its charging
parameters to the SECC. This message

Software detail
Message Description
provides status information about the
EV and additional charging parameters,
like estimated energy amounts for
recharging the vehicle, capabilities of
the EV charging system, and the point in
time the vehicle operator intends to leave
the EVSE. This block shall be used if the
EVCC wants to startt a DC Bidirectional
charge service, as this block populates
the DC_EVBidirectionalParameter field
of the ChargeParameterDiscoveryReq
message. If the EVSE instead, wants
to start a DC charge service, the
ISOv2_DC_ChargeParameterDiscoveryReq
block shall be used.
ISOv2_ChargeParameterDiscoveryRes With the ChargeParameterDiscoveryRes
consumption or a combination of these. The
term cost refers to any kind of cost specified
in this version of the standard and is not
limited to monetary costs. Based on this
cost information the EV may optimize its
charging schedule for the requested amount
of energy.
ISOv2_DC_EVSEChargeParameter Unpack the ChargeParameterDiscoveryRes
message, DC_EVSEChargeParameter
parameter
ISOv2_DC_EVSEBidirectionalParameter Unpack the ChargeParameterDiscoveryRes
message, DC_EVSEBidirectionalParameter
parameter
ISOv2_SAScheduleList Unpack the ChargeParameterDiscoveryRes
message, SAScheduleList parameter.
ISOv2_PMaxDischargeSchedule Unpack the ChargeParameterDiscoveryRes
message, PMaxDischargeSchedule
parameter.
ISOv2_SalesTariffList Unpack the ChargeParameterDiscoveryRes
message, SalesTariff parameter.
ISOv2_BuyBackTariffList Unpack the ChargeParameterDiscoveryRes
message, BuyBackTariff parameter.
ISOv2_CableCheckReq The CableCheckReq asks for the cable
check status of the EVSE and e.g. tells the
EVSE if the connector is locked on EV side
and if the EV is ready to charge.
ISOv2_CableCheckRes After receiving the CableCheckReq from the
EVCC the SECC sends the CableCheckRes
informing the EVCC about result of cable
check and EVSE status.

Software detail
Message Description
ISOv2_Pre-ChargeReq Pre charge is used for adjusting the EVSE
output voltage to the EV battery voltage.
The PreChargeReq is used to start the Pre
Charge process from EV side.
ISOv2_Pre-ChargeRes After receiving the PreChargeReq from the
EVCC the SECC sends the PreChargeRes
informing the EV about the EVSE status
and the present EVSE output voltage.
ISOv2_PowerDeliveryReq By sending the PowerDeliveryReq the
EVCC requests the SECC to provide
power on and transmits the ChargingProfile
the EVCC will follow during the charging
process.
ISOv2_PowerDeliveryRes After receiving the PowerDeliveryReq
ISOv2_CurrentDemandReq By sending the CurrentDemandReq the EV
requests a certain current from the EVSE.
Also the target voltage, current and voltage
difference are transferred.
ISOv2_CurrentDemandRes After receiving the CurrentDemandReq
from the EVCC the SECC sends the
CurrentDemandRes informing the EV about
the EVSE status and the present EVSE
output voltage and current.
ISOv2_WeldingDetectionReq By sending the WeldingDetectionReq the
EV requests welding detection on EVSE
side.
ISOv2_WeldingDetectionRes After receiving the WeldingDetectionReq
Welding Detection Response informing the
EV about the EVSE status and the present
ISOv2_SessionStopReq By sending the SessionStopReq the
EVCC requests termination of the charging
process.
ISOv2_SessionStopRes After receiving the SessionStopReq
of the EVCC the SECC sends the
SessionStopRes informing the EVCC if
terminating the charging process was
successful.
ISOv2_DC_BidirectionalControlReq By sending the DC_BidirectionalControlReq
the EV requests a certain current from the
EV supply equipment in the Scheduled
control mode. Also the target voltage,
current and voltage difference are
transferred. In the Flexible and Dynamic
control modes, the EV provides its charging
limits to the EV supply equipment

Software detail
Message Description
ISOv2_DC_BidirectionalControlRes After receiving the
DC_BidirectionalControlReq from
the EVCC the SECC sends the
DC_BidirectionalControlRes informing the
EV about the EV supply equipment status
and the present EV supply equipment DC
side output voltage and current. Other
charging and discharging information is also
provided.
6.1.105.4. Inports
• parameter_index
Specifies the index of the Parameter within the ParameterSet to access
Range: [0, 15]
Value type: Integer

Calibratable: No
• parameter_set_index
Specifies the index of the ParameterSet within the ServiceParameterList to access
Range: [0, 4]
Value type: Integer

Calibratable: No
• transmit
Range: 0 or 1
Value type: Boolean

Calibratable: No
• tuple_index
Range: [0, 2]
Value type: Integer

Calibratable: No

Range: 0 or 1
Value type: Boolean

Calibratable: No

Software detail
Optional element:
Range: 0 or 1
Value type: Boolean

Calibratable: No
• BulkSOC
Optional element:
Value type: Integer

Calibratable: No
• ChargeProgress
This message element is used to request the EVSE to fulfill all conditions that the energy
transfer can start as soon as the EV onboard system begins to retrieve energy without any
further action to be taken.
value Description
0 Start
1 Stop
2 Renegotiate

Calibratable: No
• ChargingComplete_enable
If set to TRUE, the optional message element, ChargingComplete, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:
Range: 0 or 1
Value type: Boolean

Calibratable: No
• ChargingPerformance_enable
If set to TRUE, the optional message element, ChargingPerformance, is added to the

Range: 0 or 1
Value type: Boolean

Software detail
Calibratable: No
• ChargingPerformance
Optional element:
This parameter is part of the DisplayParameters parameter.
Range: [-32768000, 32767000]
Value type: Real

Calibratable: No
• ChargingProfileEntryDuration
Optional element:
A vector of values specifying the duration that the chargingProfileEntry is valid.

Value type: Integer

Calibratable: No
Optional element:

Range: [-32768000, 32767000] Watts
Value type: Real

Calibratable: No
Optional element:

Value type: Integer

Calibratable: No
• ChargingSession
Indicates the intention of the EVCC to either pause or terminate a V2G Communication
Session
value Description
0 Terminate
1 Pause

Calibratable: No
• ConsumptionCost_index

Software detail
Specifies the index of the ConsumptionCost list to access.
Range: [0, 2]
Value type: Integer

Calibratable: No
• CurrentRange_enable
If set to TRUE, the optional message element, CurrentRange, is added to the message.
Otherwise the message element is removed.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• CurrentRange
Optional element:
This optional signal represents the current range of the EV.
Range: [0, 65535]
Value type: Integer

Calibratable: No
• CurrentSOC
This signal represents the current state of charge of the EV.
Range: [0, 100], -1 disables the optional message element
Value type: Integer

Calibratable: No
• DC_EVBidirectionalParameter_enable
This parameter enables the DC_EVBidirectionalParameter parameter of the message.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• DC_EVChargeParameter_enable
This parameter enables the DC_EVChargeParameter parameter of the message.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• DepartureTime
This signal is used to indicate when the vehicle intends to finish the charging process.
Offset in seconds from the point in time of sending this message. A value of 0 disables
the optional message element

Software detail
Value type: Integer

Calibratable: No
• EVMaximumChargeCurrent
This is a signal from the vehicle to the DC Supply indicating its maximum allowed current.
In other words, it's the maximum current limit allowed by the vehicle.
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVMaximumChargePower_enable
If set to TRUE, the optional message element, EVMaximumChargePower, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVMaximumChargePower
Optional element:
This signal represents the maximum power limit allowed by the vehicle.
Range: [-32768000, 32767000] W
Value type: Real

Calibratable: No
• EVMaximumCurrent_enable
If set to TRUE, the optional message element, EVMaximumCurrent, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVMaximumCurrent
Optional element:
This is a signal from the vehicle to the DC Supply indicating its maximum allowed current.
In other words, it's the maximum current limit allowed by the vehicle.
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVMaximumDischargeCurrent_enable
If set to TRUE, the optional message element, EVMaximumDischargeCurrent, is added to

the message. Otherwise the message element is removed.
Range: 0 or 1
Value type: Boolean

Software detail
Calibratable: No
• EVMaximumDischargeCurrent
Optional element:
This signal represents the maximum discharge current allowed by the vehicle.
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVMaximumDischargePower_enable
If set to TRUE, the optional message element, EVMaximumDischargePower, is added to

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVMaximumDischargePower
Optional element:
This signal represents the maximum discharge power allowed by the vehicle.
Range: [-32768000, 32767000] W
Value type: Real

Calibratable: No
• EVMaximumEnergyRequest_enable
If set to TRUE, the optional message element, EVMaximumEnergyRequest, is added to

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVMaximumEnergyRequest
Optional element:
The energy request of the EV it needs to fill the EVRESS completely.
Range: [-32768000, 32767000] Wh
Value type: Real

Calibratable: No
• EVMaximumPower_enable
If set to TRUE, the optional message element, EVMaximumPower, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVMaximumPower

Software detail
Optional element:
This signal represents the maximum power limit allowed by the vehicle.
Range: [-32768000, 32767000] W
Value type: Real

Calibratable: No
• EVMaximumVoltage_enable
If set to TRUE, the optional message element, EVMaximumVoltage, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVMaximumVoltage
This signal represents the maximum voltage limit allowed by the vehicle.
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No
• EVMinimumChargeCurrent
This is a signal from the vehicle to the supply indicating its minimum allowed current.
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No
• EVMinimumChargePower_enable
If set to TRUE, the optional message element, EVMinimumChargePower, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVMinimumChargePower
Optional element:
This signal represents the minimum power limit allowed by the vehicle.
Range: [-32768000, 32767000] W

Software detail
Value type: Real

Calibratable: No
• EVMinimumDischargeCurrent
This signal represents the minimum discharge current allowed by the vehicle.
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVMinimumDischargePower_enable
If set to TRUE, the optional message element, EVMinimumDischargePower, is added to

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVMinimumDischargePower
Optional element:
This signal represents the minimum discharge power allowed by the vehicle.
Range: [-32768000, 32767000] W
Value type: Real

Calibratable: No
• EVMinimumEnergyRequest_enable
If set to TRUE, the optional message element, EVMinimumEnergyRequest, is added to

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVMinimumEnergyRequest
Optional element:
The energy request of the EV it needs to fulfill the minimum SOC as specified by the owner.
Range: [-32768000, 32767000] Wh
Value type: Real

Calibratable: No
• EVMinimumVoltage
This signal represents the minimum voltage limit allowed by the vehicle.
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No
• EVMinimumVoltageLimit

Software detail
This signal represents the minimum voltage limit allowed by the vehicle.
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No
• EVOperation_enable
If set to TRUE, the optional message element, EVOperation, is added to the message.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVOperation
Optional element:
This message element is used to request the SECC the direction of power transfer, if
contactor control by HLC is applied in charging or discharging services.
value Description
0 Charge
1 BPT

Calibratable: No
• EVTargetCurrent
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVTargetEnergyRequest_enable
If set to TRUE, the optional message element, EVTargetEnergyRequest, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVTargetEnergyRequest
Optional element:
The energy request of the EV it needs to fulfill the target SOC as specified by the owner
Range: [-32768000, 32767000] Wh
Value type: Real

Calibratable: No
• EVTargetVoltage

Software detail
Range: [-32768000, 32767000] V
Value type: Integer

Calibratable: No
• InletHot_enable
If set to TRUE, the optional message element, InletHot, is added to the message.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• InletHot
Optional element:
This signal from the vehicle indicates if the inlet temperature is too high to allow the
requested charging operation
Range: 0 or 1
Value type: Boolean

Calibratable: No
• MaxSupportingPoints_enable
If set to TRUE, the optional message element, MaxSupportingPoints, is added to the

Range: 0 or 1
Value type: Boolean

Calibratable: No
• MaxSupportingPoints
Optional element:
Indicates the maximal number of entries in the SAScheduleTuple (applies for both PMax
and SalesTariff)
Range: [0, 65535]
Value type: Integer

Calibratable: No
• MinimumPMaxRequest_duration
Optional element:
Vector of durations for each MinimumPMaxRequest_PMax element.

Range: [0, 4294967295000] seconds
Value type: Integer

Calibratable: No
• MinimumPMaxRequest_length

Software detail
Identifies the number of MinimumPMaxRequest elements that are

available in MinimumPMaxRequest_start, MinimumPMaxRequest_duration, and
MinimumPMaxRequest_PMax parameters.
Range: [0, 3], 0 disables the optional message element
Value type: Integer

Calibratable: No
• MinimumPMaxRequest_PMax
Optional element:
Maximum power in Watts consumed by the EV within for each minimum PMax profile entry.

Range: [-32768000, 32767000] W
Value type: Real

Calibratable: No
• MinimumPMaxRequest_start
Optional element:
Vector of times when each MinimumPMaxRequest_PMax element begins to be valid.
Offset in seconds from time of this message.

Range: [0, 4294967295000] seconds
Value type: Integer

Calibratable: No
• MinimumSOC
This signal represents the minimum state of charge the EV will be allowed to be discharged
to.
Value type: Integer

Calibratable: No
• ParameterSetID (in)
selecting a service.
Range: [0, 65535]
Value type: Integer

Calibratable: No
Identifies the number of charging profile entries that have been

provided in the ChargingProfileEntryStart, ChargingProfileEntryDuration, and
ChargingProfileEntryMaxPower parameters.
Value type: Integer

Software detail
Calibratable: No
• RemainingTimeToBulkSOC_enable
If set to TRUE, the optional message element, RemainingTimeToBulkSOC, is added to

Range: 0 or 1
Value type: Boolean

Calibratable: No
• RemainingTimeToBulkSOC
Optional element:
Range: [-32768000, 32767000] seconds
Value type: Integer

Calibratable: No
• RemainingTimeToMinimumSOC_enable
If set to TRUE, the optional message element, RemainingTimeToMinimumSOC, is added

to the message. Otherwise the message element is removed.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• RemainingTimeToMinimumSOC
Optional element:
This signal from the vehicle allows the charging station to display a time remaining count.
Range: [-128, 127] seconds
Value type: Integer

Calibratable: No
• RemainingTimeToTargetSOC_enable
If set to TRUE, the optional message element, RemainingTimeToTargetSOC, is added to

Range: 0 or 1
Value type: Boolean

Calibratable: No
• RemainingTimeToTargetSOC
Optional element:
This signal represents remaining time to charge PEV to target SOC.
Range: [-128, 127] seconds
Value type: Integer

Calibratable: No
• SalesTariffEntry_index

Software detail
Specifies the index of the SalesTariffEntry list to access.
Range: [0, 4]
Value type: Integer

Calibratable: No
• SASchedule_tuple_index
Specifies the index of the SASchedule list to access.
Range: [0, 2]
Value type: Integer

Calibratable: No
• SAScheduleTupleID_enable (in)
If set to TRUE, the optional message element, SAScheduleTupleID (in), is added to the
Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:
Range: [0, 255]
Value type: Integer

Calibratable: No
• SelectedVASList_length
This parameter defines the length of the valid data in the SelectedVASList defined in
SelectedVASList_ServiceID, and SelectedVASList_ParameterSetID. If a length of 0 is
provided, this element will be omitted from the transmit message.
Value type: Integer

Calibratable: No
• SelectedVASList_ParameterSetID
This optional parameter contains the list of parameter sets corresponding with the service
IDs defined in SelectedVASList_ServiceID.

Range: [0, 655335]
Value type: Integer

Calibratable: No
• SelectedVASList_ServiceID
This optional parameter contains the list of services selected by the EVCC.

Software detail

Range: [0, 655335]
Value type: Integer

Calibratable: No
• ServiceID (in)
This element identifies a service which has been offered by the SECC in the
ServiceDiscoveryRes message.
Range: [0, 65535]
Value type: Integer

Calibratable: No
• SupportedServiceIDs_length
This parameter defines the length of the valid data in the SupportedServiceIDs defined
in SupportedServiceIDs. If a length of 0 is provided, this element will be omitted from the
transmit message.
Value type: Integer

Calibratable: No
• SupportedServiceIDs
This optional that contains all ServiceIDs that the EV supports. This list can be used to
filter the services that the EVSE will offer in the ServiceDiscoveryRes.
Range: [0, 65535]
Value type: Integer

Calibratable: No
• TargetSOC
This signal represents the state of charge desired by the EV.
Value type: Integer

Calibratable: No
6.1.105.5. Outports
• data_valid
Range: 0 or 1
Value type: Boolean

Calibratable: No
• error
Range: 0 or 1

Software detail
Value type: Boolean

Calibratable: No
• index_valid
Range: 0 or 1
Value type: Boolean

Calibratable: No
• receive flag
Range: 0 or 1
Value type: Boolean

Calibratable: No
• tuple_available
Range: 0 or 1
Value type: Boolean

Calibratable: No
• BuyBackTariff_length
Indicates the number of SalesTariff entries that have been populated by the SECC in the
BuyBackTariff.
If set to TRUE, the application should unpack the value of the BuyBackTariff
"ISOv2_BuyBackTariffList".
Value type: Integer

Calibratable: No
• BuyBackTariffDescription_length
Actual number of elements in the BuyBackTariffDescription parameter. If output is set to

0, the description is empty and should be ignored
Value type: Integer

Calibratable: No
• BuyBackTariffDescription
Human readable title/short description of the buy back tariff (e.g. for HMI display purposes)

Range: [0, 255]
Value type: Integer

Software detail
Calibratable: No
• BuyBackTariffEntryDuration
Value type: Integer

Calibratable: No
• BuyBackTariffEntryEPriceLevel_present
Indicates that the BuyBackTariffEntryEPriceLevel parameter has been received.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• BuyBackTariffEntryEPriceLevel
Optional element:
This signal is used to define the price level of the SalesTariffEntry being indexed by by
large values represent more expensive TariffEntry. This parameter is only populated with
valid data when BuyBackTariffEntryEPriceLevel_present is TRUE.
Range: [0, 255]
Value type: Integer

Calibratable: No
• BuyBackTariffEntryStart
Value type: Integer

Calibratable: No
• BuyBackTariffID
This signal is used to uniquely identify one BuyBackTariff. A buy back tariff ID remains a
unique identifier for one schedule throughout a charging session.
Range: [0, 255]
Value type: Integer

Calibratable: No
• ConsumptionCost_length
Indicates the number of ConsumptionCost entries that have been populated by the SECC.
Value type: Integer

Calibratable: No

Software detail
• ConsumptionCostStartValue
This signal indicates the lowest level of consumption that defines the starting point
of specified consumption block (by index ConsumptionCost_index). The block interval
extends to the start of the next interval.
Range: [-32768000, 32767000]
Value type: Real

Calibratable: No
• Cost_length
Indicates the number of different types of costs that are relevant to the Consumption block
specified by ConsumptionCost_index.
Value type: Integer

Calibratable: No
• CostAmount
A vector of the estimated or actual cost per kWh of each cost in the Consumption block.
The cost kind is defined by the same index of the CostKind parameter.
Range: [0, 4294967295000] kWh
Value type: Real

Calibratable: No
• CostKind
A vector of the kind of cost for each Cost in the Consumption block. The cost amount is
defined by the same index of the CostAmount parameter.
value Description
0 relativePricePercentage
1 RenewableGenerationPercentage
2 CarbonDioxideEmission

Calibratable: No
• DC_EVSEBidirectionalParameter_present
Identifies the presence of the DC_EVSEBidirectionalParameter and its sub-parameters

which are used by the SECC for initiating the target setting process for DC bidirectional
charging.
"ISOv2_DC_EVSEBidirectionalParameter".
Range: 0 or 1
Value type: Boolean

Calibratable: No

Software detail

"ISOv2_DC_EVSEChargeParameter".
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EnergyTransferServiceList_FreeService
A vector of values indicating that a service can be used free of charge.

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EnergyTransferServiceList_IDs
A vector of values proving a unique identifier of the service.

Range: [0, 65535]
Value type: Integer

Calibratable: No
• EnergyTransferServiceList_length
Actual number of elements in the EnergyTransferServiceList_IDs and

EnergyTransferServiceList_FreeService lists.
Value type: Integer

Calibratable: No
Range: 0 or 1
Value type: Boolean

Calibratable: No
Range: 0 or 1
Value type: Boolean

Calibratable: No

Software detail
Optional element:
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:
Range: [-32768000, 32767000] Wh
Value type: Real

Calibratable: No
• EVSEID_length
Value type: Integer

Calibratable: No
• EVSEID
message element is defined in ISO 15118-2:2014.

Range: [0, 255]
Value type: Integer

Calibratable: No
• EVSEMaximumChargeCurrent_present
If set to TRUE, the optional message element, EVSEMaximumChargeCurrent, is added to

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSEMaximumChargeCurrent
Optional element:
This signal represents the maximum charge current the EVSE can deliver.

Software detail
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVSEMaximumChargePower_present
If set to TRUE, the optional message element, EVSEMaximumChargePower, is added to

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSEMaximumChargePower
Optional element:
This signal represents the maximum charge power the EVSE can deliver.
Range: [-32768000, 32767000] W
Value type: Real

Calibratable: No
If set to TRUE, the optional message element, EVSEMaximumCurrentLimit, is added to

Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:
Range: [-32768000, 32767000] A
Value type: Integer

Calibratable: No
• EVSEMaximumDischargeCurrent_present
If set to TRUE, the optional message element, EVSEMaximumDischargeCurrent, is added

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSEMaximumDischargeCurrent
Optional element:
This signal represents the maximum discharge current the EVSE can deliver.
Range: [-32768000, 32767000] A

Software detail
Value type: Real

Calibratable: No
• EVSEMaximumDischargePower_present
If set to TRUE, the optional message element, EVSEMaximumDischargePower, is added

Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSEMaximumDischargePower
Optional element:
This signal represents the maximum discharge power the EVSE can deliver.
Range: [-32768000, 32767000] W
Value type: Real

Calibratable: No
Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:
Range: [-32768000, 32767000] W
Value type: Integer

Calibratable: No
• EVSEMaximumVoltage_present
Identifies the presence of the EVSEMaximumVoltage parameter.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSEMaximumVoltage
Optional element:
Maximum voltage the EVSE can deliver.
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No

Software detail
Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No
• EVSEMinimumChargeCurrent
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVSEMinimumDischargeCurrent
This signal represents the minimum discharge current the EVSE can deliver with the
expected accuracy.
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
• EVSEMinimumVoltage_present
If set to TRUE, the optional message element, EVSEMinimumVoltage, is present in the

message.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSEMinimumVoltage
Optional element:
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No
• EVSENotification
This signal is used by the SECC to influence the behavior of the EVCC. This parameter
contains an action that the SECC wants the EVCC to perform. The requested action is
expected by the EVCC until the time provided in EVSENotificationMaxDelay. If the target

Software detail
time is not in the future, the EVCC is expected to perform the action immediately. During
normal operation this value is usually set to "None".
value Description
0 None
1 StopCharging
1 ReNegotiation

Calibratable: No
• EVSENotificationMaxDelay
This signal is used by the SECC to indicate the time until it expects the EVCC to react on
the action request indicated in the EVSENotification parameter.
Value type: Integer

Calibratable: No
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
Range: 0 or 1
Value type: Boolean

Calibratable: No
Range: [-32768000, 32767000] A
Value type: Real

Calibratable: No
Range: [-32768000, 32767000] V
Value type: Real

Calibratable: No
• EVSEProcessing

Software detail
was sent.
value Description
0 Finished
1 Ongoing
2 Ongoing_WaitingForCustomerInteraction

Calibratable: No
• EVSEStatus_present
Identifies the presence of the EVSEStatus parameter which includes the

EVSENotificationMaxDelay and EVSENotification parameters. If set to FALSE, these
parameters should be ignored.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSETimeStamp_present
Identifies the presence of the EVSETimeStamp parameter.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• EVSETimeStamp
Optional element:
Range: [-2147483648, 2147483647] seconds
Note
data to be 03:14:07 UTC 2038-01-19.
Value type: Integer

Calibratable: No
Range: 0 or 1
Value type: Boolean

Calibratable: No
• NumEPriceLevels_present

Software detail
Identifies the presence of the NumEPriceLevels parameter.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• NumEPriceLevels
Optional element:
This signal is used to define the overall number of distinct price levels used across all
provided SalesTariff elements.
Range: [0, 255]
Value type: Integer

Calibratable: No
• Parameter_IntegerValue
If the parameter data type is one of boolValue, byteValue, shortValue or intValue it will be
returned as a signed 32-bit value through this signal. The underlying type is available as
an enum in the ParameterType parameter.
Range: [-2147483648, 2147483647]
Value type: Integer

Calibratable: No
• Parameter_PhysicalValue
If the parameter data type is physicalValue it will be returned as a 32-bit floating point value
through this signal. The underlying type is available as an enum in the ParameterType
parameter.
Range: [-32768000, 32767000]
Value type: Real

Calibratable: No
• Parameter_String_length
the length set through this signal. The underlying type is available as an enum in the
Value type: Integer

Calibratable: No
• Parameter_StringValue
the value set through this signal. The underlying type is available as an enum in the

Range: [0, 255]
Value type: Integer

Software detail
Calibratable: No
• ParameterName_length
Identifies the length of the valid data in the ParameterName parameter.
Range: [0, 51]
Value type: Integer

Calibratable: No
• ParameterName
Human readable name of the parameter being retrieved..

Range: [0, 255]
Value type: Integer

Calibratable: No
• ParameterSet_length
Actual number of Parameter elements in the ParameterSet.
Value type: Integer

Calibratable: No
• ParameterSetID
selecting a service using the PaymentServiceSelectionReq message.
Range: [0, 65535]
Value type: Integer

Calibratable: No
• ParameterType
value Description
0 boolValue
1 byteValue
2 shortValue
3 intValue
4 physicalValue
5 stringValue

Calibratable: No
• PaymentOptions_size
Identifies the size of the valid data in the PaymentOptions parameter.

Software detail
Value type: Integer

Calibratable: No
• PaymentOptions
This element includes the list of payment options an SECC offers to the EVCC indicating
what method could be chosen to pay for the services. The EVCC can only select one
payment method for all services used by the EVCC.
value Description
0 Contract
1 ExternalPayment

Calibratable: No
• PMax
connected to.

Range: [-32768000, 32767000] Watts
Value type: Integer

Calibratable: No
• PMaxDischargeSchedule_present
Indicates that the PMaxDischargeSchedule parameter in the response message has been
populated by EVSE.
The application should unpack the value of each PMaxDischargeSchedule entry

"ISOv2_PMaxDischargeSchedule".
Range: 0 or 1
Value type: Boolean

Calibratable: No

Range: [0, 5]
Value type: Integer

Calibratable: No
• ResponseCode

Software detail
value Description
current state.
response message.
4 OK_IsolationValid
5 OK_IsolationWarning
6 WARNING_CertificateExpired
7 WARNING_NoCertificateAvailable
8 WARNING_CertValidationError
9 WARNING_CertVerificationError
10 WARNING_ContractCanceled
11 FAILED
12 FAILED_SequenceError
13 FAILED_ServiceIDInvalid
14 FAILED_UnknownSession
15 FAILED_ServiceSelectionInvalid
16 FAILED_SignatureError
17 FAILED_PaymentSelectionInvalid
18 FAILED_ChallengeInvalid
19 FAILED_WrongChargeParameter
20 FAILED_IsolationFault
21 FAILED_PowerDeliveryNotApplied
22 FAILED_TariffSelectionInvalid
23 FAILED_ChargingProfileInvalid
24 FAILED_MeteringSignatureNotValid
25 FAILED_NoChargeServiceSelected
26 FAILED_WrongEnergyTransferMode
27 FAILED_ContactorError
28 FAILED_CertificateRevoked
29 FAILED_CertificateNotYetValid

Calibratable: No
• SalesTariff_length

Software detail
Indicates the number of SalesTariff entries that have been populated by the SECC.
Value type: Integer

Calibratable: No
• SalesTariffDescription_length
Actual number of elements in the SalesTariffDescription parameter. If output is set to 0,

the description is empty and should be ignored.
Range: [0, 33]
Value type: Integer

Calibratable: No
• SalesTariffDescription
Optional element:
A vector of human readable title/short description text of the sales tariff (e.g. for HMI display
purposes).

Range: [0, 255]
Value type: Integer

Calibratable: No
• SalesTariffEntryDuration
Value type: Integer

Calibratable: No
• SalesTariffEntryEPriceLevel_present
Indicates that the SalesTariffEntryEPriceLevel parameter has been received.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• SalesTariffEntryEPriceLevel
Optional element:
This signal is used to define the price level of the SalesTariffEntry being indexed by
large values represent more expensive TariffEntry.
Range: [0, 255]
Value type: Integer

Software detail
Calibratable: No
• SalesTariffEntryStart
Value type: Integer

Calibratable: No
• SalesTariffID
This signal is used to uniquely identify one sales tariff. A sales tariff ID remains a unique
identifier for one schedule throughout a charging session.
Range: [0, 255]
Value type: Integer

Calibratable: No

The application should unpack the value of each SAScheduleList element separately
by calling the block with the Vehicle to grid message parameter set to
"ISOv1_SAScheduleList".
Range: [0, 3]
Value type: Integer

Calibratable: No
• SAScheduleTupleID_present
If set to TRUE, the optional message element, SAScheduleTupleID, is present in the

message.
Range: 0 or 1
Value type: Boolean

Calibratable: No
Optional element:
Range: [-32768, 32767]
Value type: Integer

Calibratable: No
• ServiceID
Range: [0, 65535]

Software detail
Value type: Integer

Calibratable: No
• ServiceParameterSet_length
Actual number of elements in the ServiceParameterList parameter. If the output is 0, the

list is empty and should be ignored.
The application should unpack the value of each ServiceParameterList parameter

"ISOv2_ServiceParameterList".
Value type: Integer

Calibratable: No
• ServiceParameterSet_Sizes
A vector of array lengths of each parameter in each parameter set.

(i.e holds the array length of ServiceDetailRes -> ServiceParameterList -> ParameterSet
-> Parameter)

Value type: Integer

Calibratable: No

Value type: Integer

Calibratable: No

Value type: Integer

Calibratable: No
• VASList_FreeService
Optional element:
A vector of values containing that denote if a service at a index is free of charge or not.
The free service at a index of this list corresponds to the service ID in VASList_IDs at the
same index.

Range: 0 or 1
Value type: Boolean

Calibratable: No

Software detail
• VASList_IDs
Optional element:
A vector of values containing the list of service IDs of all other services (excluding charging)
that are offered by the EVSE.

Range: [0. 65535]
Value type: Integer

Calibratable: No
• VASList_length
Actual number of elements in the VASList_IDs and VASList_FreeService lists. If this value
is 0 then the values of VASList_IDs and VASList_FreeService should be ignored.
Range: [0, 8]
Value type: Integer

Calibratable: No

ISOv2_Set_DisplayParameters CurrentRange_enable error
CurrentRange
CurrentSOC
TargetSOC
BulkSOC
MinimumSOC
ChargingPerformance_enable
ChargingPerformance
RemainingTimeToTargetSOC_enable
RemainingTimeToTargetSOC
RemainingTimeToBulkSOC_enable
RemainingTimeToBulkSOC
RemainingTimeToMinimumSOC_enable
RemainingTimeToMinimumSOC
ChargingComplete_enable
ChargingComplete

Software detail

InletHot_enable
InletHot
ISOv2_SessionSetupReq transmit error
ISOv2_SessionSetupRes receive flag
ResponseCode
EVSEStatus_present
EVSENotification
EVSEID
EVSEID_length
EVSETimeStamp_present
EVSETimeStamp
ISOv2_ServiceDiscoveryReq transmit error
SupportedServiceIDs
SupportedServiceIDs_length
ISOv2_ServiceDiscoveryRes receive flag
ResponseCode
EVSEStatus_present
EVSENotification
PaymentOptions
PaymentOptions_size
EnergyTransferServiceList_IDs
EnergyTransferServiceList_FreeService
EnergyTransferServiceList_length
VASList_IDs
VASList_FreeService
VASList_length
ISOv2_ServiceDetailReq transmit error
ServiceID (in)
ISOv2_ServiceDetailRes receive flag
ResponseCode
EVSEStatus_present
EVSENotification
ServiceID
ServiceParameterSet_length
ServiceParameterSet_Sizes
ISOv2_ServiceParameterList parameter_set_index index_valid
parameter_index ParameterSetID
ParameterSet_length
ParameterName
ParameterName_length
ParameterType
Parameter_IntegerValue
Parameter_PhysicalValue
Parameter_StringValue
Parameter_String_length
ISOv2_PaymentServiceSelectionReq
transmit error
ServiceID (in)
ParameterSetID (in)
SelectedVASList_ServiceID
SelectedVASList_ParameterSetID

Software detail

SelectedVASList_length
ISOv2_PaymentServiceSelectionRes receive flag
ResponseCode
EVSEStatus_present
EVSENotification
ISOv2_AuthorizationReq transmit error
ISOv2_AuthorizationRes receive flag
ResponseCode
EVSEStatus_present
EVSENotification
EVSEProcessing
ISOv2_DC_ChargeParameterDiscoveryReq
transmit error
DC_EVChargeParameter_enable
DepartureTime
EVMaximumChargePower_enable
EVMaximumChargePower
EVMinimumChargePower_enable
EVMinimumChargePower
EVMaximumChargeCurrent
EVMinimumChargeCurrent
EVTargetEnergyRequest_enable
EVTargetEnergyRequest
EVMaximumEnergyRequest_enable
EVMaximumEnergyRequest
EVMinimumEnergyRequest_enable
EVMinimumEnergyRequest
TargetSOC
BulkSOC
MaxSupportingPoints_enable
MaxSupportingPoints
MinimumPMaxRequest_length
MinimumPMaxRequest_start
MinimumPMaxRequest_duration
MinimumPMaxRequest_PMax
transmit error
DC_EVBidirectionalParameter_enable
DepartureTime
EVMinimumChargePower_enable
EVMinimumChargePower
EVMaximumDischargePower_enable
EVMaximumDischargePower
EVMinimumDischargePower_enable
EVMinimumDischargePower
EVMinimumChargeCurrent
EVMaximumDischargeCurrent
EVMinimumDischargeCurrent
EVMinimumVoltageLimit

Software detail

EVTargetEnergyRequest_enable
TargetSOC
BulkSOC
MaxSupportingPoints_enable
MaxSupportingPoints
MinimumPMaxRequest_length
MinimumPMaxRequest_start
MinimumPMaxRequest_duration
MinimumPMaxRequest_PMax
ISOv2_ChargeParameterDiscoveryRes receive flag
ResponseCode
EVSEStatus_present
EVSENotification
EVSEProcessing
SAScheduleList_size
DC_EVSEBidirectionalParameter_present
ISOv2_DC_EVSEChargeParameter data_valid
EVSEMaximumChargePower
EVSEMaximumChargeCurrent
EVSEMinimumChargeCurrent
EVSEMaximumVoltage
EVSEMinimumVoltage
ISOv2_DC_EVSEBidirectionalParameter data_valid
EVSEMinimumChargeCurrent
EVSEMaximumVoltage
EVSEMinimumVoltage
EVSEMaximumDischargePower
EVSEMaximumDischargeCurrent
EVSEMinimumDischargeCurrent
ISOv2_SAScheduleList tuple_index tuple_available
SAScheduleTupleID
TimeInterval_start
PMax

Software detail

PMaxDischargeSchedule_present
SalesTariff_length
BuyBackTariff_length
ISOv2_PMaxDischargeSchedule tuple_index tuple_available
TimeInterval_start
PMax
ISOv2_SalesTariffList SASchedule_tuple_index data_valid
SalesTariffEntry_index SalesTariffID
ConsumptionCost_index SalesTariffDescription
SalesTariffDescription_length
NumEPriceLevels
SalesTariffEntryStart
SalesTariffEntryDuration
SalesTariffEntryEPriceLevel_present
SalesTariffEntryEPriceLevel
Cost_length
CostKind
CostAmount
ISOv2_BuyBackTariffList SASchedule_tuple_index data_valid
SalesTariffEntry_index BuyBackTariffID
ConsumptionCost_index BuyBackTariffDescription
BuyBackTariffDescription_length
NumEPriceLevels
BuyBackTariffEntryStart
BuyBackTariffEntryDuration
BuyBackTariffEntryEPriceLevel_present
BuyBackTariffEntryEPriceLevel
Cost_length
CostKind
CostAmount
ISOv2_CableCheckReq transmit error
ISOv2_CableCheckRes receive flag
ResponseCode
EVSEStatus_present
EVSENotification
EVSEProcessing
ISOv2_Pre-ChargeReq transmit error
EVTargetVoltage
EVTargetCurrent
ISOv2_Pre-ChargeRes receive flag
ResponseCode
EVSEStatus_present
EVSENotification

Software detail

EVSEPresentVoltage
ISOv2_PowerDeliveryReq transmit error
ChargeProgress
EVOperation_enable
EVOperation
SAScheduleTupleID_enable (in)
ProfileEntry_count
ChargingProfileEntryDuration
ISOv2_PowerDeliveryRes receive flag
ResponseCode
EVSEStatus_present
EVSENotification
EVSEProcessing
ISOv2_CurrentDemandReq transmit error
EVTargetCurrent
EVMaximumVoltage_enable
EVMaximumVoltage
EVMaximumCurrent_enable
EVMaximumCurrent
EVMaximumPower_enable
EVMaximumPower
EVTargetVoltage
ISOv2_CurrentDemandRes receive flag
ResponseCode
EVSEStatus_present
EVSENotification
EVSEPresentVoltage
EVSEPresentCurrent
EVSEID
EVSEID_length
SAScheduleTupleID_present
SAScheduleTupleID
ISOv2_WeldingDetectionReq transmit error
ISOv2_WeldingDetectionRes receive flag
ResponseCode

Software detail

EVSEStatus_present
EVSENotification
EVSEPresentVoltage
ISOv2_SessionStopReq transmit error
ChargingSession
ISOv2_SessionStopRes receive flag
ResponseCode
EVSEStatus_present
EVSENotification
ISOv2_DC_BidirectionalControlReq
transmit error
EVTargetCurrent
EVTargetVoltage
EVMaximumVoltage
EVMinimumVoltage
EVMaximumDischargeCurrent_enable
EVMaximumDischargeCurrent
EVMaximumDischargePower_enable
EVMaximumDischargePower
ISOv2_DC_BidirectionalControlRes receive flag
ResponseCode
EVSEStatus_present
EVSENotification
EVSEPresentVoltage
EVSEPresentCurrent
EVSEMaximumChargePower_present
EVSEMaximumDischargePower_present
EVSEMaximumDischargePower
EVSEMaximumChargeCurrent_present
EVSEMaximumDischargeCurrent_present
EVSEMaximumDischargeCurrent
EVSEMaximumVoltage_present
EVSEMaximumVoltage
EVSEMinimumVoltage_present
EVSEMinimumVoltage
EVSEID
EVSEID_length
SAScheduleTupleID_present
SAScheduleTupleID

Software detail
Value type: List

Calibratable: No
Value type: Real

Calibratable: No
6.1.105.7. Notes
None.
6.1.106. Vehicle to grid connection management

(pv2g_Connection)
Initiate and monitor a vehicle to grid communication connection.

All targets

initiate link_status
Vehicle to grid connection management
terminate tcp_status
pv2g_Connection
The vehicle to grid connection block allows the application to manage a vehicle to grid
communication link. The link and TCP connection status are provided as feedback to the
application.
6.1.106.4. Inports
• initiate
Set to 1 to initiate TCP connection.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• terminate
Set to 1 to terminate communication. This will reset the internal state machines and allow
a connection to be re-initiated.

Software detail
Range: 0 or 1
Value type: Boolean

Calibratable: No
6.1.106.5. Outports
• link_status
Communication link status. Do not attempt to initiate communication unless the link status
indicates connection.
value Description
0 Disconnected
1 Connected
Value type: Integer

Calibratable: No
• tcp_status
Communication TCP connection status.
value Description
0 Disconnected
1 Waiting for SDP response
2 Waiting for SDP ready
3 TCP ready to connect
4 TCP connecting
5 TCP connected
Value type: Integer

Calibratable: No
6.1.106.7. Notes
None.
6.1.107. Vehicle to grid connection information

(pv2g_Link_Info)
View protocol information about the active vehicle to grid communications link

Software detail

All targets

link_status
tcp_status
evcc_mac_address
evcc_ip_address
Vehicle to grid connection information
evcc_tcp_port_number
evse_mac_address
evse_ip_address
evse_tcp_port_number
pv2g_Link_Info
This block provides information about the underlying TCP link used for the active V2G
communications session.
6.1.107.4. Inports
None.
6.1.107.5. Outports
• link_status
Communication link status. Do not attempt to initiate communication unless the link status
indicates connection.
value Description
0 Disconnected
1 Connected
Value type: Integer

Calibratable: No
• tcp_status
Communication TCP connection status.
value Description
0 Disconnected
1 Waiting for SDP response
2 Waiting for SDP ready
3 TCP ready to connect
4 TCP connecting
5 TCP connected
Value type: Integer

Calibratable: No
• evcc_mac_address

Software detail
The MAC address used by the ECU. This field is only valid when the QCA chip has been
initialized.
Size: 6 entries
Range: [0, 255]
Value type: Integer

Calibratable: No
• evcc_ip_address
The IPv6 address used by the ECU. This field is only valid when TCP is connected.
Size: 8 entries
Range: [0, 65535]
Value type: Integer

Calibratable: No
• evcc_tcp_port_number
The TCP/IP port number address used by the ECU. This field is only valid when TCP is
connected.
Range: [49152, 65535]
Value type: Integer

Calibratable: No
• evse_mac_address
The MAC address used by the EVSE. This field is only valid when TCP is connected.
Size: 6 entries
Range: [0, 255]
Value type: Integer

Calibratable: No
• evse_ip_address
The IPv6 address used by the EVSE. This field is only valid when TCP is connected.
Size: 8 entries
Range: [0, 65535]
Value type: Integer

Calibratable: No
• evse_tcp_port_number
The TCP/IP port number address used by the EVSE. This field is only valid when TCP
is connected.
Range: [49152, 65535]
Value type: Integer

Calibratable: No

Software detail
6.1.107.7. Notes
None.
6.2. Automatic ASAP2 entries

When an application is built, a number of ASAP2 entries are automatically generated. These
entries reflect a number of application properties and run-time parameters which are useful
to monitor during development and deployment.
The sections below give a complete list of automatically generated ASAP2 entries.
Note
When using PiSnoop be sure to load the ASAP2 (.a2l) file symbols to view these
parameters. In many cases they are aliases for C variables with different names in
the .elf file, and some have necessary scale factors applied in the ASAP2 attributes.
6.2.1. Boot build information

The boot software runs when the ECU is turned on. It conditions the ECU for running the
reprogramming software or application software. The version and build date of this software
is available through the following ASAP2 entries.
Table 6.12. Automatic ASAP2 entries for boot build information

ASAP2 name Description Units
mpl_boot_ver_major The boot software major version number. -
mpl_boot_ver_minor The boot software minor version number. -
mpl_boot_ver_sub The boot software sub-minor version number. -
mpl_boot_build_day The numerical day when the boot software days
was created.
mpl_boot_build_month The numerical month when the boot software months
was created.
mpl_boot_build_year The numerical year when the boot software years
was created.
mpl_boot_part_num_group The Group ID numerical value of the boot -
software part number.
mpl_boot_part_num_letter The Group Letter ASCII value of the boot -
mpl_boot_part_num_id The Part ID numerical value of the boot -

Software detail

mpl_boot_part_num_issue The Issue numerical value of the boot software -
part number.
Past and current boot code version numbering is given in Section 6.3, “OpenECU software
versioning”.
6.2.2. Reprogramming build information

The ECU's reprogramming mode is started as described in Section 4.5, “Programming an
ECU”. The reprogramming code communicates using CCP (version 2.1) and provides a
calibration tool with a mechanism to change the application software and/or calibration.
Table 6.13. Automatic ASAP2 entries for reprogramming build

information (M220, M221, M250, M460, M461, M550, M670)

mpl_prg_ver_major The reprogramming software major version -
number.
mpl_prg_ver_minor The reprogramming software minor version -
number.
mpl_prg_ver_sub The reprogramming software sub-minor -
version number.
mpl_prg_build_day The numerical day when the reprogramming days
software was created.
mpl_prg_build_month The numerical month when the reprogramming months
mpl_prg_build_year The numerical year when the reprogramming years
mpl_prg_part_num_group The Group ID numerical value of the -
reprogramming software part number.
mpl_prg_part_num_letter The Group Letter ASCII value of the -
mpl_prg_part_num_id The Part ID numerical value of the -
mpl_prg_part_num_issue The Issue numerical value of the -
versioning”.
6.2.3. Platform build information

The platform software creates an environment where by the application software can execute
and access the target ECU hardware.
Table 6.14. Automatic ASAP2 entries for platform build information

mpl_plat_ver_major The platform software major version number. -

Software detail

mpl_plat_ver_minor The platform software minor version number. -
mpl_plat_ver_sub The platform software sub-minor version -
number.
mpl_plat_build_day The numerical day when the platform software days
was created.
mpl_plat_build_month The numerical month when the platform months
mpl_plat_build_year The numerical year when the platform software years
was created.
mpls_plat_build_time The date and time when the platform was -
created as a text string.
mpls_plat_copyright The platform's copyright notice. -
mpls_plat_target The hardware target the application was built -
to be run on as a text string.
mpls_plat_version The version of the platform the application was -
built against as a text string.
mpl_plat_part_num_group The Group ID numerical value of the platform -
part number the application was build against.
mpl_plat_part_num_letter The Group Letter ASCII value of the platform -
mpl_plat_part_num_id The Part ID numerical value of the platform -
mpl_plat_part_num_issue The Issue numerical value of the platform part -
number the application was build against.
versioning”.
6.2.4. Application build information

When the application is built, the automatically generated application code and the platform
software are combined, and the result is the application software configured for the target
ECU hardware.
The application name, description and copyright, as well as the time and date when the
application was built, is available through ASAP2 entries. This information is useful when
confirming what the ECU is actually executing.
Table 6.15. Automatic ASAP2 entries for application build information

mpl_app_ver_major The application software major version -
number.
mpl_app_ver_minor The application software minor version -
number.
mpl_app_ver_sub The application software sub-minor version -
number.
mpl_app_build_sec The seconds when the application software seconds
was built.

Software detail

mpl_app_build_min The minute when the application software was minutes
built.
mpl_app_build_hour The hour (in 24 hour format) when the hours
application software was built.
mpl_app_build_day The numerical day when the application days
software was built.
mpl_app_build_month The numerical month when the application months
software was built.
mpl_app_build_year The numerical year when the application years
software was built.
mpls_app_build_time The date and time when the application was -
built as a text string.
mpls_app_copyright The copyright notice for the application. -
mpls_app_description The application description. -
mpls_app_name The name of the built application. -
mpls_app_version The application version number as a text -
string.
Note
The time displayed at the end of a build in Simulink matches ASAP2 entries above.
This can be useful when determining whether the correct version of the application was
programmed into the ECU.
6.2.5. Application and library task timing information

When the application is executing, the platform is maintaining a series of tasks that iterate
the application at periodic rates (and possibly on an angular rate if engine functionality is
required). These tasks take an amount of time to execute and the following ASAP2 entries
record how long the last ran.
Table 6.16. Automatic ASAP2 entries for application rate task timing
information

mpl_tt_task_[xxx]ms The duration of the last microseconds
application iteration for the
[xxx] model rate.
mpl_tt_task_angular The duration of the last microseconds
TDC-firing triggered
application iteration.
When the application is executing, the platform is maintaining a series of tasks that support
the application. These tasks perform basic input and output support as well as general
housekeeping. Each task takes some time to execute and the following entries record the
last execution time of each.

Software detail
Table 6.17. Automatic ASAP2 entries for auxiliary task timing

information
mpl_tt_pan_task The duration of angular microseconds
platform task. This task
supports the angular
application iteration.
mpl_tt_pan_knock The duration of angular microseconds
knock support task.
mpl_tt_pan_knock_ref The duration of angular microseconds
knock reference support
task.
mpl_tt_pcx_tcan_callback The duration of the CAN microseconds
receive and transmit
(event) support task.
mpl_tt_pcx_qemptier The duration of the CAN microseconds
(polled) support task.
mpl_tt_pcx_qemptier_mcp2515 The duration of the CAN microseconds
(event) support task.
mpl_tt_psp_receive The duration of the serial microseconds
input and output support
task.
mpl_tt_psc_watchdog The duration of the microseconds
watchdog support task.
mpl_tt_pcp_client The duration of the CCP microseconds
support task. This task
provides CCP support for
the calibration tool.
mpl_tt_ppp_client The duration of the PixCal/ microseconds
tuning comms protocol
task. This task provides
support for tunable
parameters via the PixCal
calibration tool.
These entries support development by showing how long the software takes to run on the
target hardware. As development progresses, new functionality can be compared to previous
functionality to assess how much processing time is consumed.
The assessment can be made by noting how frequently the tasks run and how long they
take, giving an estimated total consumption.
Table 6.18. Automatic ASAP2 entries for CPU loading information

mpl_cpu_loaded The amount of CPU used by the percent
application and platform software
in the last 50 milliseconds as a
percentage. The CCP task may cause
the loading to reach 100 percent under

Software detail

certain conditions but this is normal.
The long running CCP task will not
cause application iterations or other
functionality to be delayed.
Some target ECU support loading measurement for processing devices other than the CPU.
The eTPU device, or devices, are used for simple and complex I/O processing.
Table 6.19. Automatic ASAP2 entries for eTPU loading information

mpl_etpu_a_loaded The amount of eTPU (device A) used by percent
the application and platform software in
the last 50 milliseconds as a percentage.
mpl_etpu_b_loaded The amount of eTPU (device B) used by percent
the application and platform software in
the last 50 milliseconds as a percentage.
Although previous entries record how long the last execution took, it is useful to know the
longest execution that has occurred since power up. There are ASAP2 entries to support this.
Table 6.20. Automatic ASAP2 entries for maximum application rate task
timing information

mpl_mtt_[name] The largest value of the microseconds
corresponding application
duration ASAP2 variable
seen since the last power
up or reset.
mpl_max_cpu_loaded The largest value of percent
mpl_cpu_loaded seen
since the last power up or
reset.
mpl_max_etpu_a_loaded The largest value of percent
mpl_etpu_a_loaded seen
reset.
mpl_max_etpu_b_loaded The largest value of percent
mpl_etpu_b_loaded seen
reset.
Note that the maximum task duration entries record the longest execution seen since power
up and not the worst case execution time of the task. It could be that a task will take longer to
run if given different stimuli. OpenECU does not support the direct derivation of worst case
execution times.
There is also a seconds counter which is cleared to zero when the ECU is turned on or resets.
The counter can be used to determine if the ECU is resetting on a regular or irregular basis.

Software detail
Table 6.21. Automatic ASAP2 entries for run-time information

mpl_run_time A seconds counter of the seconds
time since power up; range
[0, 4294967294].
Expected and unexpected resets are logged and counted. There are ASAP2 entries to report
reset counts.
Table 6.22. Automatic ASAP2 entries for reset information (M110, M220,
M250, M460, M461)

mpl_unstable_reset_count Number of resets since events
power-up, or since the
application was last stable.
mpl_reset_count Number of resets since events
power-up.
Table 6.23. Automatic ASAP2 entries for number of instances of period

overruns or skips of periodic tasks

mpl_ovrc_[name] The number of times the task has taken count
longer that its period to run.
mpl_skipc_[name] The number of times the task has count
skipped its period.
6.2.6. Memory use information

The platform software provides support for the application execution through the tasks
identified above. Each of these tasks requires some memory to record its state and the
platform does so dynamically by storing this information on the stack.
Table 6.24. Automatic ASAP2 entries for memory use information

mpl_max_used_stack The amount of stack used bytes
since power up by the
application software.
mpl_stack_limit_error Set if a stack limit error flag
(overflow or underflow)
occurred in the last reset
cycle.
mpl_stack_limit_inst_addr Address of the instruction address
that caused a stack limit
error.
mpl_stack_limit_data_addr Address of the data access address
that caused a stack limit
error.

Software detail
In the Sim-API, the size of the stack can be modified in the OpenECU RTW options. For
instance, this might be necessary after testing shows that the average amount of used stack
at run time is too large in comparison to the allocated stack size.
6.2.7. Memory error correction events

Some ECUs provide memory error correction functionality. Not all memory errors can be
corrected and in all conditions except during initialisation, reading a non-correctable memory
area will cause the ECU to reset. During initialisation, the software prevents resets when
checking adaptive, DTC and Tune memory to determine if those memory regions have
become corrupt. A non-correctable memory area detected during initialisation checks is
logged in the following automatic ASAP2 variables.
Table 6.25. Automatic ASAP2 entries for memory error correction

events
mpl_ecc_ram_address Address of last RAM address
non-correctable ECC
error, zero if no error has
occurred.
mpl_ecc_flash_address Address of last Flash address
non-correctable ECC
error, zero if no error has
occurred.
6.2.8. Floating point conditions

On those ECUs which support floating-point arithmetic, some ECUs provide status
information relating to floating-point operations. Given pmax as the most positive normalized
value (farthest from zero), pmin the smallest positive normalized value (closest to zero), nmax
the most negative normalized value (farthest from zero) and nmin the smallest normalized
negative value (closest to zero), floating-point conditions are reflected in the automatic
ASAP2 variables in the following table.
Table 6.26. Automatic ASAP2 entries for floating point conditions

mpl_flp_overflow Set if floating-point flag
overflow has occurred
since the last reset, clear
otherwise. An overflow is
said to have occurred if the
numerically correct result
is such that result > pmax,
or result < nmax. See the
processor's reference
manual for more.
mpl_flp_underflow Set if floating-point flag
underflow has occurred
otherwise. An underflow is
said to have occurred if the
numerically correct result
is such that 0 < result <

Software detail

pmin, or nmin < result <
0. See the processor's
reference manual for more.
mpl_flp_div_by_zero Set if floating-point division flag
by zero has occurred
otherwise. A divide by
zero condition arises
when the floating-point
operation is executed with
a +/-0 divisor value and a
finite normalized nonzero
dividend value.
mpl_flp_inexact Set if an inexact floating- flag
point result has occurred
otherwise. An inexact
condition arises when
the result of a floating-
point operation requires
rounding (is inexact), or if
an overflow or underflow
condition arises.
mpl_flp_invalid Set if an invalid floating- flag
point result has occurred
otherwise. An invalid
condition arises when
an operand in a floating-
point operation contains
a denormalized value,
infinitity or NaN, or if both
operands in a floating-point
divide operation are +/-0.
Note
The platform is likely to cause the inexact condition to occur due to rounding. While the
platform has been written to avoid other conditions (such as divide by zero), extreme
values passed by the application to the platform may result in the platform causing
other conditions to occur.
6.2.9. J1939 related information

The following ASAP2 entries are provided to work with J1939.
Table 6.27. Automatic ASAP2 entries for J1939 related information

pj1939c_node_addr_0 The preferred node -
address for this ECU.
Sampled on power-up
only.

Software detail
6.2.10. Engine related information

The following ASAP2 entries are provided as a development aid on some target ECUs. They
may be removed in the future.
6.3. OpenECU software versioning

Each target contains a set of software components, each identified by three numbers of the
form x.y.z. The first number, x, identifies the major version of the software component. The
other numbers, y.z identify the minor and sub-minor versions.
Table 6.28. Software component versions (for M560-000)

Processor Component Version Part-number
Primary, Combined firmware code, Combined 507.2.0 36T-070093-ISS-5
MPC5746D boot and reprogramming code (default
CCP baud rate, 500kbps).
Combined firmware code, Combined 512.2.0 36T-070092-ISS-5
boot and reprogramming code (default
CCP baud rate, 250kbps).
Firmware upgrade, application 507.2.0 36T-070088-ISS-5
to reprogram boot code and
reprogramming code (default CCP
baud rate, 500kbps).
Firmware upgrade, application 512.2.0 36T-070087-ISS-5
to reprogram boot code and
reprogramming code (default CCP
baud rate, 250kbps).
Platform library, application support to 502.2.0 36T-070085-ISS-1
access ECU functionality.
ETAC for primary processor, hardware 502.2.0 36T-070086-ISS-1
embedded test application code to
support parametric, function and
design validation testing.
When providing technical support, Pi may need to know the version numbers for the software
components.
Details on how to find out the version numbers for Main processor are given in Section 6.2,
“Automatic ASAP2 entries”.
Version numbers for HCS12 processor can be retrieved by uploading the software, with FEPS
signal applied. Contact technical support for more details.
6.4. OpenECU commands

A small number of OpenECU functionality is available through the command line prompt
of MATLAB. The commands break down into sections relating to documentation, blockset
support, model and build list support and tool support.
6.4.1. Documentation

Software detail
Name
help openecu — display OpenECU specific commands
Synopsis
help openecu
Description
Displays the available OpenECU specific commands. Additional information about an
OpenECU specific command can be displayed by executing the command:
help <command>
e.g.,
help oe_freeccp

Software detail
Name
ver openecu — display version of OpenECU installed
Synopsis
ver openecu
Description
Displays the version of OpenECU blockset the MATLAB path points at (and if using MATLAB
R12.1, displays the date when that version was created).
The MATLAB path can be changed by selecting the menu option File -> Set Path... to select
a different version of the OpenECU blockset (if the path is changed, MATLAB must be
restarted).
Warning
If more that one version of the OpenECU blockset exists on MATLAB's path, the
behaviour of OpenECU will be undefined. The command
oe_check_path
will raise an error if more than one OpenECU blockset exists on MATLAB's path (the
user must run this command manually).
6.4.2. Blockset

Software detail
Name
oe_blockset — open the OpenECU blockset library.
Synopsis
oe_blockset
Description
Opens the OpenECU blockset library. Blocks can be dragged directly from the library into
an OpenECU model.

Software detail
Name
oe_examples — open the OpenECU examples model.
Synopsis
oe_examples
Description
Opens the OpenECU examples model where the user can then open the examples by double
clicking any of the sub-systems.
6.4.3. Model and build list actions

Software detail
Name
oe_create_model — create a new OpenECU model in the current directory.
Synopsis
oe_create_model {modelname} [dd [dd-name]] [part [part-number]] [issue
[issue-number]] [template [template-type]]
Description
OE_CREATE_MODEL('model-name')
Creates a new OpenECU model with appropriate model settings and a 'basic' template
containing a put_Identification block, as well as creating a build list and data dictionary that
defaults to using a prefix of 'aaa'. The put_Identification block defaults to the 01T-068432-000
(M220-000) issue 1 target configuration.
OE_CREATE_MODEL('model-name', 'dd', 'dd-name')
containing a put_Identification block, as well as creating a basic build list and data dictionary
using a prefix given by 'dd-name'. 'dd-name' must be 3 characters long. The model defaults
to the 01T-068432-000 (M220-000) issue 1 target.
OE_CREATE_MODEL('model-name', 'dd', 'dd-name', ...

'part', 'part-number', ...
'issue', issue-number)
containing a put_Identification block, as well as creating a basic build list and data dictionary
using a prefix given by 'dd-name'. The model is configured for the target given by 'part-
number' and 'issue-number'.
OE_CREATE_MODEL('model-name', 'dd', 'dd-name', ...

'part', 'part-number', ...
'issue', issue-number, ...
'template', 'template-type')
Creates a new OpenECU model with appropriate model settings take from one of the
supported templates specified by 'template-type', containing a put_Identification block, as
well as creating a basic build list and data dictionary using a prefix given by 'dd-name'. The
model is configured for the target given by 'part-number' and 'issue-number'.
Examples
oe_create_model('my_name')
Creates a new OpenECU model named 'my_name' with a data dictionary using the prefix
'aaa' for a 01T-068432-000 (M220-000) issue 1 target.
oe_create_model('my_name', 'dd' 'mbe')
'mbe' for a 01T-068432-000 (M220-000) issue 1 target.
oe_create_model('my_name', 'dd', 'mbe', ...

'part', '01T-068276-000', ...
'issue', 2, ...
'template', 'basic-bussed')

Software detail
'mbe' for a 01T-068276-000 (M250-000) issue 2 target. The OpenECU model created will
have a basic-bussed template.
Duplicate file naming
It is not possible to create a model if a file with a matching name already exists in the same
directory. Choose a different name for the model and run the command again.
It is possible to create a model with a data dictionary file that already exists. The user will be
given a choice to retain the existing data dictionary, or overwrite the existing data dictionary
when the command runs.
Templates
The supported templates are:
minimal
Nothing but a put_Identification block to select the ECU target.
basic
Builds on top of the minimal template by including: configuration for the ECU target,
CAN bus and CCP communications for reprogramming, signal monitoring and calibration
purposes; retrieval of the version and build information for each software component
programmed into the ECU for identification purposes; retrieval of basic operating
variables, such as CPU loading and stack use for periodic checks on how large the
application becomes over time; and a basic break down of data flow from input through
to output processing ready to fill out.
basic-bussed
Identical to the basic template except that the data flow from input to output processing
utilises busses making the diagram tidier.

Software detail
Name
oe_read_build_list — read the data dictionary into the workspace.
Synopsis
oe_read_build_list [modelname]
Description
OE_READ_BUILD_LIST reads the build list for the active model and places the data
dictionary items into the workspace. OE_READ_BUILD_LIST 'model_name' reads the
build list for the named model (which must be in the current directory) and places the data
dictionary items into the workspace.

Software detail
Name
oe_clear_build_list — removes the model data dictionary items from the workspace.
Synopsis
oe_clear_build_list
Description
OE_CLEAR_BUILD_LIST removes data dictionary entries from the workspace and removes
any build list paths from MATLAB's path.
6.4.4. Model configuration and build

Software detail
Name
oe_build_model — initiate a model build using the current configuration parameters.
Synopsis
oe_build_model
Description
OE_BUILD_MODEL starts building the currently selected model using the model's
configuration parameters.

Software detail
Name
oe_check_compiler — determines whether each of the compilers that OpenECU supports is
available and, if applicable, licensed.
Synopsis
oe_check_compiler
Description
OE_CHECK_COMPILER determines whether each of the compilers that OpenECU supports
is available and licensed.
Checks are made against various compiler versions to ensure that when a model build is
initiated, the compiler is available.
Checks performed include:
• the environment variable pointing to the compiler do not contain spaces;
• the environment variable pointing to the compiler ends in a trailing '\';
• the compiler executable can be found and executed;
• the compiler version matches;
• the compiler can access a license.
If there is one compiler version installed, the user may add the path to the compiler's
executable to the system PATH environment variable. If there is more than one compiler
version installer, the user must set an environment variable for each version.
Compiler Environment variable

Diab 5.5.1.0 OPENECU_DIAB_5_5_1_0
Diab 5.8.0.0 OPENECU_DIAB_5_8
Diab 5.9.0.0 OPENECU_DIAB_5_9
GCC 4.7.3 Not applicable
GCC comes packaged with the OpenECU installer. It does not require an environment
variable or a license for use.
Each environment variable must in the short DOS format, e.g.:
c:\program files\windriver\diab\5.5.1.0\win32\bin\
would be shortened to:
c:\progra~1\windri~1\diab\5.5.1.0\win32\bin\
Each environment variable must end with a trailing '\' character.
Some versions of the Diab compiler will prompt the user for a license server or license file
through a dialog window if a license cannot be found. The user may either fill out the license
information or press the cancel button as required.

Software detail
Name
oe_check_path — determines if more than one version of OpenECU exists in MATLAB's
path.
Synopsis
oe_check_path
Description
OE_CHECK_PATH checks for all installed copies of OpenECU on MATLAB's path and warns
the user if more than one was found.
Only one version of OpenECU should be referenced from MATLAB's path otherwise different
versions can interact to result in models which do not load correctly or build correctly.
To view MATLAB's path, type
path
at MATLAB's command prompt. To modify the path, select the menu option 'File -> SetPath...'
and having made any modifications, select Save to remember the modifications for when
MATLAB next starts.

Software detail
Name
oe_config_using_ert — configure the model to use Embedded Coder (RTW) for model builds.
Synopsis
oe_config_using_ert
Description
OE_CONFIG_USING_ERT creates an active configuration set for OpenECU to be build using
Embedded Coder (RTW-EC) if the configuration set has not already been created. If the
configuration set already exists then the configuration set is activated.

Software detail
Name
oe_config_using_grt_rtmodel — configure the model to use the RTMODEL target of Simulink
Coder (RTW) for model builds.
Synopsis
oe_config_using_grt_rtmodel
Description
OE_CONFIG_USING_GRT_RTMODEL creates an active configuration set for OpenECU to be
build using Simulink Coder (RTW-RTMODEL) if the configuration set has not already been
created. If the configuration set already exists then the configuration set is activated.

Software detail
Name
oe_config_using_sim_dd — configure the model to use a Simulink Data Dictionary.
Synopsis
oe_config_using_sim_dd [modelname]
oe_config_using_sim_dd [modelname] [data_dictionary_file]
oe_config_using_sim_dd [modelname] [data_dictionary_file] [overwrite]
Description
OE_CONFIG_USING_SIM_DD creates a Simulink Data Dictionary with the default name of
bdroot.sldd from the model's build list, and configure the model to use this data dictionary.
OE_CONFIG_USING_SIM_DD 'model' creates a Simulink Data Dictionary for the specified

model, with the default name of model.sldd from the model's build list, and configure the
model to use this data dictionary.
OE_CONFIG_USING_SIM_DD 'model' 'data_dictionary_file' creates a Simulink

Data Dictionary for the specified model, with the name data_dictionary_file.sldd from the
model's build list, and configure the model to use this data dictionary.
OE_CONFIG_USING_SIM_DD 'model' 'data_dictionary_file' 'overwrite'

clears a previously created Simulink Data Dictionary for the specified model, with the name
data_dictionary_file.sldd and overwrites the data dictionary file with the specified models's
build list, and configure the model to use this data dictionary.
6.4.5. Change versions of OpenECU

Software detail
Name
oe_switch_version — list available versions of OpenECU or update MATLAB's path to
another version of OpenECU.
Synopsis
oe_switch_version
oe_switch_version string string
oe_switch_version directory-of-installed-openecu
Description
OE_SWITCH_VERSION lists available platforms relative to the current OpenECU MATLAB
path and those previously installed. The user can select which version to switch to.
OE_SWITCH_VERSION STR STR changes the current OpenECU MATLAB path to the
platform path that matches the first and second parameter (the second parameter is optional).
OE_SWITCH_VERSION DIR changes the current OpenECU MATLAB path to the platform
path specified by the first parameter. The parameter must be the full path including drive
character.
Examples:
List all available platforms
oe_switch_version
Switch to a platform which includes one string in its directory
oe_switch_version 1_9_2
oe_switch_version trunk
Switch to a platform which includes two strings in its directory
oe_switch_version platform 1_9_2
oe_switch_version trunk serengeti
Switch to a specific location where OpenECU is installed
oe_switch_version c:\openecu\platform\1_9_2
The matching strings can be shortened. For instance, the first of the two following examples
can be shortened into the second:
oe_switch_version trunk serengeti
oe_switch_version trunk ser

Software detail
so long as 'trunk' and 'ser' match uniquely.
Note
MATLAB's path will be modified for the current session and saved for the next. Next
time MATLAB starts, the switched-to version of OpenECU will be retained.
Note
Switching to an earlier version of OpenECU is supported. But earlier versions of
OpenECU do not always support switching to later versions. If switching to an later
version of OpenECU fails then you will need to manually edit the MATLAB path
manually. See the Installation section of the Release Notes or User Guide for details
on which paths to add.
Warning
MATLAB's cache of models is cleared without saving. All models and MEX functions
will be cleared from memory (except those in a debug or compile state) using the
bdclose all and clear functions commands. This avoids cached elements of
one version of OpenECU being used after switching to another version of OpenECU.
6.4.6. Supporting tools

Software detail
Name
oe_freeccp — download a built model image to OpenECU.
Synopsis
oe_freeccp [-check] [-f <image_file>] [-cancardxl] [-pci] [-croid <id>] [-
dtoid <id>] [-targetid <station address>] [-b <baudrate>]
Description
OE_FREECCP invokes the freeccp tool to either download a model image to an OpenECU or
to check if an OpenECU is available on a CAN link.
The freeccp tool is provided free and unsupported by OpenECU. Users are permitted to
use this software for commercial and non-commercial purposes.
The freeccp tool relies on a Vector CAN card.
The command options take the following form:
Option Description
-check check for an OpenECU device on the CAN link (use appropriate
CRO, DTO, station address and baud rate settings as
necessary)
-f <image_file> download the build S-record image file (do not use the Intel
HEX image)
-cancardxl select a cancardxl can card
-pci select a PCI can card
-croid set the CRO CAN identifier (PC to ECU CAN message —
default is 1785)
-dtoid set the DTO CAN identifier (ECU to PC CAN message —
default is 1784)
-targetid set the station address (default is 0)
-b set the baud rate in kBps (default is 500)
Examples:
oe_freeccp -f step1_image_small.s37
attempts to program the OpenECU device with the built step1 model.
oe_freeccp -croid 400 -dtoid 401 -targetid 2 -b 500 -f

step1_image_small.s37
attempts to program the OpenECU device with the built step1 model, using a CAN ID of
400 for the CRO messages, using a CAN ID of 401 for the DTO messages, using a station
address of 2 at 500 kBps.
oe_freeccp -check
attempts to talk to an OpenECU device using the default CCP settings.

Chapter 7. Extended diagnostics
functions
7.1. Introduction to Diagnostics ............................................................................... 507
7.2. Diagnostic Legislation ...................................................................................... 508
7.3. Approach ......................................................................................................... 510
7.4. Diagnostic trouble codes and freeze-frames ...................................................... 511
7.5. Diagnostic monitors, tests and performance ratios ............................................. 512
7.6. Worked example — building a diagnostic system ............................................... 513
7.6.1. Step 1 — test conditions at the monitor level .......................................... 513
7.6.2. Step 2 — individual flow tests ................................................................ 514
7.6.3. Step 3 — general NVM storage and other blocks .................................... 514
7.6.4. J1979/ISO 15031 scan tool request/response ......................................... 515
7.6.5. J1939 scan tool request/response .......................................................... 518
7.7. Extended diagnostic Simulink blocks ................................................................. 518
7.7.1. Calibration verification number (CVN) (psc_CvnCalc) ............................... 518
7.7.2. DTC clear all (pdtc_ClearAll) .................................................................. 520
7.7.3. DTC clear all if active (pdtc_ClearAllIfActive) ........................................... 520
7.7.4. DTC clear all if inactive (pdtc_ClearAllIfInactive) ...................................... 520
7.7.5. DTC match and clear (pdtc_ClearDtcs) .................................................. 520
7.7.6. DTC control (pdtc_Control) .................................................................... 523
(pdtc_DiagnosticTroubleCodeExt) .................................................................... 524
7.7.8. DTC lamp states (pdtc_Status) .............................................................. 534
7.7.9. DTC match exists (pdtc_MatchExists) .................................................... 537
7.7.10. DTC memory update (pdtc_Memory) .................................................... 539
7.7.11. DTC table definition (pdtc_Table) ......................................................... 539
7.7.12. DTC table cleared indication (pdtc_TableCleared) ................................. 539
7.7.13. ISO configuration (piso_Configuration) .................................................. 541
7.7.14. ISO security permissions (pdg_Permissions) ......................................... 546
7.7.15. ISO DTC extended data records (pdg_ExtendedDataRecord) ................. 550
7.7.16. Routine control (pdg_RoutineControl) ................................................... 553
7.7.17. Parameter identifier (ppid_Pid) ............................................................. 558
7.7.18. Parameter identifier scaling (ppid_Scaling) ............................................ 563
7.7.19. Freeze frame (pff_FreezeFrame) .......................................................... 565
7.7.20. DM25 freeze frame (pff_Dm25FreezeFrame) ........................................ 569
7.7.21. Freeze frame configuration (pff_Configuration) ...................................... 570
7.7.22. J1939 configuration (pj1939_Configuration) ........................................... 572
7.7.23. J1939 channel configuration (pj1939_ChannelConfiguration) .................. 572
7.7.24. J1939 Transmit DTC DM (pj1939_TransmitDtcDm) ................................ 573
7.7.33. J1939 DM7 decode (pj1939_Dm7Decode) ............................................ 580
7.7.35. J1939 DM10 transmit (pj1939_Dm10Transmit) ...................................... 584

Extended diagnostics functions

7.7.51. J1939 parameter group receive message (pj1939_PgReceive) ............... 618
7.7.52. J1939 parameter group requested (pj1939_PgRequested) ..................... 619
7.7.53. J1939 parameter group transmit (pj1939_PgTransmit) ........................... 619
7.7.54. J1939 send acknowledgement message (pj1939_SendAck) ................... 619
7.7.55. J1939 update NTE status (pj1939_UpdateNteStatus) ............................. 620
7.7.56. J1979 service $09 Infotype input (pdg_InfotypeInput) ............................. 621
7.7.57. Diagnostic monitor entity (ppr_DiagnosticMonitorEntity) .......................... 623
7.7.58. Diagnostic test entity (ppr_DiagnosticTestEntity) .................................... 628
7.7.59. General denominator (ppr_GeneralDenominator) ................................... 634
7.7.60. Ignition cycle (ppr_IgnitionCycle) .......................................................... 635
7.7.61. PPR memory update (ppr_Memory) ..................................................... 636
7.7.62. Monitors incomplete count (ppr_MonitorsIncomplete) ............................. 637
This section gives details on the Extended Diagnostics Functions which are an optional
addition to the OpenECU platform.
7.1. Introduction to Diagnostics

The legislated requirements for the infrastructure to manage on-board diagnostics data has
grown steadily over the years. This section describes the OpenECU approach to providing
that support in a flexible way. This allows the users of OpenECU and related systems to
concentrate on the system they are developing and at the same time meet the legislated
requirements for emissions related control systems.
The diagnostic infrastructure support has been designed to meet both CARB and EURO
diagnostics requirements and communicate with scan tools according to both heavy duty
(J1939) and passenger car (ISO15765) protocols. It is aimed at vehicles which have to
comply with 2010 and beyond legislation (eg EURO6).
It is important that the user understands general OBD terminology and the interactions
between the various SAE/ISO standards and emissions/OBD legislated requirements. The
standards are generally very good at describing their own terms and acronyms; therefore
they have not been repeated here. There is no substitute for reading the relevant standard.
A quick browse is absolutely essential, so that you will know where to look when the time
comes for more detailed information.
The term diagnostics can be taken to mean many different tasks on different levels. The
following diagram shows some of these. Details of how the user's application has to interact
with the OpenECU platform are described below.

Figure 7.1. Functional Levels within a Diagnostics System
Diagnostics related task Who should implement?
High System-specific tests and data collection User’s application

Level
Storage, management and reporting of

OpenECU platform
application gathered data
Flash reprogramming over CAN OpenECU platform
Low-level communications over CAN OpenECU platform
Low Detected hardware errors (e.g., short circuit) OpenECU platform

Level
7.2. Diagnostic Legislation

The OpenECU diagnostics infrastructure has been tailored to meet the following legislation.
In many cases, the exact description for a particular behaviour has to be extracted from more
than one document.
For European OBD documents, most of the emissions related legislation is held within
Directive 70/220/EEC, which has been amended many times over the years. OBD
requirements are held within Annex XI, which itself was created and subsequently modified
by directives:
• 1998/69/EC
• 1999/102/EC
• 2002/80/EC
• 2003/76/EC
For heavy-duty diesel vehicles the Commission brought in Directive 2003/522. Subsequently,
Directive 2005/55/EC introduced additional requirements for Euro-V emissions compliant
diagnostic systems from 2008 or 2009 onwards. This was in turn amended by:
• 2005/78/EC
• 2006/51/EC
• 2008/74/EC
For Euro-VI heavy duty diesel vehicles, the previous regulations were revoked and a new
Commission Directive 582/2011 was put in place.
The Californian (CARB) diagnostics requirements are captured within Title 13 California
Code of Regulations in either section 1962.8 for passenger cars, light and medium duty
vehicles or section 1971.1 for heavy duty vehicles.
Scan tool communications fall into two main categories: heavy duty using J1939 and light
duty using ISO15765 based protocols. The second (light duty) category also includes the
original J1979 diagnostic service requirements (also described in ISO15031-5) as well as the
higher numbered KWP2000 and UDS services.

The J1939 requirements are based on the SAE standards:
• J1939-03 On Board Diagnostics Implementation Guide
• J1939-73 Application Layer - Diagnostics
• J1939-21 Network Layer (Transport Protocol)
The ISO related requirements are based on:
• ISO15031, parts 5,6 and 7
• ISO15765, parts 2,3 and 4
The implementation within the OpenECU platform attempts to steer a course through
these various diagnostics requirements. At times they conflict and in such cases, the
implementation allows the user to select one alternative or another. There are also cases
where a user may want to deliberately over-ride some aspect of the protocol or diagnostic
requirements (e.g. during manufacturing). In these cases, the platform provides the user
application with the ability to make those changes. Therefore it is essential that the application
works together with the platform to provide a coherent and legally compliant diagnostic
system. It cannot be left to just one side or the other.
One of the more confusing areas is the overlap between J1939-73 and ISO15031-5 (J1979)
services for the generic, mandatory services. Both protocols have the ability to transmit more
or less the same information, but in wildly different ways. The following table is loosly derived
from one in J1939-73 and attempts to translate between the two.
Table 7.1. Diagnostic Service Comparisons

ISO/ ISO Description J1939 J1939 Description
J1979 DM
Service
0x01 PID Request Powertrain Data - index DM24 Use DM24 to declare emissions
00 of supported PIDs related support for powertrain
data and DM25 freeze frame
0x01 PID Number of DTCs, MIL status, DM5 OBD compliance, previously
01 supported monitors and their active and active DTC count
status (readiness) monitors supported and their
status (readiness)
0x01 Actual current powertrain Various Normally provided PGs will be
PIDs parameter data used to retrieve the parameter
03-1B data
0x01 PID OBD legislation supported DM5 Which OBD legislation is
1C supported
0x01 PID Distance and time while MIL on, DM21 Diagnostic Readiness 2 reports
21, 4D, Distance and time since DTCs this data
31, 4E cleared
0x01 PID Continuously monitored systems DM26 Diagnostic Readiness 3 reports
41, 1F, 30 status, time since engine start, status of monitors on this data
number of warm ups since DTCs
cleared
0x02 Freeze frame data - byte00 says DM4, DM 4 contains basic freeze
which PIDs supported, byte02 DM24/ frames - note the PG tells what
says which DTC caused each DM25 DTC caused it and the PG
contains standard parameter

ISO/ ISO Description J1939 J1939 Description

J1979 DM
Service
freeze frame, bytes 04-FF have data. DM25 provides more
the data parameter support than DM4.
DM24 says which SPNs are
supported.
0x03 Emission-related powertrain DM1 or Emissions related active(MIL
DTCs DM12, on) DTCs and lamp status
DM23 regular message on DM1 or
when required on DM12. DM23
can report DTCs which are
confirmed but the MIL is off.
0x04 Clear all emissions related OBD DM3 or DM3 clears previously active
data DM11 DTCs and DM11 clears all DTCs
0x05 Oxygen sensor test data (use Not used No planned support for specific
service 0x06 instead) oxygen sensor data
0x06 Test results for non-continuously DM10, DM10 gives the test IDs
monitored systems DM7, supported, DM7 invokes the test
DM8, and DM8 or DM30 are used to
DM30 report the test results
0x07 Emissions-related Pending DM6, DM6 has emissions related
DTCs DM27 Pending DTCs and DM27 has all
Pending DTCs
0x08 Request control of onboard DM7, DM7 commands the test and
system, test or component DM8 DM8 reports the results
0x09 Infotype 00 declares which other Various Individual DMs used for specific
Infotype infotypes are supported infotype data
00
0x09 Vehicle's VIN number Data Reported on Data Stream
Infotype Stream (J1939-71), using PGN 65260
01 / 02
0x09 Vehicle information - Calibration DM19 Bytes 5-20 contain calibration
Infotype ID information
03 / 04
0x09 Vehicle information - Calibration DM19 Bytes 1-4 contain CVN
Infotype verification number (CVN)
05 / 06
0x09 In use performance ratios for DM20 Indicates how often monitors
Infotype diagnostic monitors complete compared to vehicle
07 / 08 operation
0x09 ECU acronym and name
Infotype
09 / 0A
0x0A Permanent DTCs (emissions DM28 Permanent DTCs (emissions
related) related)
7.3. Approach
The approach to implementing the diagnostics functions is a balance between providing
flexibility and requiring minimal intervention. The user needs the ability to configure their

data and choose which services to support. In some cases, the scan tool interactions do
not require additional user code (model) as the data is well structured and can be reported
simply by the OpenECU platform.
The Simulink blockset provided does not force any particular structure or hierarchy onto
the user. The OpenECU build system will gather data about DTCs, freeze-frames, PIDs,
monitors etc at build time and generate an appropriate set of embedded data structures for
that particular system. This allows the user to implement diagnostic functions throughout their
model without carrying any extra overheads within the embedded code.
The diagnostics system works closely with the NVM file system. Again, the user has some
flexibility in terms of allocating certain amounts of memory or choosing when data is written,
but for the most part, this interface is seamless and diagnostic data is stored and retrieved
safely with minimal input from the user. The freeze-frames potentially take the largest amount
of NVM, which is controlled via the pff_Configuration block.
Communications with the scan tool behave slightly differently for J1939 compared to
ISO15765 and related protocols. For J1939, the user’s application model is required to
provide data for the reply to a scan tool request. However, for most of the ISO15765 standard
services, the data is retrieved by the platform and sent back to the scan tool with minimal
intervention from the user’s application model.
Figure 7.2. Scan tool link via platform
ECU
SCAN TOOL
User’s Application
NVM data,
DTCs,
API Freeze-frames,
Test results
IUPR
etc
CAN
OpenECU platform
7.4. Diagnostic trouble codes and freeze-

frames
Diagnostic Trouble Codes (a.k.a. DTCs or fault codes) are the basic building blocks of the
diagnostic infrastructure. There are multiple standards for the fault information to follow as
well as choices for its life-cycle depending on whether it is emissions-related or permanent
and the legislation being followed. These details are selected within the Simulink definition
block for each DTC and allow the user to configure the system for various aspects of
diagnostic legislation.
DTCs may be grouped into tables to help the user manipulate them. They can then be cleared
(by table name) if required.
DTCs will also have an associated freeze-frame that is stored when the fault occurs. The
user may specify several different types of freeze-frame for use with different DTCs. The
various freeze-frame definitions may include more or less data to be captured when a fault
occurs. Note that the legislation requires some specific pieces of data to be captured for
emissions related faults.

For a specific piece of data to be captured in a freeze-frame, the application needs to point it
out to the platform. This is one of the uses of the PID block (J1939 SPN data). The platform
can grab the latest data from the inport to the PID block when required. The same PID block
mechanism allows the OpenECU platform to provide real-time data from within the user’s
model to a scan tool (e.g. for J1979 service $01 or J1939 DM24).
The user may implement the DTC, PID and freeze-frame blocks anywhere in the model.
At build time, the OpenECU system will search the user’s model to find all potential DTCs
and associated freeze-frame definitions and will allocate sufficient memory depending on the
number and type of DTCs and freeze-frames.
The build process will automatically create a constant named

pff_dtc_sev_overrides_ff_age with a default value of "FALSE". This is used to
determine if the severity of the DTC takes precedence over age when faced with lack of
space to store freeze-frames in NVM. Selection of the desired behaviour is configurable at
the C-API level (via option ff-store-by-dtc-severity), but this has not yet been implemented
in Simulink; Simulink models will currently always select age of DTC to take precedence in
storage.
Here's an example of J1939 SPN data being collected via two PID blocks. This data can
now be used in freeze frames as well as reported via DM24. The PID blocks can be placed
anywhere in a model to gather data from the most convenient places. To incorporate this
data into a freeze frame, use a vector calibration containing the list of PID identifiers(J1979)
or SPNs(J1939) in the pff_FreezeFrame block.
Figure 7.3. Use of PID blocks to collect data
pid_bytes
1 app_bytes J1939 SPN: 899

engtrqmode
override_status
reqd_FF_data_EngTrqMode
Qy = Qu >> 8
2 Vy = Vu * 2^-8 pid_bytes
Ey = Eu
engspd
app_bytes J1939 SPN: 190
override_status
reqd_FF_data_EngSpd_RPM
There are user configurations related to freeze-frames, which determine the total number to
capture and the maximum amount of RAM and NV memory to allocate for freeze-frames. This
allows the user to limit the allocation of memory (e.g. in the event of repeated faults) while
at the same time making maximum use of the resources available in the ECU. This flexibility
means that the system can be tailored to be more useful during development phases (when
extra memory may be available) and then scaled back for the production version without
changes to the model structure.
The Simulink block pdtc_DiagnosticTroubleCodeExt is the main dialog for each fault
in describing how it should behave. In particular, note the distinctions between CARB
permanent and Euro non-eraseable DTCs. In each case the conditions required to clear the
DTC are fully specified in the relevant legislation.
7.5. Diagnostic monitors, tests and

performance ratios
A complete emissions related diagnostic system will have a have a set of diagnostic monitors
to check the performance of each of the various components on a vehicle. These diagnostic
monitors are in turn made of a series of diagnostic tests. The individual tests may be
performed continuously, for example checking the range of an analogue input or the state
of an output signal. Alternatively the tests may be classed as non-continuous which means
that they can only be performed when the vehicle is in a certain operating state, for example
checking the performance of a catalyst or the EGR sub-system.

The OpenECU platform allows the user to define the monitors and related tests in the system
using the ppr_DiagnosticMonitorEntity and ppr_DiagnosticTestEntity blocks.
The user's application must use these blocks in conjunction with their individual diagnosis
algorithms and provide data from each time an individual test is performed. The data is used
in two ways by the platform:
• Firstly, each time a test is run, this allows the platform to update the numerator and
denominator to be used in calculating the In-Use-Performance-Ratio for that particular
diagnostic.
• Secondly the most recent test results (and limits) must be available for communication to
a scan tool. The platform will store this data in NVM (to keep it in the event of a power
down) for future communication to a scan tool.
Note
The legislation has some specific values (MonitorID) that must be used for specific sub-
system emissions monitors.
7.6. Worked example — building a diagnostic

system
In this example, we will build a hypothetical flow monitor which is to be part of an emissions
compliant system and therefore needs to meet legal diagnostic requirements. We shall build
it to meet Californian OBD regulations and the scan tool will use ISO 15765 to communicate
with the ECU.
7.6.1. Step 1 — test conditions at the monitor level

The flow monitor is made up of two individual flow tests, each of which can only be performed
under certain conditions. The application needs to select the conditions to trigger each of the
actual tests. In legal terms, this is a non-continuous monitor and therefore needs to inform
the system when it can run for use in determining the In Use Performance Ratio (numerator /
denominator).
The Simulink model below shows a set of conditions for each of the tests being used to
enable two further sub-systems. Each of those sub-systems will contain an individual flow
test and associated interfaces.
At the monitor level, the application uses the ppr_DiagnosticMonitorEntity block. There are
inputs for when the tests are running, when they have completed and there is also the ability
to force data into the block. These forcing inputs have been grounded (set to FALSE). The
output of the DME block provides the latest value of the numerator/denominators associated
with the overall flow monitor.
Also shown are the two ppr_DiagnosticTestEntity blocks for the two individual tests. These
receive the data for individual test results, limits and individual numerator/denominator
updating.
For an ISO based scan tool, the data is accessed by a Service $06 command. Passing the
data to the scan tool is handled directly by the platform, so in this case, the DME and DTE
block outputs are for information only.

Figure 7.4. Building a diagnostic system — monitor level

1
Flow_parameter This subsystem determines when the flow test conditions are all true.
2
Another_flow_parameter
3
Measured_temperature
[Hi_flw_done] enabled
monitor_run
[Lo_flw_done]
readiness_complete
force_complete DME ID: 123

completed
Readiness limit: 3
4 ISO Monitor ID: 3
ISO Monitor group: Other
Measured_pressure force_not_complete numerator
denominator
monitor_enabled
ratio
5
Operational_state
[Hi_flw_done] numerator_update dte_numerator
[Hi_flw_done] dte_denominator
Test_complete denominator_update
numerator_updated_this_dc
Test_value test_value DTE ID: 2
6 Flow_data DME ID: 2 denominator_updated_this_dc
ISO Monitor ID: 123
Flow_test_data_bus Test_limit test_limit_min ISO Test ID: 23
Scaling ID: 33 dte_test_value
Hi_flow_flt_state 1 test_limit_max
dte_test_lim_min
Hi_flow_flt_state
High Flow Test [Hi_flw_done] test_run dte_test_lim_max
reset dte_test_run_status
[Lo_flw_done]
numerator_update dte_numerator
Test_Complete [Lo_flw_done]
denominator_update dte_denominator
In1 Test_Value test_value DTE ID: 2
DME ID: 2 denominator_updated_this_dc
ISO Monitor ID: 234
test_limit_min ISO Test ID: 12
Test_Limit Scaling ID: 33 dte_test_value
test_limit_max
dte_test_lim_min
Low Flow Test
[Lo_flw_done] test_run dte_test_lim_max
dte_test_run_status
reset
7.6.2. Step 2 — individual flow tests

We’ve invented two individual tests which make up our flow monitor. The principle is the
same for each, so will only consider one here.
The Simulink model below shows how an individual pass/fail result is used to set and clear
DTCs.
Figure 7.5. Building a diagnostic system — individual test

Hypothetical High Flow Test
2 4
Test_value Hi_flow_flt_state
In1
parameter1
flow_test_value K Ts
In2
parameter2 z-1 state
1
Flow test algorithm test_failed
Flow_data pressure
count
Name: High_Flow_Fault
ISO ID: 1234
FTB: hex2dec('11')
dc_count
x
x: mftm_high_flow_lim_x test_completed
y: mftm_high_flow_lim_y z(x,y) 3
z: mftm_high_flow_lim_z wu_count
y Test_limit
temperature
put_High_Flow_Threshold
K Ts
z-1
1
Test_complete
commit store_up_to_date
Delay
We’ve made up some imaginary table which provides a test limit. The flow test algorithm
computes a value which is compared against this limit. If the value is greater than the limit,
then an integrator adds up the time for which it is over the limit. Once suitable time has
passed, the test is considered to have failed and a fault code will be stored by triggering the
DTC block. These DTC blocks may exist anywhere within the Simulink model.
The duration integrator allows for sufficient time to pass and if the test value was not above
the limit, the test will be completed and passed.
Note that the test limits and test value are passed out to the DTE block for use in the event of
a scan tool service $06 request. The platform is asked to store the new results after a short
delay. This is required, as the service $06 request needs to be given the most recent test
results, even if those results are days or even weeks old.
When a DTC is triggered (via the test_failed inport as shown above) an emissions related
system must capture a freeze frame. This mechanism uses the PID and freeze-frame blocks
ppid_Pid and pff_FreezeFrame.
7.6.3. Step 3 — general NVM storage and other blocks

Some examples of hooking up other diagnostics related blocks into the application model are
shown below. Note that these examples will only exist in one place within the Simulink model.
Firstly, an example of how the lamp outputs can be used. Here, we have configured the MIL
lamp as a CAN output, the Red Stop Light and Amber Warning Light as digital outputs on
this module and the Protection Lamp is not used.

Figure 7.6. Building a diagnostic system — warning lamps

Message ID: 123 decimal

sim_request_count Length: 1 bytes request_count
Field Start Positions: [0]
Field Widths: [8]
sim_overwrite_count Field Signs: [0] overwrite_count
Field Type Codes: [3]
sim_ack_count Use Extended ID: off ack_count
Provide Simulation Output: on
CAN0(pinA28+A43) CAN0(pinA28+A43)
mil_status
rsl_status state
Sample time: Inversion: off
Default value: 0
awl_status
fault
pl_status
state
Inversion: off
Default value: 0
fault
The next model snippet shows the setting of some of the generic counters. Note that this
has some slightly simplified logic.
Figure 7.7. Building a diagnostic system — generic counters
Channel: DIN (pin XD1)

Inversion: off
Set dead time: 0.5 debounced_state update ignition_cycle_count
Reset dead time: 0.25
Sample time: MCA_BACKGROUND
4
Time_since_start
4_hrs
dc_start
1
ECT wu_start
deg-C ic_start
2 eng_running
ECT_at_startup
ok_to_clr_perm
deg C
3
Engine_speed
rpm
There are additional blocks to force NVM storage – this can be done by the user on a periodic
basis or perhaps only after tests have completed and new results are available or when DTCs
have been set. The blocks are shown in the example models.
7.6.4. J1979/ISO 15031 scan tool request/response

Once a model has been built with the diagnostics integrated, there is very little left for the
application to do to respond correctly to J1939/ISO 15031 scan tool requests. The platform
keeps track of any DTCs and whether they are classed as “pending” or “active” etc. The data
entered into each DTC block will define this. As drive-cycles and warm-up cycles go by, fault
data and freeze-frame data will be erased if they don’t recur. Similarly as individual tests
happen, the test result data is stored, together with the numerator/denominator counts for
each of the defined monitors.
If a scan tool now follows the J1979/ISO 15031 standard to request emissions data, the
OpenECU system will respond with the correctly formatted data for each request. The full list
of emissions related diagnostic services are detailed below.
The build process will automatically create a calibration variable named

pdgc_emissions_report_min_sev with a default value of "sev-c". This calibration is
used to determine the emissions severity level at or above which the platform will include a
DTC when responding service requests.
The build process will create entries for this value in the A2L file for sev-a (highest), sev-b1,
sev-b2, sev-c, or sev-none (lowest). To emit all DTCs regardless of their emissions severity
level, use sev-none.
Table 7.2. PDG supported services

ID Service Notes
0x01 Request Current Powertrain Used to read PID values that have
Diagnostic Data (J1979) a J1979 8-bit identifier defined

ID Service Notes
0x02 Request Powertrain Freeze Frame Used to read PID values that
Data (J1979) have been captured when a DTC
occurred
0x03 ReadEmissionDTCs (J1979) Reports only DTCs defined as
emission-related
0x04 ClearEmissionDTCs (J1979) Clears only DTCs defined as
emission-related
0x06 RequestOBDTestResults (J1979) Reports test results for ISO test
IDs
0x07 ReadEmissionDTCsPending Reports only DTCs defined as
(J1979) emission-related that are pending
0x09 RequestVehicleInformation Used to read Vehicle Information
(J1979) data stored as InfoTypes
0x0A ReadEmissionDTCsPermanent Reports only DTCs defined
(J1979) as emission-related that are
permanent
0x10 StartDiagnosticSession Used to request a change between
(KW2000-3) or diagnostic sessions. (Default,
DiagnosticSessionControl (UDS) Extended and Programming)
0x11 ECUReset (KW2000-3, UDS) Used to reset the ECU. Only
supported by Bootloader to exit
reprogramming mode
0x14 ClearDiagInfo (KW2000-3, UDS) Clears all or subgroup of ISO
DTCs (not J1939-only DTCs)
0x17 ReadStatusOfDTC (KW2000-3) Reports the status of the specified
DTC
0x18 ReadDTCByStatus (KW2000-3) All DTCs, regardless of emissions
severity
0x19 ReadDTCInfo (UDS) 16-bit DTCs currently output, lower
byte zero; many subfunctions
0x21 ReadDataByLocalIdentifier Used to read PID values using an
(KW2000-3) 8-bit identifier
0x22 ReadDataByCommonID Used to read PID values using an
(KW2000-3, UDS) 16-bit identifier
0x23 ReadMemoryByAddress Used to read raw memory contents
(KW2000-3, UDS) (subject to security restrictions)
0x24 ReadScalingDataByIdentifier Used to read scaling data for a PID
(UDS)
0x27 SecurityAccess (KW2000-3, UDS) Used to grant security access in
boot loader mode
0x28 CommunicationControl (UDS) Used to switch on/off the
transmission and or the reception
of certain messages
0x28 DisableNormalMessageTransmissionUsed to switch off the transmission
(J2190) of non-diagnostic and non-network
management messages

ID Service Notes
0x29 EnableNormalMessageTransmissionUsed to switch on the transmission
(J2190) for all messages
0x2A ReadDataByPeriodicIdentifier Used to request automatic periodic
(UDS) transmission of selected PIDs
0x2C DynamicallyDefineDataIdentifier Used to specify a new PID
(UDS) composed of other PIDs or
memory reads
0x2E WriteDataByLocalIdentifier Used to write PIDs specified by 16-
(KW2000-3, UDS) bit identifier (eg NV PID data)
0x2F IOControlByCommonID Used to override PID values using
(KW2000-3, UDS) a 16-bit identifier
0x30 IOControlByLocalID (KW2000-3, Used to override PID values
UDS) (identified by KW2000 8-bit local
identifier)
0x31 RoutineControl (UDS) Used to initiate a specified process
in boot loader mode, e.g. erase
memory
0x34 RequestDownload (KW2000-3, Used to initiate a downloading of
UDS) a block of memory in boot loader
mode (only the downloading of
unencrypted, uncompressed data
is currently supported)
0x36 TransferData (KW2000-3, UDS) Used to download data in boot
loader mode (only the downloading
to flash is currently supported)
0x37 RequestTransferExit (KW2000-3, Used to terminate data transfer
UDS) between the tester and the ECU in
boot loader mode
0x3E TesterPresent “Ping” to maintain communications
0x85 ControlDTCSetting Used to Stop or Start the setting of
DTCs
Note
Services $14, $17 and $18 use the ISO 15031-6 values for groupOfDTC groups in
KW2000-3 style (powertrain 0x0000, chassis 0x4000, body 0x8000, network/other
0xC000, all 0xFF00). For $14, the equivalent 24-bit UDS values may alternatively be
used (0x000000, 0x400000, ... and 0xFFFFFF for 'all').
Note
Please contact OpenECU for support with flash reprogramming. The EraseMemory
routine ($FF00) typically specified by OEMs is supported in two formats:
• Numeric range: If a length is supplied, the address value is interpreted as an actual

device address and the specified range is erased.
• Logical index: If no length is supplied, the address value is interpreted as the zero-
based index of the eraseable flash block, which is device-dependent. For example,

the MPC5534 M0 block (0x40000 - 0x5FFFF) has index 6. This follows the HIS group
reprogramming specification.
7.6.5. J1939 scan tool request/response

The OpenECU interface for J1939 responses is somewhat different. In this case, the
application has to determine the nature of the request and initiate a response. This is assisted
by the provision of the J1939 request/response blocks. The application needs to detect a
particular request and then trigger the appropriate diagnostic action (most likely via another
platform block). The platform makes the data available to the application, which it must then
feed into the appropriate J1939 response block.
Generic J1939 receive and transmit blocks are provided, but are only useful where the reply is
a fixed length. When the reply may be of a variable length, the special response blocks should
be used. They will invoke the J1939 transport protocol for multi-frame replies (if necessary).
See here Section 4.6.3.3, “J1939 (SAE) communications” for the full list of J1939 blocks
provided by OpenECU.
An example of the J1939 request/response layout is shown in the model below.
Figure 7.8. J1939 request/response example

transmit
Channel: 0
PGN: 65229
Type: Nack
sim_error_flag source_addr
sim_transport_errors error_flag pj1939_SendDM4NACK

exd_ff_DM4_transmit_error
sim_requested requested
exd_ff_datarequest
Channel: 0
PDU datapage: 0 transmit
sim_source_addr PDU format: 254 source_addr Channel: 0
PDU specific: 205
Sample time: 0.1 priority
pj1939_PgRequested_DM4 dest_addr transport_errors

exd_ff_DM4_transport_error
use_dest_addr
This example is for DM4. The same request/response arrangement should be used for all
J1939 DM requests. OpenECU provides a specific transmit block for each DM that has a
variable length response.
7.7. Extended diagnostic Simulink blocks

7.7.1. Calibration verification number (CVN)
(psc_CvnCalc)
Calculates the calibration verification number of the code and calibration memory regions.

All targets

EXT_DIAG (Extended diagnostics library). (See Section 1.4, “Licensed Features”.)
cvn
trigger CVN available
calculating
psc_CvnCalc
The CVN is calculated using CRC-16-CCITT. The reported CVN is composed of the code
area CRC and calibration area CRC. The calibration area CRC occupies the 2 most

significant bytes. The code area CRC occupies the 2 least significant bytes. Memory regions
which are expected to change during normal ECU operation have been omitted from both
code and calibration CRCs. The code area CRC excludes the file storage area. DTCs,
freeze frames, etc, are stored in the file storage memory region. The calibration area CRC
excludes adaptive calibrations. Note however that when the calibrations are mapped to RAM
on development ECUs (i.e. whenever one can actually calibrate on-the-fly), changing those
calibrations will affect the CVN. This is not the case for production units when the calibration
is fixed and stored in non-volatile memory (NVM). Unused memory areas have been omitted
from both code and calibration CRCs.
The calibration verification number (CVN) is computed in the background task. Multiple
invocations of the background task are used to calculate the CRC so as to prevent a watchdog
timeout. At each invocation the CRC is calculated for a relatively small chunk of memory.
Background checking for code or calibration corruption works through the Calibration
Verification Number computation on supported targets with the OBD library option. Ensure
that the CVN is recomputed continually if run-time corruption checking is required. If it is
detected, an unrecoverable error is raised (resulting in ECU reset). This is in addition to boot-
time checksum validation.
7.7.1.4. Inports
• trigger
A boolean flag to trigger the CVN calculation, apply a rising edge to this inport.
Value type: Boolean
7.7.1.5. Outports
• cvn
The calculated CVN is supplied to the application from this port. The supplied CVN is
composed of the code area CRC and calibration area CRC. The calibration area CRC
occupies the 2 most significant bytes. The code area CRC occupies the 2 least significant
bytes.
Value type: Integer
• available
This port indicates the availability of the CVN.
• FALSE - CVN not available.
• TRUE - CVN available.
Once a CVN has been calculated returns TRUE until ECU reset, i.e. triggering further CVN
calculations does not alter this value.
Value type: Boolean
• calculating
True if the CVN is currently being calculated, otherwise false.
Value type: Boolean

7.7.1.7. Notes
None.
7.7.2. DTC clear all (pdtc_ClearAll)

is supported by the DTC.
See Section 6.1.29, “DTC clear all (pdtc_ClearAll)” for a detailed description.
7.7.3. DTC clear all if active (pdtc_ClearAllIfActive)

is supported by the DTC, and if the DTC state is currently active.
See Section 6.1.30, “DTC clear all if active (pdtc_ClearAllIfActive)” for a detailed description.
7.7.4. DTC clear all if inactive (pdtc_ClearAllIfInactive)

is supported by the DTC, and if the DTC state is currently inactive.
See Section 6.1.31, “DTC clear all if inactive (pdtc_ClearAllIfInactive)” for a detailed
description.
7.7.5. DTC match and clear (pdtc_ClearDtcs)

Clear all DTCs which match the DTC type, DTC emissions severity and DTC state, in
accordance with the comparator parameters.

All targets

Table:
clear
pdtc_ClearDtcs
Given a DTC table, clear all DTCs (if the clear state is supported by the DTC), which match
the block parameters DTC type (in accordance with comparator Type comparison), DTC

emissions severity (in accordance with comparator Emissions severity comparison), DTC
state (in accordance with comparator State comparison). This block provides for configurable
clearing of DTCs according to the user requirements e.g. the user may wish to clear all DTCs
in a given table that are of type ISO only, with emissions severity greater than B1 and with
state not equal to active.
The user may also select to clear DTCs only according to OBD regulations (e.g. following
CARB regulations for permanent DTCs or Euro non-erasable DTCs), or may select to clear
DTCs unconditionally.
7.7.5.4. Inports
• clear
Set to 1 to force the state of each DTC to state clear which match the block parameters
DTC type (in accordance with comparator Type comparison), DTC emissions severity (in
accordance with comparator Emissions severity comparison), DTC state (in accordance
with comparator State comparison).
Value type: Boolean

Calibratable: No
7.7.5.5. Outports
None.
Value type: String

Calibratable: No
• Type comparison
A drop-down selection of the comparison to perform on the DTC's type (first step) when
clearing DTCs, in the DTC table (specified by parameter DTC table identifier). See
parameter DTC type for the second step.
Value type: List

Calibratable: No
• DTC type
A drop-down selection of the type of DTCs to use (second step) for clearing DTCs in the
DTC table (specified by parameter DTC table identifier). If the parameter Type comparison
is set to 'Any' then this drop-down is not available.
Value type: List

Calibratable: No
• Emissions severity comparison
A drop-down selection of the comparison to perform on the DTC's emissions severity (first
step) when clearing DTCs, in the DTC table (specified by parameter DTC table identifier).
See parameter DTC emissions severity for the second step.
Value type: List

Calibratable: No
• DTC emissions severity
A drop-down selection of the emissions severity to use (second step) for clearing DTCs
in the DTC table (specified by parameter DTC table identifier). If the parameter Emissions
severity comparison is set to 'Any' then this drop-down is not available.
Value type: List

Calibratable: No
• State comparison
A drop-down selection of the comparison to perform on the DTC's state (first step)
when clearing DTCs, in the DTC table (specified by parameter DTC table identifier). See
parameter DTC state for the second step.
Value type: List

Calibratable: No
• DTC state
A drop-down selection of the DTC state to use (second step) for clearing DTCs in the DTC
table (specified by parameter DTC table identifier). If the parameter State comparison is
set to 'Any' then this drop-down is not available.
Value type: List

Calibratable: No
• Clear DTCs unconditionally
If checked, this block will clear DTCs matching the comparison criteria above
unconditionally, regardless of whether they are configured as CARB permanent DTCs or
as Euro non-erasable DTCs.
If unchecked, this block will only clear DTCs which match the comparison criteria above,
and which are permitted to be cleared at this time by OBD regulations. Any CARB
permanent DTCs will be cleared under the conditions of the CARB regulations, and Euro
non-erasable DTCs will never be cleared.
Typically this would be unchecked for clearing DTCs via OBD scan tool request, and would
be checked for a full reset of DTCs during production or in other situations where OBD
regulations on clearing DTCs are not relevant (e.g. moving the ECU to a different vehicle).

Value type: Boolean

Calibratable: No
7.7.5.7. Notes
None.
7.7.6. DTC control (pdtc_Control)

Start new drive, warm-up and ignition cycles. Handle engine running signal. Handle vehicle/
operating conditions for OBD clear of CARB permanent DTCs.

All targets

dc_start
wu_start
ic_start
eng_running
ok_to_clr_perm
pdtc_Control
Platform control of DTCs can depend on the number of drive, warm-up and ignition cycles that
have taken place as well as the engine running state. This block is used to signal the start of
each cycle and the engine running state. It is up to the application to determine the conditions
for starting each of the cycles and the engine running state, as these can be dependent on
the regulatory requirements that are being adhered to.
When an OBD clear request is received, any relevant CARB permanent DTCs will not
be cleared immediately. Instead they will be cleared at the end of this drive cycle (or a
subsequent drive cycle) if the relevant test has been carried out and passed (and has not
subsequently failed again). In addition, DTCs relating to certain monitors are required to
wait for certain vehicle/operating conditions to be met during a drive cycle before permanent
DTCs for these monitors may be cleared, where these vehicle/operating conditions will have
exercised a representative range of vehicle behaviour and any existing fault is likely to have
been detected. It is up to the application to determine whether these conditions have been
satisfied, as these can be dependent on the regulatory requirements that are being adhered
to.
7.7.6.4. Inports
• dc_start
A transition from 0 to 1 indicates the start of a new drive cycle. The input should remain high
throughout the drive cycle, but it must be switched low for at least one iteration between
cycles.
Value type: Boolean

Calibratable: No
• wu_start

A transition from 0 to 1 indicates the start of a new warm-up cycle. The input should remain
high throughout the warm-up cycle, but it must be switched low for at least one iteration
between cycles.
Value type: Boolean

Calibratable: No
• ic_start
A transition from 0 to 1 indicates the start of a new ignition cycle. The input should remain
high throughout the ignition cycle, but it must be switched low for at least one iteration
between cycles.
Value type: Boolean

Calibratable: No
• eng_running
Set to 1 for engine running. Set to 0 otherwise.
Value type: Boolean

Calibratable: No
• ok_to_clr_perm
Set to 1 to indicate that vehicle/operating conditions are currently met such that an OBD
clear request may be carried out for permanent DTCs. Set to 0 otherwise.
Value type: Boolean

Calibratable: No
7.7.6.5. Outports
None.
7.7.6.7. Notes
None.

(pdtc_DiagnosticTroubleCodeExt)
Define a diagnostic trouble code, and provide the platform with information relating to its fault
conditions.

All targets


state
test_failed
count
Name: testDtc1
ISO ID: hex2dec('1001')
FTB: hex2dec('11')
dc_count
test_completed
wu_count
pdtc_DiagnosticTroubleCodeExt
A diagnostic trouble code (DTC) is a unique indicator used to remember the state of
a fault. This block supports platform-controlled fault handling for emissions-related and
non-emissions-related faults. The model determines if the conditions for progressing the
platform's fault handling state machine are satisfied or not, and passes this information to
the pdtc_DiagnosticTroubleCodeExt block. The state of any fault can be maintained by the
block while the model is running, and also across power cycles (see the pdtc_Memory block
for more details).
There are two types of DTC currently supported - J1939 and ISO-15765 - although more may
be added in the future. Each DTC can be defined as either a single type, or a combination
of both J1939 and ISO types.
Each DTC can be in one of four states. Its state is Clear if its fault conditions have never
been present, or if a previously active fault has healed itself (its fault conditions have not
been present for a sufficient amount of time). Its state is Pending if its fault conditions are
present, but have not been present for long enough to confirm the fault. Its state becomes
Active if a Pending DTC's fault conditions persist long enough for it to be confirmed, or if a
Previously Active DTC's fault conditions return. Its state becomes Previously Active if an
Active DTC's fault conditions have been not been present for a sufficient amount of time.
The library will transition through the different states, Clear, Pending, Active and Previously
Active based upon the inputs from the application, test_failed and test_completed as well
as information regarding current drive cycle and warm up cycle count.
State transitions are also affected by the action selected when a DTC reaches Previously
Active but the test then fails again. Behaviour in this situation is not specified by CARB
(and therefore not by other OBD specifications deriving from CARB), so behaviour is
manufacturer-specific. One possible interpretation is that the DTC should simply return
immediately to Active. The other possible interpretation is that the DTC should return to
Pending: in this case, if the test continues to fail then the DTC transitions to Active; or if the
test passes for the duration of another drive cycle then the DTC returns back to Previously
Active (instead of returning to Clear as a DTC would usually do from Pending state).
Selection of the desired behaviour is configurable at the C-API level, but this has not yet been
implemented in Simulink; Simulink models will currently always select the latter interpretation
(transition to Pending) for DTC.
If transitions between Previously Active and Pending states are disabled, the following
diagram describes the DTC state transitions.

Figure 7.9. Platform OBD state machine - no transitions between

Previously Active and Pending
if ‘test_failed’ = FALSE
if ‘test_failed’ = TRUE
for required drive if ‘test_failed’ = TRUE
if ‘test_failed’ = TRUE cycles
Clear Active
Pending
1 2
4
if ‘test_failed’ =
FALSE for required
FALSE throughout if ‘test_failed’ =
drive cycles
last drive cycle TRUE
Previously
Active
3
FALSE for required
warm-up cycles if ‘test_failed’ = FALSE
Transitions take place only when test_completed = TRUE
If transitions between Previously Active and Pending states are enabled, the following
diagram describes the DTC state transitions.
Figure 7.10. Platform OBD state machine - transitions between

Previously Active and Pending
if ‘test_failed’ = TRUE for
if ‘test_failed’ = TRUE
if ‘test_failed’ = TRUE required drive cycles
Clear Active
Pending
1 2 if ‘test_failed’ =
4 FALSE for required
drive cycles
throughout last drive cycle if ‘test_failed’ =
AND TRUE
was not previously active
throughout last drive cycle Previously
AND Active
was previously active
3
for required warm-up
cycles if ‘test_failed’ = FALSE
Transitions take place only when test_completed = TRUE
The library keeps track of drive cycles and warm-up cycles based on calls by the application
to the pdtc_Control block.

7.7.7.3.1. DTC ageing in Previously Active state

Detection of warm-up and DTC ageing in the Previously Active state is not as straightforward
as it might at first appear. OBD regulations (in particular CARB and European regulations)
define "drive cycles" unambiguously, but are less clear on the definition of a "warm-up cycle".
It has therefore been necessary to adopt an interpretation which is believed to be the most
stringent possible interpretation, so that regulatory compliance can be assured. Regulations
The OpenECU interpretation of a warm-up cycle is "an ignition cycle in which a warm-up (as
reported by the customer) occurs". The test causing a DTC to be raised must also run and
pass during the same ignition cycle in which the warm-up occurs, in order for the DTC to be
aged by one warm-up count. The following diagram describes scenarios which illustrate how
this will work in an application.
A B C DE F G H J K L M
Power cycle
Ignition cycle reported
Warm-up cycle reported
Test run and passed
Warm-up count incremented
At points A and B a test has not been run and passed in the same warm-up cycle, so the
warm-up count is not incremented.
At point C the warm-up has not yet occurred when the test is run and passed, so the warm-
up count is not incremented. At point D the warm-up occurs, and as a result of the test having
been previously run and passed, the warm-up count is incremented. Further instances of
the test running and passing during this ignition cycle (E) do not affect the warm-up count,
because this is required to count warm-ups and not test executions.
At point F the test is run and passed when the warm-up has already occurred, so the warm-up
count is incremented immediately. Further instances of the test running and passing during
this ignition cycle (G) again do not affect the warm-up count.
Due to power-hold relays, capacitors or other system behaviour, the ECU may not lose power
when the ignition is cycled. Points H and J illustrate that tests carried out on subsequent
ignition cycles with warm-ups will increment the warm-up count, even if the ECU has not
been powered off. Point K illustrates that the requirement for test run and warm-up remains.
Tests may also be required to take place during the power-hold period. Point L illustrates that
the warm-up count will be incremented during the power-hold period if a warm-up cycle has
previously taken place this ignition cycle. Point M illustrates that the requirement for warm-
up still exists during the power-hold period.
Note that this diagram does not mention drive cycles, as these are calculated independently
and do not affect warm-up (except insofar as they are based on conditions arising in the same
vehicle). Note also that the diagram does not mention warm-ups reported with the ignition
off, because the regulatory definition of a warm-up requires the engine to be on (and hence
the ignition to be on).
7.7.7.3.2. DTC non-volatile storage

Changes to DTC states are written to non-volatile storage when block Section 6.1.34, “DTC
memory update (pdtc_Memory)” is invoked with a request for commit to storage. This will
typically occur on shutdown and at periodic intervals during execution. If DTCs have not
changed since the last write to non-volatile storage, invocation of the block Section 6.1.34,
“DTC memory update (pdtc_Memory)” has no effect, maximising the lifespan of non-volatile
storage.

If the DTC cannot be recalled from non-volatile memory (which includes the first time the
ECU is powered up), then the library initialises the DTC as follows:
Table 7.3. DTC initialisation values
DTC information Initial value

State Clear
Number of Times Set Active Count 0
Drive Cycle Count 0
Warm-up Cycle Count 0
Test Run This Drive Cycle No
Test Not Complete Yes
7.7.7.4. Inports
• test_failed
Set to 1 if this DTC is currently in the "faulty" condition.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• test_completed
Set to 1 if the test has been completed for this DTC (can be hardwired to 1 for a continuously
monitored DTC).
Range: 0 or 1
Value type: Boolean

Calibratable: No
7.7.7.5. Outports
• state
Set to the value of the current DTC state (see the DTC states descriptions for a list of
states and values).
Value type: Integer

Calibratable: No
• count
A count of the number of times a J1939 DTC has changed to the active state. Available
only if the parameter DTC type is J1939 DTC, and currently not supported by the platform-
controlled fault handling.
Range: [0, 127] counts - 0 to 126 (The value 127 is reserved for indicating not available).
Value type: Integer

Calibratable: No
• dc_count

Drive cycle count. The number of drive cycles to 'debounce' the DTC state before setting
it to active. This is exported for information only, as the platform is responsible for
progressing the state machine.
Range: [0, 127]
Value type: Integer

Calibratable: No
• wu_count
Warm-up cycle count. The number of warm-up cycles in which the DTC has not failed -
used to 'heal' faults that are no longer present. This is exported for information only, as the
platform is responsible for progressing the state machine.
Range: [0, 127]
Value type: Integer

Calibratable: No
• DTC name

An optional name can be given to a DTC to identify it for calibrating the ID parameters. If no
name is given, it will be allocated a name when the model is built. Note that this allocated
name can change between builds, so should not be use for calibration. If a DTC will need
to be calibrated, it should be explicitly named.
Generation of DDE entries for DTCs needs to be enabled. See Configuration options for
more details.
Value type: String

Calibratable: No
The name of the DTC table to store this DTC in (there must be a corresponding named
table specified in a pdtc_Table block in the model).
Value type: String

Calibratable: No
• DTC type
A drop-down selection of the type of the DTC.
Value type: List

parameter DTC type includes J1939 DTC.
Range: [0, 524287]
Value type: Integer

Calibratable: No
Range: [0, 31]
Value type: Integer

Range: 0 or 1
Value type: Integer

• ISO ID

The value of the ID for this DTC. This ID uniquely identifies the DTC in J1979 and Keyword
Protocol 2000-3 responses, but for UDS the UDS failure type byte is also employed. If two
or more DTCs are defined with the same ISO ID but different failure type bytes, both may
be listed in response to a J1979 or KWP request as they may well have different status
bits set. Available only if the parameter DTC type includes ISO DTC.
Range: [0, 65535]
Value type: Integer

• UDS failure type byte
The value of the least significant 8 bits of the full 24-bit ID for this DTC, as output in UDS
responses to service $19 (where the most significant 16 bits are specified by the ISO ID
parameter). Available only if the parameter DTC type includes ISO DTC.
Range: [0, 255]
Value type: Integer

• Emissions severity level
A drop-down selection of the emissions severity level at which a DTC fits. This allows the
modeller to combine "emissions related" and other DTCs within the same system.
Value type: List

• UDS severity level
A drop-down selection of the UDS service $19 severity level for the DTC. Available only
if the parameter DTC type includes ISO DTC.
Value type: List

• MIL action
The action for the Malfunction Indicator Lamp when this DTC is active.
Value type: Integer

• RSL action
The action for the Red Stop Lamp when this DTC is active.
Value type: Integer

• AWL action
The action for the Amber Warning Lamp when this DTC is active.

Value type: Integer

• PL action
The action for the Protection Lamp when this DTC is active.
Value type: Integer

• Permanent
Whether or not this DTC is considered 'permanent' (as defined by CARB/EPA) when the
DTC is active. If the ECU is intended to comply with CARB, this should be selected for
all DTCs that light the MIL.
Value type: Boolean

• Requires vehicle/operating conditions for OBD clear request
Available only if the parameter Permanent is true. CARB requires that for permanent DTCs,
an OBD clear request does not immediately clear the DTC; instead the DTC may only be
cleared when the ECU has verified that the fault is no longer present.
If this option is selected, vehicle/operating conditions as specified by CARB must have

been met during a drive cycle since an OBD clear request was received, ensuring that
the vehicle has been exercised over a range of behaviour which would be likely to detect
any fault that still exists. The test for this DTC must then have been completed (during the
same drive cycle or a later one) and report no fault existing. At the end of the drive cycle in
which the test for this DTC is run, the DTC is cleared as per a normal OBD clear request.
If this option is unselected, vehicle/operating conditions are not required. The test for this
DTC must have been completed and report no fault existing since the OBD clear request
was received. At the end of the drive cycle in which the test for this DTC is run, the DTC
is cleared as per a normal OBD clear request.
Vehicle/operating conditions met is indicated by the inport ok_to_clr_perm to the block

pdtc_Control.
CARB requires that this option is selected for DTCs relating to specific monitors, and
optionally may be selected for DTCs relating to other monitors.
Value type: Boolean

• Non-erasable
Whether or not this DTC is non-erasable (as defined by Euro regulations).
Value type: Boolean

• Active drive cycles
The number of drive cycles for which the fault condition must be present before this DTC
automatically transitions from Pending to Active. By default, this parameter is set to 1 (as
recommended by the CARB regulations).

Range: [0, 255]
Value type: Integer

• Previously active drive cycles
The number of drive cycles for which the fault condition must be absent before this DTC
automatically transitions from Active to Previously Active. By default, this parameter is set
to 3 (as recommended by the CARB regulations).
Range: [0, 255]
Value type: Integer

• DTC de-activate using engine running time
Whether or not this DTC uses elapsed engine running time for it to transition from Active
to Previously Active.
Value type: Boolean

• Elapsed engine running time for de-activation
The value of the elapsed engine running time for the DTC to transition from Active to
Previously Active Available only if the parameter DTC de-activate using engine running
time is checked.
Value type: Integer

• DTC clear using warmup cycles
Whether or not this DTC uses warmup cycles for it to transition from Previously Active to
Clear.
Value type: Boolean

• Clear warm-up cycles
The number of warm-up cycles for which the fault condition must be absent before this
DTC automatically transitions from Previously Active to Clear. By default, this parameter
is set to 40 (as recommended by the CARB regulations). Available only if the parameter
DTC clear using warmup cycles is checked.
Range: [0, 255]
Value type: Integer

• DTC clear using engine running time
Whether or not this DTC uses elapsed engine running time for it to transition from
Previously Active to Clear.
Value type: Boolean

• Elapsed engine running time for clear
The value of the elapsed engine running time for the DTC to transition from Previously
Active to Clear. Available only if the parameter DTC clear using engine running time is
checked.
Value type: Integer

• Regulated exhaust level exceedance DTC
Whether or not regulated exhaust level exceedance applies to this DTC.
Value type: Boolean

• Has torque derate
Whether or not this DTC has torque derate.
Value type: Boolean

• Time until derate
The amount of time until the derate will occur, should this DTC become active. Available
only if the parameter Has torque derate is checked.
Value type: Integer

• Freeze frame associated with this DTC
A reference to the name of the frame frame to capture is entered here (see
pff_FreezeFrame for specifics).
Value type: String

Calibratable: No
7.7.7.7. Notes
None.
7.7.8. DTC lamp states (pdtc_Status)

Firstly, this indicates the required states of the Malfunction Indicator Lamp, the Red Stop
Lamp, the Amber Warning Lamp and the Protection Lamp. These states are determined
having taken into consideration the states of all DTCs in the system.
Optionally, values are output required to support EuroVI MIL activation and to populate
messages with MIL and B1-severity fault time counter values.

All targets


mil_status
rsl_status
Sample time:
awl_status
pl_status
pdtc_Status
Each DTC in the system can specify which (if any) warning lamps are to be lit or flashed
when they become active. This block reports the required states of these lamps. The relative
priorities of the lamp states are (from highest to lowest) continuously on, fast flash, slow flash,
and off. The highest priority lamp state of all of the active DTCs is indicated by this block.
7.7.8.4. Inports
None.
7.7.8.5. Outports
• mil_status
Indicates the state of the Malfunction Indicator Lamp, taking into consideration the states
of all DTCs in the system.
Value type: Integer

Calibratable: No
• rsl_status
Indicates the state of the Red Stop Lamp, taking into consideration the states of all DTCs
in the system.
Value type: Integer

Calibratable: No
• awl_status
Indicates the state of the Amber Warning Lamp, taking into consideration the states of all
DTCs in the system.
Value type: Integer

Calibratable: No
• pl_status
Indicates the state of the Protection Lamp, taking into consideration the states of all DTCs
in the system.
Value type: Integer

Calibratable: No

• mi_actv_mode
The MI Activation Mode as defined by EuroVI in UN_ECE Regulation 49 Addendum 48

Rev 4. (This outport is only shown if the "Show EuroVI outputs?" option is checked.)
Range: [0, 3] (0 is mode 1/no fault, 1 is mode 2/class C, 2 is mode 3/class B1 < 200hr, 3
is mode 4/class A or B1 > 200hr)
Value type: Integer

Calibratable: No
• mil_cumulative
The total time for which the MIL has been active with the engine running. (This outport is
only shown if the "Show EuroVI outputs?" option is checked.)
Value type: Integer

Calibratable: No
• b1_cumulative
The total time for which any B1 severity DTC has been active with the engine running. This
corresponds to the "System Greatest B1 Counter" in SAE J1939-73 DM39. (This outport
is only shown if the "Show EuroVI outputs?" option is checked.)
Value type: Integer

Calibratable: No
• b1_continuous
The current time for which any B1 severity DTC has been active with the engine running.
This counter is reset if no B1 fault is active for three engine cycles. This corresponds to
the "Single B1 Counter" in UN_ECE Regulation 49 Addendum 48 Rev 4. (This outport is
only shown if the "Show EuroVI outputs?" option is checked.)
Value type: Integer

Calibratable: No
• Show EuroVI outputs?

Whether to set additional outports to EuroVI-related values concerning MIL activation and
MIL/B1 time counters.
Value type: Boolean

Calibratable: No
• Sample time
The periodicity of the block execution in seconds.
Value type: Real

Calibratable: No
7.7.8.7. Notes
None.
7.7.9. DTC match exists (pdtc_MatchExists)

Determine the existence of DTCs which match the DTC type, DTC emissions severity and
DTC state.

All targets

dtc_match
Table:
dtc_count
pdtc_MatchExists
Given a DTC table, determine the existence of DTCs which match the block parameters
DTC type, DTC emissions severity and DTC state. Indicate the existence, or otherwise via
an output flag and a count.
7.7.9.4. Inports
None.
7.7.9.5. Outports
• dtc_match
Set to 1 if at least one DTC exists, in the DTC table, that matches the criteria. Set to 0,
otherwise.
Value type: Boolean
• dtc_count
Set to the number of DTCs, in the DTC table, that match the criteria.
Value type: Integer

Value type: String

Calibratable: No
• DTC type
A drop-down selection of the type of DTCs to match in the DTC table (specified by
parameter DTC table identifier).
Value type: List

Calibratable: No
• DTC emissions severity
A drop-down selection of the emissions severity of the DTCs to match in the DTC table
(specified by parameter DTC table identifier).
Value type: List

Calibratable: No
• GTE emissions comparison
If this option is checked, the block will attempt to match DTCs that have an emissions
severity greater than or equal to the DTC emissions severity. Otherwise, the block will
attempt to match DTCs that have an emissions severity equal to the DTC emissions
severity.
Value type: Boolean

Calibratable: No
• Only report confirmed DTCs
Available only if the parameter DTC state is set to "Active". If this option is checked, the
block will attempt to match DTCs that are considered "confirmed" (according to J1979).
Value type: Boolean

Calibratable: No
• DTC state

A drop-down selection of the state of the DTCs to match in the DTC table (specified by
parameter DTC table identifier).
Value type: List

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
7.7.9.7. Notes
None.
7.7.10. DTC memory update (pdtc_Memory)

Retain the DTC tables in non-volatile storage across power cycles.
See Section 6.1.34, “DTC memory update (pdtc_Memory)” for a detailed description.
7.7.11. DTC table definition (pdtc_Table)

Declares a table of diagnostic trouble codes (DTCs), that can be referred to by other blocks
that wish to refer to a group of DTCs.
See Section 6.1.35, “DTC table definition (pdtc_Table)” for a detailed description.
7.7.12. DTC table cleared indication

(pdtc_TableCleared)
The pdtc_TableCleared block can be used to signal when a diagnostic command to clear all
DTCs (or a subset of DTCs) has been received for the specified table.

All targets

Table:
cleared
pdtc_TableCleared
7.7.12.4. Inports
None.
7.7.12.5. Outports
• cleared

Indication of whether the table's DTCs have been cleared since the block's previous
execution. The value corresponds to which (if any) DTCs have been cleared since the last
execution.
cleared J1939 Cleared J1939 Cleared ISO Cleared ISO Cleared

Active DTCs Previously Active All DTCs ($14) Emissions
(DM11) DTCs (DM3) DTCs ($04)
0 - - - -
1 - - - Y
2 - - Y -
3 - - Y Y
4 - Y - -
5 - Y - Y
6 - Y Y -
7 - Y Y Y
8 Y - - -
9 Y - - Y
10 Y - Y -
11 Y - Y Y
12 Y Y - -
13 Y Y - Y
14 Y Y Y -
15 Y Y Y Y
Range: [0, 15]
Note
The KWP/UDS service $14 value is set regardless of the groupOfDTC parameter
requested, even if that means only a subset of DTCs were actually cleared.
Value type: Integer

Calibratable: No

The name of the DTC table to monitor (there must be a corresponding named table
specified in a pdtc_Table block in the model).
Value type: String

Calibratable: No
• Sample time
The periodicity of the block execution. The sample time must be set explicitly - the block
cannot be set to inherit a sample time from its parent. As the block's outport value is
valid only until its next execution, the sample time should be sufficient for the value to be
processed before this occurs.
Value type: Real

Calibratable: No
7.7.12.7. Notes
None.
7.7.13. ISO configuration (piso_Configuration)

Configure the ECU for ISO diagnostic communications.

All targets

Enabled: off
CAN transmit ID: 0

CAN receive ID: 0
CAN functional ID: hex2dec('7DF')
Severity Threshold:
None
piso_Configuration
The ISO messaging protocol is a CAN based messaging system designed to pass information
between vehicle network ECUs in real-time. The platform software handles communication
with an external test tool using ISO 15765-2 based protocols (J1979, Keyword Protocol
2000-3, and ISO 14229-1 UDS).
There is support in the blockset for diagnostic trouble codes (see Section 4.6.6, “Fault
support”).
The diagnostic services supported are drawn from three standards: SAE J1979 (ISO
15031-5, "OBD2"), Keyword Protocol 2000-3 (ISO 14230-3) and Unified Diagnostic Services
(UDS, ISO 14229-1). They all work in the same way, with the first byte of each request
message indicating the required service. Some services are the same (or compatible) in
KW2000-3 and UDS. For a list of supported services, see the Extended Diagnostic Functions
section.

The piso_Configuration block configures the ECU's behaviour when handling ISO messages.
This includes selecting which CAN bus for ISO messaging, specifying the transmit and
receive message IDs, as well as other parameters that adjust the amount of memory set
aside for processing ISO messages.
If a piso_Configuration block is not present in the model, or if it is but the Enable ISO
diagnostics parameter is not set, then ISO support is disabled.
7.7.13.4. Inports
None.
7.7.13.5. Outports
None.
• Enable ISO diagnostics
Enables/disables ISO messaging.
Value type: Boolean

Calibratable: No

• Transmit message ID
The unique CAN identifier for the ISO messages transmitted by the system.
For standard OBD, ISO 15765-4 requires a value in the hex range 7E8 to 7EF for 11-bit
IDs (the value being the physical receive ID plus 8), or 18DAF1xx for 29-bit IDs, where xx
is the ECU 'source address' in J1939 terms.
Value type: Integer

Calibratable: No
• Extended transmit ID
Enables/disables the use of an extended ISO transmit message CAN identifier.
Value type: Boolean

Calibratable: No
• Receive message ID
The unique CAN identifier for the ISO messages received by the system.
For standard OBD, ISO 15765-4 requires a value in the hex range 7E0 to 7E7 for 11-bit
IDs (the value being the physical response ID minus 8), or 18DAxxF1 for 29-bit IDs, where
xx is the ECU 'node address' in J1939 terms.
Value type: Integer

Calibratable: No
• Extended receive ID
Enables/disables the use of an extended ISO receive message CAN identifier.
Value type: Boolean

Calibratable: No
• Functional receive message ID
The global CAN identifier for ISO messages received by all participating ECUs in the
vehicle.
For standard OBD, ISO 15765-4 requires a value of 7DF hex for an 11-bit ID system or
18DB33F1 for a 29-bit ID system.
Value type: Integer

Calibratable: No
A drop-down selection of CAN buses available for ISO messaging.

Value type: List

Calibratable: No
• Size of ISO receive message buffer
The number of bytes for the ISO receive message buffer. This parameter allows the
modeller to reduce the amount of RAM allocated to ISO messages, and therefore increase
the RAM allocated to other functions of the ECU.
Range: [1, 4095]
Value type: Integer

Calibratable: No
• Size of ISO transmit message buffer
The number of bytes for the ISO transmit message buffer. This parameter allows the
modeller to reduce the amount of RAM allocated to ISO messages, and therefore increase
the RAM allocated to other functions of the ECU.
Range: [1, 4095]
Value type: Integer

Calibratable: No
• Emissions severity level
A drop-down selection of the emissions severity level at which a DTC should be considered
"emissions related". This allows the modeller to combine "emissions related" and other
DTCs within the same system.
Value type: List

Calibratable: No
• Number of periodic identifiers
PIDs for automatic periodic sending must be in the 0xF2nn identifier range. Of those,
this parameter is the maximum number that the platform will allow to be simultaneously
requested by the test tool for automatic periodic transmission while the application is
running via UDS service $2A. Leave at zero if service $2A support is not required, to save
RAM.
Range: [0, 254]
Value type: Integer

Calibratable: No
• Periodic identifier transmission base period
The "fast" target rate for PIDs requested for automatic transmission via UDS service $2A
in milliseconds. The "medium" rate is 2x this period, and the "slow" rate is 4x this period.
The platform will send PIDs more slowly than the target rate if this target cannot be met
due to the PID size and transport protocol delays.
Range: [20, 65530]
Value type: Integer

Calibratable: No
• Number of dynamically defined identifier buffers

The number of internal buffer slots allocated for the construction of dynamically-defined
PIDs via UDS service $2C. If necessary one large PID definition may straddle several
internal buffers. Leave at zero if service $2C support is not required, to save RAM.
Range: [0, 255]
Value type: Integer

Calibratable: No
• Override J1979 standard?
If checked, this option allows the user to override the standard message response to J1979
service requests $03, $07 and $0A. Note that this override option should only be used in
exceptional circumstances where it is understood that the resultant message responses
will deviate from the J1979 standard.
Value type: Boolean

Calibratable: No
• Service$03 response
A drop-down selection of the override to apply to a J1979 service request $03 response.
Only available if the Override J1979 standard? parameter is checked. Note that the
platform also provides a calibration to override the response at runtime.
Value type: List

Calibratable: No
• Service$07 response
A drop-down selection of the override to apply to a J1979 service request $07 response.
Value type: List

Calibratable: No
• Service$0A response
A drop-down selection of the override to apply to a J1979 service request $0A response.
Value type: List

Calibratable: No
• UDS DTCFormatIdentifier to report in $19 replies
A drop-down selection to choose the value of the DTCFormatIdentifier field output in UDS
service $19 "NumberOfDTC" responses. This conveys to the test tool the scheme the
application designer was following when allocating 24-bit DTC identifiers.
Table 7.4. UDS DTCFormatIdentifier options

Byte value output Description
0 SAE J2012/ISO 15031-6 (the default)
1 ISO 14229-1 (UDS)
2 SAE J1939-73

Byte value output Description

3 ISO 11992-4
4 ISO 27145-2 (Worldwide Harmonized
OBD)
Regardless of the option chosen, the platform outputs a 24-bit identifier for each DTC
consisting of the most significant 16 bit "ISO" identifier (also used in J1979 or Keyword
Protocol 2000-3 reporting) and the least significant "failure type byte" selected for that DTC.
In particular the DTC's J1939 SPN and FMI are not currently used in UDS $19 responses,
even if the J1939 format option is chosen for this parameter.
Value type: List

Calibratable: No
7.7.13.7. Notes
None.
7.7.14. ISO security permissions (pdg_Permissions)

Configure whether sensitive services are available and related SecurityAccess settings.

All targets

Security: off
inhibit_reprogramming
Flash: Never allowed

Read Memory: Never allowed
pdg_Permissions
Certain UDS/KWP2000 services can be restricted to protect your ECU from having
unauthorised changes or having its contents read out over the diagnostic link.
The relevant services can either be completely disallowed, or allowed only if the required
seed-key security exchange has been passed successfully. (The options are detailed below.)
Even if flash reprogramming via UDS is allowed, you may wish to disable this facility if
run-time circumstances are not appropriate (e.g. vehicle moving or engine running). The
'inhibit_reprogramming' inport allows you to control whether reprogramming is permitted at
run time.
7.7.14.4. Inports
• inhibit_reprogramming
Set to 0 to allow UDS reprogramming (if allowed by other options), or 1 to prevent

reprogramming.
Value type: Boolean

Calibratable: No

7.7.14.5. Outports
None.
• Use seed-key security?
If enabled, the platform will attempt to use a C code function that implements your own
custom security algorithm, whenever it receives the SecurityAccess ($27) service request
from the tool. The security algorithm is also used in programming mode (i.e. by the boot
loader) so that access to the ECU can be controlled even if the application has been erased,
for subsequent programming attempts.
See Notes section at the end of this block help for more detail on how to implement the
security function.
Value type: Boolean

Calibratable: No
• UDS flash reprogramming
Used to control whether UDS protocol flash reprogramming of the application code and/or
calibration is allowed at all, and if so what SecurityAccess must be achieved first (if any).
The options are:
• Allowed without security: programming is always allowed, and no SecurityAccess

exchange is required first.
• Allowed if any security level attained: programming is only allowed if a SecurityAccess

seed-key exchange has been passed successfully, but it does not matter which security
level (LEV_SAT_RSD in the UDS standard) was negotiated.
• Allowed if specified security level(s) attained: programming is only allowed if a

SecurityAccess seed-key exchange has been passed successfully, and the security
level (LEV_SAT_RSD in the UDS standard) was negotiated is one specified in the list
(next parameter down).
• Never allowed: programming is never permitted via UDS, regardless of SecurityAccess

exchanges.
Value type: List

Calibratable: No
• Security level(s) [for flash reprogramming]
This parameter only becomes visible if Allowed if specified security level(s) attained is
selected above. Specify one or more values of the seed-key security level (LEV_SAT_RSD

in the UDS standard) at which flash programming should be permitted. The levels must be
odd values as used in the requestSeed request. (The corresponding level in the sendKey
message is an even number equal to LEV_SAT_RSD + 1.)
Range: [1, 125] (odd numbers only)
Value type: Integer (scalar or

vector)
Calibratable: No
• ReadMemoryByAddress
This is very similar to the parameter which selects the allowed access for UDS
flash reprogramming, but this time controls access to ECU memory via the
ReadMemoryByAddress service ($23). See above for options.
Value type: List

Calibratable: No
• Security level(s) [for ReadMemoryByAddress]
This is just like the corresponding parameter for flash reprogramming described in detail
above, but this time relevant to ReadMemoryByAddress.
Value type: Integer (scalar or

vector)
Calibratable: No
• Allow in Default session
Whether ReadMemoryByAddress is allowed (ever) in a Default diagnosticSession.
Value type: Boolean

Calibratable: No
• Allow in Extended session
Whether ReadMemoryByAddress is allowed (ever) in an Extended diagnosticSession.
Value type: Boolean

Calibratable: No
• Allow in Programming session
Whether ReadMemoryByAddress is allowed (ever) in a Programming diagnosticSession.
Value type: Boolean

Calibratable: No
7.7.14.7. Notes
You must implement your own security function to use seed-key security; it is not supplied
by OpenECU, because it will be specific and confidential to you. The function must be
written such that it does not depend on any statically allocated variables and does not
call any functions, including functions inserted by the compiler for math utilities for example.
This is to ensure that it is fully relocatable, which is required for it to run as part of the boot
loader in reprogramming mode, as well as in normal application mode.
To add your function to the build, place the C file alongside the model, and then instruct RTW
to include it in the build by using the Custom Code... Include list of additional:... Source files
option, alongside other model configuration and build options in the Code Generation/Real-
Time Workshop section (the exact menu item depends on MATLAB version).

Alternatively, you can compile your C code to make an object (.o) file and specify it in
the Libraries option nearby. This is useful if you wish to be cautious with confidentiality by
avoiding application-builders needing to have the C source code available.
Warning
If the auto-coder settings are switched, e.g. from Simulink Coder to Embedded Coder,
this setting will need to be reconfigured.
The function name for the security algorithm and the second empty function that marks the
end of it are fixed. If they are missing, a linker error will be reported. A complete example
block of code is presented below, in which the "secret" algorithm is to reverse the order of
the two seed bytes to form the correct key:
#include "openecu.h"
/*****************************************************************************
* Purpose: Called by the library when UDS/KW2000 diagnostic security access
* is required.
* Returns: Return code to send to tool on error, otherwise zero if OK.
* Notes: Code is copied to nonvolatile memory and must be relocatable. It
* must not call any functions (including compiler arithmetic
* utilities).
*****************************************************************************
*/
U8 psc_diag_security_callback
(
const U8* pdgf_request_message, /* The received unpacked request message */
U16 pdgf_request_message_len, /* Total byte length of request message */
U8* pdgf_seed_buffer, /* Place seed here, or access it when computing correct key */
U8* pdgf_seed_len, /* Specify your seed length (in bytes) here (max 8 bytes) */
U32 pdgf_random /* Pseudorandom number you may use to generate seed */
)
{
if (pdgf_request_message_len < 2)
{
return 0x13; /* invalid length */
}
switch (pdgf_request_message[1])
{
case 0x03: /* a requestSeed value we choose to support */
/* Set up the seed bytes, here using the provided random number */
pdgf_seed_buffer[0] = (U8) pdgf_random & 0xff;
pdgf_seed_buffer[1] = (U8) (pdgf_random >> 8);
*pdgf_seed_len = 2;
return 0;
break;
case 0x04: /* corresponding sendKey value */
if ((pdgf_request_message_len == 4) &&
(pdgf_request_message[2] == pdgf_seed_buffer[1]) &&
(pdgf_request_message[3] == pdgf_seed_buffer[0]) )
{
/* security passed -- bytes reversed! */
return 0;
}
else
{
return 0x35; /* invalid key */
}
break;
default:
return 0x12; /* unsupported parameters */
break;
}
}
/*****************************************************************************
* Purpose: Marks the end of the security function above.
* Returns: None.
* Notes: Must be placed immediately after the security function. The
* platform uses this to calculate the size of the security function
* when relocating it to non-volatile memory for use in

* reprogramming mode.
*****************************************************************************
*/
void psc_diag_security_end
(
void
)
{
}
7.7.15. ISO DTC extended data records

(pdg_ExtendedDataRecord)
UDS service $19 ExtendedDataRecord configuration.

All targets

None
pdg_ExtendedDataRecord
Extended data records convey status information associated with a DTC. The information
is retrieved at the time of the request. This block allows the assignment of
DTCExtendedDataRecordNumbers within the manufacturer specific range [1,143] as well as
the range reserved for legislated OBD DTCExtendedDataRecords [144, 239].
7.7.15.4. Inports
None.
7.7.15.5. Outports
None.

• Report the DTC occurrence count
If enabled, the platform will report a one byte extended data record containing the DTC
occurrence count.
Value type: Boolean

Calibratable: No
• Occurrence count DTCExtendedDataRecordNumber
This field specifies the DTCExtendedDataRecordNumber that is used to identify the

occurrence count.
Range: [1,239]
Value type: Integer

Calibratable: No
• Report the failed number of drive cycles
If enabled, the platform will report a one byte extended data record containing the number
of drive cycles in which the test has failed. The record is only available when the DTC is
pending.
Value type: Boolean

Calibratable: No
• Failed drive cycles DTCExtendedDataRecordNumber
This field specifies the DTCExtendedDataRecordNumber that is used to identify the count
of drive cycles in which the test has failed.
Range: [1,239]
Value type: Integer

Calibratable: No
• Report the number of drive cycles since last failure
of drive cycles since the last test failure. The record is only available when the DTC is
active.
Value type: Boolean

Calibratable: No
• Drive cycles since failure DTCExtendedDataRecordNumber

number of drive cycles since the last test failure.
Range: [1,239]
Value type: Integer

Calibratable: No
• Report total warm up cycles in which the fault has not been present
of warm-up cycles in which the fault has not been present. The record is reset upon the
DTC state transition to the previously active state.

Value type: Boolean

Calibratable: No
• Warm up cycles DTCExtendedDataRecordNumber

number of warm-up cycles in which the fault has not been present.
Range: [1,239]
Value type: Integer

Calibratable: No
• Report time until derate
If enabled, the platform will report a two byte extended data record containing the total time
(resolution 1min/bit) left until derate will occur. The record is only available while the DTC
is in the active state and the DTC attribute 'has-torque-derate' is true.
Value type: Boolean

Calibratable: No
• Time until derate DTCExtendedDataRecordNumber
This field specifies the DTCExtendedDataRecordNumber that is used to identify the total
time left until derate will occur.
Range: [1,239]
Value type: Integer

Calibratable: No
• Report total time in state 'previously active'
(resolution 0.2hr/bit) that the DTC has been in the previously active state.
Value type: Boolean

Calibratable: No
• Time in state 'previously active' DTCExtendedDataRecordNumber
time that the DTC has been in the previously active state.
Range: [1,239]
Value type: Integer

Calibratable: No
• Report total time in state 'active'
(resolution 0.2hr/bit) that the DTC has been in the active state.
Value type: Boolean

Calibratable: No
• Time in state 'active' DTCExtendedDataRecordNumber
time that the DTC has been in the active state.

Range: [1,239]
Value type: Integer

Calibratable: No
• Report the engine running time
(resolution 0.2hr/bit) that the engine has been running while the DTC's fault has not been
present and the DTC has been in the 'active' or 'previously active' state.
Value type: Boolean

Calibratable: No
• Engine running time DTCExtendedDataRecordNumber
time that the engine has been running while the DTC has been in the 'active' or 'previously
active' state.
Range: [1,239]
Value type: Integer

Calibratable: No
7.7.15.7. Notes
None.
7.7.16. Routine control (pdg_RoutineControl)

Communicates UDS service 0x31 (routine control) IO to and from a diagnostic scan tool.

All targets

routine_ready
routine_running
Routine Name: pdg_RoutineControl
Routine ID: 0 decimal
results_valid RCOR Length: 0 bytes
Timed Routine: off routine_request
Results Length: 0 bytes
results Status Record Length: 0 bytes
Provide Simulation Input: on
status_record
sim_routine_request
pdg_RoutineControl
Routines can be used to allow a diagnostic tool to perform a custom function within the ECU.
For example, a function of the ECU can be started and stopped from the diagnostic tool, or
a set of values can be written to or read from ECU memory. The actual routine is defined
by the application software.
7.7.16.4. Inports
• routine_ready

Flag from the application to inform the platform that the routine is able to run. If this inport
is FALSE, the platform will send a negative response to the diagnostic tool if this routine
is requested, and the routine_request outport will output noRequest.
Value type: Boolean
• routine_running
Flag from the application to inform the platform that the routine is running.
Value type: Boolean
• results_valid
Flag from application to inform the platform that the data supplied at results inport is valid
(i.e. the routine has been run at least one time, and the results are considered valid by the
application.) If results are not used for this routine,set Results Length to 0 in the dialog,
and ground this inport.
Value type: Boolean
• results
This is the array of bytes that will be transmitted to the diagnostic scan tool when service
0x31 is requested with subfunction 0x03 (requestRoutineResults) AND results_valid is
TRUE. If results will not be used, set Results Length to 0 in the dialog, and ground this
inport.
Value type: Array
• status_record
This is an optional array of bytes that will be transmitted to the diagnostic scan tool in
response to any service 0x31 request. If a status record is not used, set Status Record
Length in the dialog to 0 and ground this inport.
Value type: Array
• sim_routine_request
This inport is only used in simulation and only appears if Provide Simulation Input is ticked
in the dialog. During simulation, any value supplied to this inport is immediately copied to
the routine_request outport.
Value type: U8
• sim_rcor
This inport is only used in simulation and only appears if Provide Simulation Input is ticked
in the dialog. During simulation, any array supplied to this inport is immediately copied to
the rcor outport.
Value type: Array
7.7.16.5. Outports
• routine_request
Indicates the routine request sub-function that was received from the diagnostic scan tool.
Note: the received routine request sub-function will only be output for one sample.

Table 7.5. RoutineControl request sub-function

Sub-function Name Value Description
noRequest 0x00 Indicates that no request has been received from the
diagnostic tool.
startRoutine 0x01 Indicates that the application must start the routine.
stopRoutine 0x02 Indicates that the application must stop the routine.
Note: requestRoutineResults (0x03) is handled automatically by the platform. Thus, the

routine_request outport will never be 0x03.
Value type: U8
• rcor
Provides the optional routineControlOptionRecord byte array to the application. This

outport only appears if the dialog entry RCOR Length is non-zero.
Value type: Array
• Routine ID
A unique routine ID that will be used by the diagnostic tool to identify this routine. Note:
routine IDs 0x0202, 0x0203, 0xFF00, and 0xFF01 are reserved by the platform and cannot
be used by the application.
Value type: U16

Calibratable: No
• RCOR Length
Defines the number of bytes in the optional routineControlOptionRecord byte array. Set to
0 if the routine does not use a routineControlOptionRecord.

Value type: U16

Calibratable: No
• Timed Routine
If ticked, this routine is a "Method B" (timed) routine, and will therefore stop on its own
(without a stopRoutine request). If unticked, this routine is a "Method A" (untimed) routine,
which requires a stopRoutine request to stop the routine. See ISO 14229-1 section 13 for
further details regarding Method A vs. Method B routines.
Even if ticked, the routine must handle a stopRoutine request to allow the diagnostic tool
to stop the routine if necessary.
Value type: Boolean

Calibratable: No
• Results Length
Defines the number of bytes in the results array. Set to 0 if the routine does not use results.
Value type: U16

Calibratable: No
• Status Record Length
Defines the number of bytes in the optional statusRecord array. Set to 0 if the routine does
not use a statusRecord.
Value type: U16

Calibratable: No
• Provide Simulation Input
If ticked, two additional inports will be revealed. See sim_routine_request inport and
sim_RCOR for further details.
Value type: Boolean

Calibratable: No
• Sample Time
Defines the sample time that this block will use to check for incoming routine requests, and
update outports. Must be a multiple of 0.001.
Value type: double

Calibratable: No
7.7.16.7. Notes
Negative response codes to service $31 requests are handled automatically by the platform
software. The following list gives the possible negative response codes and the situations
in which they are sent.
• subFunctionNotSupported (0x12): sent when the diagnostic tool requested a subfunction

other than startRoutine (0x01), stopRoutine (0x02), or requestRoutineResults (0x03).
• incorrectMessageLengthOrInvalidFormat (0x13): sent when the diagnostic tool sent a

service $31 request message that is too short to contain a 16-bit routine ID.
• conditionsNotCorrect (0x22): sent when the diagnostic tool sent a startRoutine request
when routine_ready is FALSE.

• requestSequenceError (0x24): This negative code can occur in one of 3 situations:
1) The diagnostic tool sends a requestRoutineResults command when results_valid

is FALSE.
2) The diagnostic tool sends a startRoutine command for a routine that is already
running.
3) The diagnostic tool sends a stopRoutine command for a routine that is not running.
• requestOutOfRange (0x31): This negative code can occur if one of the following two
situations occur:
1) The diagnostic tool sends a service $31 request for a routine ID that is not supported
by the application or the platform.
2) The diagnostic tool sends a service $31 request with the the number of bytes in
the optional routineControlOptionRecord that is different from what is defined in the
RCOR Length dialog parameter.
Routine requests are handled according to the following state diagram
Important notes regarding the routine control state diagram:
1) If the application specifies that the routine is ready AND a startRoutine request is received
from the tool, the application MUST start the routine. Otherwise, the routine state machine
will stay in the RoutineRequested state until a stopRoutine request is received for the same
routine ID. Furthermore, the routine must be started within the amount of time to allow the
response message to be transmitted within 1000 ms of when the diagnostic tool sent the
request.
2) If a stopRoutine request is received from the diagnostic tool, the application MUST stop the
routine. Otherwise, the routine control state machine will stay in the RoutineSopping state.
Furthermore, the routine must be stopped within the amount of time to allow the response
message to be transmitted within 1000 ms of when the diagnostic tool sent the request.

Some routines are handled by the platform without any input from the application. These
routines have routine IDs that may not be used by the application. The reserved routine IDs
are: 0x0202, 0x0203, 0xFF00, and 0xFF01.
7.7.17. Parameter identifier (ppid_Pid)

Captures the current value of a parameter to internal memory or non-volatile memory for
access by a diagnostic scan tool.

All targets

pid_bytes
app_bytes
override_status
ppid_Pid
A PID is used to access the current value of an application parameter by a diagnostic scan
tool. The access includes reading the parameter and if enabled over-riding the parameter.
If the parameter is a non-volatile PID, this value can be written to non-volatile memory, and
retained across power cycles.
7.7.17.4. Inports
• app_bytes
Application supplied data which is to be accessed by a diagnostic scan tool via the
associated PID.
Value type: Array
• write_to_nv
Flag from application to write the data supplied at app_bytes to non-volatile memory. This
inport is only active when the Non-volatile storage parameter is ticked.
Value type: Boolean
7.7.17.5. Outports
• pid_bytes
When the PID data is being overridden at the request of the diagnostic scan tool, this
outport gives the override data. When not overridden, this outport just copies what is
entered at the app_bytes inport. Note that the size and dimensions of this outport are
automatically set to match those of the app_bytes inport.
Value type: Array
• override_status
Indicates the ControlParameter status for an InputOutputControl diagnostic service. The

values of the InputOutputControlParameter are specified as per the draft KW2000-3. The

issued KW2000-3 standard does not specify the values. The draft KW2000-3 and UDS
InputOutputControlParameter values do not match
Table 7.6. InputOutputControl Status (KW2000-3 draft)
IOControl Status Value Description

returnControlToECU 0x00 Indicates that ControlParameter from InputOutputControl
request from test tool was "return control to ECU", or this
PID is not currently subject to IOControl.
freezeCurrentState 0x05 Indicates that ControlParameter from InputOutputControl
request from test tool was "freeze current state",
indicating that this PID is currently subject to override by
the tool.
shortTermAdjustment 0x07 Indicates that ControlParameter from InputOutputControl
request from test tool was "short term adjustment",
indicating that this PID is currently subject to override by
the tool.
Value type: Integer
• is_valid
Flag to indicate if the value read from a non-volatile PID is valid. The non-volatile PID
can be invalid, if it does not exist yet in non-volatile memory, as it has never been written
before. It can also be invalid if the previous size in bytes does not match the currently read
size. This flag indicates if the data in pid_bytes is valid. This outport is only active when
the Non-volatile storage parameter is ticked.
Value type: Boolean
• num_cem_recvd
The number of controlEnableMask bytes received in the most recent $2F request from the
test tool. This outport is only active when the Number of controlEnableMask bytes expected
parameter has a non-zero value.
Value type: uint8_T
• cem_bytes
The controlEnableMask byte values received in the most recent $2F request from the
test tool. This outport is only active when the Number of controlEnableMask bytes
expected parameter has a non-zero value. Only the number of bytes indicated in the
num_cem_recvd signal are valid; the rest are zeroed.
Value type: uint8_T vector

• Non-volatile storage
If ticked indicates the PID's value is to be preserved across power cycles thus it is stored
in non-volatile memory
Value type: Boolean

Calibratable: No
• J1979 (8 bit)
If ticked, this parameter is accessible using the SAE J1979 protocol. A numeric box is
unveiled upon ticking this box. In the unveiled numeric box enter the unique PID number.
This parameter is not available if the Non-volatile storage parameter is ticked.
Value type: Boolean

Calibratable: No
• KWP (8 bit)
If ticked, this parameter is accessible using the Keyword 2000-3 protocol. A numeric box
is unveiled upon ticking this box. In the unveiled numeric box enter a unique PID number.
Value type: Boolean

Calibratable: No
• ISO (16 bit)
If ticked, this parameter is accessible using the ISO 14229-1 (UDS) protocol. Two additional
parameters are unveiled upon ticking this box. In the unveiled numeric box enter the unique
PID number. Tick the unveiled "ReadScalingByIdentifier (UDS $24) support" box if UDS
$24 support is required. If this box is ticked, more options are unveiled: see below following
"Resend input as output". NOTE: If ticked, the PID data is not altered in any way by the
PID block. The UDS $24 scaling data is only used to describe the scaling done by the
application prior to the PID block so the diagnostic tool can properly decode the data.
Value type: Boolean

Calibratable: No
• J1939 (SPN)
If ticked indicates the PID represents a J1939 Suspect Parameter Number. A numeric box
is displayed upon ticking this box. In the displayed numeric box enter the unique SPN

number. Note that this parameter is only currently used to allow freeze frame data to be
stored for a J1939 DTC, and to allow reading from and writing to non-volatile memory.
Value type: Boolean

Calibratable: No
• Alphanumeric?
This checkbox is only displayed when the J1939 (SPN) checkbox is ticked. It determines
the format in which the SPN data is transmitted. If ticked, the SPN data is treated as
alphanumeric data with most significant byte transmitted first; otherwise it is transmitted
with least significant byte first.
Value type: Boolean

Calibratable: No
• String PID
If ticked indicates a string PID. A box to enter the string is displayed upon ticking this box.
The entered string needs to be enclosed with single apostrophes. Note when using a string
PID with non-volatile memory, the value of the string will only be written during initialisation.
Value type: Boolean

Calibratable: No
• Allows IOControl
If ticked allows the diagnostic scan tool to override the PID. Leave unticked to deny the
diagnostic scan tool the ability to override the PID. Not applicable for non-volatile PIDs.
Value type: Boolean

Calibratable: No
• Resend input as output
For a PID value which is being overridden by a diagnostic scan tool, two options exist for
what value to report back to the diagnostic scan tool in response to a read data by identifier
($22) command. Not applicable for non-volatile PIDs.
• Unticked - Responds with the application value written to the PID.
• Ticked - Responds with the overridden value.
Value type: Boolean

Calibratable: No
• Number of controlEnableMask bytes expected
If set to a non-zero value, the PID will accept additional input bytes as part of a $2F service
request, and these are assumed to be controlEnableMask bytes. These are made available
via the outports num_cem_recvd and cem_bytes.
It is the responsibility of the application to act appropriately on any controlEnableMask

bytes, e.g. by restricting the override of physical outputs only to selected signals.
Value type: Integer

Calibratable: No
• Number of data bytes

Part of ReadScalingByIdentifier support. Enter the number of data bytes that will be stored
by this PID. This is the number of data bytes of the PID data, NOT the number of scaling
bytes.
Value type: Integer

Calibratable: No
• Scaling Data Type
Part of ReadScalingByIdentifier support. A drop-down selection of data types as defined

in ISO-14229.
Value type: List

Calibratable: No
• Specify Scaling Formula?
Part of ReadScalingByIdentifier support. If ticked, indicates that a scaling formula will be

transmitted with the scaling information. A "Formula Type" drop-down will be unveiled
where the formula type must be specified. Additionally, numeric boxes will be unveiled
where the formula coefficients must be entered.
Value type: Boolean

Calibratable: No
• Specify engineering units?
Part of ReadScalingByIdentifier support. If ticked, indicates that engineering units will be

transmitted with the scaling information. A "Units" drop-down will be unveiled where the
engineering units must be specified. Additionally, a "Use Unit Prefix" check-box will be
unveiled. If ticked, a unit prefix will be transmitted with the scaling information. A unit prefix
drop-down will be unveiled where the unit prefix must be specified.
Value type: Boolean

Calibratable: No
• Specify state and connection type?
Part of ReadScalingByIdentifier support. If ticked, indicates that state and connection

information (such as active high/low, pull-up/down circuitry, etc.) will be transmitted with
the scaling information. Four drop-downs will be unveiled where the state and connection
information must be specified.
Value type: Boolean

Calibratable: No
• Manual Entry Scaling Bytes
Part of ReadScalingByIdentifier support. This field will be unveiled if the "Scaling Data
Type" drop-down is set to "F: Manually enter scaling bytes". This field allows the user to
manually specify all of the scaling bytes that will be sent by the test tool. Scaling bytes
must be entered as a comma-separated list of decimal integers from 0 to 255.
Value type: Array

Calibratable: No
• Scaling Bytes Sent To Test Tool
Part of ReadScalingByIdentifier support. This field displays the scaling bytes that will be
transmitted when service $24 is requested.

Value type: String

Calibratable: No
7.7.17.7. Notes
Certain PIDs are handled by the platform and should not be defined by the application using
this block. In particular, the J1979 standard defines PIDs $00, $20, $40, etc. to be bitfields
defining what other PIDs are supported in various contexts. These PIDs are handled directly
by the platform in response to the different J1979 service messages that request them.
Similarly, PID 0x02 is defined in the J1979 standard to identify the DTC that caused a freeze
frame to be stored, and since this also depends on the context (as to the identity of the freeze
frame in question) this too is handled directly by the platform.
7.7.18. Parameter identifier scaling (ppid_Scaling)

This block outputs a raw byte value to represent the input with the scaling applied.

All targets

scaling/bit: 0
offset: 0
in max: 0 raw
min: 0
ppid_Scaling
A PID value is usually stored in the ECU (server) in a finite number of bytes with an associated
scaling. This scaling is common to both the client (diagnostic scan tool) and server.
The scaling block has been added as an aid to encoding a PID value with a scaling. As
such it is envisaged that the output of this block will feed into the input of ppid_Pid. The
scaling applied by this block follows the form of output = (input - offset) /
scalingPerBit
Note this block does not support multi-packed PIDs such as PID $01 of SAE J1979.
7.7.18.4. Inports
• in
Input value to be scaled.
Value type: Integer
7.7.18.5. Outports
• raw
Raw bytes output to represent the input with the scaling applied.
Value type: Integer

• J1979 standard scaling
If ticked a drop down list of standard J1979 scalings is revealed. The scalings in the list
are as per Annex B of issue 7 of ISO15031-5 (SAE J1979).
Value type: List

Calibratable: No
• Scaling/bit
Numeric field to enter the scaling/bit.
For example a value of 0.25 in this field would result in 4 being output (assuming the offset
is set to 0) from this block when the input is 1.
Value type: Real

• Scaling offset
Numeric field to enter the scaling offset.
For example with a value of 0.25 set in the scaling/bit field and this field set to 0.5, would
result in 2 being output from this block when the input is 1.
Value type: Real

• Max
Numeric field to enter the maximum value of the input. An input value exceeding the
maximum value is clipped to the maximum value prior to the scaling being applied.
Value type: Real


• Min
Numeric field to enter the minimum value of the input. An input value falling below the
minimum value is clipped to the minimum value prior to the scaling being applied.
Value type: Real

• Engineering Units
String field to the engineering units associated with the scaling. The string in this field
should be enclosed with single apostrophes.
Value type: String

Calibratable: No
• Data type out
A drop down list of the supported data types out. The supported data types are:
• uint8
• uint16
• uint32
Value type: List

Calibratable: No
7.7.18.7. Notes
None.
7.7.19. Freeze frame (pff_FreezeFrame)

Captures a list of specified parameters upon the occurrence of an active DTC. The captured
parameter values are stored for access by a diagnostic scan tool.

All targets

Name:
pff_FreezeFrame
Freeze Frame — Generic
A Freeze Frame is a snapshot of parameter values recorded at the time a diagnostic trouble
code (DTC) was captured.
Note: non-volatile PIDs are not supported in freeze frames. If a freeze frame is defined by
the application to contain a non-volatile PID, this PID is ignored by the PFF feature when
capturing or accessing the freeze frame data.
The following diagram mirrors the finite state machine for the fault state for a DTC (see
platform OBD state machine). In the diagram the transition conditions have been removed

to aid clarity. The diagram highlights the transitions that cause a freeze frame instance to
be captured and deleted.
Figure 7.11. Freeze frame capture and deletion
Once captured, the freeze frame instance is stored in non-volatile memory. As depicted in
the diagram above, it is possible for multiple instances of a freeze frames associated with a
single DTC to be stored in non-volatile memory.
When a DTC's fault state transitions to "Cleared" all instances of stored freeze frames
associated with the DTC are deleted from non-volatile memory.
Note: The DTC occurrence count in the freeze frame may be out of sync when DTC becomes
Active
Freeze Frame - ISO (J1979)
Freeze frame numbering is used by J1979 to report back to the scan tool the DTC that caused
freeze frame capture and to read back the stored freeze frame instance(s). Numbering of
freeze frame instances stored in non-volatile memory is sequential with the earliest captured
freeze frame numbered as 0. As per J1979 numbering of freeze frames has an upper limit
of 255.
Note: J1979 freeze frames are only captured for emissions related DTCs.
Freeze Frame - Snapshot (UDS)
UDS snapshot freeze frames follow the same capture rules as other freeze frame types;
however, snapshots do not follow the same deletion rules. Snapshots captured as a result
of a particular DTC are still deleted when the associated DTC transitions to clear; however,
snapshots are not deleted when the DTC transitions from pending to previously active.
Snapshot storage gives preference to the first and the most recent occurrence of a particular
DTC. The snapshot captured as a result of the first occurrence of a DTC is assigned
DTCSnapshotRecordNumber 0. The snapshot captured as a result of the next occurrence
of a DTC is assigned DTCSnapshotRecordNumber 1 and is replaced upon subsequent
occurrences of the DTC.

Note: A maximum of 2 UDS snapshots per DTC are stored at any given time.
7.7.19.4. Inports
None.
7.7.19.5. Outports
None.
• Freeze Frame name
A unique freeze frame name is required in this field. The freeze frame name is referenced
in the Simulink block of the DTC (see pdtc_DiagnosticTroubleCodeExt) that triggers the
freeze frame.
Note the freeze frame name is used in the generated C code and as such should follow
the C variable naming convention.
Value type: String

Calibratable: No
• J1979 (service $02)
If ticked indicates the freeze frame complies with the J1979 standard.
Value type: Boolean

Calibratable: No
• PID(s) to capture
A vector calibration giving the list of PID identifiers for a J1979 freeze frame is placed in
this field. The vector calibration needs to be defined in the data dictionary. The value field
of the vector calibration in the data dictionary defines the PID identifers for the named
freeze frame. However, all freeze frames should be cleared and the ECU power cycled
after changing this calibration.
The vector calibration should be of type uint8_T.
The vector calibration should not have in excess of 255 elements.
Note a PID which is not present in an application will not be reported when supported PIDs
for a freeze frame is requested.

Note that although no restriction is placed on when one may change this calibration, the
correct procedure is to clear all freeze frame information and power cycle the ECU after
any such change. Failure to follow this procedure could lead to anomalies in the freeze
frame handling.
Value type: String

• J1939 (DM4)
If ticked indicates the freeze frame complies with J1939's DM4 freeze frame definition.
DM4 is composed of a list of mandatory SPNs and a manufacturer's list of SPN(s).
The mandatory SPNs are given by J1939-73 (FEB2010) as 899, 102, 190, 92, 110 and
84. The mandatory SPNs for DM4 have been hardcoded into the platform. As such when
the OpenECU platform captures a DM4 freeze frame it always attempts to capture the
mandatory SPN(s) regardless of the presence or absence of the SPN in the application. A
mandatory SPN absent from the application will result in 0xFF(s) populating the data field
allocated for the absent mandatory SPN in the returned DM4 message.
Value type: Boolean

Calibratable: No
• Manufacturer SPN(s)
The manufacturer's list of SPNs for a DM4 freeze frame are placed in this field. To enter the
list of manufacturer SPNs use a vector calibration. The values of the SPNs are calibratable.
However, all freeze frames should be cleared and the ECU power cycled after changing
this calibration.
A manufacturer SPN absent from the application will be ignored. The SPN will not be
saved to non-volatile memory when the DM4 freeze frame is captured. The SPN's data
will not appear in the returned DM message and no data fields within the returned DM4
are allocated to denote its presence.
Value type: String

• J1939 (DM25)
If ticked indicates the freeze frame complies with J1939's DM25 freeze frame definition.
As per J1939-73 only a single freeze frame definition can exist for DM25. The parameter
list is specified by pff_Dm25FreezeFrame.
Value type: Boolean

Calibratable: No
• UDS (Snapshot)
If ticked indicates the freeze frame complies with the ISO 14229-1 (UDS) snapshot
definition.
Value type: Boolean

Calibratable: No

• ISO PID(s)
A vector calibration giving the list of ISO PID identifiers for a snapshot is placed in this
field. The vector calibration needs to be defined in the data dictionary. The value field of
the vector calibration in the data dictionary defines the ISO PID identifiers for the named
freeze frame. However, all freeze frames should be cleared and the ECU power cycled
after changing this calibration.
Value type: String

7.7.19.7. Notes
None.
7.7.20. DM25 freeze frame (pff_Dm25FreezeFrame)

Specifies the list of SPN(s) to capture for a DM25 freeze frame.

All targets

[]
pff_Dm25FreezeFrame
7.7.20.4. Inports
None.
7.7.20.5. Outports
None.

• DM25 list of SPN(s)
The list of SPN(s) for a DM25 freeze frame are placed in this field. To enter the list of
SPN(s) use a vector calibration. The values of the SPN(s) are calibratable.
A SPN absent from the application will be ignored. No data fields within the returned DM25
are allocated to denote its presence.
Value type: String

7.7.20.7. Notes
None.
7.7.21. Freeze frame configuration (pff_Configuration)

Specifies the amount of volatile (RAM) and non-volatile (flash) memory allocated for freeze
frame storage.

All targets

NVM allocation: bytes
RAM buffer size: bytes
pff_Configuration
Specifies the amount of volatile (RAM) and non-volatile (flash) memory allocated for freeze
frame storage.
7.7.21.4. Inports
None.
7.7.21.5. Outports
None.

• Total non-volatile memory allocation to store freeze frames (bytes)
This field specifies how much of non-volatile memory is allocated to storing instances
of freeze frames. The allocation will be exclusively used for freeze frame storage. An
appropriate size should be chosen to contain your application needs.
Captured freeze frames are stored in non-volatile memory using a file system. Each
captured freeze frame is stored in an individual file. There is an overhead associated with
each file stored in NVM. This overhead is 20 bytes plus whatever is required to round up
to a multiple of 8 bytes. Thus on a freeze frame of 100 bytes, the overhead would be 20
bytes, whereas on a freeze frame of 101 bytes, the overhead would be 27. This overhead
forms part of the total non-volatile memory allocation to store freeze frames, for instance if
the application stores 10 freeze frame files each consisting of a 100 bytes of data the total
NVM allocation specified here should be at least 1200 bytes.
Value type: Integer

Calibratable: No
• RAM buffer size for buffering freeze frame data prior to writing to NVM (bytes)
RAM is allocated statically (at build time) in OpenECU. The specified RAM buffer size is
used to store instances of freeze frames prior to writing to non-volatile memory. As such
this field should at a minimum equal or exceed the largest freeze frame data size of all
freeze frames in the application. Writing data to NVM is carried out in the background task
as it takes time to complete. Should your application need to capture multiple freeze frame
instances within a short interval this buffer should be sized appropriately to ensure the
freeze frames are successfully written to NVM.
Note: an under sized RAM buffer may result in freeze frame instances not being captured.
Note: DM4 and DM25 of J1939 specify a max freeze frame data size of 1785 bytes.

Value type: Integer

Calibratable: No
• Maximum number of J1979 freeze frame instances to store in NVM
This field specifies an upper limit on how many captured J1979 freeze frame instances
can be stored in non-volatile memory (NVM).
Range: [0, 254]
Value type: Integer

Calibratable: No
• Maximum number of J1939 DM4 freeze frame instances to store in NVM
This field specifies an upper limit to how many captured DM4 freeze frame instances can
be stored in non-volatile memory.
Range: [0, 137]
Value type: Integer

Calibratable: No
• Maximum number of J1939 DM25 freeze frame instances to store in NVM
This field specifies an upper limit to how many captured DM25 freeze frame instances can
be stored in non-volatile memory.
Range: [0, 254]
Value type: Integer

Calibratable: No
• Maximum number of UDS snapshot instances to store in NVM
This field specifies an upper limit to how many captured UDS snapshot instances can be
stored in non-volatile memory.
Range: [0, 254]
Value type: Integer

Calibratable: No
7.7.21.7. Notes
None.
7.7.22. J1939 configuration (pj1939_Configuration)

Configure the ECU for J1939 communications.
See Section 6.1.44, “J1939 configuration (pj1939_Configuration)” for a detailed description.
7.7.23. J1939 channel configuration

(pj1939_ChannelConfiguration)
Configure a J1939 communications channel.
See Section 6.1.45, “J1939 channel configuration (pj1939_ChannelConfiguration)” for a

detailed description.

7.7.24. J1939 Transmit DTC DM

(pj1939_TransmitDtcDm)
Transmit a J1939/73 DM message to a specific destination address. Supports DM6, DM12,
DM23, DM27, DM28, DM29, DM31, DM41, DM42, DM43, DM44, DM45, DM46, DM47,
DM48, DM49, DM50, DM51, and DM52.

All targets

A J1939/73 DM29 or DM30 message is a fixed-length message, transmitted by a network

node to the specified destination address.
7.7.24.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
Value type: Integer

Calibratable: No
• transmit
Set to 1 to transmit a DM message, set to zero otherwise.
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
J1939 priority of the DM message to be transmitted.
Range: [0, 7]
Value type: Integer

Calibratable: No
• dest_addr

J1939 destination address for the response message (usually the source address of the
corresponding request). If use_dest_addr is false or a PDU2 message is shorter than 9
bytes, this value is ignored and the message is sent to the global address.
Range: [0, 254]
Value type: Integer

Calibratable: No
• use_dest_addr
Whether to send the DM to a specified destination address. If false (0), the message will
Range: 0 or 1.
Value type: Boolean

Calibratable: No
7.7.24.5. Outports
• error_flag
Set to 1 when the DM message could not be buffered for transmission, or if a previous
request to send a DM message has not completed.
Value type: Boolean

Calibratable: No
Range: [0, 255]
Value type: Integer

Calibratable: No
Value type: String

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
• DM Type
Specifies the DTC data this block should send, by DM type.
Value type: Popup

Calibratable: No
7.7.24.7. Notes
None.

Indicates if a J1939/73 DM1 message has been received and decodes the contents of the
lamp status.
See Section 6.1.46, “J1939 DM1 receive (pj1939_Dm1Receive)” for a detailed description.

data.
See Section 6.1.47, “J1939 DM1 decode DTC (pj1939_Dm1DecodeDtc)” for a detailed
description.

Transmit a J1939-73 DM1 message containing the DTCs with an active state from a DTC
table.
See Section 6.1.48, “J1939 DM1 transmit (pj1939_Dm1Transmit)” for a detailed description.

Indicates if a J1939-73 DM2 message has been received and decodes the contents of the
lamp status.
See Section 6.1.49, “J1939 DM2 receive (pj1939_Dm2Receive)” for a detailed description.

data.

See Section 6.1.50, “J1939 DM2 decode DTC (pj1939_Dm2DecodeDtc)” for a detailed
description.

Transmit a J1939/73 DM2 message containing the DTCs with a previously active state from
a DTC table.
See Section 6.1.51, “J1939 DM2 transmit (pj1939_Dm2Transmit)” for a detailed description.

Transmit a J1939/73 DM4 message containing freeze frame data.

All targets

sim_error_flag
sim_transport_errors
error_flag
transmit
Channel: 0
priority
dest_addr transport_errors
use_dest_addr
pj1939_Dm4Transmit
A J1939/73 DM4 message is a variable length message.
7.7.31.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
Value type: Integer

Calibratable: No
• transmit
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority

Range: [0, 7]
Value type: Integer

Calibratable: No
• dest_addr
Range: [0, 255]
Value type: Integer

Calibratable: No
• use_dest_addr
Range: 0 or 1.
Value type: Boolean

Calibratable: No
7.7.31.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
Range: [0, 255]
Value type: Integer

Calibratable: No

• J1939 Channel
Value type: Integer

Calibratable: No
7.7.31.7. Notes
None.

Transmit a J1939/73 DM5 message containing the diagnostic readiness 1 data.

All targets

sim_error_flag
transmit
Channel: 0
Table: error_flag
priority
obd_compliance
pj1939_Dm5Transmit
A J1939/73 DM5 message is a fixed length message transmitted by a network node to the
global network address. The DM5 message contents detail the diagnostic readiness data
(part 1). As the message is made up from data calculated and stored internally within the
platform, direct support is provided (rather than using the pj1939_PgTransmit block).
7.7.32.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
• transmit
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]

Value type: Integer

Calibratable: No
• obd_compliance
The OBD compliance that this controller/software combination meets (see J1939-73
section 5.7.5.3).
Range: [0, 255]
Value type: Integer

Calibratable: No
7.7.32.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
Value type: String

Calibratable: No
7.7.32.7. Notes
None.

7.7.33. J1939 DM7 decode (pj1939_Dm7Decode)

Decodes the contents of a received J1939/73 DM7 message.

All targets

sim_test_commanded test_commanded
Channel: 0
sim_source_addr TID: -1 source_addr
Sample time: -1
pj1939_Dm7Decode
A J1939/73 DM7 message is a fixed length message. The purpose of a DM7 message is to
command tests or last measured test results. Direct blockset support is provided (rather than
relying on the pj1939_PgReceive block).
Refer to J1939-73 FEB2010 section 5.7.7 for details of the DM7 message.
7.7.33.4. Inports
• sim_test_commanded
The simulation value for the outport test_commanded.
Value type: Boolean

Calibratable: No
7.7.33.5. Outports
• test_commanded
Set to 1 (true) if a DM7 message has been received containing a commanded test which
matches the Test identifier only (when parameter Test identifier is in the range [1, 64]) or
if a DM7 message has been received containing a commanded test which matches the
Test identifier and Suspect parameter number and Failure mode indicator parameters
(when parameter Test identifier is in the range [246, 250]). Note that this is a one-shot
pulse which will remain high only until the next block iteration.
Value type: Boolean

Calibratable: No
• source_addr
The source address of the DM7 message received.
Value type: Integer

Calibratable: No
• dest_addr
The destination address of the DM7 message received.
Value type: Integer

Calibratable: No
• J1939 Channel
The logical J1939 channel on which to receive the request. Must be a channel declared
Value type: Integer

Calibratable: No
• Test identifier
The value of the TID of the commanded test to match against. In the case where a DM30
response is required, the parameters Suspect parameter number, Failure mode indicator
and Test identifier uniquely identify the commanded test. If a DM8 response is required
then only the Test identifier is needed.
Range: [0, 255]
Value type: Integer

Calibratable: No
The value of the SPN of the commanded test to match against. The parameters
Suspect parameter number, Failure mode indicator and Test identifier uniquely identify the
commanded test. Only applicable if the Test identifier parameter is in the range [246, 250].
A DM30 response is required when the requested DM7 test consists of a valid SPN/FMI/
TID combination.
Range: [0, 524287]
Value type: Integer

Calibratable: No
The value of the FMI of the commanded test to match against. The parameters Suspect
parameter number, Failure mode indicator and Test identifier uniquely identify the
commanded test. Only applicable if the Test identifier parameter is in the range [246, 250].
A DM30 response is required when the requested DM7 test consists of a valid SPN/FMI/
TID combination.

Range: [0, 31]
Value type: Integer

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
7.7.33.7. Notes
None.

Transmit a J1939/73 DM8 message containing the test results for one of the non-continuously
monitored tests invoked using DM7. Refer to J1939-73 FEB2010 section 5.7.8 for details.

All targets

sim_error_flag
transmit
priority Channel: 0
test_id
transport_errors
dest_addr
use_dest_addr
pj1939_Dm8Transmit
A J1939/73 DM8 message is a variable length message. The DM8 message contains the
test results corresponding to commanded tests received in DM7 messages (refer to the
pj1939_Dm7Decode block). Test results data is supplied internally by the platform via the
PPR feature (see the ppr_DiagnosticTestEntity block). As the message is variable in length
and contains data maintained internally by the platform, direct support for the DM8 message
is provided (rather than using the pj1939_PgTransmit block).
7.7.34.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No

Value type: Integer

Calibratable: No
• transmit
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• test_id
The J1939 test identifier to use for obtaining test results to be transmitted in the DM8
message.
Range: [0, 255]
Value type: Integer

Calibratable: No
• dest_addr
Range: [0, 255]
Value type: Integer

Calibratable: No
• use_dest_addr
Range: 0 or 1.
Value type: Boolean

Calibratable: No
7.7.34.5. Outports
• error_flag

Value type: Boolean

Calibratable: No
Range: [0, 255]
Value type: Integer

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
7.7.34.7. Notes
None.

Transmit a J1939/73 DM10 message containing the list of non-continuously monitored
systems tests supported by the controller. Refer to J1939-73 FEB2010 section 5.7.10 for
details.

All targets

sim_error_flag
transmit Channel: 0 error_flag
priority
pj1939_Dm10Transmit

global network address. The DM10 message contains the list of non-continuously monitored
systems tests supported by the controller. The test identifier to bit position mapping is defined
in the DM10 bit position parameter of the ppr_DiagnosticTestEntity block. As the
message is constructed from data held within the platform, direct support for the DM10
message is provided (rather than using the pj1939_PgTransmit block).
7.7.35.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
• transmit
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
7.7.35.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
• J1939 Channel

Value type: Integer

Calibratable: No
7.7.35.7. Notes
None.

Transmit a J1939/73 DM20 message containing the Performance Ratio Monitor data.

All targets

sim_error_flag
transmit Channel: 0
priority
transport_errors
dest_addr
pj1939_Dm20Transmit
A J1939/73 DM20 message is a variable length message, transmitted by a network node to

the specified destination address. The DM20 message contents detail performance ratio data
for the components being monitored. As the message is variable in length and the message
is made up from data calculated and stored internally within the platform, direct support is
provided (rather than using the pj1939_PgTransmit block).
7.7.36.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
Value type: Integer

Calibratable: No
• transmit
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• dest_addr
corresponding request).
Range: [0, 254]
Value type: Integer

Calibratable: No
7.7.36.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
Range: [0, 255]
Value type: Integer

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
7.7.36.7. Notes
None.


All targets

sim_error_flag
transmit
priority
mil_on_time
Channel: 0 error_flag
mil_on_distance
time_since_dtc_clear
dist_since_dtc_clear
dest_addr
pj1939_Dm21Transmit
specified destination address. The DM21 message contents detail the diagnostic readiness
data (part 2). Refer to J1939-73 Feb2010 section 5.7.21 for details. Direct support is provided
(rather than using the pj1939_PgTransmit block).
7.7.37.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
• transmit
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• mil_on_time
The accumulated count (in minutes) run by the engine while the MIL is activated. Refer to
J1939-73 Feb2010 section 5.7.21.3 for details. The platform will limit the transmitted value
to the range specified below.
Range: [0, 64255] minutes
Value type: Integer

Calibratable: No
• mil_on_distance
The distance travelled (in kilometres) while the MIL is activated. Refer to J1939-73
Feb2010 section 5.7.21.1 for details. The platform will limit the transmitted value to the
range specified below.
Range: [0, 64255] kilometres
Value type: Integer

Calibratable: No
• time_since_dtc_clear
The engine running time (in minutes) accumulated since emission related DTCs were
cleared. Refer to J1939-73 Feb2010 section 5.7.21.4 for details. The platform will limit the
transmitted value to the range specified below.
Value type: Integer

Calibratable: No
• dist_since_dtc_clear
The distance accumulated (in kilometres) since emission related DTCs were cleared. Refer
to J1939-73 Feb2010 section 5.7.21.2 for details. The platform will limit the transmitted
value to the range specified below.
Range: [0, 64255] kilometres
Value type: Integer

Calibratable: No
• dest_addr
Range: [0, 254]
Value type: Integer

Calibratable: No
7.7.37.5. Outports
• error_flag

Value type: Boolean

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
7.7.37.7. Notes
None.

Transmit a J1939/73 DM24 message identifying supported SPNs.

All targets

sim_error_flag
error_flag
transmit
Channel: 0
priority
use_dest_addr
pj1939_Dm24Transmit
A J1939/73 DM24 message is a variable length message. It identifies which SPNs support
Data Streams, Scaled Test Results, and Expanded Freeze Frames (DM25).
The Data Stream SPNs are simply those ppid_Pid blocks with SPN IDs defined. The Scaled
Test Result SPNs are those defined in the ppr_DiagnosticTestEntity blocks. The DM25 SPNs
are specified by the calibration identified in the pff_Dm25FreezeFrame block.
Note: for Data Stream SPNs the application still has to create the message responses for
the corresponding PGNs itself, using the pj1939_PgTransmit block.

7.7.38.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
Value type: Integer

Calibratable: No
• transmit
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• dest_addr
J1939 destination address for the DM24 message (This could be the source address of
the corresponding PGN request, or the global address (255) if the request was sent to the
Range: [0, 255]
Value type: Integer

Calibratable: No
• use_dest_addr
Range: 0 or 1.
Value type: Boolean

Calibratable: No
7.7.38.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
Range: [0, 255]
Value type: Integer

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
7.7.38.7. Notes
None.

Request that a J1939 DM25 (expanded freeze frame) message is transmitted.

All targets

sim_error_flag
error_flag
transmit
Channel: 0
priority
use_dest_addr
pj1939_Dm25Transmit

A J1939/73 DM25 message is a variable length message, transmitted by a network node.
7.7.39.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
Value type: Integer

Calibratable: No
• transmit
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• dest_addr
Range: [0, 255]
Value type: Integer

Calibratable: No
• use_dest_addr
Range: 0 or 1.
Value type: Boolean

Calibratable: No
7.7.39.5. Outports
• error_flag

Value type: Boolean

Calibratable: No
Range: [0, 255]
Value type: Integer

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
7.7.39.7. Notes
None.


All targets

sim_error_flag
transmit
priority
dest_addr Channel: 0 error_flag
use_dest_addr
engine_run_time
warmup_count_since_clear
pj1939_Dm26Transmit

A J1939/73 DM26 message is a fixed length message. The DM26 message contents detail
the diagnostic readiness data (part 3). Refer to J1939-73 Feb2010 section 5.7.26 for details.
Direct support is provided (rather than using the. pj1939_PgTransmit block).
7.7.40.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
• transmit
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• dest_addr
Range: [0, 255]
Value type: Integer

Calibratable: No
• use_dest_addr
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• engine_run_time
The time (in seconds), since key-on, that the engine has been running. Refer to J1939-73
Feb2010 section 5.7.26.1 for details. The platform will limit the transmitted value to the

Value type: Integer

Calibratable: No
• warmup_count_since_clear
The number of warm-up cycles since all DTCs were cleared. Refer to J1939-73 Feb2010
section 5.7.26.2 for details. The platform will limit the transmitted value to the range
specified below.
Range: [0, 250]
Value type: Integer

Calibratable: No
7.7.40.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
7.7.40.7. Notes
None.

Transmit a J1939/73 DM30 message containing the scaled test results for the applicable
test(s) requested in a DM7 message. Refer to J1939-73 Jul2013 section 5.7.30 for details.

All targets


sim_error_flag
error_flag
transmit
Channel: 0
priority
spn transport_errors
dest_addr
pj1939_Dm30Transmit
A J1939/73 DM30 message is a variable length message transmitted by a network node

to the specified destination address. The DM30 message contents detail the scaled test
results for the applicable test(s) requested in a DM7 message (handled by the associated
pj1939_Dm7Decode block). As the message is variable in length and the data is derived from
information maintained by the PPR platform feature (see block ppr_DiagnosticTestEntity,
direct support is provided (rather than using the pj1939_PgTransmit block).
7.7.41.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
Value type: Integer

Calibratable: No
• transmit
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• spn
The J1939 suspect parameter number to use for obtaining the test results to be transmitted
in the DM30 message.
Range: [0, 524287]
Value type: Integer

Calibratable: No

• dest_addr
J1939 destination address for the response message (should usually be the source
address of the corresponding request, but the global address (255) if the request was sent
to the global address).
Range: [0, 255]
Value type: Integer

Calibratable: No
7.7.41.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
Range: [0, 255]
Value type: Integer

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
• Test Identifier (TID)
Together with the spn and Failure Mode Indicator (FMI), this identifies the specific test for
which results are required, to match the DTE values; or a special value of 246 (results for
all tests) or 247 (all results for specified SPN only).

Range: [0, 255]
Value type: Integer
• Failure Mode Indicator (FMI)
Together with the spn and Test Identifier (TID), this identifies the specific test for which
results are required, to match the DTE values; or a special value of 31 if a TID of 246 or
247 is requested.
Range: [0, 31]
Value type: Integer
7.7.41.7. Notes
None.

Transmit a J1939/73 DM32 message containing the regulated exhaust emission level
exceedance data. Refer to J1939-73 Feb2010 section 5.7.32 for details.

All targets

sim_error_flag
error_flag
Channel: 0
transmit
Table:
priority
transport_errors
dest_addr
pj1939_Dm32Transmit
A J1939/73 DM32 message is a variable length message transmitted by a network node

to the specified destination address. The DM32 message contents detail the DTCs and
associated timers related to a regulated exhaust emission level exceedance. Direct support
7.7.42.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
Value type: Integer

Calibratable: No
• transmit

Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• dest_addr
Range: [0, 254]
Value type: Integer

Calibratable: No
7.7.42.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
Range: [0, 255]
Value type: Integer

Calibratable: No

• J1939 Channel
Value type: Integer

Calibratable: No
Value type: String

Calibratable: No
7.7.42.7. Notes
None.

Transmit a J1939/73 DM33 message. Refer to J1939-73 Feb2010 for details.

All targets

A J1939/73 DM33 message is a variable length message transmitted by a network node to

the specified destination address.
7.7.43.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
Value type: Integer

Calibratable: No
• transmit

Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• dest_addr
Range: [0, 254]
Value type: Integer

Calibratable: No
7.7.43.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
Range: [0, 255]
Value type: Integer

Calibratable: No
• J1939 Channel

Value type: Integer

Calibratable: No
7.7.43.7. Notes
None.

Transmit a J1939/73 DM34 message containing the NTE status data. Refer to J1939-73
Feb2010 section 5.7.34 for details.

All targets

sim_error_flag
transmit
priority
dest_addr
pj1939_Dm34Transmit
specified destination address. The DM34 message contents detail the status of the engine
operating in the NTE control areas for given pollutants such as NOx and PM. Direct support
7.7.44.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
• transmit
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]

Value type: Integer

Calibratable: No
• dest_addr
Range: [0, 254]
Value type: Integer

Calibratable: No
7.7.44.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
7.7.44.7. Notes
The platform requires that the status of the various NTE areas is updated by the application.
The pj1939_UpdateNteStatus block is provided for this purpose.

Transmit a J1939/73 DM35 message containing the transient fault status of DTCs, from a
DTC table.

All targets


sim_error_flag
error_flag
start_transmission
Channel: 0
force_transmission Table:
stop_transmission
transport_errors
priority
dest_addr
pj1939_Dm35Transmit
A J1939/73 DM35 message is a variable length message. The DM35 message contents
detail the transient fault status of diagnostic trouble codes. As the message is variable in
length, direct blockset support is provided (rather than relying on the pj1939_PgTransmit
block).
When the block executes, the DTC table is inspected for a change in transient fault status
of DTCs. If any differ since the last time the block executed, a DM35 message is sent (when
the minimum inter-message interval has elapsed). The purpose for this message is that
of troubleshooting intermittent wiring problems ("wiggle test"). Refer to J1939-73 Feb2010
section 5.7.35 for details of the transmission rate and options.
7.7.45.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
Value type: Integer

Calibratable: No
• start_transmission
Set to 1 to start the transmission of DM35 messages. A rising edge on this inport causes
DM35 messages to be transmitted either until key-off or the stop_transmission inport is
set to 1.
Range: 0 or 1.
Value type: Boolean

Calibratable: No
Set to 1 to force the transmission of a DM35 message, regardless of whether any DTC
has a change of transient fault status.
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• stop_transmission

Set to 1 to stop the transmission of DM35 messages.
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• dest_addr
Range: [0, 254]
Value type: Integer

Calibratable: No
7.7.45.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
Range: [0, 255]
Value type: Integer

Calibratable: No

• J1939 Channel
Value type: Integer

Calibratable: No
Value type: String

Calibratable: No
7.7.45.7. Notes
None.

Transmit a J1939/73 DM36 message containing the vehicle harmonised roadworthiness
data. Refer to J1939-73 Feb2010 section 5.7.36 for details.

All targets

sim_error_flag
transmit
priority
vnrw_count
continuous_mil Channel: 0 error_flag
mil_strategy
mil_activation_mode
incomplete_monitors
mil_accumulated_time
pj1939_Dm36Transmit
A J1939/73 DM36 message is a fixed length message transmitted by a network

node to the global network address. The DM36 message contents detail the vehicle
harmonised roadworthiness information. Direct support is provided (rather than using the
pj1939_PgTransmit block).
7.7.46.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
• transmit

Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• vnrw_count
The sum of the system or component non-roadworthiness counts. Refer to J1939-73

Feb2010 section 5.7.36.1 for details.
Range: [0, 250]
Value type: Integer

Calibratable: No
• continuous_mil
A code indicating whether one or more systems or components requires that the MIL be
steady (continuous) burning. Refer to J1939-73 Feb2010 section 5.7.36.2 for details.
Range: [0, 3]
Value type: Integer

Calibratable: No
• mil_strategy
A code indicating whether any system is configured to employ a discriminatory MIL display.
Refer to J1939-73 Feb2010 section 5.7.36.3 for details.
Range: [0, 3]
Value type: Integer

Calibratable: No
• mil_activation_mode
A code indicating the most severe form of MIL display required by the failure status of any
system or component. Refer to J1939-73 Feb2010 section 5.7.36.4 for details.
Range: [0, 15]
Value type: Integer

Calibratable: No
• incomplete_monitors
The number of incomplete diagnostic monitors for a given sub-system or component. Refer
to J1939-73 Feb2010 section 5.7.36.5 for details. The platform will limit the value to the
Range: [0, 64255]

Value type: Integer

Calibratable: No
• mil_accumulated_time
The accumulated count, in minutes, that the MIL is activated for the current MIL activation.
Refer to J1939-73 Feb2010 section 5.7.36.6 for details. The platform will limit the value
to the range specified below. This range is chosen to match that of the accumulated time
sent on DM21 message.
Value type: Integer

Calibratable: No
7.7.46.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
7.7.46.7. Notes
None.

Transmit a J1939/73 DM37 message containing the vehicle harmonised roadworthiness
data. Refer to J1939-73 Feb2010 section 5.7.37 for details.

All targets


sim_error_flag
force_transmission
priority
snrw_count
continuous_mil
mil_strategy
mil_activation_mode
incomplete_monitors
pj1939_Dm37Transmit
A J1939/73 DM37 message is a fixed length message transmitted by a network

node to the global network address. The DM37 message contents detail the system
harmonised roadworthiness information. Direct support is provided (rather than using the
7.7.47.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
Set to 1 if the DM37 message should be transmitted in addition to the periodic transmission
and regardless of any change in input data.
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• snrw_count
The number of components that the system has determined to be non-roadworthy. Refer
to J1939-73 Feb2010 section 5.7.37.1 for details. A change of data on this inport causes
transmission of a DM37 message. The transmission is delayed, if necessary, until the
minimum inter-message interval has elapsed. Refer to J1939-73 Feb2010 section 5.7.37
for details of permitted transmission rates.
Range: [0, 250]
Value type: Integer

Calibratable: No
• continuous_mil

A code indicating whether the system requires that the MIL be steady (continuous) burning.
Refer to J1939-73 Feb2010 section 5.7.37.2 for details. A change of data on this inport
causes transmission of a DM37 message. The transmission is delayed, if necessary, until
the minimum inter-message interval has elapsed. Refer to J1939-73 Feb2010 section
5.7.37 for details of permitted transmission rates.
Range: [0, 3]
Value type: Integer

Calibratable: No
• mil_strategy
A code indicating whether the system is configured to employ a discriminatory MIL display.
Refer to J1939-73 Feb2010 section 5.7.37.3 for details. A change of data on this inport
causes transmission of a DM37 message. The transmission is delayed, if necessary, until
the minimum inter-message interval has elapsed. Refer to J1939-73 Feb2010 section
5.7.37 for details of permitted transmission rates.
Range: [0, 3]
Value type: Integer

Calibratable: No
• mil_activation_mode
A code indicating the most severe form of MIL display required by the failure status the
system or component. Refer to J1939-73 Feb2010 section 5.7.37.4 for details. A change of
data on this inport causes transmission of a DM37 message. The transmission is delayed,
if necessary, until the minimum inter-message interval has elapsed. Refer to J1939-73
Feb2010 section 5.7.37 for details of permitted transmission rates.
Range: [0, 15]
Value type: Integer

Calibratable: No
• incomplete_monitors
The number of incomplete diagnostic monitors for a given sub-system or component. Refer
to J1939-73 Feb2010 section 5.7.37.5 for details. A change of data on this inport causes
transmission of a DM37 message. The transmission is delayed, if necessary, until the
minimum inter-message interval has elapsed. Refer to J1939-73 Feb2010 section 5.7.37
for details of permitted transmission rates. The platform will limit the value to the range
specified below. This range is chosen to match that of the 'Vehicle Incomplete Monitor
Count' sent on DM36 message.
Range: [0, 64255]
Value type: Integer

Calibratable: No
7.7.47.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
7.7.47.7. Notes
In order to meet the minimum transmission rate requirements in J1939-73 FEB2010 section
5.7.37, the block should be scheduled at a 0.1Hz or faster rate. It is recommended that the
rate be faster than 1Hz in order that the transmission of DM37 messages is able to meet the
maximum allowable frequency for those transmitted on change of input data. When there is
no change in the data on the inports, and no forced transmission, the block will transmit the
DM37 messages at the rate of 0.1Hz (1 message every 10 seconds).

Transmit a J1939/73 DM38 message containing the Harmonised Global Technical
Regulation (GTR) description. Refer to J1939-73 Feb2010 section 5.7.38 for details.

All targets

sim_error_flag
error_flag
transmit
Channel: 0
GTR description: []
priority
use_dest_addr
pj1939_Dm38Transmit
A J1939/73 DM38 message is a variable length message. The DM38 message

contents detail the GTR description. Direct support is provided (rather than using the
7.7.48.4. Inports
• sim_error_flag

Value type: Boolean

Calibratable: No
Value type: Integer

Calibratable: No
• transmit
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• dest_addr
Range: [0, 255]
Value type: Integer

Calibratable: No
• use_dest_addr
Range: 0 or 1.
Value type: Boolean

Calibratable: No
7.7.48.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
Range: [0, 255]
Value type: Integer

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
• GTR description
A description of the UN/ECE WWH OBD Global Technical Regulation (GTR) to which the
sub-system or component complies. See J1939-73 Feb2010 section 5.7.38.1 for details.
The entered string must be enclosed within single quotes. The single quotes are not,
however, included in the transmitted string. The platform will limit the individual character
ASCII values to the range specified below. Should a character fall outside, it is rejected
and no further characters are processed. The platform will also limit the string length to
the range specified below.
Range (ASCII character): [0, 127]
Range (string length): [0, 200] characters
Value type: String

Calibratable: No
7.7.48.7. Notes
None.

Transmit a J1939/73 DM39 message containing the system cumulative continuous MI data.
Refer to J1939-73 Feb2010 section 5.7.39 for details.


All targets

sim_error_flag
transmit
priority Channel: 0 error_flag
cumulative_mil_time
total_b1_time
pj1939_Dm39Transmit
global network address. The DM39 message contents detail the system specific cumulative
information. Direct support is provided (rather than using the pj1939_PgTransmit block).
7.7.49.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
• transmit
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• cumulative_mil_time
The total amount of time that the MIL has been demanded to be illuminated during the life
of the system or component. Refer to J1939-73 Feb2010 section 5.7.39.1 for details.
[0, 4204501215] scaled at 0.05 hr/bit
Value type: Integer

Calibratable: No
• total_b1_time
The total amount of time that one or more DTCs with emission severity B1 have been
active. Refer to J1939-73 Feb2010 section 5.7.39.2 for details.
Range: [0, 64255] scaled at 0.1 hr/bit

Value type: Integer

Calibratable: No
7.7.49.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
7.7.49.7. Notes
None.

Transmit a J1939/73 DM40 message containing the harmonised B1 failure counts. Refer to
J1939-73 Feb2010 section 5.7.40 for details.

All targets

sim_error_flag
transmit
Channel: 0
Table:
priority
use_dest_addr
pj1939_Dm40Transmit

A J1939/73 DM40 message is a variable length message. The DM40 message contents
detail the system specific individual B1 failure counters. Direct support is provided (rather
than using the pj1939_PgTransmit block).
7.7.50.4. Inports
• sim_error_flag
Value type: Boolean

Calibratable: No
Value type: Integer

Calibratable: No
• transmit
Range: 0 or 1.
Value type: Boolean

Calibratable: No
• priority
Range: [0, 7]
Value type: Integer

Calibratable: No
• dest_addr
Range: [0, 255]
Value type: Integer

Calibratable: No
• use_dest_addr
Range: 0 or 1.
Value type: Boolean

Calibratable: No

7.7.50.5. Outports
• error_flag
Value type: Boolean

Calibratable: No
Range: [0, 255]
Value type: Integer

Calibratable: No
• J1939 Channel
Value type: Integer

Calibratable: No
Value type: String

Calibratable: No
7.7.50.7. Notes
None.
7.7.51. J1939 parameter group receive message

(pj1939_PgReceive)
Extract the data contents from a received J1939 message.

See Section 6.1.52, “J1939 parameter group receive message (pj1939_PgReceive)” for a
7.7.52. J1939 parameter group requested

(pj1939_PgRequested)
Determine whether a Parameter Group (PG) has been requested by another J1939 network
node.
See Section 6.1.53, “J1939 parameter group requested (pj1939_PgRequested)” for a

7.7.53. J1939 parameter group transmit

(pj1939_PgTransmit)
Construct the contents of a J1939 message, and attempt to transmit it.
See Section 6.1.54, “J1939 parameter group transmit (pj1939_PgTransmit)” for a detailed
description.
7.7.54. J1939 send acknowledgement message

(pj1939_SendAck)
Attempt to send an acknowledgement in response to a J1939 request.

All targets

transmit
Channel: 0
PGN: []
Type: Ack
source_addr
pj1939_SendAck
The send acknowledgement block can be used to acknowledge any PGN request (with either
Ack, Nack, Access Denied or Busy responses).
7.7.54.4. Inports
• transmit
Transition from 0 to 1 to cause the acknowledgement message to be sent; no

acknowledgement sent otherwise.
• source_addr
The source address of the request to be acknowledged.
Range: [0, 255]
7.7.54.5. Outports
None.

• J1939 Channel
Value type: Integer

Calibratable: No
• PGN to be acknowledged
The PGN request that is being acknowledged by this message.
• Required response
The required response for this message: Ack, Nack, Access Denied or Busy.
7.7.54.7. Notes
None.
7.7.55. J1939 update NTE status

(pj1939_UpdateNteStatus)
Provide the facility to update the NTE status (as reported in J1939 message DM34).

All targets

nte_status
pj1939_UpdateNteStatus
The platform requires information regarding the status of the engine operation in the NTE
control areas, for given pollutants such as NOx and PM. This block provides the facility to
update that information in order that a J1939 DM34 message (when requested) contains up-
to-date data. Refer to J1939-73 FEB2010 section 5.7.34 for details of the various NTE areas.

7.7.55.4. Inports
• nte_status
A 2-bit status code indicating the status of engine operation within the manufacturer specific
NTE area. See J1939-73 FEB2010 section 5.7.34 for details of these codes.
Value type: Integer

Calibratable: No
7.7.55.5. Outports
None.
• NTE area
A drop down to identify the NTE area for which the status is to be updated.
Value type: List

Calibratable: No
• Sample time
Value type: Real

Calibratable: No
7.7.55.7. Notes
This block updates the platform data for the pj1939_dm34Transmit block.
7.7.56. J1979 service $09 Infotype input

(pdg_InfotypeInput)
Declares vehicle specific information (VIN, calibration ID, etc) as per service $09 of the J1979
diagnostic protocol.

All targets


in InfoType: $02
pdg_InfotypeInput
The InfoType designates the type of vehicle specific information that the application is
supplying. This supplied vehicle specific information can be accessed using a diagnostic
scan tool via J1979 service $09 by specifying the InfoType.
The InfoTypes $00, $20, $40,.. etc specify which InfoTypes an application supports.
The underlying platform code implements the supported InfoType message. Placing the
pdg_InfotypeInput block with an appropriate Infotype selected in the application model will
cause the corresponding bitfield to be set in the supported InfoTypes message.
7.7.56.4. Inports
• in
Application supplied data which is to be accessed via service 0x09 by a diagnostic scan
tool.
Note this inport accepts inputs from multidimensional data types, such as a simulink Mux,
simulink constant block whose constant value is a vector (specified in the data dictionary),
etc.
Note the length of the supplied data must match that defined in the J1979 standard.
Value type: Integer
• pending
Indicates the availablity of the application data. False indicates the data is available.
When true, a J1979 request for the data will result in the negative response code $78
(requestCorrectlyReceived-ResponsePending) followed by a negative response code $78
message at 4.5s intervals until pending transistions to false where upon the supplied
infotype data is sent.
Currently this is only required by Infotype 0x06 (CVN).
Value type: Boolean
7.7.56.5. Outports
None.

• InfoType
A drop down to select the service 0x09 InfoType.
$02
Vehicle Identification Number.
$04
Calibration Identifications
Note the number of data items (NODI) is currently limited to 1 for this
InfoType
$06
Calibration Verification Number (CVN)
$0A
ECUNAME
$0B
In-use Performance Tracking
This infotype is automatically generated by the platform software

using the data processed by the Diagnostic Monitor Entities (see
ppr_DiagnosticMonitorEntity for more details). Any value passed here
will be ignored.
$0D
Engine Serial Number
$0F
Exhaust Regulation Or Type Approval Number
Value type: List

Calibratable: No
7.7.56.7. Notes
None.
7.7.57. Diagnostic monitor entity

(ppr_DiagnosticMonitorEntity)
Define a Diagnostic Monitor Entity.


All targets

enabled
monitor_run
readiness_complete
force_complete
completed
DME ID:
Readiness limit:
numerator
force_not_complete
denominator
monitor_enabled
ratio
ppr_DiagnosticMonitorEntity
A Diagnostic Monitor Entity (DME) is a group of Diagnostic Test Entities (DTEs) and is
represented by an ISO-15765 Monitor Identifier (OBDMID), a monitor group (which is used for
reporting In-Use Performance Tracking over ISO-15765 protocol) and/or by a J1939 Suspect
Parameter Number (which is used for reporting performance tracking over J1939 protocol).
Examples of a DME monitor group are:-
• NMHC converting catalyst
• NOx converting catalyst
• Catalyst
• Exhaust gas sensor
• Evaporative system
• EGR and VVT system
• Secondary air system
• PM filter
• Boost pressure control system
• NOx adsorber
• Fuel system
• Secondary oxygen sensor
The platform holds information for each DME, consisting of monitor readiness status as well
as monitor enable and monitor completion status. The monitor readiness status is a term
used in OBD that refers to a vehicle's readiness for I/M inspection. For monitors that are
non-continuous and have an emissions threshold, a readiness status indicator is stored to
indicate whether or not that particular monitor has run enough times to make a diagnostic
decision. The monitor enable status for the current driving cycle indicates when a monitor is
not disabled in a manner such that there is no way for the driver to operate the vehicle for
the remainder of the driving cycle and make the monitor run. The monitor completion status
indicates if all monitoring conditions required for the particular monitor have been tested and
a result has been obtained.
7.7.57.4. Inports
• monitor_run

Set to 1 if the monitor has run, set to zero otherwise. This is used by the the platform
to determine the monitor completion and readiness status. The platform increments the
number of times a monitor has been run on each 0 to 1 transition of this inport, provided
that inport monitor_enabled is set to 1 and force_complete and force_not_complete are
both set to 0.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• force_complete
Set to 1 to force the monitor readiness status to complete, independent of the number of
times the monitor has been run. Set to 0 otherwise. The block responds on the rising edge
of this inport.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• force_not_complete
Set to 1 to force the monitor readiness status to incomplete, independent of the number
of times the monitor has been run. Set to 0 otherwise. The block responds on the rising
edge of this inport.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• monitor_enabled
Set to 1 to indicate the monitor is enabled, 0 otherwise.
Range: 0 or 1
Value type: Boolean

Calibratable: No
7.7.57.5. Outports
• enabled
Set to 1 if the DME is enabled, set to 0 otherwise.
Range: 0 or 1
Value type: Boolean
• readiness_complete
Set to 1 if this DME's run count is greater than or equal to its Readiness count limit
parameter, set to 0 otherwise.
Range: 0 or 1
Value type: Boolean

• completed
Set to 1 if all monitoring conditions required for this DME have been tested and a result
has been obtained, set to 0 otherwise.
Range: 0 or 1
Value type: Boolean
• numerator
If there is only one DTE for this monitor then the numerator will be set to that DTE's specific
numerator. If there is more than one DTE, then the value of this outport will be the specific
numerator corresponding to the lowest ratio found in the set of DTEs for this monitor.
Range: [0, 65535]
Value type: Integer
• denominator
If there is only one DTE for this monitor then the denominator will be set to that DTE's
specific denominator. If there is more than one DTE, then the value of this outport will be
the specific denominator corresponding to the lowest ratio found in the set of DTEs for
this monitor.
Range: [0, 65535]
Value type: Integer
• ratio
If there is only one DTE for this monitor then the ratio will be set to that DTE's specific ratio.
If there is more than one DTE, then the value of this outport will be the lowest ratio found
in the set of DTEs for this monitor.
Range: [0.0, 7.99527]
Value type: Real

• DME identifier
The unique identifier for this DME.
Range: [0, 255]
Value type: Integer
• Readiness count limit
The minimum number of times the monitor must be run before the monitor readiness status
is set to complete.
Range: [0, 524287]
Value type: Integer

Calibratable: No
• ISO Type?
If this box is checked then the parameters pertaining to ISO specific DMEs are available.
Note that a DME can be ISO type, J1939 type or both.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• Monitor identifier
The ISO-15765 monitor identifier (OBDMID - see J1979 spec dated Sept 2010 appendix
D). It is used for reporting over ISO-15765 diagnostics in response to service $06. Only
available if the ISO Type? option is checked.
Range: [0, 255]
Value type: Integer

Calibratable: No
• Monitor group
A drop down to specify the ISO-15765 monitor group as described in J1979 spec dated
Sept 2010 appendix G. It is used for reporting performance ratio data over ISO-15765
diagnostics, in response to service $09. Only available if the ISO Type? option is checked.
Value type: List
• J1939 Type?
If this box is checked then the parameters pertaining to J1939 specific DMEs are available.
Note that a DME can be ISO type, J1939 type or both.
Range: 0 or 1
• J1939 SPN
The value of the J1939 SPN for this DME. Only available if the J1939 Type? option is
checked.
Range: [0, 524287]
Value type: Integer

Calibratable: No
7.7.57.7. Notes
None.
7.7.58. Diagnostic test entity

(ppr_DiagnosticTestEntity)
Define a Diagnostic Test Entity and the inputs which operate on it.

All targets

dte_numerator
numerator_update
dte_denominator
denominator_update
test_value
denominator_updated_this_dc
DTE ID:
test_limit_min DME ID:
dte_test_value
test_limit_max
dte_test_lim_min
test_run
dte_test_lim_max
reset
dte_test_run_status
ppr_DiagnosticTestEntity
A DTE is a specific test for some vehicle component for which test results are recorded. It
is represented by an ISO-15765 Test Identifier (ISO-TID), which is reported over ISO-15765
protocol and/or by a J1939 Test Identifier (J1939-TID), which is reported over J1939 protocol.
The platform holds information for each DTE, consisting of a numerator (a measure of the
number of times a vehicle has been operated such that all monitoring conditions necessary
for a specific test (DTE) to detect a malfunction have been encountered) and a denominator (a
measure of the number of times a vehicle has been operated). These are used to implement
algorithms in the platform to individually track and report a minimum acceptable In-Use
Performance Ratio (IUPR). The platform keeps track of whether the test value for the DTE
has been updated at least once in the current drive cycle and holds test value and min and
max limits for the DTE.
7.7.58.4. Inports
• numerator_update
Set to 1 if the numerator for this DTE is to be updated, set to zero otherwise. The block
responds to a rising edge on this inport. This is used by the block to increment the specific
numerator for the DTE. Note that the DTE specific numerator will be incremented only
once per drive cycle. Therefore, it is important that this inport is returned to level 0 before
a new drive cycle event, if a numerator update is not required. The signal passed to this
inport should be connected to all DTEs which contain the same Monitor identifier in order
that the specific numerator is updated simultaneously for all those DTEs.
Range: 0 or 1
Value type: Boolean

Calibratable: No

• denominator_update
Set to 1 if the denominator for this DTE is to be updated, set to zero otherwise. The block
responds to a rising edge on this inport. This is used by the block to increment the specific
denominator for the DTE. The user should set this inport to 1 only when every monitoring
condition necessary for the monitor of the specific component to detect a malfunction and
store a pending fault code has been satisfied. Note that the DTE specific denominator
will be incremented only once per drive cycle. Therefore, it is important that this inport is
returned to level 0 before a new drive cycle event, if a denominator update is not required.
The signal passed to this inport should be connected to all DTEs which contain the same
Monitor identifier in order that the specific denominator is updated simultaneously for all
those DTEs.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• test_value
The test value collected during the test.
Range: [0, 65535]
Value type: Integer

Calibratable: No
• test_limit_min
The threshold which the test value must be above in order to pass the test.
Range: [0, 65535]
Value type: Integer

Calibratable: No
• test_limit_max
The threshold which the test value must be below in order to pass the test.
Range: [0, 65535]
Value type: Integer

Calibratable: No
• test_run
Sets whether the test has been run at this time step.
When this input is 1, the block sets the test value and min and max limits for the DTE
to the values on inports test_value, test_limit_min and test_limit_max respectively. When
this input is 0, the stored test value and min and max limits are held unchanged. Note
that this input is level-triggered and not edge-triggered. This is required so that results for
continuously-monitored tests such as range checks on sensors may be updated at every
step.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• reset

Sets whether the test is to be reset at this time step.
Set to 1 to cause the block to reset the test value, test min and test max for this DTE to
initial values of 0 and its test run status to 'test not run'. Set to 0, otherwise. Note that this
input is level-triggered and not edge-triggered. This is required so that test results may be
repeatedly reset if necessary. Note also that test_run takes precedence over this input.
Range: 0 or 1
Value type: Boolean

Calibratable: No
7.7.58.5. Outports
• dte_numerator
The specific numerator for this DTE. Used internally for calculation of the DME's In-Use
performance ratio which this DTE belongs to.
Range: [0, 65535]
Value type: Integer
• dte_denominator
The specific denominator for this DTE. Used internally for calculation of the DME's In-Use
performance ratio which this DTE belongs to.
Range: [0, 65535]
Value type: Integer
• numerator_updated_this_dc
Set to 1 if the specific numerator for this DTE has been updated this drive cycle, set to
0 otherwise.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• denominator_updated_this_dc
Set to 1 if the specific denominator for this DTE has been updated this drive cycle, set
to 0 otherwise.
Range: 0 or 1
Value type: Boolean
• dte_test_value
The test value that the platform holds for this DTE.
Range: [0, 65535]
Value type: Integer
• dte_test_limit_min
The test minimum threshold that the platform holds for this DTE.

Range: [0, 65535]
Value type: Integer
• dte_test_limit_max
The test maximum threshold that the platform holds for this DTE.
Range: [0, 65535]
Value type: Integer
• dte_test_run_status
The test run status that the platform holds for this DTE. A value of 0 indicates that the test
has never run. A value of 1 indicates that a test has run on this drive cycle. A value of 2
indicates that a test has run but not on this drive cycle.
Range: [0, 2]
Value type: Integer

Calibratable: No
• DTE identifier

The unique identifier for this DTE.
Range: [0, 255]
Value type: Integer

Calibratable: No
• DME identifier
The identity of the DME that this DTE belongs to. For example, an Exhaust gas sensor
monitor will have a subset of DTEs. This DTE needs to have a matching DME identifier
parameter with its parent DME.
Range: [0, 255]
Value type: List
• ISO Type?
If this box is checked then the parameters pertaining to ISO specific DTEs are available.
Note that a DTE can be ISO type, J1939 type or both.
Range: 0 or 1
Value type: Boolean

Calibratable: No
• Monitor identifier
The ISO-15765 monitor identifier (OBDMID - see J1979 spec dated Sept 2010 appendix
D) that this DTE belongs to. It is used for reporting over ISO-15765 diagnostics in response
to service $06. Only available if the ISO Type? option is checked.
Range: [0, 255]
Value type: Integer

Calibratable: No
• ISO scaling identifier
This identifier is used to reference the scaling and unit to be used by the external test
equipment in order to calculate and display the test values (results), Minimum Test Limit,
and the Maximum for the DTE. Only available if the ISO Type? option is checked.
Range: [0, 255]
Value type: Integer

Calibratable: No
• ISO test identifier
The ISO specific test identifier (TID). Only available if the ISO Type? option is checked.
Range: [0, 255]
Value type: Integer

Calibratable: No
• J1939 Type?
If this box is checked then the parameters pertaining to J1939 specific DTEs are available.
Note that a DTE can be ISO type, J1939 type or both.

Range: 0 or 1
Value type: Boolean

Calibratable: No
• J1939 test identifier
The J1939 specific test identifier (TID). See J1939-73 Sept 2010 section 5.7.7.1 for details.
Only available if the J1939 Type? option is checked.
Range: [0, 255]
Value type: Integer

Calibratable: No
• J1939 slot identifier
This is the scaling, limit, offset, and transfer function for the DTE. Only available if the
J1939 Type? option is checked.
Range: [0, 64255]
Value type: Integer

Calibratable: No
• J1939 SPN
This is the SPN number associated with the DTE. Only available if the J1939 Type? option
is checked.
Range: [0, 524287]
Value type: Integer

Calibratable: No
• J1939 FMI
This is the FMI number associate with the DTE. See J1939-73 Sept 2010 Appendix A.
Only available if the J1939 Type? option is checked.
Range: [0, 31]
Value type: Integer

Calibratable: No
• J1939 component identifier
This identifies the non-continuously monitored component identifier. Component identifiers

are used to distinguish DTEs that have the same J1939 slot identifier Only available if the
J1939 Type? option is checked.
Range: [1, 64]
Value type: Integer

Calibratable: No
• DM10 bit position
This is the bit position to set in a requested DM10 message response, to indicate test
supported. Refer to J1939-73 FEB2010 section 5.7.10 for details. The assignment of a
given test identifier (as provided in the J1939 test identifier parameter) to a given bit position

is manufacturer specific. This parameter is optional and may be left blank, in which case the
DM10 bit position will default to the value provided in the J1939 test identifier parameter,
provided it lies in the range specified below. Only available if the J1939 Type? option is
checked.
Range: [1, 64]
Value type: Integer

Calibratable: No
7.7.58.7. Notes
None.
7.7.59. General denominator

(ppr_GeneralDenominator)
Provide the means to update the In-use performance ratio general denominator.

All targets

update general_denominator
ppr_GeneralDenominator
The general denominator is defined as a measure of the number of times a vehicle has
been operated and is not specific to a Diagnostic Test Entity. The general denominator is
incremented by one if inport update is set to 1. Otherwise, no increment is attempted.
7.7.59.4. Inports
• update
Set to 1 if the general denominator is to be incremented, set to zero otherwise. Note that the
platform's general denominator will be incremented only once per drive cycle. Therefore,
it is important that this inport is set to 0 before a new drive cycle event occurs, if a general
denominator update is not required.
Range: 0 or 1
Value type: Boolean
7.7.59.5. Outports
• general_denominator
The value of the general denominator that is held by the platform.
Range: [0, 65535]

Value type: Integer
7.7.59.7. Notes
None.
7.7.60. Ignition cycle (ppr_IgnitionCycle)

Provide the means to update the In-use performance ratio ignition cycle counter.

All targets

update ignition_cycle_count
ppr_IgnitionCycle
The ignition cycle counter is defined as a counter that indicates the number of ignition cycles
a vehicle has experienced under certain engine speed conditions for a certain amount of
time. The ignition cycle counter is incremented by one if inport update is set to 1. Otherwise,
no increment is attempted. Note that the platform's ignition cycle counter will be incremented
only once per ignition cycle.
7.7.60.4. Inports
• update
Set to 1 if the ignition cycle counter is to be incremented, set to zero otherwise. Note
that the platform's ignition cycle counter will be incremented only once per ignition cycle.
Therefore, it is important that this inport is set to 0 before a new ignition cycle event occurs,
if an ignition cycle counter update is not required.
Range: 0 or 1
Value type: Boolean

Calibratable: No
7.7.60.5. Outports
• ignition_cycle_count
The value of the ignition cycle counter that is held by the platform.

Range: [0, 65535]
Value type: Integer
7.7.60.7. Notes
None.
7.7.61. PPR memory update (ppr_Memory)

Retain the In-use performance ratio data in non-volatile storage across power cycles.

All targets

commit store_up_to_date
ppr_Memory
The ppr_Memory block stores the In-use performance ratio data in non-volatile memory.
Storage consists of DME and DTE data plus the ignition cycle counter and general
denominator. On start-up, the block attempts to retrieve the data prior to running the model.
While the model is running, the time at which the data is stored back to non-volatile memory
is determined by the model itself.
Failure to retrieve the data on start-up causes the data to be reverted to the default start-
up conditions.
The target non-volatile memory may be provided in two ways: either through storage that
requires an external power source when the ECU is powered down (battery backed RAM
storage), or not (Flash storage). In the case of IUPR data, only Flash storage is supported.
See the technical specification for details on which storage type is supported by each target.
This block is used to write the In-use performance ratio data to non-volatile store. When the
inport commit is set to 1, the block pauses execution of the model, stores the IUPR data in
non-volatile memory, then continues execution of the model.
Note
This block suspends the scheduler for a period of time. When storing the information,
the worst case Flash erase time given worst case environmental conditions, can be
around 1.8 seconds.

Old IUPR data is reused so long as it has the expected total data size and was written
by an application with the same user-specified version number. Otherwise the values
revert to defaults.
To ensure the IUPR data is up to date before shutting down the ECU, the store_up_to_date
outport provides an indication of whether the storage to Flash was successful or not. If not,
shutdown of the module can be prevented (if conditions are appropriate), and the store
updated (by setting the commit inport to 1).
7.7.61.4. Inports
• commit
Set to 1 to write the IUPR data to non-volatile memory. Note that the block responds to the
rising edge of this inport in order to prevent multiple stores to NVM. Set to zero otherwise.
Range: 0 or 1
Value type: Boolean

Calibratable: No
7.7.61.5. Outports
• store_up_to_date
Set to 1 if the storage of IUPR data to non-volatile memory was successful, set to zero
otherwise.
Range: 0 or 1
Value type: Boolean

Calibratable: No
7.7.61.7. Notes
• None.
7.7.62. Monitors incomplete count

(ppr_MonitorsIncomplete)
Provide a count of the total number of monitors (DMEs) that are enabled and have a readiness
status of not complete.

All targets


count
ppr_MonitorsIncomplete
The count of the number of DMEs that are enabled and have a status of readiness not
complete is calculated and presented on the count outport.
7.7.62.4. Inports
None.
7.7.62.5. Outports
• count
The count of the number of monitors (DMEs) that are enabled and incomplete.
Range: [0, 65535]
Value type: Integer
• Sample time
Value type: Real

Calibratable: No
7.7.62.7. Notes
None.

Appendix A. Reference
documentation
A.1. ECU hardware reference documentation
For each ECU, there is a technical specification which provides an overview of the electronics
and components of the ECU, including a list of connectors, pin outs, pin capabilities, flash
codes, and so on. These technical specifications are available from the Downloads area of
the website. See Appendix K, Contact information.
Further information about ECUs, including simplified I/O schematics and mechanical
drawings, can be downloaded from the website (registration or purchase of ECU required)
or requested through OpenECU technical support as described in Appendix K, Contact
information.

Appendix B. Supporting tools
B.1. Introduction
This section provides a quick introduction to the tools that support OpenECU, both supplied
by OpenECU and those by other companies. The section is intended to be a first step with
the tools when used with OpenECU.
For tools that are supplied by other companies, additional details about how to use the tools
can be found in their respective manuals. OpenECU will not provide technical support in the
use of these tools.
The sections on the calibration tools (Section B.3, “ATI Vision”, Section B.5, “Vector
CANape”, Section B.4, “ETAS INCA”) and on a free programming tool called FreeCCP
(Section B.6, “FreeCCP”) assume that the step1 example application (see Chapter 3, Quick
start for details) has been built using the default CCP settings (Table 6.3, “CCP defaults”)
and that the user is familiar with the installation of the calibration tool.
Note
On M5xx ECU's (eg. M560, M580), calibration tools must use the A2L file, not the .elf
file to commit cal-on-the-fly calibration changes. This is due to the calibration overlay
mechanism on the mpc5746 micro-controller.
B.2. PiSnoop
Pi Innovo's PiSnoop tool has many functions that are useful in typical OpenECU
developments. It offers a cost-effective alternative to traditional calibration tools, but its
emphasis is more on software development than calibration. Therefore it presents an
interface that is part way to a debugger in terms of watch and memory windows, but typically
interacts with the ECU via CCP, just like a calibration tool.
A demo version of PiSnoop is available from our website [http://www.pisnoop.com]) in

which all features may be tried out, but with some limitations on the number or duration of
operations. This provides a route to getting up and running right away with OpenECU.
PiSnoop is under continual development, so this manual does not attempt to document how
to use it with OpenECU in detail as is done for the other tools below. Instead, see the online
help that is included in the PiSnoop installation (including the specific OpenECU application
note) for up-to-date guidance. In brief however, capabilities include:
• Works with any Vector, Kvaser or PEAK-System (PCAN) CAN interface on Windows XP
or higher.
• Loads symbols (parameter names, addresses, types and descriptions) from ASAP2 (.a2l)
files...
• ... but can also load symbols from the linker output (.elf) files, giving access to all
static C language objects present including arrays, structure elements, pointers and
bitfields, without needing data dictionary entries. In Simulink builds, this means Real-Time
Workshop structures such as rtDWork and rtB can be explored, making "hidden" block-
related values, present in the autocode, available for debug purposes.
• ECU memory access and flash reprogramming via CCP, with seed-key security support
and fast DAQ data-logging, which tolerates ECU power cycling.

Supporting tools
• Reloading symbols and/or reprogramming the ECU after rebuilding is a single-click

operation.
• Calibration parameter value changes can be uploaded by name to a file, to use for
download or flash reprogramming with a different build later.
• Watch, map lookup and raw memory windows to view and edit ECU memory or offline
file images.
• CAN traffic generation and monitoring/logging with .dbc file support for named messages
and signals.
• ISO 15765-2 (UDS/Keyword Protocol/J1979) and J1939 diagnostic messaging windows.
• UDS/Keyword Protocol can be used as an alternative memory access and flash

reprogramming protocol, with seed-key security support.
• ASAP3 support is provided to enable test automation.
• Extensible through plug-in architecture supporting new protocols, hardware interfaces and
custom windows.
B.2.1. Example Screenshots

This shows how calibration parameters and RAM variables can be accessed and logged
together in debugger-style watch windows. Parameters can be loaded from ASAP2 (.a2l) and
linker (.elf) files simultaneously. Structures, pointers, bitfields and arrays can be explored:
Debugger-style memory windows can be used to view and edit memory contents. Known
symbols loaded from .a2l or .elf files are highlighted when the mouse pointer is placed over
their locations:
Further windows are integrated for CAN and diagnostic functions. For example, arbitrary
CAN traffic can be generated by hand or using a .dbc file:

Supporting tools
Similarly, CAN traffic can be monitored and logged:
B.3. ATI Vision

ATI Vision by Accurate Technologies is a calibration tool that can communicate to a CCP
compliant device. It provides facilities for calibration, data logging and display and can be
used with OpenECU.
B.3.1. Creating a new project and strategy in ATI

Vision
The following instructions assume the user is using a supported version. These instructions
were transcribed against a supported version but it may be that these instructions match
other versions of the tool.
They also assume that an ATI Vision Hub is used. If another communications device is used,
the user will need to deviate from these instructions.
1. Install ATI vision, the installer may reboot your machine. Once windows is restarted, it will
detect new USB hardware (assuming the hub is plugged in: if not, plug it in).
Ask windows to install the USB hardware software from the "device software" directory
located where you just installed ATI vision, e.g., c:\program files\Accurate Technologies
\ati vision\device software.
Start Vision and you will be presented with a window similar to the following:

Supporting tools
2. Next, you must create a project to details how ATI Vision will communicate with the
OpenECU device.
Create a new project using the menu option File->New, then select Project.
and save it somewhere on your hard-disk (here, it has been saved using the name
"example_project").
Next, add a device by right clicking on the Computer item and selecting "Add Device..."

Supporting tools
Select USB port and in the subsequent dialog, accept all the defaults and select OK.
Next, add a device by right clicking on the USB item and selecting "Add Device..."
Select VISION Network Hub in the subsequent dialog and select OK.

Supporting tools
Accept the default hub name and in the subsequent dialog properties defaults by selecting
OK.
Next, add another device by right clicking on the VisionHub item and selecting "Add
Device..."
Select a VNI CAN device type, accept the default name and in the subsequent dialog,
accept the defaults by selecting OK.
Next, add another device by right clicking on the VNICAN item and selecting "Add
Device..."

Supporting tools
Select the CCP Controller Device, accept the default name and in the subsequent
dialog, accept the defaults by selecting OK. This has told the Vision tool that you will be
communicating to a CCP compatible device over CAN via the Vision Hub connected to
the PC via a USB cable.
3. Next, you must create a strategy file to hold both the calibration data and program data.
Select File->New, then Strategy File.
The main Vision window will change and you will be presented with the import wizard.
Select the ASAP2 description file item.
For the step1 example, select the step1_tool_vision.a2l file from the location
where you built it (note that the following diagrams show an older version of the step1
application called step1_r12_g800).

Supporting tools
It is important to keep the "Strategy Presets" text box clear and to tick the "Delete existing
data items from before importing" check-box. This ensures that the memory and CCP
settings are taken from the ASAP2 file and that subsequent imports of the same strategy
will clear out previous ASAP entries before loading the latest.
Click Import to read in the ASAP2 file, then click on the More button.

Supporting tools
Select import memory image, then select Motorola S-record File, then browse and select
the step1_image_small.s37 file from the place where you built it.
Select Import, then Finish. The Wizard dialog box now closes.
Note
You must now save this strategy (menu option File->Save) and change back to
the project file by clicking on the "example_project" tab at the bottom of the Vision
window.

Supporting tools
B.3.2. Downloading an application with an ATI Vision

strategy
The following instructions assume the user is using a supported version of ATI Vision. These
instructions were transcribed against a supported version but it may be that these instructions
match other versions of the tool.
They also assume that an ATI Vision Hub is used. If another communications device is used,
the user will need to deviate from these instructions.
Before building an application, select the Generate ATI Vision Strategy file RTW option (see
Section 4.3.4, “Configuration options” for more details about how to do this). Alternatively,
follow the instructions for creating an ATI Vision strategy described in Section B.3.1, “Creating
a new project and strategy in ATI Vision”.
1. Add this strategy to the tree list by right clicking on the PCM item and selecting "Add
Strategy...", browse to the location where you saved the strategy file and select it.
This will add two items to the tree view, one for the strategy and one for the calibration
data immediately below it.
2. If CCP seed/key security is to be used, copy the relevant DLL(s) into the same location
as the strategy file.
3. To try out the connection, go online by selecting the menu option Project->Online.

Supporting tools
The tree view will change to show that each of the devices previously added are
communicating correctly:
and brings up a dialog box:

Supporting tools
If any of the devices show a yellow or red mark, then there is a physical disconnection or
CCP communications error (e.g., different settings for CCP in the OpenECU device and
the application). The dialog box will not pop-up and you will not be able to Flash the device.
Go back and check that each of the settings corresponds to physical devices and CCP
settings, check that CAN is connected to the correct pins and try again.
To program the OpenECU device with the strategy, select Flash then OK. This brings up
a dialog box which shows which memory regions on the OpenECU device to program.
Select Start to program the device.
Note
In order to reprogram or Flash the OpenECU device, the OpenECU device must be
in reprogramming mode. For details on how to enter reprogramming mode refer to
Section 4.5, “Programming an ECU”
Once programmed, the FEPS must be disconnected (if used) and the OpenECU device
power cycled. This reboots the OpenECU and starts to run the application.
4. You can now view ASAP2 entries by creating a screen and adding the application signals
and calibrations you wish to see. Select File->New, then Screen File. The main window
will change. Right click on the background and select "Add Control".

Supporting tools
For now, we will only look at scalar values by selecting Data List items, but 1-d and 2-d
maps are supported, as well as recorders etc..
Select Data List and you will be presented with a dialog box which lists the ASAP2 entries.

Supporting tools
Double click on stp_ect_state and then select OK. You will be presented with the
current value of stp_ect_state in real-time.
At this point, you have managed to connect ATI Vision to OpenECU, download the step1
application and view one application signal in real-time. Please refer to the ATI Vision user
manual for more details about how to use ATI Vision.
B.3.3. Configuring two OpenECUs on the same CAN

bus with ATI Vision
When connecting to a single OpenECU for the first time, the tool and OpenECU settings
will probably use the default CCP settings (as described in Table 6.3, “CCP defaults”). The
example which follows assumes the default CCP settings.
ATI Vision
Strategy A
OpenECU A
USB CAN
CRO: 1785 ATI Hub
CRO: 1785
DTO: 1784
DTO: 1784
The above diagram shows ATI Vision with a single strategy using the default CCP settings.
A similarly configured OpenECU is connected to ATI Vision via the CAN bus to the Vision
Hub, and from the Hub to the PC via a USB cable. Your setup may vary depending on what
equipment you have (for instance, you may have two ATI Hubs but the overall concept of
configuring the additional OpenECU's remains).

Supporting tools
When a second OpenECU is first required, a second application will be built into a second
strategy which must use different CCP settings from the first strategy. The tool settings may
follow the example default settings for two OpenECUs.
ATI Vision
OpenECU A
CRO: 1785
Strategy A DTO: 1784
USB CAN
CRO: 1785 ATI Hub
DTO: 1784
OpenECU B
Strategy B CRO: 1785

DTO: 1784
CRO: 1787
DTO: 1786
The diagram shows ATI Vision with two strategies: strategy A using the default CCP settings
(as in the single OpenECU example above); strategy B using different CCP settings. The
CCP settings distinguish between the two OpenECUs. Two OpenECUs are connected to the
Hub allowing ATI Vision to communicate with both.
As this is the first time the second OpenECU has been connected to the CAN bus, it uses the
default CCP settings. When the user selects strategy B in Vision, Vision uses the strategy
B CCP CAN identifiers but there is no OpenECU with matching CCP settings. Without any
response Vision shows the OpenECU for strategy B as offline.
Follow this procedure to program OpenECU B with strategy B for the first time:
1. Disconnect OpenECU A from the CAN bus. This prevents OpenECU A from interfering
with communications to OpenECU B.
2. Right click on strategy B and select Open File. The screen will change.
3. Select File -> Properties and change to the Device Settings tab in the new dialog.

Supporting tools
Change the CRO CAN identifier to 1785 and the DTO CAN identifier to 1784, then select
File -> Save.
4. Change back to the Project tab (so you can see both strategy A and strategy B), right
click on strategy B and select Reload File. This brings the CRO and DTO changes into
strategy B.
Your setup is now configured as:

ATI Vision
OpenECU A
CRO: 1785
USB CAN
CRO: 1785 ATI Hub
DTO: 1784
OpenECU B

DTO: 1784
CRO: 1785
DTO: 1784
If strategy B is selected, ATI Vision will show OpenECU B as online.
5. Reprogram OpenECU B with strategy B (see Section B.3, “ATI Vision” and Section 4.5,
“Programming an ECU” for more).
6. Once reprogrammed, power cycle OpenECU B. ATI Vision will show OpenECU B as
offline.
7. Right click on strategy B and select Open File. Select File -> Properties, change to the
Device Settings tab in the new dialog, change the CRO CAN identifier to 1787 and the
DTO CAN identifier to 1786, then select File -> Save.
8. Change back to the Project tab (so you can see both strategy A and strategy B), right
click on strategy B and select Reload File.
Your setup is now configured as:

ATI Vision
OpenECU A
CRO: 1785
USB CAN
CRO: 1785 ATI Hub
DTO: 1784
OpenECU B

DTO: 1786
CRO: 1787
DTO: 1786
9. Reconnect OpenECU A to the CAN bus. Select strategy A to communicate with

OpenECU A, or select strategy B to communicate with OpenECU B.

Supporting tools
Note
The above procedure is equally applicable when reprogramming a single OpenECU to
new CCP settings. Ensure there is only one OpenECU connected to the CAN bus, build
the application with the new CCP settings, import into Vision, adjust the CCP settings
in Vision to that of the connected OpenECU, reprogram the OpenECU and reset it,
then adjust the CCP settings in Vision to that of the application.
B.3.4. Configuring CCP seed/key security with ATI

Vision
Some manufacturers may enable CCP seed/key security for certain CCP operations,
particularly in software which is released to production. Configuring this in the application is
discussed in Section 6.1.21, “CCP seed/key security (pcp_CCPSecurity)”.
CCP seed/key security requires that a Win32 DLL is built containing a function which will
generate a key value from a seed value supplied by the ECU. The name and function
prototype are specified in the ASAP1A and ASAP2 standards to be
BOOL SEEDKEYAPI ASAP1A_CCP_ComputeKeyFromSeed(BYTE *Seed,

unsigned short SizeSeed,
BYTE *Key,
unsigned short MaxSizeKey,
unsigned short *SizeKey);
// Seed: Pointer to seed data
// SizeSeed:Size of seed data (length of ‚Seed‘)
// Key: Pointer, where DLL should insert the calculated key data.
// MaxSizeKey: Maximum size of ‚Key‘.
// SizeKey: Should be set from DLL corresponding to the number of data
// inserted to ‚Key‘ (at most ‚MaxSizeKey‘)
// Result: The value FALSE (= 0) indicates that the key could not be
// calculated from seed data (e.g. ‚MaxSizeKey‘ is too small).
// TRUE (!= 0) indicates success of key calculation.
Vision allows differently-named functions to be used, which may be convenient in cases

such as supplying a single DLL containing multiple different seed/key algorithms for different
strategies). Note though that this may make seed/key DLLs for Vision incompatibile with
other calibrations tools which require a single function per DLL with a fixed name per the
ASAP standard.
B.4. ETAS INCA

INCA by ETAS GmbH is a calibration tool that can communicate to a CCP compliant device.
It provides facilities for calibration, data logging and display and can be used with OpenECU.
The following instructions assume the user is using version 5.1.2. These instructions were
transcribed against this version but it may be that these instructions match other versions
of the tool.
The instructions also assume that ES 580 CAN card is used. If another communications
device is used, the user will need to deviate from these instructions.
1. Start INCA and you will be presented with a window similar to the following:

Supporting tools
2. Select the menu option Database->New to create a new database. This database will
contain the binary image of the built application and calibration and other items used to
calibrate the OpenECU device.
Type in a suitable name: the example here uses example_database and select OK.
Next, select the menu option Edit->Add->ECU Project (a2l) and browse to your
built application, e.g., step1_tool_inca.a2l. The example shows an older
step1_r12_g800 application.

Supporting tools
Once loaded, the INCA main window updates.

Supporting tools
Next, select the menu option Edit->Add->Workspace and accept the default name, then
select the menu option Project->Add Project/Dataset:
and a new dialog appears. Select the project you just added then OK. The main window
will have updated to show the project in window 5.
Select the offline item in window 5, then select device->new device

Supporting tools
Select an appropriate CCP compatible device. In this example, the PC running INCA has
a ES 580 CAN card attached, so the related CCP item is selected.
3. Next, double click on the workspace item in window 1. If there is an error in the CCP
configuration or in the wiring to the OpenECU device, the INCA log window will show that
INCA could not communicate with the OpenECU device. If this occurs, check the CCP
settings and wiring.

Supporting tools
If the memory pages dialog does not pop-up, the select the menu option Hardware-
>Manage memory pages
Select Flash programming, then do it. If this is the first time INCA has been used or if
OpenECU was installed without the option to Patch INCA, you will be asked to browse
to a ProF configuration file.
Note
The INCA tool makes a distinction between the base calibration (reference page)
and a derived calibration (working page). Be sure to download the reference page
to start with.

Supporting tools
Select the "Install..." button and browse to the install location of OpenECU, .../
tools_integration/inca_prof and select OK.
This will have installed the INCA ProF configuration file for OpenECU. Select it then OK.
This brings up the ProF settings dialog.
Select Flash strategy and calibration (or Flash strategy, calibration and tunes if using
Tunes in your application — the step1 application does not use Tunes), then OK.

Supporting tools
Note
In order to reprogram or Flash the OpenECU device, the OpenECU device must be
in reprogramming mode. For details on how to enter reprogramming mode refer to
Section 4.5, “Programming an ECU”.
This brings up the ProF control flow dialog box which shows the progress of programming
the OpenECU device.
Press Close when it has finished and Close in the manage memory pages dialog.
4. Next, to view a measurable, select the menu option Variables->Select...

Supporting tools
and from the dialog that pops up, select those signals or calibrations to view. Here, the
stp_ect_state signal has been selected and will be updated every 100 milliseconds.

Supporting tools
Select the Configure button, followed by the OK button on the next dialog.
Finally, to display the data of the selected item in real-time, select the menu option
Measurement->Start Visualisation. You will be presented with the current value of
stp_ect_state in real-time.

Supporting tools
At this point, you have managed to connect ETAS INCA to OpenECU, download the step1
application and view one application signal in real-time. Please refer to the ETAS INCA user
manual for more details about how to use INCA.
B.5. Vector CANape

CANape by Vector Informatik GmbH is a calibration tool that can communicate to a CCP
compliant device. It provides facilities for calibration, data logging and display and can be
used with OpenECU.
The following instructions are for version 8.0. Other versions may differ.
The instructions also assume that CANcaseXL is used. If another communications device is
used, the user may need to deviate from these instructions.
1. Start CANape and you will be asked to accept a disclaimer. After this you will see the
following:

Supporting tools
2. Select 'Create new project' and press 'OK'. You will then be asked for a project name.
Enter a suitable name, click 'Next' and then browse to a suitable directory to save the
project, click 'Next' and then 'Finish'. You should now see the following:
Select the menu option Device->New from database... and browse to where your
model_name_canape.a2l file is located and select Open. If the device is connected
correctly and configured with the appropriate baud rate then you should see no errors or
warning. The a2l file contains the CAN configuration as set by the model. It also has the
relevant information for the flash, cal and RAM locations. CANape will use these values
with no further configuration input required from the user.
If CCP seed/key security is required for an operation, the DLL implementing the
appropriate key-generation algorithm must be placed in the same directory as the

Supporting tools
CANape project. Note that CCP seed/key security is disabled by default in the
model_name_canape.a2l file.
Having set up the project (and CCP security if required), select the menu
option Flash->Download file to flash... and browse to your built application, e.g.,
step1_m460_image_small.hex. Depending on the size of the memory region to be
flashed, it may be necessary to increase the flash clear timeout parameter in CANape.
At the bottom left of the window the progress bar should be seen to advance until
programming is complete.
Next, select the menu option Measurement->Measurement configuration... and the

following window will appear:

Supporting tools
The Simulink model name should be visible in the left hand pane under 'Measurement
signals'. Right click on the model name and select 'Insert signal' from the menu that
appears. The Database selection window should then appear, listing all of the model
signals and calibrateable values.

Supporting tools
Double click on each signal of interest so that their text colour changes to blue. Close
both windows and accept changes and you will return to the main window. Now select
the menu option Display->Display windows->Numeric window, an empty numeric display
will appear. Right click on this numeric display and select 'Insert measurement signal...'
the following appears:

Supporting tools
3. Next, right click and select 'Insert signal' on each parameter that you want to monitor in
the numeric window

Supporting tools
To access calibration values select the menu option Display->Calibration windows-

>Calibration window, then scroll down to find calibration parameters and select the ones
that are required.

Supporting tools
At this point, you have managed to connect Vector CANape to OpenECU, downloaded the
step1 application and viewed some signals in real-time. Please refer to the Vector CANape
user manual for more details about how to use CANape.
B.5.1. Configuring CCP seed/key security with Vector

CANape
Some manufacturers may enable CCP seed/key security for certain CCP operations,
particularly in software which is released to production. Configuring this in the application is
discussed in Section 6.1.21, “CCP seed/key security (pcp_CCPSecurity)”.
CCP seed/key security requires that a Win32 DLL is built containing a function which will
generate a key value from a seed value supplied by the ECU. The name and function
prototype are specified in the ASAP1A and ASAP2 standards to be
BOOL SEEDKEYAPI ASAP1A_CCP_ComputeKeyFromSeed (BYTE *Seed, unsigned

short SizeSeed, BYTE *Key, unsigned short MaxSizeKey, unsigned short
*SizeKey); // Seed: Pointer to seed data // SizeSeed:Size of seed
data (length of ‚Seed‘) // Key: Pointer, where DLL should insert
the calculated key data. // MaxSizeKey: Maximum size of ‚Key‘. //
SizeKey: Should be set from DLL corresponding to the number of data //
inserted to ‚Key‘ (at most ‚MaxSizeKey‘) // Result: The value FALSE
(= 0) indicates that the key could not be // calculated from seed data
(e.g. ‚MaxSizeKey‘ is too small). // TRUE (!= 0) indicates success
of key calculation.
Some calibration tools allow different function names to be used, but CANape does not.
Each seed/key algorithm must therefore be provided in a separate DLL and referenced
appropriately. Section 4.3.1.1 "CCP Parameters" of the CANape user manual specifies this
in more detail.

Supporting tools
B.6. FreeCCP
FreeCCP is a command line tool which can program an OpenECU with a built application.
It requires a Vector or Kvaser CAN card.
This tool is provided free and unsupported by OpenECU. Users are permitted to use
this software for commercial and non-commercial purposes.
Note
On 64-bit Windows 7 PCs, FreeCCP does not currently work with Vector interfaces,
but does with Kvaser interfaces.
Note
FreeCCP is now deprecated, and so may be removed from future releases of
OpenECU. Please contact support if you would like a free trial of PiSnoop to get started
with OpenECU, even if you intend to migrate to a third-party calibration tool. See also
Section B.2, “PiSnoop”.
B.6.1. Programming an OpenECU

To program an OpenECU with a built application using a Kvaser CAN card, issue the following
at the command line (if using MATLAB, use the oe_freeccp command instead):
oe_freeccp -kvaser -f <application_name>_image_small.s37
where <application_name> is replaced by the name of the application. For instance, with
the step1 application for the M670 target, the command to issue would be:
oe_freeccp -kvaser -f step1_m670_image_small.s37
Note
The command can be run from either the Windows command line or MATLAB
command line. If running from the Windows command line, add the path to the
freeccp tool to the system PATH environment variable.
B.6.2. Choosing the CAN card device (Kvaser)

The tool supports using a variety of Kvaser CAN cards. To use this interface use the -kvaser
command line option.
oe_freeccp -kvaser -f <application_name>_image_small.s37
B.6.3. Choosing the CAN card device (Vector)

The tool supports using a variety of Vector CAN cards. The tool defaults to using a CANcardX
interface, but can connect to others using the following options: -cancardxl or -pci.

Supporting tools
The options are added to the command for reprogramming, so as an extension to

programming an OpenECU device with the step1 application, choosing the AC2 PCI option
would be:
oe_freeccp -pci -f step1_image_small.s37
B.6.4. Choosing the CCP settings

Without additional command line parameters, the tool uses the default CCP settings from
(Table 6.3, “CCP defaults”. To make the tool use alternative CCP settings, use the following
options:
-croid <standard can identifier>

-dtoid <standard can identifier>
-targetid <station address>
-b <baud rate in kBps>
So for instance, if the CCP settings were:
CCP option Setting

CRO message identifier 400
DTO message identifier 401
Station address 2
CAN baud rate 500 kBps
then the command to issue to download the step1 application using a Vector CAN card
would be:
oe_freeccp -croid 400 -dtoid 401 -targetid 2 -b 500 -f

step1_image_small.s37
CCP seed/key security is not supported by FreeCCP. FreeCCP cannot therefore carry out
operations for which the currently-running application requires security to be unlocked. This
may make it unsuitable for use with production-level software.
B.6.5. Checking that the OpenECU device is active

The tool supports a function to determine if it can communicate with an OpenECU device
or not, rather than programming the device. This can be used to check the wiring between
the OpenECU and CAN card.
To check the CCP connection using a Vector CAN card, issue the command:
oe_freeccp -check

Appendix C. Examples
C.1. Introduction
This chapter gives an overview to some of the OpenECU Simulink examples provided with
the developer software package.
C.2. Custom C code

C.2.1. Introduction
Simulink provides a mechanism to integrate existing or custom C code with a model, usually
with little change to the C code itself. It may be beneficial to mix Simulink and C code for a
number of reasons. For instance:
• when there is an existing body of C code which would take a significant amount of effort
to re-create as a Simulink model;
• when an existing algorithm written in C has been tested and proven to work correctly —
the code is at a mature stage and re-creating the code in Simulink means additional testing
is required;
• when an algorithm written in C code might be more efficient and easier to understand than
the equivalent created using Simulink blocks.
Existing or custom C code can be incorporated into a Simulink model using S-functions. S-
functions can be written in MATLAB, C, C++, Ada, or Fortran and except for the MATLAB
type function, the rest are compiled as a MEX-function using the MATLAB mex utility. An S-
function can be used with Simulink Coder and the code generated by Simulink Coder for S-
functions can be customized by writing a Target Language Compiler (TLC) file.
This section explains how to write and integrate a C type S-function into an OpenECU
Simulink model (OpenECU does not support C++, Ada or Fortran S-functions, or non-inlined
S-functions). S-functions with TLC files, are called inlined S-functions, while S-functions
without TLC files are non-inlined. For OpenECU models, a TLC file is required, which
improves the efficiency of code generation and helps reduce RAM usage.
Note
See “S-Functions and Code Generation” in MATLAB's help section for more
information.
C.2.2. Procedure
To create a S-function, begin by copying the files listed below from the directory:
[OpenECU install directory]\examples\simulink\two_pot_demo_w_sfunction\tpd\
to a data dictionary directory of your model directory:
[your model directory]\[data dictionary directory]
xx_code.h
This file defines the interface to the C source code.

Examples
xx_code_wrapper.c
This file tells MATLAB how to simulate the S-function block.
xx_code_wrapper.tlc
This file tells MATLAB how to generate code for the S-function block.
xx_code.c
This file implement's the user's algorithms as C source code.
rtwmakecfg.m
This file tells MATLAB where the C source code is located.
The xx part of the file name represents the core function of the S-function and it's up to the
user to choose an appropriate name. If multiple S-functions are created then each function
should have a unique set of files.
As the OpenECU model load scripts add each of the data dictionary directories to MATLAB's
path, then by placing the files in a data dictionary directory MATLAB will be able to find the
S-function and the hand-written C code is located.
Note
Some versions of MATLAB and OpenECU cannot correctly deal with paths that include
spaces. Make sure the path of the model directory doesn’t have any spaces (e.g. a good
example is C:\TestModel\drc\; a bad example is C:\Documents and Settings
\Test Model\drc\).
The xx_code.h, xx_code_wrapper.c, xx_code_wrapper.tlc and xx_code.c files

have step by step instructions embedded within the code. Changes will be required to parts
of the code following comments which look like:
/*
*****************************************************************************
* Step n:
* ...
******************************************************************************
*/
The number n is the step number and each step is explained below. Other sections of the
code are generic and do not need to be altered. Follow the steps below in sequence to create
a S-function which implements custom C code.
Begin by editing the xx_code.h file:
a. Replace the literal TPD_CODE_H with a name unique across all source
files, to protect against double inclusion.
b. Define the data types and assign names for the inports and outports of
the S-function.
Note
These are the name that will be used to pass data from Simulink
into the C code and from C code to Simulink via the inports and
outports.
Edit the xx_code_wrapper.c file:
c. Define S_FUNCTION_NAME as the S-function wrapper name.

Examples
d. Include the S-function C code file (i.e xx_code.c).
e. Define the number of arguments, inports and outports used in the S-

function.
Note
In this example, the S-function does not use any input arguments,
so the number of arguments is set to 0. For more information on
how to use input arguments, please refer to the S-function block’s
help section.
f. Define the properties of each inport used in the S-function.
g. Define the properties of each outport used in the S-function.
h. Get hold of storage locations of the data being sent from Simulink to the
S-function via the inports.
i. Get hold of storage locations of the data that is going to be sent to

Simulink from the S-function via the outports.
Note
The port numbers start from 0 and not 1. For more information
on the property functions, search for the section named “Writing
S-functions” or search using the property function name under
MATLAB's help.
j. Pass the data received from Simulink via the inports to the C code.
k. Pass the data received from the C code to Simulink via the outports.
Edit the xx_code.c file.
l. Include the header file for the S-function.
m. Add the variables used in the S-function that need to be calibratable.
Note
The variable should have a four letter prefix with the fourth letter
set to c (e.g. mbec_maximum_engine_speed). See the variable
naming requirements in section Section 5.2.5, “Naming rules”.
n. This is where the main algorithm is going to be located.
Edit the xx_code_wrapper.tlc file:
o. Update %implements directive with the S-function wrapper name.
p. Include the S-function C code header file (i.e xx_code.h).
q. Include the S-function C code file (i.e xx_code.c).
r. Pass the data received from Simulink via the inports to the C code.

Examples
s. Execute the C-code function.
t. Pass the data received from the C code to Simulink via the outports.
After making changes to the source code, do the following:
u. MEX Setup
• Change MATLAB path to the data dictionary directory where the C

files are.
• Issue the command
mex –setup
at MATLAB's command prompt and when prompted with the question:

“Would you like mex to locate installed compilers [y]/n?”, enter Y.
• Then choose the number associated with the desired compiler and
when prompted with the question: “Are these correct?”, enter Y.
Note
This step need to be done once and MATLAB will remember these
settings each time it is opened.
v. Compile and Link Source Files
• Change MATLAB path to the data dictionary directory where the C

files are.
• Issue the command
mex xx_code_wrapper.c
at MATLAB's command prompt.
• If there are no errors, MATLAB will compile and link the source files
into a DLL file but won’t give any confirmation that the compilation
was successful. The DLL file is used by Simulink to create the S-
function block with an appropriate number of inports and outports, and
to perform the C source code algorithms when simulating the model.
• If there are errors, MATLAB will display and errors in the command
window. Fix the errors and re-issue the previous command.
Note
These steps need to be done each time the S-function or algorithm
C code is altered for the new changes to take effect.
w. Run the Model
• Change MATLAB path to the model directory and open the model.
• Insert an S-function block from the User-Defined Function.

Examples
• Double-click on the block to open it. In the S-function Name field insert
the name of the wrapper i.e xx_code_wrapper.
• Click OK and then click update.
• If there has been no problem with the previous steps, the inports and
outports on the S-function block will appear. The block is now ready
to be used when simulating or building the model.
• If the source files were not compiled and linked into a DLL, the
following error will be displayed “Error in S-function 'model directory/
model name/S-function name': S-function 'xx_code_wrapper' does
not exist”.
The S-function is now ready to be used when simulating or building the model. Each time the
C sources are modified, the S-function must be built manually by issing the mex command.
However, it is possible to build the S-function automatically by adding a callback function to

Examples
the S-function block. The advantage is that Simulink invokes the callback before the model is
simulated, updated or built, ensuring the S-function is up to date regardless of whether the C
sources have been altered or not. The disadvantage is that if the C sources are large, there
can be a noticable delay each time the model is updated, simulated or built.
The S-function can be setup with a callback function as follows:
x. Right-click on the S-function block and choose Block Properties.
y. Then choose InitFcn and enter the following commands:
cd ddd
mex xx_code_wrapper.c
cd ..
where ddd is replaced with the name of the data dictionary directory.

Appendix D. Memory configurations
Some OpenECU targets support different configurations of the ECU's application, calibration
and RAM memory sizes, allowing design trade offs to be made whilst developing the
application. There are two broad classes of ECUs:
Fleet ECUs
Lower-cost that developer ECUs due to the lack of run-time calibration support. These
ECUs are intended to be used for fleet trials or production, and are not intended to
be used for bench or dyno activities, especially those that require calibration support.
Typically, fleet ECUs do not include external RAM.
Developer ECUs
Higher-cost that fleet ECUs due to support for run-time calibration. These ECUs are
intended to be used for development activities such as dyno cell calibration or HIL based
testing. Typically, developer ECUs do include external RAM.
M560, M580
The following memory configurations are available.
Table D.1. Memory configurations supported

Configuration App size Cal size RAM External Run-time
(KiB) (KiB) size RAM calibration
(KiB) required? supported?
a
A 2302 128 384 N Y
B 2302 128 384 N N
a
If an OpenECU target that supports memory configuration is loaded with an application in which no such
configuration has been specified, then configuration A will be used as the default.
The M560 currently only supports two configurations: Configuration A and B. Configuration
A supports cal-on-the-fly, Configuration B does not.
Other targets
No other targets support memory configuration.

Appendix E. ASAP2 compliance
The OpenECU generation of ASAP2 files is against a sub-set of version 1.40 of the standard.
Warning
OpenECU does not adhere to the ASAP2 rule which governs the length of identifiers.
OpenECU may generate identifiers with more than 32 characters.

Appendix F. CCP compliance
The OpenECU implementation of CCP is against a sub-set of version 2.1 of the standard
and supports the following commands:
Table F.1. Supported CCP commands

CCP command Command Optional Notes
value
CONNECT 1 Reprogramming code prior to version
5.0.6 and 105.0.11 assumes a station
address of zero or one.
SET_MTA 2 Supports one MTA. Addresses must
not be extended.
DNLOAD 3
UPLOAD 4
START_STOP 6
DISCONNECT 7 Reprogramming code prior to version
START_STOP_ALL 8 yes
SET_S_STATUS 12 yes
GET_S_STATUS 13 yes
BUILD_CKHSUM 14 yes Implements the 16 bit CCITT CRC (shift
register initially set to 0xFFFF, non-
reflected form).
SHORT_UP 15 yes Expects no address extension. Does
not change MTA.
CLEAR_MEMORY 16 yes
GET_SEED 18 yes Not supported before platform version
1.8.6.
UNLOCK 19 yes Not supported before platform version
1.8.6.
GET_DAQ_SIZE 20 Ignores any attempt to set the DAQ
CAN message identifier to anything
other than the DTO CAN message
identifier.
SET_DAQ_PTR 21
WRITE_DAQ 22
EXCHANGE_ID 23 Access to the ECU's type,
manufacturing data, and if available,
the application defined name. See
Section F.1, “EXCHANGE_ID message
handling” for details.
PROGRAM 24 yes If the length to program is specified as
zero, reprogramming code will treat
this as a special signal to indicate that
programming has finished.

CCP compliance

value
GET_CCP_VERSION 27 Returns 2.1.
PROGRAM_6 34 yes
DNLOAD_6 35 yes
Some older versions of software (prior to platform version 1.6.0, or prior to RPRG version
x.6.0) support a larger number of CCP commands. In addition to the commands above, these
older versions also supported the following commands:
Table F.2. Supported CCP commands (in older versions of ECUs)

value
TEST 5 yes Reprogramming code prior to version
GET_ACTV_CAL_PG 9 yes Only one page of calibration is
supported.
SELECT_CAL_PAGE 17 yes Only one calibration page is supported
at a fixed address.
MOVE 25 yes
DIAG_SERVICE 32 Replied to as "unavailable".
ACTION_SERVICE 33 Replied to as "unavailable".
All other commands are replied to as "unknown command".
F.1. EXCHANGE_ID message handling

The ASAP1b standard for CCP defines the EXCHANGE_ID message as follows:
Table F.3. Original EXCHANGE_ID message

Position Type Description
0 byte Command Code = EXCHANGE_ID 0x17
1 byte Command Counter = CTR
2... bytes CCP master device ID information (optional and
implementation specific)
OpenECU will interpret the master device ID information to determine how to setup the
Memory Transfer Address (MTA0) for later uploading.
Table F.4. Modified EXCHANGE_ID message

0 byte Command Code = EXCHANGE_ID 0x17
1 byte Command Counter = CTR
2..4 bytes Ignored
5..6 byte Manufacturing data key

CCP compliance

See Table F.6, “EXCHANGE_ID manufacturing data key
values and binary format”
7 bytes Selection
See Table F.5, “EXCHANGE_ID selection values”
The message is processed by the ECU by inspecting the selection in position 7:
Table F.5. EXCHANGE_ID selection values

Value Description
1 If the ECU contains manufacturing data and the manufacturing data
key in position 5..6 is valid for the ECU, then set the MTA0 to the
address of the manufacturing data in binary format. Valid key values
and the structure of the data is defined in Table F.6, “EXCHANGE_ID
manufacturing data key values and binary format”.
Otherwise, leave MTA0 unmodified and set an appropriate error code
in the response message.
Note that some older M220, M250, M460 and M461 variants do not
contain manufacturing data.
2 If running in application mode then set MTA0 to null terminated ASCII
string defined by the application in the put_Identification block.
Otherwise, sets MTA0 as if the EXCHANGE_ID selection value were
zero.
any other value Set MTA0 to the address of a null terminated ASCII string of the ECU
family. The string has the form “OpenECU-[name]”. For example,
“OpenECU-M220”.
Position 5 (MSB) and 6 (LSB) is interpreted as the manufacturing data identifier:
Table F.6. EXCHANGE_ID manufacturing data key values and binary

format
a b
Position Description
Key = 1, Serial number
0..3 Serial number
Key = 2, Date of manufacture
The date is composed as (shift) dd:mm:yyyy, where the shift identifies the team involved
in the manufacturing process.
0 The team shift at time of manufacture
1 The day of the month of manufacture, range [1, 31]
2 The month of manufacture, range [1, 12]
3..4 The year of manufacture, range [2010, ...]
Key = 3, Engineering part number
The engineering part number matches the pattern: prefix letter engineering-part-number.
For instance, the engineering part number assigned to the M250-000 is '01T068165',
where '01' represents the prefix, 'T' represents the letter and '068165' represents the
engineering part number.
0 The part number prefix, range [0, 99]
1 The part number letter, represented in ASCII, range [A-Z]
2..5 The engineering part number, range [0, 999999]

CCP compliance
a b
Position Description
Key = 4, ECU mod and issue numbers
The issue level represents a specific design of PCB. Changes to the issue level may have
an effect on the software version.
The modification level represents what changes were performed to the PCB after
manufacturing to correct issue level design mistakes. Changes to the modification level
should not have an effect on the software version.
0 The PCB issue level, range [0, 255]
1 The PCB modification level, range [0, 255]
Key = 5, Factory part number
For instance, the factory part number could be '450FT1034', where '450' represents the
part_num[0], 'F' represents the letter[0], 'T' represents the letter[1], and '1034' represents
the part_num[1].
0..1 First number of identifier, range [0, 65535]
2..3 Second number of identifier, range [0, 65535]
4..5 Characters used to separate identifier numbers, represented in ASCII,
range [A-Z]
Key = 6, Factory part number build type
0..1 The factory part number build type, represented in ASCII, range [A-Z]
a
All data is arranged in MSB format.
b
Not all keys are available on all ECUs.

Appendix G. CCP troubleshooting
guide
This section describes a troubleshooting procedure for when CCP communications can not
be established:
• Section G.2, “No communication between PC and ATI Hub”
• Section G.3, “No communication between PC and OpenECU”
This section explains the symptoms and the solution using examples of a system with an ATI
Hub and ATI Vision. Specific issues with ATI products are not addressed in this document as
are issues with other system configurations such as ATI's Kvaser and ETAS' INCA, although
the overall symptoms and resolutions remain the same.
Note
This guide is provided to help diagnose issues when connecting OpenECU with ATI
Vision, and is a reference only. Please direct technical support questions regarding ATI
products, to ATI. Pi can supply support for Pi products only.
If at the end of following this guide, the OpenECU module will not communicate to ATI Vision,
please get in touch with OpenECU technical support (see Appendix K, Contact information).
G.1. Anatomy of an ATI Hub

As a reference to the following troubleshooting guide, this diagram outlines the major
interfaces to the ATI Hub. Please refer to the ATI Vision User Guide for further details.
Power switch
Power LED
Status LEDs
USB connector
Front
Back
Power fuse
Power connector
15 pin D-type
Communications connector

CCP troubleshooting guide
G.2. No communication between PC and ATI

Hub
G.2.1. Symptoms
ATI Vision indicates that the Hub and its components are offline. No transmission data rate
is shown as no data is communicated. In this case, ATI Vision shows red crosses against
“VisionHub”, “VNICAN” and “PCM” while in online mode. The red crosses disappear when
while in offline mode.
G.2.2. Possible causes

There are several potential reasons why there are no communications between the computer
and the ATI Hub. Also see the Help instructions in ATI Vision's User Guide for further
description of how to use the ATI Hub.
G.2.2.1. ATI Hub is not powered up/switched on

Troubleshoot
• Check that the “Power LED” on the ATI Hub is illuminated.
Solution
1. Check that the “Power switch” is in the ON position (pointing upwards).
2. Check that the 12V DC is applied on the power connector at the back of the ATI Hub.
3. Check the fuse at the back of the ATI Hub is intact.
G.2.2.2. ATI Hub is not connected to the computer correctly

Troubleshoot
• Ensure ATI Hub is powered on (see Section G.2.2, “Possible causes”).

Solution
1. Check that the USB cable between the ATI hub and the computer is connected
properly.
2. Ensure that the correct USB driver is installed on the computer (contact ATI Technical
Support for more details about the correct USB driver).
G.3. No communication between PC and

OpenECU
G.3.1. Symptoms
ATI Vision indicates that the PCM is offline. A transmission data rate is shown between the
computer USB and the Vision Hub. In this case, ATI Vision shows a red cross on “PCM”
while in online mode. The red cross disappears and no data transmission rate is reported
while in offline mode.
G.3.2. Possible causes

G.3.2.1. OpenECU module is not powered-up
Troubleshoot
• Visually check for the response from actuators that are driven by the OpenECU
module (lamps, relays, DC motors, etc.) during power-up. When the observed actuator
response is not as expected, then the OpenECU module is not powered up correctly.
• Check that the 5V sensor reference output on the OpenECU module is present. When
the reference line voltage does not match the expected 5V, then the module is not
powered up correctly.

• Measure the current drawn by the OpenECU module (electrical current into all VPWR
input pins). When the total current is less than 250mA, then the module is not powered
up correctly.
Solution
1. When fused, check that all fuses are intact.
2. Check that all VPWR pins have a DC voltage supply of 9V to 16V.
3. Check that all PWRGND connections are connected to ground.
G.3.2.2. OpenECU module is not connected to the ATI Hub

correctly
Troubleshoot
• Ensure OpenECU is powered-up (see Section G.3.2.1, “OpenECU module is not

powered-up”).
Solution
1. Remove all devices from the CAN bus except the OpenECU module and the ATI Hub.
Note
When communications are established, then the cause may be in the
disconnected device(s). Terminating resistors, different CAN baud rate or
clashing CAN message ID's are potential causes. Further investigation will be
required but is outside the scope of this trouble shooting guide.
2. Check the 15 pin D-type connector on the back of the ATI Hub if fixed securely.
3. Check that the ATI CAN connections are fitted correctly. CAN-High (white) and CAN-
Low (blue) are connected to the corresponding pins of the OpenECU module.
G.3.2.3. OpenECU module resets continuously

Troubleshoot

powered-up”).
• Ensure the Hub is connected to the Hub correctly (see Section G.3.2.2, “OpenECU
module is not connected to the ATI Hub correctly”).
Solution
1. Power down the OpenECU module.
2. Apply 18V DC to the FEPS input pin of the OpenECU module (i.e. use an external
power supply between the FEPS pin and ground).
3. Power up the OpenECU module (powering up with 18V applied to the FEPS pin, forces
the OpenECU module to enter reprogramming mode).
4. When communications is established, flash the module with the strategy that is known
to be working. Continue with the following steps:
a. Wait for flashing to complete.

b. Remove the 18V DC power from the FEPS input pin of the OpenECU module.
c. Power cycle the module.
Note
Continuous module resets can be caused by a mistake in the strategy model
(e.g. divide by zero) or when a model takes too long to run in its allotted time
budget (e.g., a 1ms model rate takes longer than 1ms to complete). It is good
practice to review the source model for potential causes of the reset.
5. When communications is not established, the OpenECU module is not resetting

continuously and the problem is potentially with the CAN configuration (see
Section G.3.2.4, “CAN baud rate between OpenECU and ATI disagree” and
Section G.3.2.5, “CCP CRO and DTO values do not agree with OpenECU”).
G.3.2.4. CAN baud rate between OpenECU and ATI disagree

Troubleshoot

powered-up”).
• Ensure the module does not reset continuously (see Section G.3.2.3, “OpenECU
module resets continuously”).
Solution
1. In ATI Vision, right click on “VNICAN” and select the menu option Properties.
2. Select the Settings tab.
3. Select a Bus Frequency of what is expected to match the strategy that is currently
flashed onto the module.
Note
When the version of the latest strategy is known, then the bus frequencies of
that strategy can be found by opening the strategy in ATI Vision and selecting
the menu option File > Properties. The frequency is displayed as “Baudrate” in
the Device Settings tab. If the strategy is unknown, then it will be any of the
following possible frequencies: 33.333, 50, 62.5, 83.333, 100, 125, 250, 500 or
1000 kBps. Select one at a time until communications are established.
4. When communications is still not established, then the most likely cause is a mismatch
of the CRO and DTO vales between the active strategy in the project and the strategy
that is currently flashed onto the module. See Section G.3.2.5, “CCP CRO and DTO
values do not agree with OpenECU” on how to change CRO and DTO values.
5. When communications is established, flash the module with the strategy that has the
new desired bus frequency.
6. Power cycle the module when flashing has completed.
7. In ATI Vision, right click on “VNICAN” and select the menu option Properties.

8. Highlight the Settings tab.
9. Select a “Bus Frequency” of the strategy that is flashed onto the module.
G.3.2.5. CCP CRO and DTO values do not agree with OpenECU
Troubleshoot

powered-up”).
• Ensure the CAN baud rate is correct (see Section G.3.2.4, “CAN baud rate between
OpenECU and ATI disagree”).
Solution
Note
You will need to know the CRO and DTO values of the strategy that was
last successfully flashed onto module. These values can either be found in the
corresponding MATLAB model or from the corresponding strategy (VST) file. Use
steps 2 to 6 below to find out what the existing values are. Because the CRO
and DTO can be any CAN identifier number, it will be very difficult to establish
communications without knowing the values used in the strategy that is currently
flashed onto the modules.
1. Create a copy of the strategy file that needs to be flashed onto the module.
2. Opening it in ATI Vision and selecting the menu option File > Properties.
3. In the Device Settings tab, highlight CRO and press the Edit button. Enter the CRO
number of the strategy that is currently flashed onto the module and select the OK.
4. In the Device Settings tab, highlight DTO and press the Edit button. Enter the DTO
number of the strategy that is currently flashed onto the module and select the OK.
5. Save the modified strategy file.
6. Attach the modified strategy file to the PCM in ATI Vision and make active.
7. When communications is established, flash the module with the strategy.
8. Power cycle the module when flashing has completed (comms should no longer be
established).
9. Attach the version of the strategy file with the original CRO and DTO values to the
PCM in ATI Vision and make active.
G.3.2.6. CCP seed/key has not been configured, or is using

incorrect algorithm(s)
Troubleshoot

powered-up”).

• Ensure the CAN baud rate is correct (see Section G.3.2.4, “CAN baud rate between
OpenECU and ATI disagree”).
• Ensure the CCP CRO and DTO values are correct (see Section G.3.2.5, “CCP CRO
and DTO values do not agree with OpenECU”).
Solution
1. Check the directory where the Vision strategy file is located. If this directory does not
contain a DLL file and the strategy is known to require CCP seed/key security, then
copy the relevant file to this directory.
2. If the directory contains one or more DLL files but CCP seed/key security is still
not available, it is possible that the DLL file in this directory may have the correct
name but the wrong algorithm. (It may be the algorithm for a different manufacturer or
platform, for example). Locate the correct DLL file(s) providing CCP seed/key security
algorithms for this application, and copy the file(s) to this directory.

Appendix H. Data dictionary tool
errors
When the DDE tool generates an error about a DDE, the entry (and possibly related entries)
will not be read into MATLAB's workspace. The user must correct the entry and re-read the
data dictionary into the workspace using the command oe_read_build_list.
When the DDE tool generates a warning about a DDE, the entry will be read into MATLAB's
workspace but some of the attributes about the DDE may be changed. To remove the
warning, the user must change the entry and re-read the data dictionary into the workspace
using the command oe_read_build_list.
H.1. Command line option messages

The interface tool can generate the following error and warning messages when it processes
the command line options presented to the tool.
100. (error 100): unrecognised command line arguments, try -h or --help for
more.
The interface tool has detected that there are command line options which
mean nothing to the tool.
101. (error 101) file 'file name': could not open interface file for reading,
'error message'.
The interface tool could not read the interface file given by 'file name' and
the operating system's reason for not being able to do so is given by 'error
message'. Correct the reason for failure and try again.
102. (error 102) file 'file name': could not open AST debug file for writing,
'error message'.
The interface tool could not create or write to the first debug file called 'file
name' and the operating system's reason for not being able to do so is given
by 'error message'. Correct the reason for failure and try again.
103. (error 103) file 'file name': could not open AST debug file for writing,
'error message'.
The interface tool could not create or write to the second debug file called
'file name' and the operating system's reason for not being able to do so is
given by 'error message'. Correct the reason for failure and try again.
104. (error 104) file 'file name': could not open code file for writing, 'error
message'.
The interface tool could not create or write to the first code file called 'file
105. (error 105) file 'file name': could not open code file for writing, 'error
message'.
The interface tool could not create or write to the second code file called file
name and the operating system's reason for not being able to do so is given

Data dictionary tool errors
106. (error 106) file 'file name': could not open m-script file for writing, 'error
message'.
The interface tool could not create or write to the MATLAB m-script file, call
file name and the operating system's reason for not being able to do so is
107. (error 107) file 'file name': could not open generic ASAP2 file for writing,
'error message'.
The interface tool could not create or write to the generic ASAP2 file called
108. (error 108) file 'file name': could not open INCA ASAP2 file for writing,
'error message'.
The interface tool could not create or write to the ETAS INCA ASAP2 file
called file name and the operating system's reason for not being able to do
so is given by 'error message'. Correct the reason for failure and try again.
109. (error 109) file 'file name': could not open Vision ASAP2 file for writing,
'error message'.
The interface tool could not create or write to the ATI Vision ASAP2 file called
110. (error 110): at least one command option required an ASAP2 file to be
generated but no MAP file or ELF information file was specified. Try -
h or --help for more information.
The interface tool has been asked to generate an ASAP2 file but has not
been told the MAP or ELF information file to derive the addresses of DDEs.
111. (error 111): the asap2 naming pattern must be one of 'prefix_name',
'prefix.name', 'prefix.name_prefix', 'name', 'name_prefix'.
The interface tool has been told to transform the DDE names when
generating an ASAP2 file, but the interface tool does not understand the
transformation required (there are only a few pre-determined transforms).
112. (error 112): the boolean type must be specified as 'u8' or 'float'.
The interface tool has been told to generate ASAP2 boolean types with a
specific type, but the interface tool does not understand the type provided.
113. (error 113): you may specify a Diab or GCC MAP file OR an ELF
information file as input, but not both.
The interface tool has been given more than one of a Diab MAP file, a GCC
MAP file, Diab ddump file, or a GCC objdump file as input but does not know
which to use. Specify only one MAP file or ELF information file as input.
114. (error 114): you cannot specify data dictionary generation using --
output-elf-contents without also specifying an ELF information file to
be read.
Using the command line option --output-elf-contents the interface

tool has been told to generate a data dictionary file from the contents of a
Diab ddump or GCC objdump file (derived from an ELF file) but no such

file has been specified with the --diab-ddumpfile option or --gcc-

objfile option.
115. (error 115) file 'file name': could not open DDE file for writing, 'error
message'.
The interface tool could not write to the data dictionary file given by 'file name'
and the operating system's reason for not being able to do so is given by
'error message'. Correct the reason for failure and try again (the file may be
read-only or locked by another application).
116. (error 116) file 'file name': could not open [type of] file for writing, 'error
message'.
The interface tool could not create or write to the file specified by 'file name'
117. (error 117): you cannot specify address list output using --output-
address-list without also specifying a ELF information file to be read.
The interface tool has been told which file to output the address list to, but
it has not been told which Diab ddump or GCC objdump file to read this
information from.
118. (error 118): the compiler must be 'diab_5_5_1_0', 'diab_5_8', 'diab_5_9',

'diab_5_9_4_8' or 'diab_5_9_6_7'.
The interface tool has been told which compiler is being used, but it does
not recognise the compiler so identified.
119. (error 119) file 'file name': could not open output linker file for writing,
'error message'.
The interface tool could not write to the output linker file given by 'file name'
120. (error 120): to generate a linker file output you must specify the
OpenECU installation base path using the --oe-base-path option.
The interface tool can only output linker file using the --output-linker-
file command line option if the --oe-base-path option is also used to
specify the path to the OpenECU installation.
121. (error 121) file 'file name': could not open linker source file for reading,
'error message'.
The interface tool could not read from the linker source file given by 'file
122. (error 122): the compiler must be specified when outputting a linker file
for the 'target name' target.
For any target that supports more than one compiler, the interface tool needs
to be passed the compiler id using the --compiler-id command line
option when outputting the linker file using the --output-linker-file
option.

123. (error 123): no input program images. Please specify values for --img-
app and --img-cal.
In order to use the --output-s-rec option, the options --img-app and

--img-cal must be specified.
124. (error 124): no diab mapfile. please specify value for --diab-mapfile.
In order to use the --output-s-rec option, the option --diab-mapfile

must be specified.
125. (error 125): could not open s-record file for writing.
The tool tried to create the file specified by --output-s-rec , but failed.
This often means that the file already exists and is read-only, or the file was
specified in a non-existing directory.
126. (error 126): could not open application image file for reading.
The tool tried to read the file specified by --img-app , but failed. This often
means that the file does not exist.
127. (error 127): could not open calibration image file for reading.
The tool tried to read the file specified by --img-cal, but failed. This often
means that the file does not exist.
128. (error 128): could not open linker file excerpt for reading.
The tool tried to read the file specified by --ld-excerpt-file, but failed.
This often means that the file does not exist.
129. (error 129): cannot check data dictionary entity data types using --
check-dde-data-types.
The tool received an error when checking for the ELF file. When using the
--check-dde-data-types option, the ELF file must be specified.
130. (error 130): Unable to validate license.
The tool received an error while verifying the license. Verify that OpenECU
is installed correctly with a valid license.
H.2. File handling messages

200. (error 200): found internal error — attempting to set the handle for file
'filename' a second time.
The interface tool has found in internal error. Please contact OpenECU
support if this error occurs.
201. (error 201) file 'file name': could not close file.
The interface tool could not close the file given by 'file name' after the file
was opened to be read or written to. In this case, the interface tool may leave
a temporary file called 'file name' after the tool completes.
202. (error 202): found internal error — cannot remove file 'file name' when
the type of file is unknown.

203. (error 203) file 'file name': could not delete temporary file.
The interface tool could not close the file given by 'file name' after the file
was opened to be read or written to. In this case, the interface tool may leave
a temporary file called 'file name' after the tool completes.
204. (error 204): found internal error — repeated file registration for 'file
name'.
H.3. ASAP2 generation messages

300. (error 300) file 'file name': could not open map file for reading, 'error
message'.
The interface tool could not read the mapfile given by 'file name' and the
operating system's reason for not being able to do so is given by 'error
3001. (error 3001) file 'file name': label 'name' is not defined by 'map file' but
is required for ASAP2 generation.
The interface tool has read a DDE called 'name' from the DDE file called 'file
name' but cannot find the address of the DDE in the Diab MAP file called
'map file'. This often occurs because there is no extern C variable with the
name 'name' (either because the variable does not exist or because it is not
declared extern).
3002. (error 3002) file 'file name': label 'name' is not defined by 'file' but is
required for ASAP2 generation of DDE 'dde name'.
The interface tool has read a DDE called 'dde name' from the DDE file called
'file name' but cannot find the address of the DDE in the Diab MAP or ddump
file called 'file'. This often occurs because there is no extern C variable with
the name 'name' (either because the variable does not exist or because it
is not declared extern).
3003. (error 3003): found internal error while creating an ASAP2 entry for DDE
'dde name' — no X-axis DDE 'name' found.
'dde name' — no Y-axis DDE 'name' found.
'dde name' — DDE class 'type' is unsupported.
3006. (error 3006): found internal error while searching for an 'os-native'
statement — not found but should be present.

3007. (error 3007): found internal error while searching for task 'name'
required by an ATI shadow table — not found but should be present.
3008. (error 3008): found internal error while creating a unique ASAP2
identifier for DDE 'dde name' — too many unique conversions.
3009. (warning 3009) line 'number' of 'file name': the DDE name 'dde name' is
either too long for an ASAP2 identifier (max 32 characters), or clashes
with another identifier, and has been changed to 'short dde name' for
ASAP2 file generation.
The interface tool has read a DDE file called 'file name' and at line 'number'
has found a DDE called 'dde name' which is too long for an ASAP2 file.
The DDE has been changed to 'short dde name' which is guaranteed to be
unique and be less than 33 characters long.
3010. (warning 3010) file 'file name': label 'name' is not defined by 'map file'
but is required for ASAP2 generation, DDE not added to ASAP2 file.
The interface tool has read a DDE called 'name' from the DDE file called 'file
name' but cannot find the address of the DDE in the Diab MAP file called
'map file'. This often occurs because there is no extern C variable with the
name 'name' (either because the variable does not exist or because it is not
declared extern), or because the DDE file is out of date. The warning does
not stop generation of the ASAP2 file, but the DDE will not be added to the
ASAP2 file.
3011. (error 3011): found internal error while creating an ASAP2 entry for
DDE 'dde name' -- X-axis 'dde' must have at least two elements. (Note
unspecified array size in code is currently read as one element.)
The interface tool needs to generate an ASAP2 axis definition for a

calibration map named 'dde name' but has found an internal error. If this
error occurs, please contact OpenECU technical support.
'dde name' — X-axis DDE 'name' must be 'caxis' Class.

'dde name' — Y-axis DDE 'name' must be 'caxis' Class.

'dde name' -- Y-axis DDE 'name' must be 1-D array.


DDE 'dde name' -- Y-axis 'dde' must have at least two elements. (Note
unspecified array size in code is currently read as one element.)

'%s' — Y-axis DDE '%s' must also be in C-style data dictionary
If the calibration map DDE 'dde name' is declared in a C-style data dictionary
file then the x-axis DDE 'name' must also be declared in a C-style data
dictionary. It is not possible to mix axis and map definitions between prefix
and C style data dictionaries.
DDE 'dde name' — X-axis DDE 'name' must also be in C-style data
dictionary.
If the calibration map DDE 'dde name' is declared in a C-style data dictionary
file then the y-axis DDE 'name' must also be declared in a C-style data
dictionary. It is not possible to mix axis and map definitions between prefix
and C style data dictionaries.
'dde name' -- map array must be array.
The interface tool needs to generate an ASAP2 map definition but has found
an internal error.
'dde name' — 2D array but only Xaxis specified.
The interface tool needs to generate an ASAP2 map definition for a two-
dimensional calibration map DDE 'dde name' but only one axis has been
specified. Both the Xaxis and Yaxis columns must be specified.
'dde name' -- array size incompatible with axis size(s).
The interface tool needs to generate an ASAP2 map definition for a

calibration map DDE 'dde name' but the equivalent C variable does not
match the size of the map axes. For instance, a map with 4 elements in the
x-axis and 10 elements in the y-axis, must have an equivalent C variable
with 40 elements.
3021. (warning 3021) file 'file name': one-dimensional array expected for 'dde
name'; now treated as such.
A DDE called 'dde name' is expected to be a one dimensional array (for

instance, because it's Class column specifies the DDE to be an axis or a
string) but the equivalent C variable is not one dimensional (but should be).
3022. (error 3022): file 'file name': label 'dde name' according to 'file' has more
than 3 final array dimensions.

The interface tool can generate ASAP2 entities with up to 3 dimensions but
no more, because the ASAP2 syntax does not allow further dimensions.
However, the interface tool will break up arrays with more than 1 or 2
dimensions into multiple DDEs of smaller dimension. If this error occurs,
please contain OpenECU technical support.
3023. (error 3023): C-style data dictionary specified in dde_filename not

allowed without ELF information file.
For ASAP2 generation, C-style data dictionaries can only be used if a Diab
ddump or GNU objdumb ELF information file file is also specified (not just
a map file). Otherwise the tool cannot obtain the types and sizes of the
variables detailed in the data dictionary.
'dde name' -- X-axis DDE 'name' must be 1-D array.

3025. (warning 3025): string array 'dde name' had zero size, so a default size
of 'bytes' has been used, hence it may display incorrectly.
The DDE string 'dde name' has an equivalent C variable in the Diab ddump
file with no information about the string's size. The interface tool generates
an entry for the DDE but with a size 'bytes' long which probably does not
match the actual string length. To avoid this, use an explicit array size in the
C declaration.
'dde name' — too many array dimensions for map data.
The interface tool needs to generate an ASAP2 map definition for a

calibration map DDE 'dde name' but the equivalent C variable has more
dimensions than the calibration map.
3028. (warning 3028): the application name, 'name', contains characters

not supported by ASAP2 standards; the application name has been
replaced with 'updated name'.
The application name generated in the ASAP2 file contained characters

that were unacceptable in accordance to ASAP2 standards. The calibration
tool Vector CANape doesn't support use of such ASAP2 files. The C-
API interface tool has been updated to generate ASAP2 files containing
characters of the application name that are in accordance with the
standards.
3332. (error 3332) shadow table references task (task) but that task as not
been declared.
The shadow table entry must reference a declared task. This is the task
which is to carry out the calibration tool writes. Here a task is referenced
which has not been declared.
3333. (error 3333) more than four shadow-table statements are present.
The tool does not currently support more than four shadow table statements.
3334. (warning 3334) shadow table must have number of entries in the range
[1, 256].

The number of entries in the shadow table is not within the supported range.
H.4. Automatic DDE generation messages

400. (error 400): found internal error while searching for an 'os-native'
statement — not found but should be present.
402. (error 402): while creating automatic adaptive DDE 'dde name' an
existing DDE of the same name was found — do not replicate adaptive
DDEs in DDE files.
The interface tool has tried to create an automatic adaptive DDE for the
corresponding DDE named 'dde name' but found that one is already present.
This situation occurs because one of the DDE files contains a definition for
a DDE that the interface tool requires — rename the DDE.
403. (error 403): there is no DDE for the adaptive 'adaptive name'.
The interface tool has read an interface file which declares some adaptive
data using the adaptive-list statement but there is no corresponding
DDE for the 'adaptive name'. Update one of the DDE files to include a
definition of the adaptive data.
404. (error 404): while creating automatic tune DDE 'dde name' an existing
DDE of the same name was found -- do not replicate tune DDEs in DDE
files.
The interface tool has tried to create an automatic Tune DDE for the
corresponding DDE named 'dde name' but found that one is already present.
This situation occurs because one of the DDE files contains a definition for
a DDE that the interface tool requires — rename the DDE.
405. (error 405): there is no DDE for the tune 'tune name'.
The interface tool has read an interface file which declares some Tune data
using the tune-list statement but there is no corresponding DDE for
the 'tune name'. Update one of the DDE files to include a definition of the
adaptive data.
406. (error 406): found internal error — could not find 'named' node.
407. (error 407): found internal error — could not find 'named' declaration.
H.5. Interface file messages

500. (error 500) line 'number' of 'file name': incomplete string literal, or
string literal containing unsupported characters.
The interface tool has read an interface file called 'file name' and found an
error at line 'number' containing a string without a closing quote, or a string

containing unsupported characters (only the printable ASCII characters are

valid (ranging from character 32 (space) through to character 126 (tilde)).
Change the interface file to contain a valid string.
501. (error 501) line 'number' of 'file name': incomplete comment.
error at line 'number' containing a comment without the final */ characters.
Change the interface file to complete the comment.
502. (error 502) line 'number' of 'file name': unexpected character 'letter'.
error at line 'number' containing text which the tool does not expect to see.
503. (error 503) line 'number' of 'file name': could not read number.
The interface tool has read an interface file called 'file name' and at line
'number' the interface tool could not convert the text into a number. Adjust
the number to be valid and in the range [0, 2147483647].
504. (error 504) line 'number' of 'file name': number must be positive.
'number' the interface tool found an unexpected negative number. Adjust the
number to be in the range [0, 2147483647].
505. (error 505) line 'number' of 'file name': number must be less than
2147483648.
'number' found a number which was too large. Adjust the number to be in
the range [0, 2147483647].
506. (error 506) line 'number' of 'file name': cannot use the '-' character in
an identifier.
The interface tool has read an interface file called 'file name' and found a
'-' character as part of an identifier at line 'number'. Rename the identifier
without the '-' character.
600. (error 600): found internal error — unexpected error.
601. (error 601) line 'number' of 'file name': repeated identifier.
'number' has found an identifier that has been used elsewhere in the
interface file. All identifiers must be unique.
602. (error 602) line 'number' of 'file name': identifier is more than 31
characters in length.
'number' has found an identifier with more than 31 characters. All identifiers
must be limited to a maximum of 31 characters.
603. (error 603) line 'number' of 'file name': unexpected input.
'number' has found a syntax error.

604. (error 604) line 'number' of 'file name': unexpected end of file.
'number' has encountered the end of the file while still expecting to see more
detail in the interface file. This may occur if there is a missing close brace
(}) in the file.
H.6. DDE processing messages

700. (error 700) file 'file name': could not open tabbed DDE file for reading,
'error message'.
The interface tool could not read the DDE file named 'file name' and the
800. (error 800) file 'file name': could not open units file for reading, 'error
message'.
The interface tool could not read the units file named 'file name' and the
900. (error 900) line 'number' of 'file name': from within the 'compound'
statement, there is a missing 'assignment' statement.
The interface tool has read an interface specification file called 'file name'
and at line 'number' has found a compound statement with a missing
assignment statement called 'assignment'. In this case, the interface tool
is expecting the assignment statement to be present (i.e., the assignment
statement is not optional).
901. (error 901) file 'file name': within the interface file, there is a missing
'compound' statement.
The interface tool has read an interface specification file called 'file name'
and at line 'number' has found that the file is missing a compound statement
called 'compound'. In this case, the interface tool is expecting the compound
statement to be present (i.e., the statement is not optional).
1001. (error 1001): line 'number' of 'file name': 'dde name' is an invalid name
for a data dictionary entry (must be greater than 3 characters long).
All data dictionary entry names must be greater than 3 characters long.
Change the name so it is at least 4 characters in length.
for a data dictionary entry (must be less than 256 characters long).
for a prefix-style data dictionary entry (must not start with a digit or a
'_' character).
To provide compatibility with Simulink, prefix-style DDE names must not start
with an underscore. To provide compatibility with Simulink and C compilers,
prefix-style DDE names must not start with a digit.
for a prefix-style data dictionary entry (must only use characters 'a'
through 'z', 'A' through 'Z', '0' through '9' or '_').

Simulink and many C compilers disallow certain characters to appear in

signal and variable names. Change the name to avoid the use of these
characters.
for a calibration map (must end in '_x' or '_y' or '_z').
The tool has recognised that the DDE forms part of a calibration map but
does not conform to the rules for naming these entities. See Section 5.2.5,
“Naming rules” for more details.
for an item which is not a calibration map (must not end in '_x' or '_y'
or '_z').
The tool has recognised that the DDE does not form part of a calibration
map and does not conform to the rules for naming these entities. See
Section 5.2.5, “Naming rules” for more details.
1007. (error 1007): line 'number' of 'file name': 'dde name' is a calibration but
has no value.
The entry is a calibration of some sort but does not contain a default
calibration value, which it must do.
1008. (error 1008): line 'number' of 'file name': 'dde name' has an invalid value
'text of value'.
The tool could not convert the text of the value into a numeric value. All
numeric values must be scalar and represent a real value. The following are
examples of valid values: 3.14, 10, 10., .001, 1e8, 3.14e-10, 0e0.
1009. (error 1009): line 'number' of 'file name': 'dde name' must be a vector
or a matrix surrounded by '[' and ']').
The tool has recognised that the entry forms part of a calibration map but
that the value or values supplied are not valid expressions, either of a vector
or of a matrix. Values for an axis (_x or _y) should be given as a vector.
Values for the data points (_z) should be given as a vector for 1-d maps or
as a matrix for 2-d maps.
vector
A vector takes the form [numbers separated by spaces]. An example of
a vector containing three elements would be: [10, 15, 20].
matrix
A matrix takes the form [vectors separated by semicolons]. An example
of a matrix containing three rows and columns would be: [1 2 3; 10 20
30; 100; 200; 300].
1010. (error 1010): line 'number' of 'file name': the row sizes for 'dde name'
differ."
The tool requires map axes and map data to match in size. For instance,
a 1-d map with 5 elements in the x-axis, requires 5 elements in the z-data.
Change the axis and data elements to match in size.
1011. (error 1011): line 'number' of 'file name': the row size for 'dde name'
must be at least 2 entries.

The tool requires that map axes and map data have at least 2 elements. For
instance, if a 1-d map had 1 element for the x-axis and therefore 1 element
for the z-data, the map lookup would be equivalent to a constant block.
1012. (error 1012): line 'number' of 'file name': the row data for 'dde name'
must be 1xN matrix.
The tool requires that any map axis be a vector (a 1xN matrix), the OpenECU
1-d and 2-d map lookup blocks do not work with other sized matrices.
1013. (error 1013): line 'number' of 'file name': the units for 'dde name' is too
long (must be less than 'number' characters long).
The units field must be less than 32 characters long by default so that it can
be exported into other file formats (e.g., ASAP2 file) without issues. Either
change the units so it contains less than 32 characters, or change the limit
using the Simulink Model Configuration Option 'Maximum data dictionary
entry name length'.
1014. (error 1014): line 'number' of 'file name': the units for 'dde name' cannot
contain single quote characters.
The units field must not contain single quote characters so that it can be
exported into other file formats (e.g., ASAP2 file) without issues.
1015. (error 1015): line 'number' of 'file name': the units for 'dde name' cannot
contain double quote characters.
The units field must not contain double quote characters so that it can be
1016. (error 1016): line 'number' of 'file name': the description for 'dde name'
is too long (must be less than 256 characters long).
The description field must contain less than 256 characters so that it can be
cannot contain single quote characters.
The description field must not contain single quote characters so that it can
be exported into other file formats (e.g., ASAP2 file) without issues.
cannot contain double quote characters.
The description field must not contain double quote characters so that it can
be exported into other file formats (e.g., ASAP2 file) without issues.
1019. (error 1019): line 'number' of 'file name': 'dde name' has an unspecified
type (must be one of: int8_T, S8, uint8_T, U8, int16_T, S16, uint16_T,
U16, int32_T, S32, uint32_T, U32, real_T, F32, BOOL).
The type of the DDE must be one of the types that MATLAB/Simulink/RTW
supports so that simulation and code generation can occur without error.
See Section 4.2.2.2, “Data dictionary files” for more.
1020. (error 1020): line 'number' of 'file name': 'dde name' has an invalid
type 'type text' (must be one of: int8_T, S8, uint8_T, U8, int16_T, S16,
uint16_T, U16, int32_T, S32, uint32_T, U32, real_T, F32, BOOL).

The type of the DDE has been specified but it is not one of the types
supported by MATLAB/Simulink/RTW. See Section 4.2.2.2, “Data dictionary
files” for more.
1021. (error 1021): line 'number' of 'file name': 'dde name' represents map
calibration data and must have a real_T or F32 type.
OpenECU 1-d and 2-d map lookup blocks only work with floating point types
(integer types are unsupported in these blocks). Change the type of the map
axis or map data to be real_T or F32.
number 'x' for the accuracy column.
The tool was expecting to find a number in the accuracy field but found
something else instead.
1023. (error 1023): line 'number' of 'file name': 'dde name' has a maximum
value but no minimum.
The tool expects to see both a minimum and a maximum for the DDE if
one or the other is present. The DDE must either have no minimum and
maximum specified or both.
1024. (error 1024): line 'number' of 'file name': 'dde name' has a minimum
value but no maximum.
The tool expects to see both a minimum and a maximum for the DDE if
one or the other is present. The DDE must either have no minimum and
maximum specified or both.
number 'x' for the minimum value.
The tool was expecting to find a number in the minimum field but found
1026. (error 1026): line 'number' of 'file name': 'dde name' has boolean type
so its minimum must be zero.
The type of the DDE is a boolean, so the minimum value must be zero but
the tool found a different value for the minimum field.
number 'x' for the maximum value.
The tool was expecting to find a number in the maximum field but found
1028. (error 1028): line 'number' of 'file name': 'dde name' has boolean type
so its maximum must be one.
The type of the DDE is a boolean, so the maximum value must be one but
the tool found a different value for the maximum field.
number 'x' for the scale value.
The tool was expecting to find a number in the scale field but found

number 'x' for the offset value.
The tool was expecting to find a number in the scale field but found
1032. (error 1032): line 'number' of 'file name': 'dde name' has a different
matrix size from the X-axis matrix size.
The tool has detected that the z-data matrix size in for the x-axis differs in
size from the x-axis. The size of the axes and data must match.
1033. (error 1033): line 'number' of 'file name': 'dde name' has a different
matrix size from the Y-axis matrix size.
The tool has detected that the z-data matrix size in for the y-axis differs in
size from the y-axis. The size of the axes and data must match.
1034. (error 1034): line 'number' of 'file name': 'dde name' has multiple rows
but no Y-axis data dictionary entry.
The tool has detected that the z-data for a map contains data for both the x
and y axes but no y-axis DDE has been declared.
1035. (error 1035): line 'number' of 'file name': 'dde name' does not have a
corresponding X-axis data dictionary entry.
The tool has detected that there is z-data for a map lookup but no
corresponding x-axis DDE has been declared.
1036. (error 1036): line 'number' of 'file name': 'dde name' must be a scalar.
The tool has read more than one value for the scalar calibration. Only one
value can be specified.
1037. (error 1037): line 'number' of 'file name': an unnamed column was found
— skipping entire data dictionary.
The tool has found a column without a name. This can occur if two tab
characters are placed next to each other
Name Value Units Description Type Accuracy Min Max Offset

Scale Cref
1038. (error 1038): line 'number' of 'file name': column 'name' is only allowed
in 'style'-style data dictionaries — skipping entire 'style'-style data
dictionary.
The tool has found a column in the title line of the data dictionary that it does
not recognise. The only valid column names in a prefix-style data dictionary
file are:
Name Value Units Description Type Enums Accuracy Min Max

Offset Scale Cref
The only valid column names in a C-style data dictionary file are:
Name Units Description Accuracy Min Max Offset Scale

Class Xaxis Yaxis Lookup
1039. (error 1039): line 'number' of 'file name': 'dde name' is an invalid Cref
for a data dictionary entry (must not start with a digit).

The tool has found an invalid name for the Cref column. This is an internal
error. Please contact OpenECU support.
1040. (error 1040): line 'number' of 'file name': 'dde name' is an invalid Cref
for a data dictionary entry (must only use characters 'a' through 'z', 'A'
through 'Z', '0' through '9' or '_').
The tool has found an invalid name for the Cref column. This is an internal
error. Please contact OpenECU support.
1041. (error 1041): line 'number' of 'file name': 'dde name' is a reserved name
for a data dictionary entry (must not use the 'mpl' prefix).
The tool has found a DDE with a name which starts with mpl. This prefix
is reserved for OpenECU use. Rename the DDE variable using a different
prefix.
1042. (error 1042): line 'number' of 'file name': the 'field_name' field must
be present in [style]-style data dictionaries — skipping entire data
dictionary.
The tool has found the title line but could not locate all the necessary fields/
columns. At a minimum, the following fields/columns must be present in
prefix-style data dictionaries:
Name Value Units Description Type Min Max
And for C-style data dictionaries, the following fields/columns must be

present:
Name Units Description Class Min Max
In both cases, the Name field must be first.
1043. (error 1043): line 'number' of 'file name': 'dde name' is an invalid [object]
name for a data dictionary entry (must be greater than 3 characters
long).
All data dictionary entry enumeration names must be greater than 3

characters long. Change the name so it is at least 4 characters in length.
name for a data dictionary entry (must be less than 'number' characters
long).
Some versions of Simulink and some C compilers disallow names that

contain more than 31 characters. Some ASAP2 calibration tools disallow
names that contain more than 32 characters. Either change the name so it
contains less than the character limit, or change the limit using the Simulink
Model Configuration Option 'Maximum data dictionary entry name length'.
name for a data dictionary entry (must not start with a digit or a '_'
character).
Simulink and C compilers disallow names that start with a digit or '_'
character. Change the DDE name to start with a letter.
name for a data dictionary entry (must only use characters 'a' through
'z', 'A' through 'Z', '0' through '9' or '_').

Simulink and C compilers disallow certain characters to appear in names.

Change the name to avoid the use of these characters.
name for a data dictionary entry (must not end in '_x' or '_y' or '_z').
The tool has recognised that the referenced enumeration looks like a map
DDE. Rename the enumeration reference so it does not end like a map.
1048. (error 1048): line 'number' of 'file name': 'dde name' is a reserved name
for a data dictionary enumeration entry (must not use the 'mpl' prefix).
The tool has found a DDE with an enumerated name which starts with mpl.
This prefix is reserved for OpenECU use. Rename the DDE variable using
a different prefix.
1049. (error 1049): line 'number' of 'file name': 'dde name' uses an
enumeration 'enum name' that is not declared in any data dictionary.
The tool has found an enumeration reference for the DDE named 'dde name'
that does not exist in any data dictionary. Change the enumeration reference
to a data dictionary entry that does exist.
1050. (error 1050): line 'number' of 'file name': 'dde name' uses an
enumeration 'enum_name' which has a non-scalar value.
The tool has found a reference to an enumeration which has a non-scalar

value. All enumerations must be single valued entries.
1051. (error 1051): line 'number' of 'file name': 'dde name' uses enumerations
'enum_name' and 'enum_name' which have the same value.
The tool has found a data dictionary entry which refers to two enumerations
but both enumerations have the same value. Enumerations for one data
dictionary entry must have unique values.
1052. (error 1052): line 'number' of 'file name': 'dde name' has a value less
than its type allows.
The tool has found a value for a data dictionary entry which has a value
outside the range of its type.
1053. (error 1053): line 'number' of 'file name': 'dde name' has a value greater
than its type allows.
The tool has found a value for a data dictionary entry which has a value
outside the range of its type.
1054. (error 1054): line 'number' of 'file name': 'dde name' must not have a
scale value of zero.
The tool has found a DDE with a scaling factor of zero. This is disallowed, as
the reciprocal of the factor is used by OpenECU tools and calibration tools.
1055. (error 1055): line 'number' of 'file name': 'dde name' has no
corresponding DDE called 'z-data dde name'.
The tool has found a x-axis DDE without a corresponding z-axis DDE, both
are needed to create a 1-d map.

1056. (error 1056): line 'number' of 'file name': 'dde name' has no
corresponding DDE called 'z-data dde name'.
The tool has found a y-axis DDE without a corresponding z-axis DDE, both
are needed to create a 2-d map.
1057. (error 1057): line 'number' of 'file name': 'dde name' is a displayable
with a value.
The tool has found a displayable DDE with a value, only calibration DDEs
can have values.
1058. (error 1058): line 'number' of 'file name': 'dde name' has a minimum
smaller than its type allows.
The tool has found a DDE which has a minimum value less than the type of
the DDE can store. The minimum or type must be adjusted.
1059. (error 1059): line 'number' of 'file name': 'dde name' has a maximum
larger than its type allows.
The tool has found a DDE which has a maximum value greater than the type
of the DDE can store. The maximum or type must be adjusted.
1060. (error 1060): line 'number' of 'file name': 'dde name' has duplicated
enumeration 'enum name'."
The tool has found a DDE which has a repeated enumeration in the DDE's
enumeration list. Duplicated enumerations are disallowed.
1061. (error 1061): line 'number' of 'file name': 'class' is an invalid Class for
a data dictionary entry (must be one of: 'c', 'cmap', 'caxis', 'cstring',
'carray', 'd', 'darray').
The string 'class' given in the Class column is not one of the allowed types
for this DDE.
1062. (error 1062): line 'number' of 'file name': enum 'c identifier' has an
invalid byte size = 'bytes'.
The interface tool has found an enumeration with name 'c identifier' which
has a byte size it does not recognise. If this error occurs please contact
OpenECU technical support.
1063. (error 1063): line 'number' of 'file name': variable 'c identifier' is a
pointer; this is not supported for ASAP2 generation.
The interface tool can generate ASAP2 files but ASAP2 files cannot
represent pointers. DDE references to C variables which have pointer type
are therefore rejected.
1064. (error 1064): line 'number' of 'file name': variable 'c identifier' is a
bitfield; this is not supported for ASAP2 generation.
The interface tool cannot yet generate ASAP2 files that access bitfields.
Adjust the data structure to avoid using bitfields or copy the bitfields of
interest to other variables which are accessible.
1065. (error 1065): line 'number' of 'file name': variable 'c identifier' has a type
not currently supported for ASAP2 generation of 'value'.

The interface tool has found type information for a C variable that it does
not know how to handle. If this message occurs, please contact OpenECU
technical support.
1066. (error 1066): line 'number' of 'file name': variable 'c identifier' has class
cstring but is not a byte array.
A C-style DDE has been classed as a string but the type of the equivilent C
variable is not signed or unsigned char (wide characters are not supported).
Either change the C variable to have an appropriate type of change the class
of DDE.
1067. (error 1067): line 'number' of 'file name': variable 'dde name' is not class
cmap yet has Xaxis, Yaxis and/or Lookup entries.
A C-style DDE has information in the Xaxis, Yaxis or Lookup columns but the
DDE is not a calibration map. Only calibration maps should have information
in the Xaxis, Yaxis or Lookup columns.
1068. (error 1068): line 'number' of 'file name': variable 'dde name' used in
map must have real_T (float) type.
OpenECU 1-d and 2-d map lookup blocks only work with floating point types
(integer types are unsupported in these blocks). Change the type of the map
axis or map data to be real_T or F32.
1069. (error 1069): line 'number' of 'file name': variable 'dde name' has
Lookup entry 'name' which caused an unexpected error.
An internal error has occurred in the interface tool. If this error occurs, please
contact OpenECU technical support.
1070. (error 1070): line 'number' of 'file name': variable 'dde name' has x and
y Lookup entries 'string' but no Yaxis entry.
The calibration map with 'dde name' is 2d and has an x-axis Lookup DDE
but no y-axis Lookup DDE. Calibration maps must have a lookup DDE for
each map axis.
Lookup entry 'name' which is not found in ELF data.
The lookup DDE 'name' for calibration map DDE 'dde name' doesn't exist in
the Diab ddump file. Check that the spelling is correct, that the equivalent C
variable is declared and not optimised away by the compiler.
Lookup entry 'name' which has no corresponding DDE, removing
lookup variables from map.
The lookup DDE 'name' for calibration map DDE 'dde name' doesn't exist
as a DDE in any of the other DDE files. The lookup DDE must be declared
in one of the DDE files.
Lookup entry 'name' which does not have Class 'd'.
The lookup DDE 'name' for calibration map DDE 'dde name' is declared
as something other than a displayable (Class column set to 'd'). Only
displayable variables can be used as lookups to calibration maps.

Lookup entry 'name' which does not have type real_T (float).
The lookup DDE 'name' for a calibration map DDE 'dde name' must have
single precision floating point type to correctly match the C-API to the map
lookup functions.
1075. (error 1075): line 'number' of 'file name': variable 'dde name' has Xaxis
and Yaxis but only one Lookup entry; should have nothing or two.
The calibration map with 'dde name' is 2d and has one lookup DDE.
Calibration maps must have a lookup DDE for each map axis. Check that
the Lookup column does not specify only a y-axis lookup DDE.
1076. (error 1076): line 'number' of 'file name': 'dde name' is not found in the
ELF information file output, contains an out of range array index, or is
declared but not referenced in the source code.
A DDE is declared in the data dictionary but the corresponding varaible could
not be found in the Diab ddump or GNU objdump output file. Check the name
for spelling mistakes or add the corresponding variable to the application C
code.
1077. (error 1077): line 'number' of 'file name': map variable 'dde name' has
no Xaxis or Yaxis specified.
A calibration map specified by a C-style DDE has neither the Xaxis and Yaxis
DDEs specified. A 1d calibration map must have the Xaxis specified, a 2d
calibration map must have both the Xaxis and Yaxis specified.
1078. (error 1078): line 'number' of 'file name': 'dde name' is not found in
the ddump ELF file output, contains an out of range array index, or is
declared but not referenced in the source code.
The name for a C-style data dictionary entity wasn't present in the final linked
application image and therefore cannot be processed. Check the name for
spelling mistakes or add the corresponding variable to the application C
code.
for a C-style data dictionary entry (must resolve to a C identifier).
The name for a C-style data dictionary entity doesn't conform to the allowed
scheme. The name of the DDE must be changed.
Lookup entry 'string' but should have one identifier or two separated
by a comma.
The Lookup column for DDE 'dde name' has an unexcepted value of 'string'.
Instead the Lookup column should have one DDE name or two DDE names
separated by a comma.
1081. (error 1081): line 'number' of 'file name': unexpected information at end
of line — skipping entire data dictionary.
The tool has found a DDE line containing more information that there are
columns. Remove the additional information and tab characters, or declare
an additional column in the title line of the DDE file.
for a C-style data dictionary entry (must not start with a digit character).

To provide compatibility with C compilers, C-style DDE names must not start
with a digit.
for a C-style data dictionary entry (must only use characters 'a' through
'z', 'A' through 'Z', '0' through '9' or '_', '.', '[', ']').
The interface tool accepts a subset of the C lanaguage syntax for variable
names, array and structure member access.
1085. (error 1085): line 'number' of 'file name': column 'name' is unrecognised
— skipping entire data dictionary.
The tool has found a column with a name it does not recognise, i.e., not one
of the allowed column names. The only valid column names in a prefix-style
data dictionary file are:
Name Value Units Description Type Enums Accuracy Min Max

Offset Scale Cref
The only valid column names in a C-style data dictionary file are:
Name Units Description Accuracy Min Max Offset Scale

Class Xaxis Yaxis Lookup
1086. (error 1086): line 'number' of 'file name': DDE 'dde name' has Lookup
entry 'string' but should have none, one or two identifiers separated
by a comma.
The Lookup column for DDE 'dde name' has an unexcepted value of 'string'.
Instead the Lookup column should have one DDE name or two DDE names
separated by a comma.
1087. (error 1087): line 'number' of 'file name': 'dde name' is a constant but
has no value.
The entry is a constant but does not contain a default value, which it must do.
1100. (error 1100) file 'file name': could not open 'ELF-type' output file for
reading, 'error message'.
The interface tool could not read the Diab ddump or GNU objdump file
named 'file name' and the operating system's reason for not being able to do
so is given by 'error message'. Correct the reason for failure and try again.
1101. (error 1101): file 'file name': variable with no name attribute in ELF
information file at line 'number'.
The interface tool has found an unnamed attribute in the Diab ddump or
GNU objdump file, something the tool was not expecting. If this error occurs
please contact OpenECU technical support.
1102. (error 1102): file 'file name': 'object' with no type attribute in ELF
The interface tool has found a variable or typedef declaration without

additional type information in the Diab ddump or GCC objdump file,
something the tool was not expecting. If this error occurs please contact
OpenECU technical support.

1103. (error 1103): file 'file name': referenced ID not found in ELF information
file at line 'number'.
The interface tool has found a reference in the ELF information file with
no corresponding entry, as if the Diab ddump or GNU objdump file was
incomplete. If this error occurs please contact OpenECU technical support.
1104. (error 1104): file 'file name': nested array in ELF information file at line
'number'.
The interface tool has found a nested array reference in the Diab ddump or
GNU objdump file, something the tool was not expecting. If this error occurs
1105. (error 1105): file 'file name': structure element with unreadable offset
in ELF information file at line 'number'.
The interface tool has found a structure member in the Diab ddump or GNU
objdump file but could not read the offset information, something the tool
was not expecting. If this error occurs please contact OpenECU technical
support.
1106. (error 1106): file 'file name': structure element with no offset in ELF
The interface tool has found a structure member that the Diab ddump or
GNU objdump file has no offset information for, something the tool was not
expecting. If this error occurs please contact OpenECU technical support.
1107. (error 1107): file 'file name': variable with no byte size in ELF
The interface tool has found a variable without size information in the Diab
ddump or GNU objdump file, something the tool was not expecting. If this
error occurs please contact OpenECU technical support.
1108. (error 1108): file 'file name': DIE with two identically named attributes
found.
The interface tool has found two identically named attributes in the contents
of the Diab ddump file 'file name'. This is an unexpected condition, please
contact OpenECU technical support if this message occurs.
1109. (error 1109): file 'file name': two DIEs with same tag 'name' found in
ELF information file.
The interface tool has found two identically named DIEs in the contents of
the Diab ddump or GNU objdump file 'file name'. This is an unexpected
condition, please contact OpenECU technical support if this message
occurs.
1110. (error 1110): auto-generated data dictionary output from the C-API has
been fed back in as input; this is disallowed to avoid the possibility of
attempting to write a file which is simultaneously being used as input.
The interface tool rejects attempts to read the autogenerated data dictionary
file the interface tool itself generates. Instead, the autogenerated data
dictionary entities of interest should be copied to a separate data dictionary
file and included.
1112. (error 1112): file 'file name': no match for 'dde name' in ELF information
file.

The interface tool found an array which was too small or could not find
an array element while decoding the 'dde name' DDE. Check that the 'dde
name' exists as a C variable and that the variable has not been optimised
away by the compiler.
file — array bound exceeded.
The interface tool has found a matching C variable for the DDE 'dde name'
but one of the array range specifiers in the DDE is outside the bounds of the
equivalent array range of the C variable.
1114. (error 1114): file 'file name': unexpected section type 'name' in ELF
information file.
The interface tool found an ELF section in the Diab ddump or GNU objdump
file it wasn't expecting. If this error occurs, please contact OpenECU
technical support.
1115. (error 1115): file 'file name': no debug variables or section information
found in ELF information file — is this a Diab 5.5.1.0 (or later) ddump
-Dht file?
The interface tool could read the Diab ddump or GNU objdump file but did
not find any C variable or ELF section information. Check that the correct
file was specified in the command line options.
file.
The interface tool could not find information about DDE 'dde name' in the
Diab ddump or GNU objdump output file. This may occur if there is no
equivilent C variable with the same name as the DDE.
1117. (error 1117): line 'number' of file 'file name': 'dde name' has an invalid
number 'number' for the sample rate value.
The interface tool expects the sample rate value to be a natural integer.
1118. (error 1118): line 'number' of file 'file name': the group for 'dde name'
cannot contain single quote characters.
The interface tool expects each group name to avoid the use of the single
quote character ', to avoid issues with ASAP2 validation by calibration tools.
cannot contain double quote characters.
The interface tool expects each group name to avoid the use of the double
quote character ", to avoid issues with ASAP2 validation by calibration tools.
is invalid (group must start with a '/' character).
The interface tool expects each group name to be empty or start with a /
character denoting the top of the hierachy. In this case, the group is not
empty, change the group string to start with a / character.
1121. (error 1200): line 'number' of file 'file name': there must be no more than
8 DAQ rasters defined for CCP messaging.

The platform software does not support more than 8 DAQ rasters. Reduce
the total number of rasters to 8 or less.
1122. (error 1201): line 'number' of file 'file name': the total size of the CCP
DAQ rasters must be no more than 254.
The CCP protocol does not support more than 254 ODTs for all of the defined
rasters. Reduce the size of each raster to total less than the allowed limit.
1123. (error 1202): line 'number' of file 'file name': the CCP DAQ raster name
'%s' must not be repeated.
When generating an ASAP2 file, the interface tool requires that the name of
each CCP DAQ raster is unique. This avoids situations where a calibration
tool displays the same raster name for different rasters, making the selection
of raster ambiguous.
1124. (error 1203): line 'number' of file 'file name': the CCP DAQ raster named
'raster-name' must have a rate not smaller than 5 milliseconds.
The platform software supports CCP DAQ rasters with a base period of 5
milliseconds. Increase the raster rate to be at least 5 milliseconds.
'raster-name' must have a rate not exceeding 10 seconds.
The platform software supports CCP DAQ rasters with a maximum period
of 10 seconds. Reduce the raster rate to at least 10 seconds.
'raster-name' must have a rate that is a multiple of 5 milliseconds.
The platform software supports CCP DAQ rasters with a period resolution
of 5 milliseconds. Adjust the raster rate to be a multiple of 5 milliseconds.
'%s' must have have at least one ODT.
The platform software does supports CCP DAQ rasters with one or more
ODTs. Increase the raster size to at least 1.
1128. (warning 1207): line 'number' of file 'file name': the CCP DAQ raster rate
'%s' is repeated and may confuse some calibration tools.
Not all calibration tools support multiple CCP DAQ rasters with the same
periodic rate (for example, INCA v.5.1.2). Workaround the calibration tool
issue by changing the periodic rates of rasters to differ.
2001. (warning 2001): line 'number' of 'file name': 'dde name' has type 'type'
which supports at most 'x' digits of display after the decimal point.
The tool has detected that the type of the element can support a certain
number of digits after the decimal point, but the DDE accuracy field asks
for more digits to be displayed. The tool reduces the number of digits to be
displayed after the decimal point to the maximum supported by the type.
2002. (warning 2002): line 'number' of 'file name': 'dde name' has a value less
than the minimum specified.
The minimum specified for the DDE is greater than the minimum value given.
The minimum field is adjusted to the minimum of the values.

2003. (warning 2003): line 'number' of 'file name': 'dde name' has a minimum
greater than the maximum.
The tool was expecting to see a minimum value less than the maximum
value but this was not the case.
2004. (warning 2004): line 'number' of 'file name': 'dde name' has a value
greater than the maximum specified.
The maximum specified for the DDE is greater than the maximum value
given. The maximum field is adjusted to the maximum of the values.
2005. (warning 2005): file 'file name': repeated unit 'units'.
The tool has read the unit 'units' more than once. The redundant copy (or
copies) can be removed from the units file.
2006. (warning 2006): file 'file name': empty units file.
A units file is present but it contains no unit definitions (the file contains
whitespace or comments only).
2007. (warning 2007): line 'number' of 'file name': the unit 'unit name' for DDE
'dde name' is not in the units file.
The tool has read a DDE with a unit definition that does not match any from
the units file. Edit the unit definition for that DDE to match any unit definition
in the units file, or extend the units file accordingly.
2008. (warning 2008): file 'file name': found an empty tabbed DDE file.
A tabbed DDE file is present but it contains no DDE definitions (the file
contains whitespace or comments only).
2009. (warning 2009): file 'file name': found repeated DDE 'dde name',
discarding DDE.
A repeated DDE named 'dde name' was found in file file name. The original
DDE is retained and the duplicate is ignored.
2010. (warning 2010): line 'number' of 'file name': variable 'c identifier' occurs
at more than one address.
The interface tool has found more than address in memory for the same
C variable and does not know which address to use. If this warning occurs
2011. (warning 2011): line 'number' of 'file name': ignoring variable 'dde
name' for which no type information was obtained from the ELF
information file; this may occur if it is declared but not actually used
in source code, or if you specify a containing structure instead of a
specific element within it.
The interface tool found a DDE which had no corresponding type

information. The DDE information was either derived from a Diab MAP file
(which does not contain type information), or the DDE was declared but not
used in the source code, or the DDE name refers to a structure rather than a
structure member. If a Diab MAP file was used, consider using the Diab ELF
file instead, otherwise check the DDE name use in the application source.
2501. Warning (2501): 'dde_name' is an unrecognised map type. Skipping

this DDE.

The tool has found a data dictionary entry which appears as if it were a
map but does not follow the naming convention specified in Section 5.2.5,
“Naming rules”.
2502. Warning (2502): 'dde_name' must be a 1xN vector. Skipping this DDE.
The tool has found a data dictionary entry which is an array or a axis DDE
but the data for the DDE isn't a vector (as required).
2503. Warning (2503): 'dde_name' must be a MxN matrix. Skipping this DDE.
The tool has found a data dictionary entry which is the z-data for a map but
the data for the DDE isn't a 2-D matrix (as required).
2504. Warning (2504): 'dde_name' the x-axis DDE 'dde_name' for map
'map_dde_name' must be a 1xN vector. Skipping this DDE.
The tool has found a data dictionary entry which has a x-axis DDE which
isn't a vector (as required).
2505. Warning (2505): 'dde_name' the size of the x-axis DDE 'dde_name' for
map 'map_dde_name' must be a 1xN vector (where N > 1). Skipping
this DDE.
The tool has found a data dictionary entry for an x-axis with only one element.
X-axis DDEs should have at least two elements.
2506. Warning (2506): 'dde_name' the size of the x-axis DDE 'dde_name'
differs from the number of columns in the map DDE 'map_dde_name'.
Skipping this DDE.
The tool has found a data dictionary entry for an x-axis which does not match
the size of the corresponding z-data map DDE.
2507. Warning (2507): 'dde_name' the y-axis DDE 'dde_name' for map
'map_dde_name' must be a 1xN vector. Skipping this DDE.
The tool has found a data dictionary entry which has a y-axis DDE which
isn't a vector (as required).
2508. Warning (2508): 'dde_name' the size of the y-axis DDE 'dde_name' for
map 'map_dde_name' must be a 1xN vector (where N > 1). Skipping
this DDE.
The tool has found a data dictionary entry for a y-axis with only one element.
Y-axis DDEs should have at least two elements.
2509. Warning (2509): 'dde_name' the size of the y-axis DDE 'dde_name'
differs from the number of columns in the map DDE 'map_dde_name'.
Skipping this DDE.
The tool has found a data dictionary entry for a y-axis which does not match
the size of the corresponding z-data map DDE.
H.7. Code generation messages

950. (error 950): line 'number' of 'file name': from within the 'compound'
statement, there is a missing 'assignment' statement.

The interface tool has read an interface specification file and found
a compound statement with a missing assignment statement called
'assignment'. In this case, the interface tool is expecting the assignment
statement to be present (i.e., the assignment statement is not optional).
950. (error 950): within the 'compound' statement, at least one of these
lists of statements must be provided completely (entries marked * are
already present):
(error 950): 1. 'list-of-statements'
The interface tool has read an interface specification file and found a
compound statement with a missing assignment statement. In this case, the
interface tool is expecting the compound statement to contain assignment
statements from one of the lists presented (i.e., some assignment
statements are not optional).
951. (error 951): within the interface file, there is a missing 'compound'
statement.
The interface tool has read an interface specification file and found that the
file is missing a compound statement called 'compound'. In this case, the
interface tool is expecting the compound statement to be present (i.e., the
statement is not optional). Missing assignment statements are marked by
the absence of an asterisk.
951. (error 951): within the interface file, at least one of these lists of
statements must be provided completely (entries marked * are already
present):
The interface tool has read an interface specification file and found a
compound statement with a missing assignment statement. In this case, the
interface tool is expecting the compound statement to contain assignment
statements from one of the lists presented (i.e., some assignment
statements are not optional). Missing assignment statements are marked by
the absence of an asterisk.
3090. (error 3090): incorrect declarations in target-ecu statement
The interface tool has not been able to identify the target based on the
declarations given in the target-ecu statement. See error text emitted for
specific information.
3091. (error 3091): more than one target-ecu statement is present.
The interface tool has found more than one target-ecu compound statement
in an interface file, where the tool was expecting only one.
3092. (error 3092): no target-ecu statement specified.
The interface tool has found no target-ecu statement in an interface file,

when the tool was expecting one.
3093. (error 3093): missing declarations in target-ecu statement.

The interface tool has found that required declarations were missing from
the target-ecu compound statement. See the error text emitted for further
details.
3094. (error 3094): multiple declarations in target-ecu statement.
The interface tool has found multiple declarations in the target-ecu

compound statement. See the error text emitted for further details.
3095. (error 3095): 'hw-issue-number' outside range [0, 65535].
The interface tool has found a hw-issue-number outside the value range of
[0, 65535].
3096. (error 3096): 'hw-option' must be a three-character text string.
The interface tool has found a hw-option text string that was not three
characters long.
3101. (error 3101): more than one application statement is present.
The interface tool has found more than one application compound statement
in an interface file, where the tool was expected only one.
3102. (error 3102): miscellaneous error in application statements.
This error code is emitted for a variety of issues with application statements.
See error text emitted for details of problem identified.
3103. (error 3103): 'version' outside range [0, 65535]
The interface tool has found a major-version, minor-version or subminor-

version number outside the value range of [0, 65535].
3121. (error 3121): more than one memory-config statement is present
The interface tool has found a repeated memory-config compound

statement in an interface file (the tool expects only one).
3123. (error 3123): memory configuration is not supported on this target
Only certain targets support memory configuration. Please consult

Appendix D, Memory configurations for further details.
3131. (error 3131): more than one os-native statement is present.
The interface tool has found a repeated os-native compound statement in

an interface file (the tool expects only one).
3141. (error 3141): more than one stack-size statement specified.
The interface tool has found a repeated stack-size statement in an interface

file (the tool expects only one).
3142. (error 3142): no stack-size statement specified.
The interface tool has not found the stack-size statement in an interface file
(the tool was expecting one).
3143. (error 3143): stack size less than 1024 bytes.

The interface tool has found a stack-size statement specifying less than 1024
bytes (the tool requires at least 1024 bytes to be specified).
3151. (error 3151): miscellaneous task statement error.
The interface tool reports this error code for several different errors relating
to OS task declarations. See emitted error text for details of the problem
identified.
3152. (error 3152): no task statement specified.
The interface tool has found no tasks specified in an os-native compound

statement (the tool expects at least one).
3153. (error 3153): more than 12 tasks specified.
The interface tool has found more than 12 tasks specified in an os-native
compound statement (the tool expected less than 12).
3154. (error 3154): task has no specified 'name' statement.
The interface tool has found a task compound statement without a required
'name' statement.
3155. (error 3155): duplicate task name for task 'name' already exists.
The interface tool has found a task named 'name' more than once (all task
names must be unique).
3156. (error 3156): an existing task 'name' already has a priority of 'value'.
The interface tool has found a task with a priority of 'value' but the priority
value is not unique (all task priority values must be unique).
3157. (error 3157): task rate less than 1 millisecond.
The interface tool has found a task with a period less than one millisecond
(the tool does not support task rates less than one millisecond).
3158. (error 3158): task rate greater than 1 hour.
The interface tool has found a task with a period greater than one hour (the
tool does not support task rates greater than one hour).
3163. (warning 3163): offset greater than twice period for task.
The interface tool has found a task with an offset (delay before first
execution) time that is more than twice the task period. This is allowed but
the warning is generated in case the long offset was specified accidentally.
3166. (error 3166): more than one task declared 'tdc-firing'.
The interface tool has found more than one top-dead-centre triggered
angular task. Currently only one such task is supported.
3167. (error 3167): tasks with a 'tdc-firing' trigger are only supported by (xxx)
targets.
The interface tool has found an angle-triggered task specified for an ECU
target which does not yet support angular tasks.
3171. (error 3171): resource has no specified name statement.

The interface tool has found a resource compound statement without a

required name statement.
3172. (error 3172): attempt to rename resource 'name'.
The interface tool has found a resource compound statement with a repeated
name statement.
3173. (error 3173): resource with name 'name' already exists.
The interface tool has found a resource compound statement with a name
statement identical to another resource statement (all resource names must
be unique).
3174. (error 3174): task 'name' already present in used-by-task statement.
The interface tool has found a used-by-task statement which repeats a

reference to a task (all references must be unique).
3175. (error 3175): task 'name' in used-by-task statement is not declared.
The interface tool has found a used-by-task statement which refers to a task
which is not specified.
3181. (error 3181): more than one can-messaging statement is present.
The interface tool has found a repeated can-messaging compound

statement (the tool expects to find only one).
3182. (error 3182): number of CAN receive messages is reassigned.
The interface tool has found a repeated number-of-receive-messages

3183. (error 3183): number of CAN receive messages is outside the range
[0,100].
The interface tool has found a number-of-receive-messages statement with

a value outside the valid range of [0, 100].
3184. (error 3184): number of CAN transmit messages is outside the range
[0,100].
The interface tool has found a number-of-transmit-messages statement with

a value outside the valid range of [0, 100].
3191. (error 3191): more than one PGN pdu-datapage statement specified.
The interface tool has found a repeated pdu-datapage statement within a

pgn-receive compound statement (the tool expects to see only one).
3201. (error 3201): more than one ccp-messaging statement is present.
The interface tool has found a repeated ccp-messaging statement (the tool
expects only one).
3202. (error 3202): miscellaneous CCP-related error.
The interface tool reports this error code for several reasons relating to CAN
Calibration Protocol statements. See error text emitted for details of problem.
3203. (error 3203): CCP CRO identifier of 'value' is outside the range [0,2047].

The CRO identifier was specified to be in standard ID mode, and the

interface tool has found a cro statement with value outside the valid range.
3204. (error 3204): CCP DTO identifier of 'value' is outside the range [0,2047].
The DTO identifier was specified to be in standard ID mode, and the interface
tool has found a dto statement with value outside the valid range.
3205. (error 3205): CCP CRO and DTO identifiers both have the same value
of 'value'.
The interface tool has found a cro and dto statement with identical CAN
identifier values (the CRO and DTO CAN identifiers must be unique).
3206. (error 3206): CCP station address identifier of 'value' is outside the
range [0,255].
The interface tool has found a station-address statement with value outside
the valid range.
3207. (error 3207): CCP bus 'value' is outside the range [0,2] supported by
target 'name'.
The interface tool has found a can-bus statement referring to a CAN bus
which isn't implemented by the target.
3208. (error 3208): CCP baud rate of 'value' kBps is not supported.
The interface tool has found a baud statement with an unsupported

value. See Section 6.1.12, “CAN configuration (pcx_CANConfiguration)” for
supported baud rates.
3209. (error 3209): more than one cro-ext-id statement specified.
The interface tool has found more than one cro-ext-id statement in the c-
api interface file.
3210. (error 3210): more than one dto-ext-id statement specified.
The interface tool has found more than one dto-ext-id statement in the c-
api interface file.
3211. (error 3211): CCP CRO identifier of 'value' is outside the range
[0,536870911].
The CRO identifier was specified to be in extended ID mode, but the cro
statement still specifes a value outside of the 29 bit range. range.
3212. (error 3212): CCP DTO identifier of 'value' is outside the range
[0,536870911].
The DTO identifier was specified to be in extended ID mode, but the dto
statement still specifes a value outside of the 29 bit range.
3221. (error 3221): more than one j1939-messaging statement is present.
The interface tool has found a repeated j1939-messaging compound

statement (the tool expects only one).
3223. (error 3223): J1939 CAN bus 'value' is outside the range [0,2] supported
by target 'name'.

3224. (error 3224): J1939 message buffer size 'value' is outside the range
[8,1785]")
The interface tool has found a size-of-message-buffer statement with a value

outside the valid range.
3225. (error 3225): J1939 number of simultaneous receive messages value

of 'value' is outside the range [1,20].
The interface tool has found a num-simultaneous-rx statement with a value

3226. (error 3226): J1939 number of simultaneous transmit messages value

of 'value' is outside the range [1,20].
The interface tool has found a num-simultaneous-tx statement with a value

3227. (error 3227): J1939 num-rx-tx value of 'value' is outside the range
[1,100].
The interface tool has found a num-rx-tx statement with value outside the
valid range.
3236. (error 3236): miscellaneous J1939-related error.
The interface tool reports this error code for several different issues related
to J1939 declarations. See error text emitted for details of problem.
3241. (error 3241): J1939 node address of 'value' is reserved and cannot be
used in the list of DMx nodes.
The interface tool has found the address 254 or 255 in a listen-for-dm1-
message or listen-for-dm2-message statement (addresses 254 and 255 are
reserved by the J1939 protocol).
3242. (error 3242): J1939 node address of 'value' is an address of one of the
channels on this node.
The interface tool has found a listen-for-dm1-message or listen-for-dm2-

message statement which refers to an address of this node (the tool will not
listen for its own DM1 and DM2 messages).
3251. (error 3251): more than one J1939 this-node statement is present.
The interface tool has found a repeated this-node statement within a j1939-
messaging compound statement (the tool expects only one).
3252. (error 3252): miscellaneous J1939-related error.
to J1939 declarations. See error text emitted for details of problem.
3253. (error 3253): J1939 node address cannot be 254 or 255.
The interface tool has found a this-node compound statement containing

an address statement using a reserved address (valid address range is [0,
253]).

3254. (error 3254): J1939 node industry-group value of 'value' is outside

range of [0,7].
The interface tool has found a this-node compound statement containing an

industry-group statement with invalid value.
3255. (error 3255): J1939 node vehicle-system-instance value of 'value' is

outside range of [0,15].
The interface tool has found a this-node compound statement containing a

vehicle-system-instance statement with invalid value.
3256. (error 3256): J1939 node vehicle-system value of 'value' is outside

range of [0,127].

vehicle-system statement with invalid value.
3257. (error 3257): J1939 node function value of 'value' is outside range of
[0,255].

function statement with invalid value.
3258. (error 3258): J1939 node function-instance value of 'value' is outside

range of [0,31].

function-instance statement with invalid value.
3259. (error 3259): J1939 node ecu-instance value of 'value' is outside range
of [0,7].

ecu-instance statement with invalid value.
3260. (error 3260): J1939 node manufacturer-code value of 'value' is outside

range of [0,2047].

manufacturer-code statement with invalid value.
3261. (error 3261): J1939 node identify-number value of 'value' is outside

range of [0,2097151].

identify-number statement with invalid value.
3271. (error 3271): more than one PGN size statement specified.
The interface tool has found a pgn-receive compound statement containing

a repeated size statement (the tool expects only one).
3276. (error 3276): J1939 PGN has a size outside the range of [0,1785] bytes.

a size statement with an invalid value.
3277. (error 3277): J1939 PGN has a size larger than the J1939 message
buffer.


a size statement with a value greater than the value specified in the J1939
size-of-message-buffer statement. All J1939 messages must not exceed the
size specified in the size-of-message-buffer statement.
3278. (error 3278): duplicate PGN requested information found.
The interface tool has found a more than one pgn-receive compound
statement with the same PGN (the tool expects only one).
3291. (error 3291): miscellaneous J1939 PGN-related error.
to J1939 PGN declarations. See error text emitted for details of problem.
3292. (error 3292): pdu-datapage value of 'value' is outside the range [0,1].
The interface tool has found a pgn-receive or pgn-requested compound

statement containing a pdu-datapage statement with an invalid value.
3293. (error 3293): pdu-format value of 'value' is outside the range [0,255].

statement containing a pdu-format statement with an invalid value.
3294. (error 3294): pdu-specific value of 'value' is outside the range [0,255].

statement containing a pdu-specific statement with an invalid value.
3295. (error 3295): J1939 PGN has a PDU format less than 240 and a PDU
specific value that is non-zero.

statement where the PDU1 format requires the PDU specific to be specified
as zero (the library substitutes the destination address automatically).
3296. (error 3296): duplicate PGN receive information found.
The interface tool has found a more than one pgn-requested compound
statement with the same PGN (the tool expects only one).
3297. (error 3297): duplicate PID ID found.
The interface tool has found more than one PID with its j1979-8bit-id
statement set to the same identifier.
The interface tool has found more than one PID with its kwp-8bit-id statement
set to the same identifier.
The interface tool has found more than one PID with its iso-16bit-id statement
set to the same identifier.
3300. (error 3300): duplicate DTE ID 'id' found
The interface tool has found a DTE identifier 'id' more than once (DTE IDs
must be unique).

3301. (error 3301): more than one DTC storage statement specified.
The interface tool has found a dtc-data compound statement with a repeated
storage statement (the tool expects one).
3302. (error 3302): target 'name' does not support battery backed RAM
storage.
The interface tool has found a dtc-data compound statement containing a

storage statement which specifies battery backed RAM for a target which
does not implement battery backed RAM.
3303. (error 3303): DTCs are not supported for target 'name'.
The interface tool has found a dtc-data compound statement for a target
which does not support DTCs.
3304. (error 3304): duplicate DME ID 'id' found
The interface tool has found a DME identifier 'id' more than once (DME IDs
must be unique).
3305. (error 3305): undeclared Monitor group ID 'id' used
The interface tool has found that the Monitor group ID 'id' defined for the DTE
is not defined (each DTE must be associated with a Monitor that exists).
3311. (error 3311): miscellaneous DTC error.
The interface tool reports this error code for several issues relating to J1939
and ISO-15765 Diagnostic Trouble Codes. See error text emitted for details
of problem.
3312. (error 3312): duplicate DTC named 'name' specified.
The interface tool has found a dtc- compound statement containing a name
statement specifying an identical name to another object (the tool expects
all names to be unique).
3313. (error 3313): DTC uses an undeclared table 'name'.
The interface tool has found a dtc compound statement containing a table
statement that refers to an unspecified table.
3314. (error 3314): J1939 DTC SPN value of 'value' is outside the range
[0,524287].
The interface tool has found a dtc-j1939 compound statement containing a

spn statement with an invalid value.
3315. (error 3315): J1939 DTC FMI value of 'value' is outside the range [0,31].

fmi statement with an invalid value.
3316. (error 3316): J1939 DTC CM value of 'value' is outside the range [0,1].

cm statement with an invalid value.
3317. (error 3317): duplicate DTE ID 'id' specified

The interface tool has found a DTE identifier 'id' more than once (DTE IDs
must be unique).
3318. (error 3318): duplicate DME ID 'id' specified
The interface tool has found a DME identifier 'id' more than once (DME IDs
must be unique).
3319. (warning 3319): DTE uses an undefined DME 'id'
The interface tool has found that the DME ID 'id' defined within the DTE is not
defined (each DTE should be associated with a DME that exists, otherwise
it is orphaned).
3320. (warning 3320): no DTEs have been defined for this DME 'id'
The interface tool has found that the DME ID 'id' has not been associated with
any DTE. This is allowed, but a warning is raised to check if it is intentional.
3321. (warning 3321): ISO diagnostics physical address and functional

address receive IDs are the same
The interface tool has found that the same ID has been used for the Physical
and Functional Rx on ISO-15765 comms. This is currently allowed, but a
warning is raised in case this was unintentional.
3341. (error 3341): adaptive adaptive name has already been specified.
The interface tool has found more the same adaptive parameter name listed
more than once.
3345. (error 3345): more than one adaptive storage statement specified.
The adaptive storage statement specifies where adaptives should be stored

when the ECU is not powered (e.g. flash, battery-backed RAM). Only one
such statement is allowed.
3346. (error 3346): target target_name does not support battery backed RAM
storage.
The adaptive storage statement specifies where adaptives should be stored

when the ECU is not powered (e.g. flash, battery-backed RAM). Here a
target ECU has been specified which does not support battery backed RAM
storage.
3351. (error 3351): Tunes are not supported for target 'name'.
The interface tool has found a tunes compound statement for a target which
does not support Tunes.
3352. (error 3352): no application statement specified.
The interface tool has found no application statement in an interface file,

when the tool was expecting one.
3353. (error 3353): no os-native statement specified.
The interface tool has not found the os-native compound statement in an
interface file (the tool was expecting one).
3354. (error 3354): task 'name' has no specified 'priority' statement.

The interface tool has found a task compound statement without a required
'priority' statement.
3355. (error 3355): task 'name' has no specified 'period' statement.
The interface tool has found a task compound statement for a periodic task
which has no (or zero) repetition time period specified.
3356. (error 3356): task 'name' has a specified 'period' statement.
The interface tool has found a task compound statement for a non-periodic
(e.g. angular) task which has a repetition time period specified.
3357. (error 3357): task 'name' has no specified 'function' statement.
The interface tool has found a task compound statement for a task which
has no C function specified.
3358. (error 3358): resource 'name' has no specified used-by-task statement.
The interface tool has found a resource compound statement without a

required used-by-task statement.
3359. (error 3359): number of CAN transmit messages is reassigned.
The interface tool has found a repeated number-of-transmit-messages

3360. (error 3360): more than one DTC lamp state priority statement
specified.
dtc-lamp-state-priority statement (the tool expects at most one).
3361. (error 3361): more than one DTC transition previously active to pending
statement specified.
dtc-transition-prev-active-to-pending statement (the tool expects at most
one).
3401. (error 3401): PID ID out of range.
The interface tool has found a diagnostic PID with an out of range 16-bit ID
number.
3402. (error 3402): ISO diagnostics receive ID is outside the range
The interface tool has found an receive ID beyond permitted range

for ISO-15765 (permitted range is [0, 0x7FF] for standard ID and [0,
0x1FFFFFF] for extended ID).
3403. (error 3403): ISO diagnostics physical address receive ID is same as

the transmit ID
The interface tool has found that the same ID has been used for the Physical
Rx and Tx IDs for ISO-15765 (the receive and transmit IDs have to be
different).
3404. (error 3404): ISO diagnostic tx buffer size must be in range [1, 4095]

The interface tool has found that the Tx buffer size defined for ISO-15765
is out of allowed range.
3405. (error 3405): ISO diagnostic rx buffer size must be in range [1, 4095]
The interface tool has found that the Rx buffer size defined for ISO-15765
is out of allowed range.
3406. (error 3406): more than one ISO Diagnostic can-bus statement
specified
The interface tool has found a repeated ccp-messaging statement (the tool
expects only one).
3407. (error 3407): PID ID out of range.
The interface tool has found a diagnostic PID with an out of range 8-bit ID
number.
3408. (error 3408): J1939 dm7-req-buf-size value of 'value' is outside the

range [1,10]
The interface tool has found that the DM7 request buffer/ queue size is out
of allowed range.
3409. (error 3409): duplicate AECD number error.
The interface tool has found a more than one aecd compound statement
with the same AECD number (the tool expects only one).
3410. (error 3410): test map position out of range.
The interface tool has found a test map position outside the permitted range
of [1, 64].
3411. (error 3411): test ID is out of range.
The interface tool has found a test ID outside the permitted range of [1,
0xFF].
3412. (error 3412): test map position redefined.
The interface tool has found a test map position that has been assigned to
more than one test ID.
3413. (error 3413): DTC time-to-derate value out of range.
The interface tool has found a DTC time-to-derate value outside the
permitted range of [0, 225000] seconds.
3414. (error 3414): J1939 Suspect Parameter Number (SPN) out of range.
The interface tool has found a J1939 SPN outside the permitted range of
[0, 524287].
3415. (error 3415): J1939 multiframe-priority value out of range.
The interface tool has found the J1939 multiframe-priority value outside the
permitted range of [0, 7].
3416. (error 3416): ISO bus 'value' is outside the range [0,2] supported by
target 'name'.

3421. (error 3421): ISO diagnostic maximum number of UDS dynamically

defined identifiers must be in range [0, 255].
3422. (error 3422): ISO diagnostic maximum number of UDS periodic

identifiers must be in range [0, 254].
3423. (error 3423): ISO diagnostic periodic ID base period must be in range
[20, 65530].
3430. (error 3430): DTC extended data record number 'value' is outside the
range [1,239].
The interface tool has found a DTC extended data record number outside
of the permitted range of [1,239].
3572. (error 3572): target declaration in target-ecu statement.
The interface tool has found a target declaration in the target-ecu statement
for an interface file. The use of target declarations is now deprecated and
will become illegal in a future release. Please delete this declaration.
3501. (error 3501): DTE or DME identifier is not defined.
The interface tool has found a dte statement without the required dte-id or a
dme statement without the required dme-id statement.
3503. (error 3503): Routine identifier is not defined.
The interface tool has found a routine statement without the required
iso-16bit-id statement.
3504. (error 3504): Routine identifier is reserved by the platform.
The interface tool has found a routine statement that has the iso-16bit-id
statement set to a routine ID that is reserved by the platform software. Please
select a different routine ID.
3505. (error 3505): Duplicate routine ID found.
The interface tool has found more than one UDS service $31 routine with its
iso-16bit-id statement set to the same identifier.
3506. (error 3506): Routine data byte length outside of range [0, 4095]
The interface tool has found that the byte length for a UDS service $31 data
item is out of allowed range of [0, 4095].
3572. (error 3572): target declaration in target-ecu statement.
The interface tool has found a target declaration in the target-ecu statement
for an interface file. The use of target declarations is now deprecated and
will become illegal in a future release. Please delete this declaration.
3574. (error 3574): missing hw-part-number declaration in target-ecu

statement.
The interface tool has found the hw-part-number declaration to be missing

from the target-ecu statement for an interface file. A default hw-part-number

as displayed in the warning text emitted has been reconstructed using the
target declaration instead. Please note that the use of target declarations is
now deprecated and will become illegal in a future release. Please replace
this declaration with the correct hw-part-number, hw-issue-number and hw-
option declarations instead.
3575. (error 3575): missing hw-issue-number declaration in target-ecu

statement.
The interface tool has found the hw-issue-number declaration to be missing

from the target-ecu statement for an interface file. A default hw-issue-
number as displayed in the warning text emitted has been reconstructed
using the target declaration instead. Please note that the use of target
declarations is now deprecated and will become illegal in a future release.
Please replace this declaration with the correct hw-part-number, hw-issue-
number and hw-option declarations instead.
3576. (error 3576): multiple security settings for CCP privilege level
The interface tool has found multiple security statements specifying settings
for the same CCP privilege level in the ccp-messaging statement for an
interface file. At most one security statement must exist for a CCP privilege
level.
3577. (error 3577): parameter 'dde-entry' missing from J1979 freeze frames
declaration
The interface tool has found the dde-entry declaration to be missing from
the declaration of a J1979 protocol freeze frame.
3578. (error 3578): parameter 'dde-entry' missing from uds snapshot

declaration.
the declaration of a UDS protocol freeze frame.
3579. (error 3579): parameter 'dde-entry' missing from J1939 dm4 freeze
frame declaration.
the declaration of a J1939 protocol dm4 freeze frame.
3580. (error 3580): type option 'type' unknown, expecting one of: dm4, dm25.
The interface tool has found an invalid type declaration for a J1939 freeze
frame.
3581. (error 3581): type option 'type' unknown, expecting one of: snapshot.
The interface tool has found an invalid type declaration for a UDS freeze
frame.
H.8. ELF to DDE generation messages

4001. (error 4001): C-style data dictionary specified in 'file name' not allowed
without ELF ddump output.
The interface tool has been asked to generate a C-style DDE file from
the Diab ddump input file but a Diab MAP file has been specified instead.
Change from the MAP file to the ddump file.

H.9. Data type checks between ELF and DDE

messages
5001. (warning 5001): the DDE [name] is not defined by [ELF-file] and may be
redundant, consider removing from DD file.
The interface tool has identified that a data dictionary entry with a given
name was not found in the ELF file. This may indicate that the DDE is no
longer required and can be removed from the data dictionary. Or this may
indicate that Simulink Coder has not generated a variable for the DDE and
a change is necessary to the model or model configuration.
5002. (warning 5002): the automatically added DDE [name] is not defined by
[ELF-file], please contact OpenECU technical support.
The interface tool has identified that a data dictionary entry with a given name
was not found in the ELF file. The data dictionary entry was automatically
added by the C-API tool, and failures of this type are not expected. Please
contact OpenECU technical support if this warning occurs.
5003. (warning 5003): the DDE [name] is defined with data type [a] but the
ELF uses data type [b].
The interface tool has identified that a data dictionary entry with a given
name and given data type a, but that Simulink Coder generated a variable
using data type b. This can lead to the calibration tool incorrectly displaying
the value of a signal. To remove the warning, change the DDE data type to
match that generated by Simulink Coder.

Appendix I. Change log
I.1.1. Release 3.2.0 (r2022-1)
Release labelled release-3.2.0-r2022-1 from 21 January 2022. This release is marked
as general meaning the release has been regression tested and is intended for general use.
The following table provides quick access to each of the changes.
Table I.1. Release summary for v3.2.0-r2022-1

Package New features Fixes and improvements Backwards Firmware
compatible upgrade
C-API 28619 (F), 25851 (F), 30116 (F), 28796 (F), No, see: No
25666 (F) 28793 (F), 28776 (F), 25851 (F),
28681 (F), 28504 (F), 25666 (F)
28410 (F), 28178 (F),
27797 (F), 27670 (F),
27475 (F), 27426 (F),
27377 (F), 27177 (F),
27176 (F), 27022 (F),
26647 (F), 26176 (F),
26173 (F), 26157 (F),
25854 (F)
Sim-API 28619 (F), 28592 (F), 28796 (F), 28795 (F), No, see: No
25851 (F), 25666 (F) 28794 (F), 28793 (F), 25851 (F),
28776 (F), 28681 (F), 25666 (F)
28504 (F), 28410 (F),
28178 (F), 27800 (F),
27797 (F), 27670 (F),
27478 (F), 27475 (F),
27454 (F), 27426 (F),
27377 (F), 27177 (F),
27176 (F), 27061 (F),
27022 (F), 26647 (F),
26176 (F), 26173 (F),
26157 (F), 25854 (F)
I.1.1.1. New features

New features introduced by this version, or significant changes to existing features.
Communications
External communication mechanisms and protocol support for both

reprogramming and application mode, including CCP, SAE-J1939 and
ISO-15765 over CAN.
• Added ISO 15118-2 (v1) and ISO 15118-20 (v2) communication

interfaces
CR 25851 (F), affects Sim-API and C-API
The pv2g_Message block was replaced by four new

blocks pv2g_Protocol_Handshake_Message, pv2g_DIN_Message,
pv2g_ISO_15118_V1_Message, and pv2g_ISO_15118_V2_Message in
order to support ISO 15118-2:2014 (edition 1) and the Committee Draft

Change log
(CD) of ISO 15118-20 (edition 2) circulated on 2017-03-24. The interface

to the DIN SPEC 70121 protocol has been modified in order to support
this addition, and the blockset interface is not backwards compatible
to the previous blockset. The internal TCP/IP stack and V2G encoder/
decoder has also been replaced with a different version to support the
new interfaces. See the Simulink User Guide for more details.
• Added V2G Link Info block
The pv2g_LinkInfo block was created to allow the application to access

the MAC and IP address information of both the EVCC and EVSE during
an active V2G session.
Input/output drivers
Each target ECU is designed with a different set of input and output
conditioning circuitry. Interfaces provide access, from simple low-side digital
output drive to stepper motor output drive and crank trigger wheel input
decoding.
• Enable individual control of H-Bridge channels.
Enabled individual control of H-Bridge channels:XH1, XG1, ZH1, ZH2,

ZH3, ZH4.
Third party tool support
OpenECU builds on, and utilises, various tools from third parties, including
C compilers, calibration tools and operating systems. See the third party tool
requirements section for a complete list of required and options software,
and the versions supported.
• Added support for MATLAB R2021b
CR 28592 (F), affects Sim-API
I.1.1.2. Fixes and improvements

Fixes or improvements to existing features with details of why they were previously wrong.
Application programming interface
The programming interface for linking the application to each ECU.

OpenECU developer software presents two interfaces, one for C and one
for Simulink. See the third party tool requirements section for a list of C
compilers, their versions and versions of Simulink supported by OpenECU
developer software.
• Fixed implicit resolution warnings.
Updated oe_config_using_sim_dd.m to remove implicit resolution

warnings. Changed signal resolution to Explicit only.
• Do not link the full V2G functionality if not required by an application

Change log
Previously, regardless of whether an application used the PV2G interfaces

for vehicle-2-grid functionality or not, the application build would include
the full PV2G library. The full PV2G library uses approximately 355 KiB of
code space and 75 KiB of RAM space.
Now, for applications that do not use the PV2G blockset or C-API
interfaces, the application can link an alternative library that reduces the
amount of additional code and RAM space to a minimum. The selection
of PV2G library is automatically selected for Simulink models; if a model
contains at least one of the PV2G blocks, then the full PV2G library is
linked. The selection of PV2G library must be manually set for C-API
applications.
• Addressed issue with the Sample Time parameter not showing in

the pv2g_Link_Info block
Previously, the sample time parameter was not showing up in the mask of
the pv2g_Link_Info block even though it was implemented in the platform.
This has now been fixed and the Sample Time text box is visible now.
• Addressed ECU reset issue if V2G message transmission is

attempted before a V2G Link is active
Fixed a bug that could cause an ECU reset if V2G message transmission
is attempted while no V2G link is active.
• Addressed issue with mismatched labels in the

ISOv2_DC_BidirectionalControlReq Simulink block
The ISOv2_DC_BidirectionalControlReq mask previously had

mismatches labels at the inport. The inport for EVMaximumVoltage
was labeled as EVMaximumVoltage_enable and EVMinimumVoltage was
labeled as EVMaximumVoltage. This has now been fixed.
• Added Session ID outports to the Session Setup Response blocks

across all V2G standards
Added two new outports, SessionID and SessionID_length, to the Session

Setup response blocks for all three of the V2G standards. A new error
code has also been added. The pv2g_error_code PDD signal output now
contains a value, PV2G_ERR_SESSION_ID_MISMATCH, which will get
set if an incoming V2G message contains a session ID that is different than
the ID set initially by the SECC in the Session Setup response message.
• Broke the ISOv2_ChargeParameterDiscoveryReq block into to two

for BPT charging
Previously, the ISOv2 Charge Parameter Discovery Request

block contained both the parameters for regular DC EIM
and bidirectional charging. To improve usability and to

Change log
streamline this block, it has now been broken down into

two separate blocks, ISOv2_DC_ChargeParameterDiscoveryReq
and ISOv2_Bidirectional_ChargeParameterDiscoveryReq. The
ISOv2_DC_ChargeParameterDiscoveryReq block shall be used
when the EV wants a DC EIM charge service while the
ISOv2_Bidirectional_ChargeParameterDiscoveryReq block shall be used
for a DC bidirectional charge service. The blocks were broken down to
reduce interface clutter so that an EV using BPT or regular DC EIM
charging services does not have to worry about the parameters of the
other service. User applications should be updated to account for these
new blocks and their updated inport ordering.
• Added the Payment Options parameter output to the ISO15118

ServiceDiscoveryRes blocks.
Previously, the payment options list parameter of the Service Discovery

Response message was omitted from the block mask. This was done with
the assumption that since the OpenECU platform only supported External
payment having this output is not required. The parameter has now been
added back as it can be used for testing and verifying that the charger is
also using the external payment method.
• Set input port direct feedthrough on pv2g_message blocks.
The pv2g_message blocks did not have the direct feedthrough setting
enabled. This causes the input port signal to be delayed by one loop in
the generated code. For V2G messages, this means the message will be
transmitted one loop after the transmit trigger is set. This change enables
direct feedthrough to remove the input signal delay.
• Removed MinimumSOC and CurrentSOC parameters from ISOV2

ChargeParameterDiscoveryReq
The current and minimum SOC inports to the

ISOv2_ChargeParameterDiscoveryReq block were not defined by the
ISO15118 ED2 specification but they were implemented in the OpenECU
blocks. These parameters are not used in the V2G schema and have now
been removed to avoid confusion.
• Removed SelectedServiceList parameter from DIN and ISOv1

ServicePaymentSelectionReq blocks
Previously, in the ISOv1_PaymentServiceSelectionReq and

DIN_ServicePaymentSelectionReq blocks, the parameters
SelectedServiceList and SelectedServiceList_length were taken as
inports. These parameters represented a list containing all the selected
Service IDs that the EV supports. The charger (SECC) will look at this
list and determine if it accepts any of the provided services by setting the
response code in the ServicePaymentSelectionRes message. However,
the issue with this approach is that the OpenECU platform for the ISOv1
and DIN protocols only supports one service, the DC EIM charge service,
so for an EV using the DIN/ISOv1 messages the SelectedServiceList

Change log
would only be a 1 element array containing that single service ID. This is
a counterintuitive process and thus those blocks have now been change
to accept one service ID instead of an entire list.
• Added a Sample Time parameter to pv2g_Link_Info block
Previously, the pv2g_Link_Info block did not have any inports and also
did not have the sample time parameter to set the block sample time.
The block defaults to use an inherited sample time (-1) in the S-function
parameters, which will either put the block in the fastest task rate, or force
the user to put the block in an enabled/triggered subsystem to run at a
slower rate. This has now been fixed and the sample time parameter has
been added to the mask.
• Addressed issue with the Session ID field not being populated in

DIN V2G messages
Previously, the DIN70121 V2G message blocks would always populate

the Session ID field of very request message to be all zeros, this was
due to an assumption that was made incorrectly about the DIN spec. The
issue has now been resolved so that when a SessionSetupRes message
is received from the SECC, the session ID field set in that message is
saved in an internal buffer and used later to populate the session ID in all
of the subsequent request messages that the EVCC sends out.
Communications
External communication mechanisms and protocol support for both

reprogramming and application mode, including CCP, SAE-J1939 and
ISO-15765 over CAN.
• Stack usage improvements for Vehicle to Grid blocks
Previously, the V2G blocks were allocating a number of temporary buffers

on the main model stack frame. This resulted in high stack usage for
models that contain a large number of V2G blocks. These blocks have
been revised for more efficient stack usage.
• Added several bug fixes to improve the robustness of SLAC

connection process
Previously, there have been many known issues with the SLAC
connection process that have been causing sporadic bugs when talking
to an SECC. Some of these known issues were, SLAC terminating
with errors, false errors being reported to the application even when a
connection was successful, and random QCA chip link timeouts. Most of
these issues have now been rectified with this change and now provide
a more reliable SLAC process. One of the main changes made was to
improve the random QCA chip link timeouts and that was done by using
a dedicated link status MME to query the QCA chip about it's link status.
This provided a better and more robust method of detecting the link status
allowing it to get rid of most of the sporadic link timeouts that were being
experienced.

Change log
• V2G message buffer concurrency improvements
Previously, when a V2G message block was accessing the message

buffer at the same time as a new V2G message was received, there
was a chance for the incoming message to be ignored by the ECU. This
change will buffer the incoming message in case of a conflict and the new
message will be processed on the next loop.
• Addressed an issue with large V2G message not being sent over
TCP/IP
Previously, when sending a V2G message with a payload length greater

than 696 bytes the underlying TCP/IP layer would not be able to transmit
this message and it would report an out of memory error. A memory
allocation bug was found in the platform and has been now addressed.
With this change any V2G message with a payload length up to 1452 bytes
shall be sent and received without any problems.
• Updated the TCP transmit buffer size from 1024 to 1440 bytes
The V2G maximum EXI buffer size was not updated in the last change fix,
it was left at 1024 bytes. This has now been updated and set to 1440 bytes
which is the the maximum allowable data size for one Ethernet frame. An
Ethernet frame can be at most 1514 bytes and taking into account the
different TCP/IP protocol headers (i.e Ethernet header, IPv6 header, and
TCP header) a V2G message could be at most 1440 bytes in order for it
to fit in one Ethernet frame. With this change any encoded V2G message
up to 1440 bytes can be sent over the TCP connection.
Diagnostics (communications and fault handling)
Diagnostic trouble codes and read/write parameter IDs are supported over
the ISO-15765 and SAE-J1939 protocols.
• DTC MIL lamp issue
Fix for issue preventing the pdtc_DiagnosticTroubleCode block from

lighting the MIL.
Third party tool support
OpenECU builds on, and utilises, various tools from third parties, including
C compilers, calibration tools and operating systems. See the third party tool
requirements section for a complete list of required and options software,
and the versions supported.
• Invalid pin warnings on loading M5xx models
Previously, creating a new model with the M5xx-specific platform, or

using an unsupported OpenECU library block, would result in unwanted
MATLAB warnings about invalid block parameter settings.

Change log
Now, a custom choice 'Not supported for this target ECU' provides a
defined fallback case for block dropdowns to avoid warnings prior to
building, whereupon the use of an target-unsupported block is reported
anyway.
• Add support for Diab v5.9.6.7 compiler
Added support for Diab v5.9.6.7 compiler for M5x targets as currently
recommended by Wind River, in preference to the previous v5.9.4.8 which
now has legacy status.
User documentation
User documentation covers technical specifications for each ECU, user

guides or reference manuals, installation guides and release notes, in HTML
and PDF formats.
• Added C-API documentation for V2G feature
CR 30116 (F), affects C-API
Previously, the C-API user guide did not include the Vehicle to Grid
interface.
• Fix oe_create_model
Updated template models to fix the issue
• Fix the m560 step1 example model
Updated model and loom diagram of m560 step1 example
• Update the branding information.
Updated customer documents and OpenECU block masks with Dana

logos.
• Fix M560 memory configuration documentation
Updated memory configuration documentation for M560 in

memory_configurations_mpc5746d.xml
• Update the C-API documentation for the NVM file system.
Updated the Doxygen comments for public API functions in

pnv_filesystem_access.c
I.1.1.3. Outstanding issues

• Delay between DTC status change and lamp status change

Change log
The J1939 diagnostics feature manages the status of lamps and DTC's.
There is a delay between when the DTC is set and when the lamp
indication is set. For example, if DM12 is transmitted immediately after the
DTC is set, it may report that the DTC is active but the MIL is off.
• J1939 transmit truncates messages that are too long
If the platform attempts to send a message that is longer than the size
of the message buffer, the message will be truncated without a warning.
For example, if there are 12 active DTCs, and the J1939 message buffer
only has room to report 9 DTCs, on an attempt to report all active DTCs
OpenECU will send a message containing 9 DTCs with no indication to
the tool that any error has occurred.
• J1939 Buffer size checks
J1939 buffer size is configurable by the application designer. However,

some of the J1939 transmit blocks (for example pj1939_dm20_transmit
and pj1939_dm24_transmit) do not verify that transmit data fits in the
buffer. This could result in a buffer overflow, memory exception, or loss
of data.
• J1939 Multibus simultaneous PGN request on multiple buses
If the same PGN is requested simultaneously on two CAN buses, the first
request will be lost and the ECU will only respond to the second request.
• Simultaneous receive of J1939 PGNs on multiple buses
When the same PGN is received on multiple buses within the same
model iteration, including DM7 test requests or PG requests, unexpected
behavior may occur.
• Errors integrating with ETAS INCA calibration tool during OpenECU

installation
When integrating OpenECU with the ETAS INCA calibration tool during
OpenECU installation, there is a problem with part of the installation
procedure. Selecting the Integration -> INCA-ProF Integration option
when choosing components to install is necessary to generate the target-
specific ProF configuration files in the OpenECU installed directory (under
tool_integration\inca_prof).
However, when later in the installation process the user is invited to

“Choose INCA Updates” (with a list of any currently installed versions of
INCA), the user should select "None". This step copies the ProF files into
the ETAS INCA installed location, however it does not correctly adjust the

Change log
paths to those files. This causes errors when attempting to use these ProF
files.
Instead the ProF files should be installed directly using the ETAS INCA tool
(after installing OpenECU) using the procedure described in the Appendix
of the OpenECU User Guide on how to use INCA with OpenECU (under
section “Supporting Tools”).
• Cannot define a DME without an associated DTE
CR 8752 (W), affects Sim-API and C-API
The ppr_DiagnosticMonitorEntity block to update the numerator,

denominator and ratio outputs incorrectly assumes that at least one DTE
will be found belonging to that DME. Otherwise it returns an error, and
the values for the numerator, denominator and ratio are indeterminate and
should not be relied on. As a work around, an application must assign at
least one DTE to every DME.
• Application scheduled tasks immediately after software

initialisation completes can be delayed by up to 11 milliseconds
Thereafter, the task schedule continues as expected.
• The adaptive blocks do not generate properly on the Real-Time

Workshop Embedded Coder target when Global data is placed in a
seperate file
CR 8499 (W), affects Sim-API
The default values of adaptive parameters are stored in a defined section

of memory in the calibration region. When these calibrations are defined
in a seperate file, the compiler does not place them in the proper region of
memory, and thus they are disabled. The workaround is to place all global
data in the same file as the source file.
• Negative responses to J1979 services not supported for physically

addressed requests
J1979 SEP2010 section 6.2.4.3.7 specifies that if any of services $00 to

$0F are not supported, the ECU shall not respond. However, the ECU
does give a negative response here for physically addressed requests.
• Negative responses to incorrectly formatted J1979 messages
On certain J1979 ISO 15765-4 services, the ECU generates a negative

response to incorrectly formatted request messages in contradiction to the
standard. No response is preferred in this situation. This affects services
$03, $06, $07 and $0A. See also CR8153.
• Avoiding processor exceptions if NULL dereferenced in customer

application during flash erase
CR 8211 (F), affects C-API

Change log
See CR 8211 (F) for detail. It is still possible for a bad access to cause
an exception which will continue to occur until the flash operation has
completed. If it does, a continuous loop is effectively entered until the flash
operation is over. If that operation is an erase, it may take long enough for
a watchdog exception to take place. Therefore this issue remains open
for further action in future to address this scenario. Note however that this
type of exception pattern occurs only very rarely even if NULL is repeatedly
read during flash operations, so it is now very much less probable that a
customer application will cause a reset in the manner described.

Appendix J. Glossary of terms
Glossary
ADC Analogue to Digital Converter — a mechanism to read an
analogue voltage signal and convert to a digital value.
ASAP2 A standardized description data format for calibration

data — for more information refer to ASAM Standards:
ASAM MCD 2MC / ASAP2 at the ASAM Web site (http://
www.asam.de).
CAN Controller Area Network — more information can be found

on the Bosch web site (http://www.can.bosch.com).
CANdb CAN Database — a CANdb file contains information

regarding CAN messages transmitted between CAN nodes
in a network. CANdb files (which usually have the file
extension .dbc can be edited with tools supplied by Vector
CANtech, Inc. (http://www.vector-cantech.com).
CCP CAN Calibration Protocol — for more information refer to

ASAM Standards: ASAM MCD: MCD 1a at the ASAM Web
site (http://www.asam.de).
CRO Command Receive Object — the CAN identifier of the CCP

message, sent by a calibration tool to command the ECU
to perform an action.
DTO Data Transmission Object — the CAN identifier of the CCP

message, sent by the ECU with the results of a commanded
action.
ECU Electronic Control Unit — for instance, an OpenECU device.
KAPWR Keep Alive Power — apply power to this pin while the
module is is otherwise powered down to retain the values of
any adaptive data or Tunes until the module is next powered
up again (see the technical specification for each target for
details).
H-Bridge An H-bridge is an electronic circuit which enables a voltage

to be applied across a load in either direction. These circuits
are used to allow to supply loads such as DC motors
forwards and backwards.
Hall Hall Effect Sensor — typical sensor used for cam and shaft
position sensing.
HIL Hardware In the Loop — a term used to indicate

the replacement of the plant by a simulator (e.g.,
Pi Innovo's AutoSim — www.piautosim.com [http://
www.piautosim.com]).
J1939 SAE J1939 — a vehicle bus standard used

for communications and diagnostics among vehicle
components, originally for the heavy duty truck industry in
the USA.

Glossary of terms
MIOS Modular Input Output System — a sub-processor of the

OpenECU main processor used to encode and decode
digital signals.
MISRA The Motor Industry Software Reliability Association

produced a set of guidelines for developing vehicle software
— for more information refer to Development Guidelines
for Vehicle Based Software at the MISRA Web site (http://
www.misra.org.uk).
QADC Queued Analogue to Digital Converted — a sub-processor

of the OpenECU main processor used to convert analogue
input signals to a quantized digital representation.
PixCal A simplified calibration tool based on Microsoft Excel

that requires only a RS232 UART port to communicate
with OpenECU. PixCal supports Tunes but not general
calibrations and displayables.
NOTE: PixCal is no longer supported by OpenECU.
PWM Pulse Width Modulation — a digital pulse train, where the

ratio of the high time to the low time of a single cycle
represents the duty cycle of the PWM signal.
RS232 RS232 is an electrical signalling specification published by

the Electronic Industries Association (EIA). It is a standard
for serial transmission of data between two devices.
RTOS Real-Time Operating System — a low level piece of

software that executes tasks or model iterations in real-time
in a periodic fashion.
RTW Real-Time Workshop — a component of MATLAB/Simulink

used to autogenerate C code from model diagrams.
SIL Safety Integrity Level — the likelihood of a safety related

system achieving the safety functions under all the stated
conditions within a stated period of time. References to SIL
in the OpenECU user manual refer to the MISRA guidelines.
SPI Serial Peripheral Interface — a sub-processor of the

OpenECU main processor used to communicate with other
devices.
TDC Top Dead Center
TPU Time Processing Unit — a sub-processor of the OpenECU

main processor used to encode and decode digital signals.
VRS Variable Reluctance Sensor — typical sensor type for

crank, cam or shaft position sensing.

Appendix K. Contact information
If you have questions, or are experiencing issues with OpenECU please see the websites:
Support and FAQ

Support.OpenECU.com [http://Support.OpenECU.com]
Downloads, including installers and Technical Specifications

openecu.com/downloads [https://www.openecu.com/downloads/]
If you still have questions after searching through the FAQ, or want to discuss sales or
proposals, you can contact main office:
Tel
+1 734 656 0140
Fax
+1 734 656 0141
during normal working hours (Mon to Fri, 0930 to 1700 EST).

Openecu User Guide Simulink

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Openecu User Guide Simulink

Uploaded by

Copyright:

Available Formats

User Guide

OpenECU Developer Platform

Copyright © 2021 OpenECU

Copyright 2021, OpenECU ii

3.3.8. Programming the ECU .................................................................... 48

Copyright 2021, OpenECU iii

5.2.5. Naming rules ................................................................................ 125

Copyright 2021, OpenECU iv

6.1.52. J1939 parameter group receive message (pj1939_PgReceive) ....... 253

Copyright 2021, OpenECU v

6.1.105. Vehicle to grid communication - ISO 15118 v2

Copyright 2021, OpenECU vi

7.7.22. J1939 configuration (pj1939_Configuration) ................................... 572

Copyright 2021, OpenECU vii

B.6.3. Choosing the CAN card device (Vector) ......................................... 674

Copyright 2021, OpenECU viii

Copyright 2021, OpenECU ix

Copyright 2021, OpenECU x

7.1. Diagnostic Service Comparisons ....................................................................... 509

Copyright 2021, OpenECU xi

2. Health and Safety information

Copyright 2021, OpenECU xii

The OpenECU system consists of:

Applications of the OpenECU platform include:

• engine control system development;

• chassis control system development;

• after treatment control system development;

• transmission control system development;

• hybrid powertrain control system development;

• vehicle fleet trials.

Copyright 2021, OpenECU 1

1.2. Included in your OpenECU kit

Electronic Control Unit (ECU)

1.2.2. Software — C-API

OpenECU C Application Programming Interface (API)

1.2.3. Software — Simulink API

Complete OpenECU strategy suites (optional)

OpenECU Simulink strategies (optional)

OpenECU Simulink blocks

Copyright 2021, OpenECU 2

1.2.4. Required Tools

1.3. About MATLAB and Simulink

1.4. Licensed Features

The current set of available features is:

Copyright 2021, OpenECU 3

Extended diagnostics features.

• Allows use of the Extended diagnostics blockset in Simulink models.

See Chapter 7, Extended diagnostics functions.

1.5. OpenECU requirements

1.5.1. Hardware requirements

• CPU: a modern Intel or AMD x86 32-bit or 64-bit processor.

1.5.2. Software requirements

• Operating system: Microsoft Windows 10

• MathWorks: Simulink Coder (formerly Real-Time Workshop) versions:

• Calibration tool: PiSnoop, ATI Vision™, ETAS INCA, or Vector CANape.

1.5.3. Assumed knowledge

A working knowledge of design modelling and system dynamics principles in an engineering

Copyright 2021, OpenECU 4

1.6. General development process

1.7. Co-operational development with Pi

For contact information, refer to Appendix K, Contact information.

1.8. Warnings and safety guidelines

A structured approach to testing is recommended, particularly before the product is used in