introductionmirabilisdesign.com/new/software/demo/automotive/can_bus... · web viewthe can_bus...

ContentsIntroduction.................................................................................................................................................2

System Architecture....................................................................................................................................2

Overview on VisualSim Model.....................................................................................................................3

CAN Wire.................................................................................................................................................4

Signal_DB:............................................................................................................................................6

Message_DB........................................................................................................................................6

Filtering DB..........................................................................................................................................7

Enabling CAN-FD..................................................................................................................................7

CAN Node Block.......................................................................................................................................7

Task Generator........................................................................................................................................8

ECU Processing........................................................................................................................................8

Vehicle Network with two CAN Network Segments....................................................................................9

System Analysis.........................................................................................................................................11

Change the Rate of Signal and Messages from CAN_Wire Block...........................................................11

Move Messages from one ECU to another, or one network to another................................................15

Move Tasks from one ECU to another ECU...........................................................................................19

Move Node from one network to another............................................................................................23

Modeling and Simulation of Complex Automotive Networks

IntroductionComplex Vehicle networks with multiple protocol types are the future of modern vehicle architectures; where inter-vehicle or intra-vehicle communication tend to create large latencies and securing against external threats increases the processing requirements. These new types of network topologies providing higher bandwidth; but also create higher processing cost for protocol conversion and intrusion checks. This means that the design must be tested against a larger number of workloads, more user scenarios and various topologies. Multi-hop throughput is influenced by network load, characteristics of shared wireless medium, inconsistent communication latency between two/more vehicle networks, and network architecture.

In this document we will be explaining how CAN network can be modeled and simulated to compute end-to-end latency, ECU processing, achieving task deadline time. Initially we will be considering a single CAN segment network and then extending this as a two CAN segment network model. Later we can extend the model with FlexRay and Ethernet segments too.

System ArchitectureInitially we have started with single CAN segment with 6 CAN nodes, each CAN node will have its own ECU Processing unit. Network has signal generation module, task generation module and CAN message generation module, each modules are running independently as in a real vehicle network. The nodes can also wait for trigger from another node or it can trigger itself to start. The CAN message will have complete details about the DLC, length, destination, message, data, priority, cycle time, start bit etc. The VisualSim model of the proposed system architecture is shown below

Figure 1

Overview on VisualSim Model

The vehicle network constructed using VisualSim has four major subsystems, CAN Wire, CAN Node, ECU Processing Unit, Task Generator. The CAN signals are generated at each CAN Node blocks at different rates, size and priority based on CAN db format. The Task generator will be continuously checking for any signal generated from a node and process the data in the corresponding ECU Processing Unit. CAN Messages will be generated for the corresponding signals and sent across the CAN Bus. Each CAN Nodes will receive the CAN messages and the nodes will accept/reject a message based on the details specified in Filtering Database.

Each computing node contains multiple software applications or tasks. The tasks execute at an independent rate irrespective of whether data is available or not. The data for each task is in the form of either sensor input or a message from another task. Each task can have any number of message or sensors as input. After the task is complete, it can generate any number of output messages to the

same or different tasks. If the message or sensor data does not arrive, as required, the task will operate with the persistent data. Each sensor, message and task has a task rate and the user can vary these.

Let us look at each subsystem one by one

CAN WireCAN Wire is a very powerful library block in VisualSim and it helps the user to generate signals, messages and also filtering of messages for a specific node as well. Traffic for the CAN bus is defined in a standard CANdb format within VisualSim or user can create traffic with a set of predefined fields as well. The user can use the CAN Bus as a normal CAN Bus or CAN-FD as well by configuring couple of parameters. The configuration window of CAN Wire/CAN Bus is shown below

Figure 2

There is a facility to enter power consumption by each ECU’s in the network at Active, Standby, Suspend and off. The power consumption computation is purely dynamic power analysis and helps the designer to optimize power consumption of the complete system to meet power requirements.

Signal_DB:

Signal Database is responsible for generating signals from various sensors at different rates. The Signals generated will have Identifier value, DLC, Cycle time, Start bit, length, min and max data sizes. The Sample Signal database is shown below

Message_DB

Message database provides the details on messages for the corresponding signals.

Message_DB and Signal_DB are connected with the field “ID”, if you notice the “ID” of CarSpeed and Diagnostics in Signal_DB file, which is “0x608”, this corresponds to message “ABSData” in the Message_DB, this also has the ID “0x608”.

Filtering DBFiltering database helps in identifying if the message received over a CAN network is for that node or not.

User can list out all the relevant messages in the message array for a specific node.

Enabling CAN-FDCAN flexible data rate can be enabled by selecting the check box “FD_Enable” in CAN_Wire/CAN_Bus configuration. Then user can specify the data rate they would be interested to run with by configuring the parameter “FD_Multiplier”.

CAN Node Block

This block emulates a CAN device connected to the CAN network. This block requires the CAN_Bus block to function. The CAN_BUs block maintains all the tables required for sensor traffic generation, the messages, filtering of messages to be accepted by this block and the arbitration. Each CAN_Node must have a unique name over the entire network. if this is the bridge to another network via a bridge, all the messages that need to be sent to the other network must be included in the filtering database for this Node. If the Sensor tables in the CAN_Bus are to be ignored, then the traffic must be connected to the node_in/node_out ports and set the parameter ”Enable_Sensor_DB” as false. The bridge can also be connected to this block.

User can also generate error messages from CAN Nodes.

Task GeneratorTask generator is a custom module created for this example, purpose of having task generator is to make sure that the software runnable execution time is under the given deadline times. The Task generator will run independently and it will send request to appropriate ECU to execute the functionality based on the signal arrived, if there is no signal then it will consider the previous signal information for processing. In this module we are also getting feedback from the ECU’s and check if the tasks are being executed in the given deadline times or not. The Task table is shown below

ECU ProcessingECU Processing block is a custom module created for this example, this module represents the microprocessor resource and a mapper function that maps incoming tasks on to processing resource.

This module receives data from Task Generator and once the processing is over, it will send the information back to Task generator to check if the task has been processed in given deadline time or not.

Vehicle Network with two CAN Network Segments

This section is an enhancement to the previous system constructed and here we are moving a function from CAN Segment 1 to Segment 2. The VisualSim model is shown below

The mode consists of additional CAN Wire/CAN Bus, CAN Bridge. We have moved the Processing Unit connected to Node 6 to another CAN segment here. A specific message or all messages can be sent across to another CAN Segment. BridgeSwitch table enables the second can segment to accept a specific message or all by specifying the “Identifier” with a ID or by typing ALL. The table is shown below

Distance between one CAN bus to another can be defined in the routing table, this table also has the bandwidth details. The Routing table information is shown below

System AnalysisYou can do the analysis by doing below mentioned changes to the network

1. Change Rate of Signals and Messages

2. Move Messages from one ECU to another, or one network to another

3. Move Tasks from one ECU to another ECU

4. Move Node from one network to another

Change the Rate of Signal and Messages from CAN_Wire Block

Signal and Messages will be generated on their own time schedule and it can be modified by editing the “Cycle_Time” field in Signal_DB and Messages_DB.

Analysis 1:In this analysis we will change the Signal rate and Message rate and analysis the impact on latency.

The Signal_DB for the CAN Bus1 is shown belo

Name ID DLC Cycle_Time StartBit Length Initial_Value Minimum Maximum ;

FrontCam 0x608 2 100 8 2 10 0 100 ;

RearCam 0x608 2 100 8 2 10 0 100 ;

WheelSensor 0x068 2 100 8 2 10 0 100 ;

Radar 0x006 2 100 8 2 10 0 100 ;

Braking 0x618 2 100 8 2 10 0 100 ;

Mirrors 0x168 2 100 8 2 10 0 100 ;

CruiseControl 0x016 2 100 8 2 10 0 100 ;

Climate 0x268 2 100 8 2 10 0 100 ;

SOS 0x316 2 100 8 2 10 0 100 ;

Engine 0x016 2 100 8 2 10 0 100 ;

OtherSignals 0x165 2 100 8 2 10 0 100 ;

The Message Database for the CAN Bus1 is shown below

ECU Address Message ID DLC Cycle_Time StartBit Length Initial_Value Offset Minimum Maximum ;

ECU1 0x600 EngineInfo 0x016 4 100 2 2 0 0 0 2048 ;

ECU2 0x601 ADASInfo1 0x608 8 100 2 2 0 0 0 2048 ;

ECU3 0x602 OtherInfo 0x168 4 100 2 2 0 0 0 2048 ;

ECU3 0x602 OtherInfo1 0x268 4 100 2 2 0 0 0 2048 ;

ECU4 0x603 BrakingInfo 0x618 4 100 2 2 0 0 0 2048 ;

ECU4 0x604 WheelSpeedInfo 0x068 4 100 2 2 0 0 0 2048 ;

ECU5 0x604 ADASInfo3 0x006 8 100 2 2 0 0 0 2048 ;

ECU5 0x604 ADASInfo2 0x316 8 100 2 2 0 0 0 2048 ;

ECU6 0x604 OtherInfo2 0x068 4 100 2 2 0 0 0 2048 ;

Let us run the initial simulation run with default settings, the latency graph with default settings in which Cycle_Time for Both Signal and Message is set to 100 for the signal/Message with ID “0x608”. This represents the FrontCam signal in our case and corresponds to ADASInfo1 message.

The Latency graph with default settings is shown below

X-Axis is Simulation time and Y-axis is Latency in seconds. The dots represented in different colors correspond to each message types listed in the right hand side of the graph.

Now let’s change the Cycle_Time for the FrontCam/RearCam signal and ADASInfo1 message in Signal_DB and Message_DB.

Make Cycle_Time for FrontCam as 40 and Cycle_Time for ADASInfo1 message as 40.

The below table is the modified Signal_DB, Cycle_Time is highlighted in Red

Name ID DLC Cycle_Time StartBit Length Initial_Value Minimum Maximum ;

FrontCam 0x608 2 40 8 2 10 0 100 ;

RearCam 0x608 2 40 8 2 10 0 100 ;

WheelSensor 0x068 2 100 8 2 10 0 100 ;

Radar 0x006 2 100 8 2 10 0 100 ;

Braking 0x618 2 100 8 2 10 0 100 ;

Mirrors 0x168 2 100 8 2 10 0 100 ;

CruiseControl 0x016 2 100 8 2 10 0 100 ;

Climate 0x268 2 100 8 2 10 0 100 ;

SOS 0x316 2 100 8 2 10 0 100 ;

Engine 0x016 2 100 8 2 10 0 100 ;

OtherSignals 0x165 2 100 8 2 10 0 100 ;

Below table is the modified Message_DB, Cycle_Time is highlighted in Red



ECU2 0x601 ADASInfo1 0x608 8 40 2 2 0 0 0 2048 ;

ECU3 0x602 OtherInfo 0x168 4 100 2 2 0 0 0 2048 ;

ECU3 0x602 OtherInfo1 0x268 4 100 2 2 0 0 0 2048 ;



ECU5 0x604 ADASInfo3 0x006 8 100 2 2 0 0 0 2048 ;

ECU5 0x604 ADASInfo2 0x316 8 100 2 2 0 0 0 2048 ;

ECU6 0x604 OtherInfo2 0x068 4 100 2 2 0 0 0 2048 ;

Now run the simulation and analyze the Latency graph


You can note that the latency for ADASInfo1 message has decreased as a result of decreased Cycle_Time. Similarly we can analyze for other signals and messages

Move Messages from one ECU to another, or one network to another

For moving Messages from one ECU to another, you will need to modify Message_DB and Filtering_DB of CAN_Bus.

The Message_DB with default configuration is shown below



ECU2 0x601 ADASInfo1 0x608 8 100 2 2 0 0 0 2048 ;

ECU3 0x602 OtherInfo 0x168 4 100 2 2 0 0 0 2048 ;

ECU3 0x602 OtherInfo1 0x268 4 100 2 2 0 0 0 2048 ;



ECU5 0x604 ADASInfo3 0x006 8 100 2 2 0 0 0 2048 ;

ECU5 0x604 ADASInfo2 0x316 8 100 2 2 0 0 0 2048 ;

ECU6 0x604 OtherInfo2 0x068 4 100 2 2 0 0 0 2048 ;

The Filtering_DB with default configuration is shown below

ECU Message_Array ;

ECU1 {"EngineInfo"} ;

ECU2 {"ADASInfo1","ADASInfo2","ADASInfo3","OtherInfo"} ;

ECU3 {"OtherInfo"} ;

ECU4 {"BrakingInfo","WheelSpeedInfo"} ;

ECU5 {"OtherInfo2"} ;

ECU6 {"OtherInfo","OtherInfo1","OtherInfo2"} ;

Run Simulation with default configuration

Let us look at the Latency graph for messages and also Latency for task Processing.

Latency graph for messages is shown below


Now let us move ADAS tasks ADASInfo1 from ECU2 to ECU1, ADASInfo2 and ADASInfo3 from ECU5 to ECU1 . Modified Message_DB and Filtering_DB is shown below. Modified lines are highlighted in red



ECU1 0x601 ADASInfo1 0x608 8 100 2 2 0 0 0 2048 ;

ECU3 0x602 OtherInfo 0x168 4 100 2 2 0 0 0 2048 ;

ECU3 0x602 OtherInfo1 0x268 4 100 2 2 0 0 0 2048 ;



ECU1 0x604 ADASInfo3 0x006 8 100 2 2 0 0 0 2048 ;

ECU1 0x604 ADASInfo2 0x316 8 100 2 2 0 0 0 2048 ;

ECU6 0x604 OtherInfo2 0x068 4 100 2 2 0 0 0 2048 ;

We also need to update the Filtering_DB. The modified Filetring_DB is shown below and updated lines are highlighted in Red

ECU Message_Array ;

ECU1 {"EngineInfo","ADASInfo1","ADASInfo2","ADASInfo3"} ;






The resultant latency graph is shown below

You can notice the difference in the latency for different messages.

Another important plot to look for is the Timing Diagram of ECU activity.

As there are no messages being generated for ECU2 and ECU5, the activity graph is not displayed.

Move Tasks from one ECU to another ECU

User can move the tasks from one ECU to another by modifying the “Task_List” Table available in the Top Level Model and also update the Filtering_DB if any dependent messages has to be listed.

The default Task_List table is as shown below

Task_Num Task_Name ECU ID Task_Rate Task_Time Priority Deadline ;

1 VideoProc ECU2 0x608 50.0e-3 50.0e-3 4 280.0e-6 ;

2 VideoProc2 ECU2 0x608 100.0e-3 20.0e-3 4 280.0e-6 ;

3 ABS ECU4 0x068 50.0e-3 40.0e-3 4 280.0e-6 ;

4 Other2 ECU5 0x006 100.0e-3 25.0e-3 3 280.0e-6 ;

5 ABS2 ECU1 0x618 50.0e-3 40.0e-3 4 280.0e-6 ;

6 Other ECU3 0x168 500.0e-3 10.0e-3 1 280.0e-6 ;

7 Control ECU4 0x016 100.0e-3 100.0e-3 5 280.0e-6 ;

8 Other3 ECU3 0x268 500.0e-3 10.0e-3 1 280.0e-6 ;

9 Other4 ECU5 0x316 100.0e-3 10.0e-3 5 280.0e-6 ;

10 Engine ECU2 0x016 50.0e-3 100.0e-3 4 280.0e-6 ;

11 Other5 ECU6 0x016 50.0e-3 100.0e-3 4 280.0e-6 ;

The Task generator has its own rate and can be controlled by modifying the “Task-Rate” parameter value in the table, user can also modify the Task Priority by varying the values in the table, higher the number higher the value. Each tasks are provided with its own deadline time and once the task processing is competed we can check if the task is completed in the given deadline time or not.

We also need to check if Filtering_DB has all the required messages for the corresponding ECU.

The default configuration of Filtering_DB is shown below;

ECU Message_Array ;


ECU2 {"ADASInfo1","ADASInfo2","ADASInfo3","OtherInfo"} ;





Let us run the simulation with default settings; the Task Latency graph provides the details on the total time taken to process each tasks. We also have generated a textual report that provides details on tasks that are exceeded the timing deadline.

The Task Latency graph is shown below

x-axis is Task number and y-axis is latency.

Let us modify the Task_List table, and move Tasks “VideoProc” and “VideoProc2” running on ECU2 to ECU5.

The modified Task_List table is shown below, modified lines are highlighted in Red

Task_Num Task_Name ECU ID Task_Rate Task_Time Priority Deadline ;

1 VideoProc ECU5 0x608 50.0e-3 50.0e-3 4 280.0e-6 ;

2 VideoProc2 ECU5 0x608 100.0e-3 20.0e-3 4 280.0e-6 ;

3 ABS ECU4 0x068 50.0e-3 40.0e-3 4 280.0e-6 ;

4 Other2 ECU5 0x006 100.0e-3 25.0e-3 3 280.0e-6 ;

5 ABS2 ECU1 0x618 50.0e-3 40.0e-3 4 280.0e-6 ;

6 Other ECU3 0x168 500.0e-3 10.0e-3 1 280.0e-6 ;

7 Control ECU4 0x016 100.0e-3 100.0e-3 5 280.0e-6 ;

8 Other3 ECU3 0x268 500.0e-3 10.0e-3 1 280.0e-6 ;

9 Other4 ECU5 0x316 100.0e-3 10.0e-3 5 280.0e-6 ;

10 Engine ECU2 0x016 50.0e-3 100.0e-3 4 280.0e-6 ;

11 Other5 ECU6 0x016 50.0e-3 100.0e-3 4 280.0e-6 ;

The modified Filtering_DB is shown below, modified lines are highlighted in Red

ECU Message_Array ;


ECU2 {"ADASInfo2","ADASInfo3","OtherInfo"} ;



ECU5 {"OtherInfo2","ADASInfo1"} ;


The resultant Task_Latency graph is shown below

Move Node from one network to another

In this analysis the baseline model will be CAN_Bus_Model_w_Tasks_V2_new.xml and we are moving Node6 from Segment 1 to CAN Segment 2. The model to consider for analysis will be CAN_Bus_Model_w_Tasks_V3.xml.

The VisualSim model of the two segments CAN model is shown below

To connect with additional CAN Network, we need to consider adding CAN_Bridge, Routing_Table, Bridge Table.

The Routing Table will have the details on how two networks are connected over CAN_Bridge. The Routing Table is shown below

User will update the Bridge table and provides facility to filtering the messages that needs to be sent across the bridge to another network. User can select all messages to be sent across by defining “ALL” for the identifier field or specify specific message ID. For example if the data from Radar should be moved to another CAN network, we should specify ID “0x006” in the BridgeSwitch Table.

Src_Net Dest_Net Identifier ;

SW1_CAN1 ALL 0x006 ;

SW1_CAN2 ALL 0x708 ;

SW1_ETHER1 ALL ALL ;

As user can connect to multiple CAN networks using the CAN Bridge; user can select to which CAN network he/she wants to send the message by defining the Destination network name or broadcast messages to all networks.

In addition, user should make sure that the incoming message is listed in the Message_DB and Filtering_DB of second CAN segment

With default settings, CAN_Bus2 Message_DB is as shown below.


ECU7 0x600 ABSData1 0x068 8 1 2 8 0 0 0 2048 ;

ECU8 0x600 OtherInfo 0x268 8 1 2 8 0 0 0 2048 ;

Message with ID “0x268” and name “OtherInfo” is sent from the first CAN segment.

Filtering_DB is shown as below

ECU Message_Array ;

ECU7 {"Ignition_Info1","ABSData1"} ;

ECU8 {"Radar1","OtherInfo"} ;

“OtherInfo” message will be accepted by ECU8

When we run simulation, the timing diagram of ECU activity in segment 1 and segment 2 is shown below

Segment 1Segment 2

We can see that, as we have moved Node6 from Network 1 to Network 2, we can’t see the timing diagram for ECU6 in Network1 and we can see the activity in Network 2.

Similarly we can look at the latency of messages and task as well.

introductionmirabilisdesign.com/new/software/demo/automotive/can_bus... · web viewthe can_bus...

Documents