ICSim++

Instrument Cluster Simulator for SocketCAN

By: University of Adelaide

ICSim++ is a Linux-based CANbus simulator designed for Instrument Cluster (IC) simulations using SocketCAN. It is recommended to install Kali Linux on your system for optimal compatibility.

Installing Kali Linux

1. Download Kali Linux:

   • Visit the official Kali Linux website: Download Kali Linux
   • Choose the appropriate version based on your system architecture (32-bit or 64-bit).
   • Follow the installation instructions provided by Kali Linux for your hardware Kali Linux Installation.

2. Set up Kali Linux:

   • Complete the installation process according to the guidelines provided by Kali Linux.
   • Ensure that your Kali Linux installation is up to date.

Cloning and Setting Up ICSim++

1. Open a terminal in Kali Linux.

2. Clone the ICSim++ repository into your Kali Linux system:

    git clone git@github.com:AUCyberLab/ICSimPlusPlus.git

Then go to the cloned repo

    cd ICSim_Plus_Plus

2. Install prerequisite libraries: You will need to install some prerequisites libraries:
   • SDL2
   • SDL2_Image
   • can-utils

    sudo apt-get install libsdl2-dev libsdl2-image-dev can-utils

3. To update the compiled files

    sudo make all

4. Use the provided setup_vcan.sh script to set up a virtual CAN interface:

    ./setup_vcan_multiple.sh

Alternatively, manually set up a virtual CAN interface with the following commands:

    sudo modprobe can
    sudo modprobe vcan
    sudo ip link add dev vcan0 type vcan
    sudo ip link set up vcan0

Usage

1. Start the Instrument Cluster (IC) simulator:

./icsim vcan1 &

2. Launch the controls for interaction:

./controls vcan6 &

Use the keyboard for optimal interaction with the controls interface. The controls application generates CAN packets based on keyboard inputs, which the IC Sim uses to simulate changes in display

Troubleshooting

• If encountering an error related to canplayer, ensure can-utils is properly installed and in your system's PATH.
• Ensure the controls window is active for the controller to respond correctly.

Additional Notes

• If lib.o fails to link, compile can-utils and copy the compiled lib.o to the icsim directory.
• To address the "read: Bad address" error encountered when running ./icsim vcan0 &, it's crucial to update the SDL libraries or modify the Makefile's CFLAGS to indicate the correct SDL.h location. This issue often arises due to outdated SDL libraries. Begin by ensuring you have the latest SDL2 libraries installed; use package managers like apt-get or yum for updates. If the problem persists, create symbolic links manually for SDL.h files or edit the Makefile's CFLAGS to specify the proper SDL.h path. For instance, you can use the ln -s command to create symlinks or modify the Makefile's CFLAGS to include -I/path/to/SDL2 with the correct SDL.h location. These steps should help resolve the "read: Bad address" message and ensure smooth execution of ./icsim vcan0 &.

Simulated ECUs and their CAN IDs in ICSim++

Sr.	ID (hex)	ECU Function	Control Type
1	244	RPM (tachometer)	System
2	245	Speed (speedometer)	System
3	246	Oil Temperature	System
4	247	Radiator Temperature	System
5	239	Battery Voltage	System
6	248	Fuel Level Sensor	System
7	19B	Doors	Human/User
8	188	Indicators/blinkers	Human/User
9	238	Throttle	Human/User
10	249	Headlights	Human/User
11	241	Handbrake	Human/User
12	240	Wiper	Human/User

Scripted Input Mode

Users can run the simulator in scripted mode by the command “. /controls -I scripts/filename.txt”, where the filename.txt file contains a predefined sequence of actions in the scripts folder.

./controls vcan6 -I scripts/input.txt &

The "delay" command is in milliseconds, so it is possible to create a timed sequence, which makes the simulation of vehicle behavior over time quite realistic.

Sample Script

The script uses a simple predefined, as illustrated below, human-readable syntax:
• Each line represents a single action or delay.
• Actions are formatted like "component action", with a space in between.
• Parts consist of vehicle elements such as doors, lights, wipers, etc.
• Actions are states, such as "on," "off," "locked," etc.

delay 2000
all_door unlocked
delay 2000
wiper on
throttle on
delay 2000
left_signal ON
delay 2000
all_door locked
delay 2000
all_door unlocked
delay 2000
wiper OFF
all_door locked
delay 2000
all_door unlocked
delay 2000
all_door locked
head_light off
left_signal off
handbrake off
throttle off
delay 2000
front_left_door unlocked
delay 2000
front_left_door locked
delay 2000
front_right_door unlocked
delay 2000
front_right_door locked
delay 2000
back_right_door unlocked
delay 2000
right_signal on 

Note: Please refer to sample_command.txt in scripts folder.

Data Logging and Analysis

ICSim++ offers flexible logging options with two flags, “-l” for logging and “-c” for enabling comments, along with three following types of optional log files.

1. a (all) – It would enable the capture of all the traffic/data frames on the CAN interface.
2. u (user) – This option only logs the user-controlled ECU data.
3. s (system) – It captures system-controlled ECUs in the log file.
4. t (segments logs) – It generators individual CAN segemetn logs.

# Launching ICSim++ in logging and commenting mode

./setup_vcan.sh
./controls vcan6 &
./icsim vcan1 -l aust -c aust &

So, employing the command flags “-l aus -c us” the system will produce a trio of distinct log files: a comprehensive record encompassing all network traffic, a focused file containing exclusively user-controlled ECU information, and a separate document dedicated to system-controlled data. However, commenting would only be enabled in the system and user-controlled log files, not the log file with all the traffic.

Note: The background noise can also be disabled with the “-X” flag.

Log File Management

The application currently saves log files in a designated log folder. When executing multiple test scenarios, the system appends new log entries to an existing file if one is present in the folder. This approach may lead to the conflation of log data from different test scenarios.

Recommendation for Testing Multiple Scenarios

To maintain clear separation between test scenarios and ensure accurate logging, it is advisable to adopt the following practice:

1. After completing each test scenario, relocate the generated log file to a separate directory.
2. This relocation process should be performed before initiating a new test scenario.

By following this procedure, each test scenario will generate its own distinct log file, facilitating more effective analysis and troubleshooting of individual test cases.

Detailed Packet Information

A CAN bus packet comprises several key components: a timestamp, an interface designation, a message ID, and the data payload. The timestamp indicates when the message was captured, providing a chronological context for the data. The interface designation (e.g., VCAN0) specifies the virtual CAN interface through which the message was transmitted or received. The message ID uniquely identifies the type of message being transmitted, enabling the differentiation of various vehicle functions and controls. Lastly, the data payload contains the communicated information, such as the status of doors, blinkers, or the engine's tachometer readings

CAN bus traffic log entries provide valuable insights into the status of vehicle doors, such as the following captured/sniffed log entry of the door’s status.

(1711370446.712092) VCAN0 19B#000000000000 //Door All Unlocked

Timestamp: "(1711370446.712092)" – This part of the data frame is the log entry's timestamp in Unix timestamp format; the number of seconds elapsed since January 1, 1970, represents when this message was captured. Moreover, this timestamp allows for the precise order of each message in the vehicular communication network to be tracked.

Interface: "VCAN0"—This specifies the virtual CAN interface, "VCAN0," on which the message was transmitted. Identifying the network segment is essential for testing and simulation purposes.

Message Identifier (ID): "19B#" - The "19B#" that follows is the message identifier in hexadecimal format that shows the message ID that distinguishes between different types of messages on the CAN bus. The "#" symbol is a delimiter, separating the ID from the subsequent data payload.

Data Payload: "00 00 00 00 00 00" - This section of the data framer contains the actual data being transmitted, and a sequence of six bytes (each represented by two hexadecimal digits) carries the actual information being transmitted. The CAN data is organized into each pair of digits/nibbles representing one byte. In this case, six bytes of data are transmitted, each byte consisting of two hexadecimal digits. In both log entries, the data section comprises six hexadecimal values. However, it’s worth noting that while this example shows six bytes, CAN messages can contain anywhere from one to eight bytes of data.

Optional Interpretive Comments: //Door All Unlocked - The comments for each log entry can be enabled. These comments explain the message identifier and data payload, facilitating easier interpretation and analysis of CAN bus traffic.

Compatibility with CAN-Explorer

ICSim++'s compatibility with the CAN-Explorer graphical tool allows users to visualize raw CAN values transmitted through a graphical interface.

To install can-explorer, execute the following command:

pipx install can-explorer

After launching ICSim++, use the following command to run can-explorer:

can-explorer

Additional Troubleshooting Tips

• Plguin to install for LLM sudo apt install libcurl4-openssl-dev sudo apt-get install libsdl2-dev sudo apt-get install libsdl2-image-dev

• run sudo make all

• RUN LLM ./llm_command_generator ./scripts/input.txt

• Free TCP Port if not getting free sudo fuser -k 8080/tcp

• --icsim--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