Technical issues and proposals for use expansion of ... · 12/18/2015 · Japan Virtual...

All Rights Reserved by Japan Virtual Microcontroller Initiative / vECU-MBD WG The 17th Car-Electronics Research Workshop

Technical issues and proposals for use expansion of virtual ECU

(Parallel co-simulation of multiple ECUs, Multi-core)

- Japan Virtual Microcontroller Initiative / vECU-MBD WG activity example introduction -

Japan Virtual Microcontroller Initiative

vECU-MBD WG

Virtual HILS TF Leader

Yoshihiro Miyazaki Technology Development Div. Hitachi Automotive Systems, Ltd.

December 18, 2015 The 17th Car-Electronics Research Workshop

@ Fukuoka International Meeting Hall

1


Today's presentation contents

1. Establishment background and activity summary of vECU-MBD WG

2. Multiple ECU co-simulation:

Past result of activities

Technical issues and proposals about parallel co-simulation

3. Multi-core: User requirement analysis and proposal

4. Conclusion

2

[Notes]

ECU： Electronic Control Unit

vECU: Virtual ECU

MBD: Model Based Development

WG: Working Group


1. Establishment background and activity summary

of vECU-MBD WG

3

* Progress and subject of MBD

* Virtual microcontroller (MCU) and virtual ECU

* The goal image to be aimed

* Summary of vECU-MBD WG

2. Multiple ECU co-simulation

3. Multi-core

4. Conclusion


Progress of the MBD utilization

4

Utilize model for result prediction in later development process

Man-hour

time

Background of Automotive Product Development

• Development of high-functionality & high-quality product to respond product

performance

• Shortening turn-around time for early release to the market

Increased load to S/W development engineer by electronic control of automotive

part

Test &verification Design & implementation

Additional Spec. design

Result prediction

of additional

Spec. is difficult

•Engine and break etc., i.e individual function is getting large & complex •Assigning adjustment among functions is getting complex by network connection of functions

Man-hour increase

In lower process

(implementation,

test, verification)

Can't they shift to

upper process

(system design,

specification

design) ?

Application of MBD for electronic control system is expanding

From:


What is models in MBD?

5

Models enable simulation in virtual system

From:

Optimize System Organization by Model Based Development

ECU model

Real ECU

S/W control model

H/W circuit model

H/W circuit model

Sensor model

Actuator model

Mechanical model

Control target model

Real target

System Design Phase (Virtual System Design & Test) • Clarification of input and output of a control target and a control device • Clarification of each composition module • Clarification of a total test and individual module tests

Additional spec. design

Modeling Verification


Subject of a complex electronic control system test

6

HILS B-CAN

F-CAN

In-Vehicle Test

Large scale HILS Test of a whole-vehicle

Early detection of software errors is difficult, because test of application & platform & network is executed only after completion of real unit.

Electronic control system

In-vehicle LAN

High-performance

Fusion High-

technology

Complicated

Engine control

Brake control

Body control

Steering control

Around monitor


Solution ⇒ Virtual MCU and virtual ECU

7

Virtual ECU (ECU model):

A model of ECU targeted for implementation. The model (virtual

microcontroller) of a processor targeted for implementation is included.

The model that is targeted

for control ECU model

Input model Output model MCU model

System layer

Unit layer

Parts layer Virtual MCU

Target object code

En

gin

e n

um

be

r of

revo

lutio

ns

AT

ge

ar

Virtual ECU

Virtual microcontroller (MCU) (microcontroller model): The model of a processor targeted for implementation. Peripheral circuits in the microcontroller are included.

Target object code (binary code) which is the same as the product is simulated including the base software with the OS.

../../../１．開発プロセス・環境改革/仮想マイコン応用推進協議会／vECU-MBD WG/121019/honnda作成資料/NE_RPM&Gear.avi


The goal image to be aimed

10

To apply virtual ECU in each development process phase → Shortening the right side of V-shape development process

Component Verification

Mass Production Requirement Design

S/W Detail Design

Spec. Design

Implementation

In-Vehicle Verification

Demand Side

Supply Side

Demand Side

Supply Side

Shortening

Component-less Debug & Verification

Vehicle-less Debug & Verification

Virtual MCU

Virtual ECU／Virtual HILS

Code

Code

ECU Internal Requirement Model

System Requirement Model

Software Requirement Model

ECU Requirement Model

コード

Virtual System／Virtual Full-Vehicle Simulation

コード

Shortening


Start of the cooperation activity in Japan

11

Activity of vECU-MBD WG was started

by voluntary members from April, 2010

Japan Virtual Microcontroller Initiative / vECU-MBD WG

The activity through vertically integrated industry domains

(Car – ECU – semiconductor – development tool) is necessary for

realization of model based design using virtual ECU in order to keep

superiority in global competition.

Construction of the model supply chain beyond the domain of car makers, ECU

makers, semiconductor makers and simulation tool makers is necessary.


Outline of vECU-MBD WG

12

◆ Feature： Cooperation activity which crosses vertically through industry

◆ Objectives： To promote application of MBD environment using virtual ECU

◆ Participating members：

Car makers, ECU suppliers, semiconductor vendors, tool vendors, research institutions and

universities

◆ Activity history： April 2010～present

◆ URL: http://www.vecu-mbd.org/en/ (Japanese ver.： http://www.vecu-mbd.org/)

◆ Main achievement：

(1)Use cases, Glossary, and User support guide to consider introduction

(2)Experimental example (system integration and evaluation)

◆ Important activity theme of 2013FY～ :

(1) multiple ECU co-simulation, (2) fault injection test

【Members】

Aisin Seiki Co.,Ltd., ETAS K.K., VITS INC., Australian Semiconductor Technology Company K.K., OMRON Automotive

Electronics Co., GAIO TECHNOLOGY Co.,Ltd., Calsonic Kansei Corporation, Institute of Systems, Information

Technologies and Nanotechnologies （ ISIT） , Qualiarc Technology Solutions, Inc., Spansion Innovates Ltd., Sumitomo

Wiring Systems, Ltd., dSPACE Japan K.K., TOOL Corporation, DENSO Corporation, TOSHIBA CORPORATION, Toyota

Technical Development Corporation, Nissan Motor Co., Ltd., Cadence Design Systems, Japan, Nihon Synopsys G.K,

Japan Automobile Research Institute（JARI） , Semiconductor Technology Academic Research Center （STARC） , Hitachi

Automotive Systems, Ltd., Hitachi Industry & Control Solutions, Ltd., Hitachi, Ltd., Fujitsu Ten Ltd., Honda R&D

Co.,Ltd., Mazda Motor Corporation, LINKPORT Co., Renesas Electronics Corporation, Zerosoft Assist Technology Co.,

Ltd. (Total 30 organizations) [in no particular order] (Sept.. 2015)


Activity Roadmap

◆Considering importance and difficulty, three activity phases have been planned. TF activities started from 2011. ◆2013FY～： Model supply chain TF were closed because its purpose were almost achieved. Virtual HILS TF were newly established.

Phase１（2011FY～ 2012FY）

Phase2 （2013FY～20xxFY）

Phase3 （20xxFY～20yyFY）

Model Supply Chain TF

Standardization and mechanism for model

distribution

—Model development of use case

—Definition of development process and

model supply chain business process

Virtual HILS TF

(TBD)： Cloud supporting, co-operation in

business f ield supporting

Basic Technology Environment for High Efficiency Large Scale, High Availability

Microcontroller Model TF

Standardization in business f ield, Supporting

model and tool

－Fault injection

－Interface model connecting multiple ECUs

－Co-simulation of multiple ECUs

11


The WG activity system

12

vECU-MBD WG

Model supply chain TF

Representative: Murakami (ISIT, Kyushu University)

Secretariat: ISIT/STARC Meeting frequency: Three months / time

Microcontroller model TF

Leader: Shimada (Honda R & D) Sub-leader: Miyazaki (Hitachi Automotive Systems)

Secretariat: ISIT Meeting frequency: One month / time

Leader: Yoshino (Fujitsu semi-conductor) Sub-leader: Komatsu (IBM JAPAN)

Okazaki (Renesas Electronics) Secretariat: STARC

Meeting frequency: One month / time

vECU-MBD WG

Virtual HILS TF

Microcontroller model TF

Leader: Miyazaki (Hitachi Automotive Systems)

Sub-leader: Abe (Denso)

Secretariat: ISIT Meeting frequency: One month / time

Leader: Chujo (Renesas Electronics) Sub-leader: Yoshino (Spansion Innovates )

Secretariat: STARC Meeting frequency: One month / time (under a stop)

Phase 1 (... 2012) Phase 2 (2013 ...)

Representative: Murakami (ISIT, Kyushu University)

Secretariat: ISIT/STARC Meeting frequency: Three months / time


Main activity result - Use-cases of the virtual ECU <enlightenment>

・Experimental example : Virtual microcontroller was cooperated with power windowing

system offered by JMAAB

- User support guide ＆ Glossary <enlightenment & standardization>

- CAN I/F behavior model <standardization>

- Experimental example : Fault injection @ MCU model

- Proposal and trial of SILS with peripheral model

◆ Information publication -2012/5: ISIT 12th Car-Electronics Research Workshop

-2012/11: Public HP open

-2012/11: ET2012xEDSF2012 panel session

-2013/5: ISIT Car-Electronics Research Workshop

-2013/6: User guide uploaded on HP

-2013/9: IFAC-AAC2013

-2013/9: Public HP open (English version)

-2013/12: User guide uploaded on HP (English version)



-2014/12: User guide (Rev2) uploaded on HP (English

version)

-2015/3: Automotive Functional Safety Conference

◆ Works shown in public (example) 1. purpose: This book summarizes the information as a guide which seems to be useful in considering of introduction & use of virtual ECU 2. table of contents: (1) Purpose of Introduction & Use of Virtual ECU Simulator (2) Positioning on Development Process (3) Present Condition Example (Use-case) (4) Timing Accuracy (5) Synchronization of Two or More Simulators (6) Interface between Models (7) User Interface (UI) (8) Fault Injection (9) Performance Evaluation (10) Points of Attention in Peripheral Model Design

2011FY～

2012FY

User Support Guide to Consider Introduction of Virtual ECU

- Integration of CAN bus model

- Experimental example : Multiple ECUs (CAN connection)

- Experimental example : Fault injection @ ECU input/output circuit model

- Expansion of user support guide to consider Introduction (requirement specification

of fault injection, etc.)

2013FY～

2014FY

13


WG Activity Scene

Activity scene of the 23rd vECU-MBD WG meeting September 29,2015＠Semiconductor Technology Academic Research Center （STARC）

14



3. Multi-core

4. Conclusion


15

- Summary of multiple ECU co-simulation

- Development of vECU-CAN bus model

- Experimental example (multiple ECU system)

- Exhibition of vECU-CAN bus model

- Technical issues and proposals about parallel co-simulation


Overview of multiple ECU co-simulation

HILS B-CAN

F-CAN

CAN

Vehicle

Environment

Operation

Pattern

I/F I/F I/F I/F

Virtual MCU

Target Object Code Target Object Code Target Object Code Target Object Code

Virtual MCU Virtual MCU Virtual MCU

Conventional method

Full Vehicle HILS

Controllers are real

machine

New method

Full Vehicle Off-Line simulation

To virtualize all including controllers

Vision of multiple ECU co-simulation: To realize the simulation of a whole car

16


Goal image of multiple ECU co-simulation

System constitution of multiple ECU cooperation simulation

FI/AT ECU

ADAS ECU

EPS ECU

Power

Window

ECU

Engine Model

T/M Model

Braking system

Model

EPS G/B ASSY Model

Head Light

Model

Power W indow /Mirror Model

Wiper model

Driving Position

Model

Door model

Vehicle model

[plant model]

Car behavior model

[controller model]

ECU model

ESC ECU

Chassis

system

ECU

Body

system

ECU

Engine

system

ECU

Communications bus model (e.g.:) CAN bus model)

17


Background of development of vECU-CAN bus model

◆ Background

* The standardization of interface model among multiple ECUs is not yet

achieved because generalization is difficult.

* This WG planned to investigate standard specifications (proposal) of the

communication interface model used frequently in automotive control use

and to correspond to CAN bus interface as the first step.

* As for CAN bus interfaces, standardization is desirable because it is used

widely for communication among multiple ECUs. Its standardization will

make it easy to connect multiple ECU models of the different suppliers.

Standard specification of the CAN bus interface model has been proposed

by vECU-MBD WG.

The name of the proposed CAN bus interface model is the following.

"vECU-CAN bus model"

18


Overview of vECU-CAN bus model

Name vECU-CAN bus model _ message level vECU-CAN bus model _ bit level

Feature High speed version Highly accurate version

General

structure

Timing precision

Demand function * The arbitration is controlled by a message

unit

* CAN2.0b based

* The arbitration is controlled by a bit unit

Use case * Simulation of virtual car one whole car

* Software function verification * Fault injection (message level timing)

* CAN bus competing behavior evaluation

* Fault injection (bit level timing)

MCU model

CPU

CAN

Tx

Value send/receive

Rx

Value send/receive

ECU 1 MCU model

CPU

CAN

ECU n

* * *

CAN Bus

Message level transfer

Tx

Rx

Message level

Microcontroller model

CPU

CAN

Tx

Value send/receive

Rx

Value send/receive

ECU 1 Microcontroller model

CPU

CAN

ECU n

* * *

CAN Bus

Bit level transfer

Tx

Rx

Bit level

Models with two kinds of timing accuracy are defined in order to use them in various use cases. "vECU-CAN bus model _ message level" was constructed and evaluated in the experimental example.

19


Implementation structure of vECU-CAN bus model message level

vECU-CAN BUS

Adapter

CAN Controller

CPU Simulator

Network

Scheduler

Inter-process communication

TCP/IP

v ECUCAN-API

Socket

Buffer +Adapter

Adapter

CAN Controller

CPU Simulator


TCP/IP

)

v ECUCAN-API

Socket

Buffer +Adapter



Socket Socket Socket IF can be omitted In case of single PC

Standard API

Standard Socket IF

Developed by vECU-MBD WG

Existing model can be used. To be connected via standard API (or standard Socket IF)

Virtual MCU Virtual MCU

Simulink (including plant model)

Features: (1) Standard API connectable with existing models of the virtual microcontroller tool (2) Co-simulation with Simulink (existing properties can be used) (3) Parallel co-simulation is possible

Existing property can be used

20


Structure of the experimental example (multiple ECUs)

- Multiple power windowing systems are arranged. Each ECU system was developed in phase 1 (2011FY-2012FY) - Additional single ECU for whole PW control is developed newly (it is developed using SILS w/ peripheral)

： New

development ： Reused PW: Power Window

ECU model 1

Virtual microcontroller

vECU-CAN bus model

ECU model 2


ECU model 0

SILS w/ peripheral

ECU model 3


ECU model 4


Driver's seat PW Assistant driver's seat PW

Rear left PW Rear right PW whole PW control

Plant model Plant model Plant model Plant model Plant model

Simulink

ECU model


Driver's seat PW

Plant model

Simulink

Multiple ECU co-simulation system (2013FY ...)

Single ECU system

(developed in phase 1)

2013FY goal: - Simulink x 1 + ECU model x N + vECU-CAN bus model x1 ->Built on single PC - Evaluated on both Synopsys /Virtualizer and Gaio technology /No.1 system simulator for virtual microcontroller tool

Notes: This is system structure for experimental example of the virtual ECU technology and has nothing to relate with the st ructure of actual products

21


Reference: Power windowing system (Single ECU system)

Virtual microcontroller cooperated with JMAAB power window system

from vECU-MBD WG 2011FY Report

Virtual Microcontroller Tool： Experimented on 2 tools • Synopsys／CoMET-METeor • Gaio Technology／No.1 System Simulator

Ｔａｒｇｅｔ Object Code

Virtual Microcontroller

Replace Micro-

controller Behavior

Area

Sample model of executable ECU spec. in power window system

Top level model

PWM driv e circuit model H-bridge circuit model

DC motor model

Power window mechanical model

Current sensing model A/D converter model

Voltage/Current I/F Circuit model

Rotational pulse calculation model

Pulse interval counter model Rotational pulse I/F circuit model

Simulation result

Motor current

Window speed

22


Experimental example 1st step [CoSim environment = Simulink]

Network Scheduler for vECU-CAN bus

ECU model 0 <PW whole system control>

SILS w/ peripheral

ECU model 1

ECU model 2

Virtual MCU (Virtualizer or No.1SS)

23

Item 1 <driver's seat PW>

Item 2 <seat next to the driver PW>


Publication of vECU CAN bus model specification and sample

24

vECU-CAN bus model specification

vECU-CAN bus model

sample code

◆Publication of WG workout vECU-CAN bus model specification (for publication) has been edited. It has been

open on HP with sample code. （December/'15） Everyone who wants to get it can download it if registered on HP.

member site http://member.vecu-mbd.org/


Technical issues and proposals about parallel co-simulation： Role of CoSim environment and limit of 1st step

25

◆Role of CoSim environment When co-simulation of multiple models is done, execution order control or parallel execution control among models are necessary. CoSim environment shall have functions of execution order control or parallel execution control among models/ ◆Limit of 1st step (CoSim environment = Simulink ) (→experimented in 2013FY) （１） Execution order control →○ In case of the experimented CoSim environment (Simulink + SFUNC), Simulink supports the function of execution order control, and it was used. Example: In the experimental example, it was designated by Simulonk function of execution order control that the execution of each models start after the execution of Network Scheduler(for vECU-CAN bus) completes . （２）Parallel execution control →× But, Simulink does not support the function of parallel execution control. Therefore,it can't be applied as a CoSim environment for parallel execution control.


2nd step:

Status and plan to promote CoSim environment for parallel processing

26

◆It was decided to work on experimental example using the CoSim environment for parallel processing as activity of the 2nd step in this WG. As CoSim environment for parallel computation, two following candidates are examined.

①FMI cooperation

Considered result is introduced in this time

Functional Mockup Interface (FMI) is open standard interface for cooperation to operate plural models to be comprised of different kind simulation tools in MBD. German Daimler company (Germany) proposed it and was developed by "MODELISAR" project (2008 through 2011) and is continued as the project of association of Modelica from 2012. https://www.fmi-standard.org/

◆Working status and plan 2014FY 2nd half～2015FY 1st half： Technical problem extraction and countermeasure consideration + Partial verification

2015FY 2nd half～: Start of integration of the experimental example （for both ① and ②）

②D-EIPF cooperation

D-EIPF is abbreviation of Design-EIPF or Digital-EIPF. It is co-simulation function to synchronize the model groups (control models, multiplex communication models, harness circuit models) for the evaluation, a vehicle model and the model of a generic name of in-vehicle integration simulation environment comprised of a panel for evaluations to control user interface and an automatic evaluation or the plural control system CAD tools and to carry it out is shown. Reference: Akira Watanabe and Asuka Sotome, "Functional Development Methodology for On-Board Distributed ECU Systems for Production Vehicle Application", SAE Int. J. Passeng. Cars - Electron. Electr. Syst. September 2012 5:492-500; doi:10.4271/2012-01-0929


Problem and countermeasure of CoSim environment for parallel processing

27

◆Problem of new CoSim environment (for parallel processing) As new CoSim environment for parallel processing, FMI-related tools and others were examined. However, in the CoSim environment for the parallel processing that were examined this time, it became clear that the parallel execution control function is supported but execution order control function is not supported as the basic function of the tool.

Classification of CoSim environment Execution order control

Parallel execution control

CoSim environment for parallel processing Expected function

○ ○

Experimented CoSim environment (Simulink + SFUNC) ○ ×

New CoSim environment for parallel processing Basic function

× ○

◆Countermeasure Method 1：To synchronize finely between the tools Method 2：To make CoSim tool to add execution order control function （Functional expansion of the CoSim tool） Method 3：To use Simulink (SFUNC) together about the part needing execution order control


Method 1：To synchronize finely between the tools

28

Item N

Item１ Controller model１（ＥＣＵ model１）

Input

circuit

model１

Output

circuit

model１

MCU model１

(Virtualizer, etc.) (w ith CAN adapter

Plant model１

Motor

model１ Mechanical

model１

Controller model N (ＥＣＵ model N）

Input

circuit

model N

Output

circuit

model N

MCU model N


Plant model N

Motor

model N Mechanical

model N

CAN model

Communication model

between ECUs

・・・

・・・

Simulink, etc.

CAN bus interface data buffer

Total control：CoSim environment for parallel processing 【without execution order control function】

：order control ：data flow

Feature：Every synchronization period between models, each model is

executed in parallel.


Limitation of method 1 and activity of this WG

29

◆Limitation pf method 1 （To synchronize finely between the tools）

Limitation 1：

When synchronization period T between models becomes large (e.g.：100μs）,

the period that the last stage model output is reflected on the first stage model input

is T x N（e.g.：500μs) in case that N stage models are connected in serial. In case of motor control of chassis system, etc., synchronization period of the total control

system （the first stage model ～ the last stage model）shall be short. （e.g.：10μs）

⇒Countermeasure： To synchronize finely between the tools (e.g.：1μs) ⇒Demerit： Due to the synchronization overhead between tools, simulation run time becomes slow. Merit of speed up by parallel processing may be lost.

Limitation 2：

In case of existing models (Simulink based MILS), synchronization method between controller model and plant model applies execution order control. When method 1 is

applied, redesign of the existing models may be necessary.

（It is expected to avoid operation that parallel processing derives redesign of the existing models.)

◆Activity of this WG

To try investigation and experimental sample of method 2 and

method 3 as a solution to solve the limitation of method 1


Method 2：To make CoSim tool to add execution order control function

30

Method 2 is being tried at FMI cooperation experimental sample in this WG. (FMI basic

function doesn't support it, but execution order control function will be added as

expanded function of the tool.)

Input

circuit

model１

・・・

・・・



Total control：CoSim environment for parallel processing 【Execution order control function is added】

Feature： To add execution order control function to CoSim tool for parallel processing

Item１ Controller model１（ＥＣＵ model１） Plant model１

Output

circuit

model１

MCU model１


Motor

model１ Mechanical

model１

Input

circuit

model N

Output

circuit

model N

MCU model N


Motor

model N Mechanical

model N

Item N Controller model N (ＥＣＵ model N） Plant model N

CAN model

Communication model

between ECUs


Method 3：To use Simulink's execution order control function together

31

Method 3 is being tried at D-EIPF cooperation experimental sample in this WG.

Feature：Simulink (SFUNC) is used in combination at part where execution order control function is necessary.

SFUNC

SFUNC

CAN model

Simulink SFUNC

・・・

・・・

Simulink【 with execution order control function 】

Simulink【 with execution order control function 】

Simulink, etc.



Total control：CoSim environment for parallel processing 【without execution order control function】

Communication model

between ECUs

Item１

Controller model１（ＥＣＵ model１） Plant model１

Input

circuit

model１

Output

circuit

model１

MCU model１


Motor

model１ Mechanical

model１

Item N

Controller model N (ＥＣＵ model N） Plant model N

Input

circuit

model N

Output

circuit

model N

MCU model N


Motor

model N Mechanical

model N


3. Multi-core

32

・Trade-off of requirement specification

・Basic requirement specifications

・Software bugs assumed in case of multi-core

・Timing accuracy , synchronization period between the cores

・Additional requirement specifications


4. Conclusion



Trade-off of requirement specification

33

In the modeling of the microcontroller core, precision (timing accuracy) of the

model , development man-hour (cost and delivery date), and simulation run

speed are in a relation of the trade-off.

Activity of this WＧ： To make user requirement specification of multi-core model slim and standardized

⇒Purpose： decrease of tool development man-hour, speed-up of simulation run

Action policy：

（１）In case of single-core, 3 types of timing accuracy requirement specification

according to use cases have been defined. -> The above method will be applied in expansion to the multi-core.

（２）Especially, requirement specifications which secures minimum accuracy for software function verification and which is better from the view point of run time

and development man-hour will be clarified.

Timing accuracy

Development man-hours, cost, and

delivery time Timing accuracy

Execution time


Basic requirement specifications for multi-core

34

Core１

Core２

（１）To show software execution trace result in parallel on the same timing axes.

（Not to show them separately by each single core)

Core１

Core２

Shared memory

（２）To simulate share resource function between the multi-cores

a)To simulate the function of shared memory,

inter-core interrupt, inter-core semaphore

mechanism, etc. b)To simulate the function of

memory reserve instruction for shared memory

between multi-cores (e.g. Compare & swap

(CAS) instruction)

c)To simulate execution order control

Time


Software bugs assumed in case of multi-core

35

Examples of the outbreak timing of a bug assumed in verification of the software in

the multi-core have been considered.

No. Examples of the outbreak timing of a bug Requirement specification of model

1 By omission of the shared memory reservation, a memory access of the other core which was not permitted becomes inserted between two memory accesses of a certain core.

In order to be used for software function verification even in ATAL-1 (the lowest timing accuracy level) , "to simulate atomic characteristic and competition in memory competitive access "is required. To make the states (1)～(3) described left is required.

2 When one memory access of a certain core overrides the alignment of the shared memory bus, the memory access is divided to two memory access on the memory bus. Another memory access of the other core which was not assumed becomes inserted between the two memory accesses.

3 Avoidance of memory competition can be performed by interrupt inhibition. But it cannot be performed by interrupt inhibition in case of multi-core.

4 It assumes that a certain program expects the shared memory twice by prohibition of compiler optimization. If omission of prohibition of compiler optimization, occurs, the second read doesn't read the shared memory by the compiler optimization. As the result, the certain program misreads the data written by another core.

In case of SPILS which simulates based on object code, this error phenomenon can be basically simulated.


Requirement specifications of timing accuracy in case of multi-core

36

From the viewpoint of multi-core, definition and explanation of timing accuracy requirement specification has been added. (Added part is colored.）

Main uses

Remarks：Trade-off Level Definition and explanation S/W

Function Verification

S/W

Performance Evaluation

ATAL-3

Less than 5% of errors. A bus arbitration and pipeline control

are modeled. Number of processor clock cycles are simulated closely to the real processor. As for memory

access competition, precise simulation of the memory behavior can be performed based on the processor

clock cycle level by modeling memory bus arbitration and cache memory control.

○ ○

ATAL-2

Less than 15% of errors. Processor clock cycle number is

estimated roughly, and it is simulated. For example. number of the execution cycle setting mean as for every instruction

or every access place. As for memory access competition, atomic

characteristic and competition can be simulated, but its timing accuracy is estimated roughly.

○ ○

ATAL-1

Maximum error rate is not guaranteed. For example, it is

simulated in 1 processor clock cycle by all one instruction. The timeliness of timer interrupt and the event outbreak

appointed at time is guaranteed. But the precision is not guaranteed in a processor instruction execution time.

As for memory access competition, atomic characteristic and competition can be simulated, but its

timing accuracy is not guaranteed. （eg. all atomic

memory access is 1 processor clock cycle.）

○ ×

High

Low

Long

Short

Tim

ing

accu

racy

Ma

n-h

ou

rs, c

ost

Exe

cutio

n tim

e

Large

Small


Requirement specifications about the synchronization period

between the cores

37

Synchronization period ＝the processor cycle x １

Core１

Core２

Core１

Core２

Shared

memory data after modified

[correct] data before modified

[wrong]

time time Processor cycle time Processor cycle time

write read write read

Shared

memory

◆Problem

The synchronization period between the core should be equal to the processor cycle in order to simulate exactly the

access order to the shared memory in case of multi-core. However. when the synchronization is going to be taken

every 1 cycle, task switching occurs each time, and the simulation execution speed may extremely decrease

depending on a simulator.

◆Requirement specification (proposal)

One of three following methods should be applied for the synchronization period between the core.

Method 1： The synchronization period between the cores should be the processor cycle. Even, in that case, the

method that a simulation execution speed does not decrease should be adopted. (eg. the method that the switching

overhead is as low as possible)

Method 2： If the method that the simulation execution speed decreases (switching overheads occur) is adopted

when the synchronization period between the core is a processor cycle, the synchronization period can be chosen by

the user. （ the processor cycle ｘ 1～N) User can select it considering the trade-off between "timing accuracy of the

shared memory access order "and "simulation execution speed".

Method 3： It is assumed The synchronization should be done in every timing of the access to the shared resource

between the cores.

Synchronization period ＝the processor cycle x 5


Additional requirement specifications

38

Additional requirement specifications have been derived described below.

⇒ Support by tool vendors is expected.

1. Help function to generate memory access competition

The difference of the execution speed between the cores can be controlled on the

simulator. Specifically, waiting can be inserted into one of the cores if the waiting is

ordered by the test scenario.

2. Help function to show memory access competition 【WANT requirement】 Function to show clearly access competition occurrence clearly (e.g. colored) at

showing page of memory access trace.

3. Help function to analyze results 【WANT requirement 】 Help function to find easily points that memory access competition may occur

4. Help function to generate a competition timing 【WANT requirement 】 Function to find access competition to the same memory address in near timing

and to generate a test timing which simulates three cases (1)just before (2)just after

and (3) inserted between

⇒The contents reported at this time (Requirement specifications for multi-core

model) have been reflected on the user guide (Rev.3) and shown on the HP.


3. Conclusion


2. Activity example introduction : Fault injection

39


Conclusion

40

◆ vECU-MBD working group - Purpose of the virtual ECU utilization: Shortening the right side of V-shape development process - Cooperation activity in Japan which crosses vertically through technologies of car makers, parts makers, semiconductor makers, tool makers, and research organizations ⇒ To promote application expansion of virtual ECU ◆ Activity example (1) : Multiple ECU co-simulation - vECU-CAN bus model: Open of specification and sample - Experimental evaluation: Trying CoSim for parallel processing (FMI cooperation and D-EIPF cooperation) Technical issues extraction and countermeasure consideration + partial verification ◆ Activity example (2) : Multi-core - Requirement specifications for multi-core model have been developed. ⇒ They have been reflected on the user guide and shown on the HP ◆ Future activity (plan) - Multiple ECU co-simulation: To construct and verify the experimental example for parallel processing - Fault injection : To try the experimental example using tools with extended functions - Development of model purchasing and integration guide

Note: The plan mentioned above may be changed without notice. due to discussion result in the WG


References

Japan Virtual Microcontroller Initiative / vECU-MBD WG exhibition document

http://www.vecu-mbd.org/en/

JMAAB exhibition document http://jmaab.mathworks.jp/

ISO26262 Road vehicles - Functional safety -

Niimi, Virtual Development of Engine ECU by Modeling Technology, SAE paper No. 2012-01-

0007(2012.4)

Oho , A Virtual Development of Automotive ECU and Cloud Environment,

the 10th Car-Electronics Research Workshop, Jan., 2012

Shimada：Introduction of Joint Activity by JMAAB / Japan Virtual Microcontroller Initiative to

apply Virtual Microcontroller for Automotive Control System Simulation, The 11th Car-

Electronics Research Workshop, May 2012

Shimada, Yoshino, Saito: Trial of Model Based Development using Virtual ECU, ,The 13th

Car-Electronics Research Workshop, May 2013

Miyazaki: User guide development for using virtual ECU ～Introduction of vECU-MBD WG

Activity Example～, the 14th Car-Electronics Research Workshop, January, 2014

Miyazaki, Abe: Trial of multiple ECU co-simulation and fault injection using virtual ECU -

vECU-MBD WG activity example introduction -, the 15th Car-Electronics Research Workshop,

July, 2014

41


Thank you for your attention.

42

Technical issues and proposals for use expansion of ... · 12/18/2015 · Japan Virtual...

Documents

Transcript of Technical issues and proposals for use expansion of ... · 12/18/2015 · Japan Virtual...