Automotive Embedded Testing

➢ What is SDLC (Software Development Life Cycle)?

SDLC is a process used by software developers to design, develop, test,
and deploy software in a structured and efficient way.
Main Phases of SDLC:
1. Requirement Gathering – Understand what the customer needs.
2. Design – Plan how the software will look and work.
3. Development – Code the software.
4. Testing – Check for bugs or issues.
5. Deployment – Release the software to users.
6. Maintenance – Fix issues and update the software as needed.
EXAMPLE
What is SDLC? (Software Development Life Cycle)
It’s like building a mobile app — say, a food delivery app like Swiggy or
Zomato.

Real-life Example:
You want to build a food delivery app.
1. Requirement Gathering – Ask: What should the app do?
(Customer’s order food, restaurants get orders, delivery agents
deliver food.)
2. Design – Sketch how the app screens should look (login page,
restaurant list, cart).
3. Development – Developers write the code to make it work.
4. Testing – Tester’s check: Can users log in? Can they place orders?
5. Deployment – App goes live on Play Store.
6. Maintenance – After launch, fix bugs and add new features.
STLC (Software Testing Life Cycle)
STLC is the step-by-step process followed to test software, ensuring
it meets quality standards.
 Phases of STLC:
1. Requirement Analysis
2. Test Planning
3. Test Case Design
4. Test Environment Setup
5. Test Execution
6. Test Closure
STLC focuses only on testing activities, whereas SDLC covers the entire
software development.
EXAMPLE
What is STLC? (Software Testing Life Cycle)
This is just the testing part of the SDLC, like double-checking the food
before it reaches the customer.
Real-life Example in the App:
You’re a tester for the food app:
1. Requirement Analysis – You understand what to test (e.g., order
placement).
2. Test Planning – Plan how many people are testing, what to test
first.
3. Test Case Design – Write test cases like: "What happens if the
user orders without logging in?"
4. Test Environment Setup – Install the app in a test phone, connect
to test servers.
5. Test Execution – Actually test the app: try logging in, ordering food,
making payment.
6. Test Closure – Once everything works fine, testing is closed.

V-Model (Verification and Validation Model)

The V-Model is an SDLC model where testing is done in parallel with
development. It is shaped like a "V" to show the relationship between
development and testing.
Left Side (Verification):
• Requirement Analysis → Acceptance Testing
• System Design → System Testing
• Architecture Design → Integration Testing
• Module Design → Unit Testing
Right Side (Validation):
• Each development stage has a corresponding test stage.
EXAMPLE
What is Verification & Validation (V&V)?
Example 1:
You're building a calculator app.
• Verification: Did you follow the design correctly?
(e.g., Is the "+" button working as per the technical design?)
• Validation: Does the app do what the user expects?
(e.g., When users press 2 + 2, does it actually give 4?)
Example 2 (Food App):
• Verification: Code is written correctly, and design is followed.
• Validation: Customers can easily place orders and track delivery
without issues.
SDLC (SOFTWARE DEVELOPMENT LIFE CYCLE)
• Software Development Life Cycle is a process used by the software
industry to design, develop and test high-quality software.
• produce high-quality software that meets the customer
expectations,
• completion time and cost
1.Gathering and analysis
• SRS Documents (Software requirement specification)
2.Planning
• We plan the entire project based on the requirement
• What are the features implement
• Time
• Cost
• Resources
3.Architectural design
• System architectural design (High level design and low level)
• Define architecture of the system – hardware, software,
communication
Output: System Architecture Document
• This includes high-level designs and Low level
• Output: Architectural design document

4.Software development
• Once the design is ready, developers write the actual code to build
the software based on design.
5.Testing
• testing the software to reach the customer expectations and
product should be bug free
6.Deployment
• Once testing is complete and the product is stable, it’s deployed in
the production environment.
7. Maintenance
• After deployment, the software needs regular updates and support
to address any issues. This is the maintenance phase
SDLC Models
• Azile model
• V and V model
• Waterfall model
• Spiral model
• Fine bone model
V and V model: Verification and Validation
V- Model is also known as Verification and Validation Model. In this
model Verification & Validation goes hand in hand i.e. development and
testing go parallel. Each phase must be completed before the next phase
begins. In V-model where execution of processes happens in a
sequential manner in a V-shape that’s why it’s called as V model.

Verification phase Validation phase

1.Requirement analysis:
At this phase, the focus is on gathering and analysing the customer’s
requirements to ensure a clear understanding. These requirements
are documented in a Software Requirements Specification (SRS). This
phase corresponds to User Acceptance Testing
 2.System Design
Once requirements are clear, the next step is to define the overall
system architecture and design
3. Architecture design:
Here, the system is broken down into modules, and their interactions
are defined. This phase ensures the system's overall functionality is
planned. The corresponding testing phase is integration testing."
Example: Design
5.Module design
After the high-level design is analysed, each component in the high-
level design is discussed in detail. defining how each function works or
what inputs and outputs it has. This corresponds to unit testing.
Example: Inside Navigation module, design how "Search function
works, voice guidance" works step by step
6.Coding Phase of V-Model
In this phase the actual coding is done based on the low-level design.
7.Unit Testing
Here each module goes through the testing by executing the code
written for that module. whether each module can perform its
required functions or not. Performed by the developers
8.Integration Testing
Integration testing, we do end-to-end flow testing by integrating all
the modules, we check whether each module is working properly with
other modules or not.
9. System Testing
System testing is performed in the system design phase. Here the
functionality of the whole system is checked by checking the
integration of hardware and software and how well they are
coordinating with each other.
10. Acceptance Testing
User Acceptance testing happens in the requirement analysis phase.
Here the system is checked in the user environment to ensure it meets
customer expectations and is ready for deployment."
STLC (Software testing life cycle)
The Software Testing Life Cycle (STLC) is a systematic approach to
testing a software application to ensure that it meets the
requirements and is free of defects.

1. Requirement Analysis
In this phase, the testing team understands the requirements given in
the Software Requirement Document.
We try to find:
• What features need to be tested
• What tools we may need
• What kind of test data is required"

Example:
If we are testing infotainment features like Bluetooth, Navigation, FM, we
need to check how these will be tested and what all we need.
2. Test Planning
This phase is about creating the test strategy and test plan.
We decide:
• Who will test what
• What tools to use
• How much time it will take
• What the scope is"

Example:
For infotainment, we may plan to use CANoe, JIRA for bug reporting, and
define a schedule.
3. . Test Case Design
In this phase, testers write test cases. Test cases are step-by-step
instructions to test each feature."
We write:
• Positive test cases
• Negative test cases

Example:
Test case for checking whether volume buttons increase/decrease audio
properly.
4. Test Environment Setup
Here, we prepare the environment needed to test.
This includes:
• Connecting ECUs
• Power supply
• Installing testing tools
• Flashing software"

Example:
Setting up infotainment unit on a test bench with power and CAN tool.
5. Test Execution
"This is the actual testing phase. We follow the test cases and check if the
system is working as expected."

Example:
We press the volume button and check if the speakers respond.
6. Defect Reporting
"If any test fails, we report it as a bug.
We mention:
• Bug description
• Steps to reproduce
• Expected vs Actual result
• Attach logs or screenshots"
Example: If Bluetooth is not connecting properly, we raise a bug in JIRA.
7. Test Closure
"This is the final phase of STLC.
We prepare
• Test summary report
• Total test cases executed
• Bugs found and fixed
• Lessons learned"

Example:
Report showing 50 test cases executed, 3 bugs found, and all resolved.
➢ Ignition Mode
No ECU or system is active

Use:
– To completely shut down the vehicle
– Save battery
– Parked condition

Only basic systems turn ON like:

• Infotainment System & BCM (Radio, Bluetooth)
• USB charging
• Cigarette lighter/power socket

Use:
To listen to music, charge phone, or use screen without starting engine
Battery will drain slowly if used for long
All ECUs and modules are activated
• Instrument Cluster
• ABS, Airbag
• Infotainment
• HVAC (AC control)
• BCM, EPS, VCU etc.
1. Map Display Functionality
Ensure the map is loading properly when navigation is launched.
We test both 2D and 3D map views, along with day/night modes
depending on light sensor or manual settings. Also, we validate
smooth map panning, zoom in/out gestures, and map orientation
(north up, heading up).
2. Search Functionality
We verify different search methods like:
o Address input
o POI (e.g., petrol bunk, ATM)
o Coordinates
o Voice-based destination search
o We also check the "Point on Map" feature (pin drop), which
allows users to touch and select a destination.
3. Route Calculation & Guidance
After setting a destination, we validate if the route is calculated
correctly.
o We test multiple route types like Fastest, Shortest, and Eco-
friendly routes.
o Turn-by-turn instructions, voice guidance, and lane assistance
are also validated.

4. Navigation Alerts
We test for timely voice alerts such as:
o Turn left/right
o Speed breaker warnings
o School zone or one-way road alerts
o Also, we verify the alert sound volume controls and
mute/unmute options.

5. Traffic Information
If the vehicle is connected to internet (or via connected car features),
we validate real-time traffic status on the route.
o We also test whether the system suggests alternative routes in
case of traffic.
6. Voice Command Testing
We test commands like:
o "Navigate to home"
o "Find nearest hospital"
o Navigation Settings
o We verify options like:
o Avoid highways/tolls
o Map theme/color
o Units (km/miles)
o Auto rerouting toggle

7. Navigation During Phone Calls:

o Navigation voice should mute or reduce during calls.
o Map guidance should continue to screen.
o After call ends, voice guidance should resume.
o Check with Bluetooth, AA, and CP calls.

8. Navigation During Media Playback:

o Media volume should reduce during navigation voice.
o Navigation voice should be clear and audible.
o After guidance, media volume should return to normal.
o Test with FM, USB, Bluetooth Audio, etc.
Add Waypoints (Tour Points)
• Users can add intermediate stops (tour points) between the
starting point and destination

BT Phone book
• Whether the "Contacts download request" popup is received on
the mobile phone while pairing with the infotainment system.
• If the user tries to download more than 5000 contacts, whether
the system displays an OSD saying “Maximum number of
contacts exceeded (Max 5000)”.
• Whether the user can search for contacts using the dial pad and
contact search screen.
• Whether contacts with long names or special characters are
handled correctly.
 • Whether contacts are synced properly after reconnecting the
phone.
• Whether no contacts are shown if contact access is denied
during pairing.
• Whether contact images are displayed correctly (if supported by
system and phone).
• When privacy mode is enabled, whether contacts are hidden
successfully.
• When privacy mode is disabled again, whether hidden contacts
reappear properly.

BT AUDIO – Test Cases

• Whether Play, Pause, Next, and Previous options work correctly
in Bluetooth media.
• Whether Fast Forward and Fast Rewind functions operate as
expected.
• Whether Repeat Song, Repeat Folder and Repeat all options
work correctly.
• Whether Shuffle on and Shuffle Off work as expected.
• Whether song title, artist, and album art information are
displayed properly.
• Whether Bluetooth audio volume can be adjusted
independently.
• Whether music pauses automatically during an incoming call.
• Whether music resumes automatically after the call ends.
• Whether audio quality is clear and stable during Bluetooth
music playback.
• Whether steering wheel control buttons (Mute, Volume Up,
Volume Down, Seek Up, Seek Down) work during Bluetooth
audio playback.
• Whether Bluetooth audio resumes after turning
ignition OFF and ON.
BT CALL – Test Scenarios
• Whether mobile phone is pairing with infotainment
successfully.
• Whether the phone reconnects automatically after turning the
ignition OFF and ON and maintain the call.
• Whether a call can be made from the infotainment dial pad.
• Whether a call can be made from the synced contact list or call
history list.
• When privacy mode is enabled, whether contacts are hidden
successfully.
• When privacy mode is disabled again, whether hidden contacts
reappear properly.
• Whether an incoming call can be answered using the
infotainment screen or steering control.
• Whether speed dial functionality works as expected.
• Whether the user can end a call using screen or steering
buttons.
• Whether an incoming call can be rejected from the screen and
Steering wheel control.
• Whether the mute and unmute functions work during a call.
• Whether the call duration is displayed correctly on the screen.
• Whether the system supports both Hands-Free Mode and
Handset Mode, and whether the user can switch between them
successfully.
• Whether the infotainment handles an ongoing call properly
when ignition is turned OFF or ON.
• Whether the caller’s name or number is displayed correctly
during an incoming call.
• During an active Bluetooth call, if the user presses any HK (hard
key) button like Media, Seek Up, or Seek Down, whether an on-
screen message appears stating “Feature is
unavailable during call”.
FM/AM Radio Test Cases
1. Seek Up
• Meaning: Moves from the current frequency to the next available
clear station.
Example:
If you are on 91.1 FM and press, Seek Up, it jumps to the next
strong signal like 92.7 FM.
2. Seek Down
• Meaning: Moves from the current frequency to the previous clear
station.
Example:
If you are on 94.3 FM and press, Seek Down, it goes to 93.5 FM.
3. Auto Seek Up
• Meaning: Automatically searches upwards for multiple stations
in sequence.
Example:
Long pressing the Seek Up button will make it keep finding the
next strong stations until you release/stop it.
4. Auto Seek Down
• Meaning: Automatically searches downwards for multiple
stations in sequence.
5. Scan Option
• Meaning: Gives a short preview of all available stations one by
one.
Example:
Plays 91.1 FM for 5 sec → 92.7 FM for 5 sec → 93.5 FM for 5 sec…
until you stop at the one you like.
6. Refresh
• Meaning: Re-scans and updates the station list.
Use: Helpful if a new FM station has started in your area and you
want it to appear in the list.
7. Station List
• Meaning: Shows the list of stations already scanned and stored.
 Example:
You can directly select 91.1 FM, 92.7 FM, 93.5 FM from the list
without tuning manually.
8. Favourites
• Meaning: Lets you save your preferred stations for quick
access.
Example:
If you mark 92.7 FM as favourite, you can play it instantly with one
tap.
9. Radio Noise Cancellation / Reduction
• Meaning: Reduces the background “shhh” noise in weak signal
areas.
How: Uses filters & DSP (Digital Signal Processing) to improve
sound clarity for voice/music

1. Bluetooth/Phone Connectivity Check

Goal: Make sure the phone connects to the car system properly.
• Is Bluetooth ON in the car and mobile?
• Does the infotainment system detect the phone?
• Can we enable messaging access permissions?
2. Message Sync Test
Goal: Verify that recent messages are synced and shown on the car
display.
• Are recent SMS/WhatsApp messages pulled into the system?
• Is the sender’s name showing correctly from contacts?
• Are unread messages highlighted?
3. Voice Reading of Messages
Goal: The system should read messages aloud while driving.
• Does the system read the message clearly when you ask,
“Read my messages”?
• Can it pronounce names and content correctly?
• Is the feature working even when music is playing?
4. Voice Reply Functionality
Goal: Send a reply using only your voice.
• When you say, “Reply to John”, does it open the reply prompt?
 • Can you speak your message clearly and is it converted to text
properly?
• Does the system confirm the message before sending?
5. Manual Reply (When Stationary)
Goal: When parked, you should be able to type a reply on the screen.
• Is the on-screen keyboard responsive?
• Can you delete/edit text easily?
• Does “Send” button trigger the message?
6. Notification Handling
Goal: Proper alerts for new messages without distraction.
• Does a new message show a popup or voice alert?
• Is it shown only when safe (e.g. car is not in motion)?
• Can the driver dismiss or mute notifications easily?

Bluetooth Profiles:
1. GAP (Generic Access Profile)
• It defines how Bluetooth devices discover each other, establish
connections, and set security modes.
• It is the foundation layer — without GAP, higher profiles like
HFP, A2DP, MAP cannot start communication.
Key GAP functions:
➢ Device Discovery – Scanning & advertising for nearby
devices.
➢ Pairing & Bonding – Exchanging PIN/keys for secure
connection.
➢ Connection Establishment – Initiating or accepting a
Bluetooth link.
➢ Security Management – Selecting
authentication/encryption level.
2. PBAP (Phone Book Accessing Profile)
• Phone Book Accessing Profile is Bluetooth profile; it allows the
infotainment system to access the contacts and call logs to the
connected mobile device.
3. MAP (Message Accessing Profile)
• MAP is Bluetooth profile; it allows the infotainment system to
access the Messages to the connected mobile device. So, we
receive and send SMS messages via connected device.
 4. BIP (Basic Imaging Profile)
• BIP is designed for transfer the images between the mobile and
connected device (infotainment)
Example: profile picture of the contacts and album art during
media play back.
5. HFP (Hands Free Profile)
• It is used for making and receiving voice calls over Bluetooth
without holding the phone.
• By using these profiles, we make and receive the phone call,
and it enables hands free calling (we talk with car infotainment
speaker without holding phone)
6. AVRCP (Audio Video Remote Control Profile)
• AVRCP is a Bluetooth profile, it allows the remote-control
interface during the media play back like audio or video, so we
can use the functionalities like play, pause, Next/Previous
Track, Fast Forward / Rewind, Volume Control.

7. A2DP (Advanced Audio Distribution Profile)

• A2DP Profile is BT profile; it enables wireless streaming of high-
quality audio from one device to another device.
Example: we can play the music from our mobile phone, and we
can listen through the car infotainment speaker.
8. SAP (SIM Access Profile)
• SAP is a BT Profile; it allows the SIM Card of the connected
mobile device for cellular network connectivity.

Android auto/CarPlay Test cases

1. If I connect an Android Auto supported phone via USB cable, first
the “Reading USB” message should be displayed, and then the
“Android Auto Initialization (AA INIT)” popup should appear on the
infotainment screen.
2. If I click on the “Yes” button in the Android Auto Initialization
popup, Android Auto should launch on the infotainment screen.
3. If I click on the “No” button in the Android Auto Initialization
popup, the “Charging Device” message should be displayed on
the screen.
4. Check whether the Android Auto icon is visible in the
Media/Home menu screen once connected.
5. If I disconnect the USB cable, Android Auto should close and
return to the previous screen.
6. After connecting Android Auto using a USB cable, Bluetooth
should automatically turn on and connect, If I disconnect the USB
cable, Android Auto should close and the system should return to
the home screen, but the Bluetooth connection should remain
active.
7. If I want to connect wireless Android Auto, I will first pair the
phone via Bluetooth. After pairing, if the device supports wireless
Android Auto, an initialization popup should appear with the
message: “The device supports Wireless Android Auto. Do you
want to launch Android Auto?” with Yes and No buttons. If I click
on the Yes button, Wireless Android Auto should launch on the
infotainment screen. If I click on the No button, only the Bluetooth
connection should remain active, and Android Auto should not
launch.
8. Whether Google Maps or any supported navigation app opens
correctly in Android Auto.
9. Whether navigation voice instructions play clearly through the
infotainment speakers.
10. Whether I can make and receive phone calls using Android Auto
interface.
11. Whether I can access recent call history and contacts through
Android Auto.
12. Whether SMS messages are received and shown as notifications
with options to “Listen” or “Reply” using voice commands.
13. Whether Google Assistant launches and responds correctly when
I say “Hey Google” or press the mic icon or steering wheel VR
button.
14. If I switch between Android Auto apps (e.g., from Maps to Music),
the transition should be smooth and without crashing.
15. Check how the system handles unsupported phones (e.g., show
"Device not supported" OSD).

Android Auto Media

1. Check if media apps like Spotify, YouTube Music, etc., are
accessible and playing smoothly via Android Auto.
 2. Whether play, pause, next, and previous buttons are work
properly while using Android Auto media apps.
3. While playing music through Android Auto, the album art should
be displayed properly on the infotainment screen.
4. If I press the SWRC Mute button, the Android Auto music should
mute, and the mute icon should appear on the volume status bar.
5. While playing AA music, If I rotate volume knob, the music is
increase or decrease as per the key input
6. If I long press PTT button on SWRC (Push to talk) then AA google
voice should be activated.
7. During AA VR mode, if I press power HK, track up/down HK, Radio
HK, Media HK, SWRC Mode key, SWRC Mute key, then “This
feature is currently not available” OSD Should display on AA VR
Screen.
8. In the Android Auto main screen, if I click on the OEM logo icon,
the screen should switch from Android Auto to the OEM
(infotainment system) home screen.

USER PROFILES
• Infotainment systems use user profiles like “Driver 1,” “Driver 2,”
and “Guest” to personalize the in-vehicle experience.
• The primary purpose of profiles is to store individual settings and
preferences for different users.
• Each user can have their own customized environment without
affecting others’ settings.
• Example:
• One driver can save preferred radio stations, seat position, and
navigation history.
• Another driver can store their own unique preferences separately.
• The “Guest” profile provides a basic, non-customizable
experience for temporary users.
• Guest profiles usually reset to default state after each use.
• This separation of settings makes the system more convenient and
user-friendly for multiple people sharing the same vehicle
Core Profile Functionality
Change Profile:
• Test: Navigate to "Change Profile" and select a different
profile.
 • Expected Outcome: The system should successfully switch to
the selected profile and load its corresponding settings.
Rename Profile:
• Test: Go to profile settings and rename a profile (e.g., "Driver
1" to "John").
• Expected Outcome: The new name should be displayed
consistently.
Set Profile Image:
• Test: Select a profile and upload/set a profile image.
• Expected Outcome: The selected image should be shown
next to the profile name.
Password Management:
Test: Set, change, or delete a password for a profile. Restart the
system (ignition OFF/ON).
Expected Outcome: The system should prompt the password on
reboot. All password functions (change, delete) should work
correctly.
Delete Profile:
Test: Delete a profile (e.g., Driver 1).
Expected Outcome: The profile should be permanently removed,
and all associated settings (Bluetooth, volume, image) should be
reset to default values.
Profile Settings Isolation (Crucial Feature)
Per-Profile Settings:
Test: Set different values for Driver 1 (e.g., volume: 30, a paired
Bluetooth device, a custom image).
Test: Switch to another profile (Driver 2 or Guest).
Expected Outcome: The settings from Driver 1 should not carry
over. Each profile must maintain its own independent settings.
Specific Isolation Test Cases:
• Language: Setting a unique language for each driver should
persist after a profile switch.
 • Bluetooth: A device paired under Driver 1 should not auto-
connect when the system is switched to Driver 2.
• USB Media: Music playback started under Driver 1 should
not resume from the same point when switching to Driver 2.
Edge Cases & Guest Profile
Rename to Existing Name:
• Test: Try to rename "Driver 2" to "Driver 1".
• Expected Outcome: The system should prevent duplication
and display a warning message (e.g., "Profile name already
exists").
Guest Profile Behavior:
• Guest Profile Limitations: The Guest profile should not
allow changes to the profile image or the setting of a
password. A message should indicate this limitation.
• Guest Profile Reset: Any changes made in the Guest profile
(e.g., volume) should be reset to default settings after the
ignition is turned OFF and then ON (if the Guest mode is
session-based).

Quiet Mode Module

• Module Name: Quiet Mode Module – Functional Test Cases
• Purpose:
• To adjust the infotainment system’s audio output for
specific situations.
• Functionality when Quiet Mode is enabled:
• Rear speakers are muted.
• Front speakers’ volume is reduced to level 5.
• Objective:
• To ensure audio playback is less disruptive.
• Especially beneficial for rear seat passengers (e.g., when
they are resting).
Core Quiet Mode Functionality
Activation via Steering Wheel Button:
Test Case: Set the steering wheel custom button to trigger
"Quiet Mode" and press it.
Expected Outcome: Quiet Mode should toggle ON/OFF,
and a corresponding icon should appear or disappear on
the status bar.
Behavior with High Volume Playback (above 25):
Test Case: Play media at a volume above 25, then enable
Quiet Mode.
Expected Outcome: Rear speakers should be muted, front
speakers' volume should automatically reduce to 5, and the
Quiet Mode icon should appear.
Volume & Persistence
Manual Volume Adjustment During Quiet Mode:
Test Case: Enable Quiet Mode while media is playing, then
manually adjust the volume.
Expected Outcome: The Volume OSD (On-Screen Display)
should appear, rear speakers should remain muted, and the
front speakers should reflect the updated volume.
Persistence After Ignition Cycle:
Test Case: Enable Quiet Mode, turn ignition OFF and then
ON again.
Expected Outcome: Quiet Mode should return to the default
OFF state, and the status bar icon should not be shown
Quiet Mode Integration
Behavior with Different Media Sources:
Test Case: Enable Quiet Mode while playing Bluetooth
Audio, USB Music, and FM Radio.
Expected Outcome: Rear speakers should be muted, and
front speakers should reduce to volume 5 for all supported
media sources. The Quiet Mode icon should be displayed.
Interaction with Navigation Announcements:
Test Case: Enable Quiet Mode, start media playback, and
trigger a navigation announcement.
 Expected Outcome: Navigation guidance should play
normally through the front speakers. Rear speakers should
remain muted, and Quiet Mode should stay ON.
Edge Case Scenario
Quiet Mode + Bluetooth Call:
Test Case: Enable Quiet Mode, then receive a Bluetooth
call.
Expected Outcome: Quiet Mode should remain active. The
voice from the call should play only through the front
speakers, and the rear speakers should remain muted.

USB AUDIO & VIDEO TEST CASES

Module Name: USB Media Module
Objective: To verify the functional behavior and integrity of the USB
media playback feature within the infotainment system.
Key Areas Tested:
➢ Connection and Recognition
➢ Media Playback Controls
➢ Display and Metadata
➢ Integration with Vehicle Systems (Steering Wheel, Call,
Reverse Camera)
➢ File and Data Handling (Support, Errors, Persistence)
Initial Connection & File Handling
USB Connection:
Test Case: Connect a USB to the infotainment system.
Expected Outcome: The screen should display a "Reading
USB" message.
USB Music Screen Access:
Test Case: Tap on "USB Music" in the media gate screen.
Expected Outcome: The system should switch to the USB
Music screen.
File Format Support:
Test Case: Check if the system supports various audio and
video file formats.
 Expected Outcome: The system should successfully play
supported file formats.
File Capacity:
Test Case: Verify if the system can handle up to 20,000
audio files and 10,000 video files.
Expected Outcome: The total number of audio and video
files should be displayed correctly
Playback Controls & Display
Basic Playback Controls:
Test Case: Verify the functionality of play, pause, next,
previous, fast forward, and fast rewind buttons.
Expected Outcome: All controls should work correctly.
Advanced Playback Controls:
Test Case: Check the functionality of repeat song, repeat
track, repeat folder, shuffle on, and shuffle off.
Expected Outcome: All shuffle and repeat functions should
work properly.
Metadata & Album Art Display:
Test Case: Verify that the song name, artist name, and
album art are displayed correctly.
Expected Outcome: The correct metadata should be
shown. If the title is too long, the text should scroll
(marquee) to display the full information.
Progress Bar:
Test Case: Check the progress bar, including drag-and-drop
and tap-to-update functionality.

Vehicle System Integration

Steering Wheel Controls:
Test Case: Verify that steering wheel buttons (seek up, seek
down, volume up, volume down, and mute) work correctly
while playing USB songs.
Expected Outcome: All controls should function as
expected.
 Display ON/OFF:
Test Case: Turn off the display while music is playing.
Expected Outcome: The screen should go off, but the music
should continue playing. Tapping the screen should turn it
back on.
Call Scenario:
Test Case: Receive a call while playing USB music.
Expected Outcome: The music should pause during the call
and resume from the same point after the call ends.
Reverse Camera Integration:
Test Case: Invoke the reverse camera while playing USB
music.
Expected Outcome: The camera screen should be
displayed, and the music should continue playing in the
background.
Expected Outcome: The progress bar should be displayed
correctly and should update the playback position properly
when interacted with

Video & Error Handling

Video Playback & Driving Signal:
Test Case: While a video is playing, send a driving signal
through CANoe.
Expected Outcome: The video should stop displaying, but
the audio should continue playing in the background.
Error Messages:
Test Case: Insert a USB with a damaged, unsupported, or
low-resolution file.
Expected Outcome: The system should display the
appropriate error message.
No Playable Songs:
Test Case: Insert a USB with no playable songs.
 Expected Outcome: The system should display a “No
Playable Songs” message.
Persistence after Ignition Cycle:
Test Case: Turn the ignition OFF and then ON again while
USB music is playing.
Expected Outcome: USB music should resume from the
same point.

Voice Memo Module

Objective: To verify the functional behavior and integrity of the Voice
Memo feature.
Key Areas Tested:
➢ Recording Controls (Start, Stop, Pause, Resume)
➢ File Management (Save, Playback, Delete, Export)
➢ User Interface & System Feedback
➢ Interaction with other vehicle features (Calls, Navigation)
➢ Data Persistence and Error Handling
Core Recording Functionality
Start Recording:
Test Case: Tap the "Record" button.
Expected Outcome: The system should start recording and
display a live timer (e.g., "Recording 00:01").
Stop Recording:
Test Case: Tap the "Stop" button during recording.
Expected Outcome: The recording should end, and the
system should automatically save the audio file. A
confirmation message like "Saved" should appear.
Pause and Resume:
Test Case: Press "Pause" during recording, then press
"Resume".
Expected Outcome: The recording should temporarily stop,
and the timer should freeze. Pressing "Resume" should
continue recording from where it was paused.
File Management & Playback
File Saving:
Test Case: After stopping recording, check where the file is
saved and its duration.
Expected Outcome: The file should be saved in internal
storage (e.g., "Voice Memo" folder) and display the correct
duration.
Playback Features:
Test Case: Open a saved voice memo and test play, pause,
fast forward, and rewind functionality.
Expected Outcome: All playback controls should work
correctly.
Long Press on File:
Test Case: Long-press on a voice memo file.
Expected Outcome: The user should enter a
selection/delete mode with options to "Mark All" or "Unmark
All." Deleting selected files should work as expected.
Save File to USB:
Test Case: Connect a USB, select a file, and choose "Save to
USB."
Expected Outcome: The file should be saved successfully.
A "Voice Memo" folder should be created on the USB drive.

System Integration & User Feedback

Navigating Away During Recording:
Test Case: Start recording and navigate to another screen
(e.g., Settings).
Expected Outcome: An OSD (On-Screen Display) like
"Recording 1:15" should appear with a live timer. Pressing
"Stop" from this state should still save the file.
Memory Display:
Test Case: Check for the available memory display on the
screen.
 Expected Outcome: The system should show remaining
memory (e.g., "Remaining: 100 MB") to the user.
Bluetooth Call Scenarios:
Active Call: If a call is active, attempting to start a voice
memo should fail and show an OSD message.
Incoming Call: If an incoming call is received during a
recording, the voice memo should pause automatically.
Outgoing Call: If an outgoing call is made during a recording,
the voice memo should automatically stop and be saved.

Error Handling & Persistence

Remove USB While Saving:
Test Case: While saving a file to a USB, remove the USB.
Expected Outcome: A popup should appear with a message
like "Unable to save. Check USB and try again." The
recording should not be lost from internal storage.
Restart Behavior During Playback:
Test Case: Turn OFF and then ON the ignition while a voice
memo is playing back.
Expected Outcome: The voice memo should not auto-play
after the reboot. The system should return to the Voice
Memo screen in an idle state, and playback should only start
when the user presses "Play" again

Infotainment Display Resolutions in Cars

Resolution Pixels Usage / Segment Examples

HD 1280 × 720 Mid-range cars Navigation, Rear Camera

(720p)

WXGA 1280 × 800 Premium infotainment Some premium models

Full HD 1920 × 1080 Premium vehicles High-quality CarPlay / Android

(1080p) Auto

WUXGA 1920 × 1200 Luxury models Select luxury cars

 QHD / HD+ 2560 × 1440 High-end cars Digital cockpits, large screens

4K UHD 3840 × 2160 Cutting-edge luxury Mercedes Hyperscreen, BMW iX

Infotainment – Common Audio Formats Supported

Format Full Form Usage / Notes Examples

MP3 MPEG Layer-3 Most common, Songs from USB, Bluetooth

compressed audio streaming
WAV Waveform Audio Uncompressed, Audio test files, system
File Format high quality tones

WMA Windows Media Legacy format, Older systems/music files

Audio limited support
AAC / M4A Advanced Audio Widely used in Apple CarPlay audio,
Coding Apple ecosystem iTunes songs
FLAC Free Lossless Audio Lossless, high- Premium music playback
Codec quality

OGG / Vorbis Open-source codec Optional, Linux- Some open-source

based IVI systems infotainment setups

Infotainment – Common Video Formats Supported

Format Full Form Usage / Notes Examples

Playing movies from USB,

Most widely
MP4 H.264 / H.265 codecs CarPlay/Android Auto
supported video
mirroring
format
AVI Audio Video Interleave Legacy format, still Older video collections
supported in many
systems
MKV Advanced, supports Some premium
Matroska Video multiple audio/subtitle infotainment systems
tracks
MPEG / MPEG-2, MPEG-4 Common for DVD video In-car DVD entertainment
MPG playback
WMV Legacy, limited support Older Windows-based
Windows Media Video infotainment setups

CAN stands for Controller Area Network.

It is a serial communication protocol designed to allow multiple
Electronic Control Units (ECUs) in a vehicle (or any embedded system)
to communicate with each other without needing a central computer.
Features of CAN Protocol
1. Multi-Master Communication
➢ Any ECU can start communication on the CAN bus.
➢ If two ECUs try to send at the same time → CAN uses priority
arbitration (based on message ID).
➢ Ensures the highest priority message always wins.
2. Message-Based Communication
➢ CAN does not use addresses of ECUs.
➢ Instead, each message has a unique Identifier (ID).
➢ All ECUs on the bus read the message, but only the relevant
ECU acts on it.
This makes communication flexible and efficient.
3. Error Detection and Fault Confinement
➔ CAN has built-in error detection mechanisms:
➢ Cyclic Redundancy Check (CRC)
➢ Bit Monitoring
➢ Acknowledgement
➔ Faulty nodes automatically go to error passive mode or bus-
off mode.
Improves safety and reliability.
4. Speed
➢ Classical CAN → up to 1 Mbps.
➢ CAN FD (Flexible Data Rate) → up to 8 Mbps and larger data
payloads (up to 64 bytes).
Suitable for both control signals and larger data.
5. Robust Communication
➢ Uses differential signalling (CAN_H and CAN_L wires).
➢ Resistant to electrical noise → very reliable in harsh
automotive environments.
6. Efficient Bandwidth Usage
➢ Messages are short (8 bytes in Classical CAN) → very fast
communication.
➢ Arbitration ensures no data collision.
7. Low-Cost Wiring
➢ Only two wires (CAN_H & CAN_L) are needed for
communication between all ECUs.
➢ Reduces weight, complexity, and cost of wiring harness.
8. Real-Time Capability
High-priority messages (like brake/airbag) are delivered immediately.
Applications of CAN Protocol
1. Automotive Applications (Main Domain)
• Engine Control → ECU shares engine speed, temperature,
fuel data.
•ABS & Braking Systems → Wheel speed, brake pressure
monitoring.
• Airbag Systems → Crash signal communication for
deployment.
• Infotainment Systems → Audio control, navigation, steering
wheel buttons.
• Instrument Cluster → Speedometer, tachometer, warning
indicators.
• Electric Vehicles (EVs) → Battery Management System
(BMS), motor control.
2. Industrial Automation
• Robotics → Coordination between robot arms and
controllers.
• Factory Machines → Sharing machine parameters (speed,
temperature).
• Elevators → Door sensors, floor control, display
communication.
3. Medical Applications
• X-Ray and MRI machines → Communication between
modules.
• Dialysis Systems → Control of pumps and sensors.
• Patient Monitoring → Reliable communication for safety-
critical data.
4. Aerospace Applications
• Aircraft Systems → Cabin lighting, seat control, in-flight
monitoring.
• Avionics → Data sharing between control units.
5. Railway Applications
• Train Door Systems → Open/close status monitoring.
 • HVAC Systems → Air conditioning control.
• Safety Systems → Alarm and monitoring communication.
6. Marine Applications
• Ships & Boats → Engine monitoring, navigation, onboard
safety.

CAN Termination
What is CAN Termination?
• CAN uses a differential bus (CAN_H & CAN_L) for communication.
• At both ends of the CAN bus, a resistor of 120 Ω is placed → This is
called termination resistor.
• These two resistors (one at each end) are connected between
CAN_H and CAN_L.
Purpose of CAN Termination
1. Prevent Signal Reflection
• In long cables, when signals reach the end, they can bounce
back (reflect).
• This causes data errors.
• Termination resistor absorbs the signal and prevents
reflection.
2. Maintain Characteristic Impedance
• CAN bus cable has a characteristic impedance ~120 Ω.
• Matching it with 120 Ω resistor ensures proper signal
integrity.
CAN Voltage Levels
CAN uses differential signalling with two wires:
• CAN_H (High line)
• CAN_L (Low line)
Messages are carried by the voltage difference between CAN_H and
CAN_L.
 Two States in CAN Bus
1. Recessive State (Logic ‘1’)
• No ECU is driving the bus → bus is idle.
• CAN_H ≈ 2.5 V
• CAN_L ≈ 2.5 V
• Difference (Vdiff) ≈ 0 V
2. Dominant State (Logic ‘0’)
• An ECU drives the bus to send data.
• CAN_H ≈ 3.5 V
• CAN_L ≈ 1.5 V
• Difference (Vdiff) ≈ 2 V

Dominant state always overrides recessive state (important for

arbitration).
Summary Table
State CAN_H Voltage CAN_L Voltage Vdiff (CAN_H – CAN_L)
Recessive(1) ~2.5 V ~2.5 V ~0 V
Dominant(0) ~3.5 V ~1.5 V ~2 V

Why Differential Signalling

Any noise affecting both wires equally will be cancelled out. Ensures robust
communication even in noisy automotive environments.

What is a CAN Message?

A CAN message (CAN frame) is a data packet sent over the CAN bus
so that Electronic Control Units (ECUs) can share information.
Real-Time Example in Infotainment
Scenario:
You press the “Next Song” button on your steering wheel.
1.Steering Wheel ECU detects button press.
2.It sends a CAN message onto the bus:
ID: 0x2A1
DLC: 1
 Data: 0x01 (Command = Next Track)
3.Infotainment ECU receives this CAN message.
4.It understands that 0x01 = Next Track and changes the music.
5. Optionally, Infotainment ECU may also send another CAN
message back:
ID: 0x3B2
DLC: 8
Data: "Song Name"
7. Instrument Cluster ECU picks this up and displays the new
track name on the dashboard.
Types of CAN Frames
1. Data Frame
• Most common type.
• Carries actual data from one ECU to another.
• Example: Engine ECU sends vehicle speed (80 km/h) to
Instrument Cluster ECU.
2. Remote Frame
• Used when one ECU requests data from another ECU.
• Like asking: “Hey, what’s your value?”
• Example: Instrument Cluster ECU sends a remote frame
asking Engine ECU for the current speed.
3. Error Frame
• Sent when an ECU detects an error (like wrong bit, CRC
failure).
• It forces all ECUs to discard the faulty message and re-
transmit.
• Example: If a CAN message gets corrupted due to noise,
ECUs send an error frame.
4. Overload Frame
• Provides extra delay between messages when an ECU is
busy or overloaded.
• Example: If Infotainment ECU is processing too many
messages, it can send overload frames to slow down traffic.
What is a Standard Data Frame?
A Standard Data Frame is the most common CAN message format.
• It is used to carry actual data (like speed, RPM, volume, button
press).
• Called standard because it uses an 11-bit Identifier (ID).
• Max data: 8 bytes (64 bits) in Classical CAN.
Standard CAN Data Frame – Field-by-Field Explanation

1. Start of Frame (SOF) – 1 bit

• First bit in the frame.
• Always dominant (0).
• Signals all ECUs that a new message is starting.
2. Arbitration Field
➢ 11-bit Identifier (ID):
• Defines the type of message (e.g., engine speed,
infotainment).
• Decides priority (lower ID = higher priority).
• Example: 0x100 (Engine Speed) > 0x200 (Infotainment).
➢ RTR (Remote Transmission Request, 1 bit):
• 0 = Data Frame (normal data).
• 1 = Remote Frame (data request).
3. Control Field -6bit
➢ IDE (Identifier Extension bit):-1bit
• 0 → Standard Frame (11-bit ID).
• 1 → Extended Frame (29-bit ID).
➢ r0 (reserved bit): Always 0. -1bit
 ➢ DLC (Data Length Code, 4 bits):
• Tells how many bytes are in the Data Field (0–8).
4. Data Field (0–8 bytes)-64bits
• Holds the actual payload (the real information).
• Example (Infotainment): 0x05 = Volume level 5.
• Example (Engine): 0x50 0x00 = Speed = 80 km/h.
5. CRC Field (Cyclic Redundancy Check)
➢ 15-bit CRC
➢ 1-bit delimiter.

• Used for error checking.

• Ensures the message is valid and not corrupted.
6. ACK Field (2 bits)
➢ ACK Slot: If a receiver gets the message correctly, it sends back a
dominant bit (0).
➢ ACK Delimiter: Always recessive (1).
• If no ACK received → transmitter knows an error occurred.
7. End of Frame (EOF, 7 bits)
• All bit’s recessive (1).
• Marks the end of the CAN message.
NOTE: Standard Data Frame = 11-bit ID + up to 8 bytes of data,mainly
used for real-time ECU communication.

Standard Frame vs Extended Frame)

1. Message ID (Identifier)
• Standard Frame:
Uses 11-bit ID → About 2,000 messages possible.
• Extended Frame:
Uses 29-bit ID → About 500 million messages possible.
2. IDE Bit
• A small flag in the frame that tells type:
IDE = 0 → Standard Frame (11-bit)
 IDE = 1 → Extended Frame (29-bit)
2. Where Used
• Standard Frame (11-bit):
Cars (because fewer ECUs, so 11-bit ID is enough).
• Extended Frame (29-bit):
Trucks, buses, industrial systems (need many more ECUs and
IDs).
Simple Summary:
• Standard Frame = Short ID (11 bits), fewer messages, faster.
• Extended Frame = Long ID (29 bits), more messages, but slightly
slower.

What is a Remote Frame?

Remote Frame is a special type of CAN message used by one ECU to
request data from another ECU.
• Think of it like asking a question:
“Hey Engine ECU, what’s your current speed?”
• Unlike a Data Frame (which carries data), a Remote Frame does
not carry data, it only requests it.
Structure of a Remote Frame (Standard 11-bit)

1. Start of Frame (SOF)-1 bit

• Marks the beginning of a new CAN message.
2. Arbitration Field-11-bit
Identifier (ID) + RTR bit
➢ Identifier: Defines what data is being requested.
 ➢ RTR (Remote Transmission Request): Set to 1 → indicates it’s a
Remote Frame.
• Lower ID = Higher priority.
• Example: 0x200 (request for Engine Speed).
3. Control Field
➢ IDE bit (1 bit): Identifier Extension → 0 for Standard Frame.
➢ r0 (1 bit): Reserved bit.
➢ DLC (4 bits): Indicates how many data bytes are expected.
• But in Remote Frame, no actual Data Field is present.
4. CRC Field (Cyclic Redundancy Check)
15 bits + 1 delimiter bits
➢ CRC Sequence (15 bits)
Generated by transmitter for error checking.
➢ CRC Delimiter (1 bit)
Separates CRC sequence from the next field.
5. ACK Field-2 bits
➢ ACK Slot (1 bit)
Receiver sets this bit dominant (0) if message received correctly.
➢ ACK Delimiter (1 bit)
Separates ACK from the rest of the frame.
6. End of Frame (EOF)-7 bits
• Marks the end of the Remote Frame.
Standard Data Frame vs Remote Frame in CAN
Feature Standard Data Frame Remote Frame

Structured

To send actual data from one ECU to To request data from another ECU
Purpose others

RTR Bit RTR = 0 → Means Data Frame RTR = 1 → Means Remote Frame
Contains 0–8 bytes of actual payload
Data Field No data field (only the request)
Engine ECU sends Speed = 80 km/h
Example Cluster ECU asks Engine ECU → “Send
me Speed

Use in Steering ECU → Infotainment ECU Infotainment ECU could request

Infotainment (Volume Up data) “Track Info” from Media ECU
 Rarely used now → replaced by
Modern Use Very common (most messages) periodic Data Frames

Error Frame (CAN Protocol)

An Error Frame is a special message sent by any CAN node when it
detects an error in the ongoing transmission.
Real-Time Example (Traffic Signal Analogy)
• Red light = Must stop.
• If suddenly it shows green when it should be red → Wrong. ICAN:
• Example: End of Frame bits must be recessive (1).
• If any node sees a dominant (0) there → Form Error.
Structure of an Error Frame
An Error Frame has two parts:
1. Error Flag – Indicates “something is wrong.”
o Active Error Flag → 6 dominant bits (000000), sent by error-
active node.
o Passive Error Flag → 6 recessive bits (111111), sent by error-
passive node.
o This forces all other nodes to stop the current message.
2. Error Delimiter – 8 recessive bits (11111111).
o Marks end of Error Frame.
o Bus becomes idle/free for retransmission.
Real-Life Car Example
• Engine ECU: “Speed = 80 km/h.”
• Dashboard ECU finds error (CRC mismatch).
• It shouts “Stop!” → sends Error Flag.
• All nodes pause → Error Delimiter.
• Engine ECU retransmits correct speed.

Simple Line:
Error Frame = Error Flag (Stop signal) + Error Delimiter (Calm-down signal)
Types of Errors in CAN
1. Bit Error
When a node transmits a bit but reads a different bit on the CAN bus.
Real-Time Example:
• Engine ECU sends 1 (recessive = soft voice).
• But on the bus, it sees 0 (dominant = loud voice).
• Like you say “Yes” softly, but in the crowd, you hear “No.”
2. Stuff Error
In CAN, after 5 identical bits, a different bit must be inserted (bit
stuffing rule). If this rule is broken → Stuff Error.
Real-Time Example:
• You are reading a speech and must pause after every 5 words
• If you keep speaking without pause, listeners get confused.
• Same way, if ECU puts more than 5 same bits in a row → Stuff
Error.
3. CRC Error
At the end of every message, a CRC (Cyclic Redundancy Check) is
calculated to verify data integrity. If received CRC ≠ calculated CRC →
CRC Error.
Real-Time Example:
• You download a file, and its checksum doesn’t match → file
corrupted.
• In a car: Engine ECU sends mileage = 20 km/l, but CRC
check fails at Dashboard ECU → data not trusted.
4. Form Error
Fixed format fields in CAN (like End of Frame, CRC Delimiter) must
have specific values. If wrong value appears → Form Error.
Real-Time Example:
• End of Frame should always be all 1s.
• If an ECU sends 0 there, it’s a mistake.
• Like ending a sentence with “???” instead of “.”
 5. ACK Error
After a message is transmitted, at least one receiver must send an
Acknowledgement (ACK). If no node responds → ACK Error.
Real-Time Example:
• Engine ECU says: “Car speed = 80 km/h.”
• Dashboard ECU does not reply “Heard you.”
• Like you call your friend’s name, but nobody replies back.
Final Summary
• Bit Error – Mismatch between sent and read bit.
• Stuff Error – Bit stuffing rule violated.
• CRC Error – Data checksum mismatch.
• Form Error – Wrong fixed bit format.
• ACK Error – No acknowledgment received.

Overload Frame (CAN Protocol)

An Overload Frame is a special frame sent by a CAN node to delay the
next message when it is not yet ready to process data. It mainly provides
extra time (delay) between two data or remote frames.
Real-Time Example (Traffic Signal Analogy)
• Imagine at a toll gate, cars are passing one by one.
• Suddenly, the toll operator needs a short break to count
cash.
• He raises his hand → “Wait!” → Cars stop for a moment.
• After a few seconds, the process continues.
In CAN:
• ECU is busy or buffer is full → sends Overload Frame.
• This gives time before next message transmission.
Structure of an Overload Frame
It has two parts (like Error Frame):
1. Overload Flag
o Sent to request delay.
 o Consists of 6 dominant bits (000000).
o If multiple nodes send, they overlap (no problem).
2. Overload Delimiter
o 8 recessive bits (11111111).
o Marks the end of Overload Frame.
o After this, the bus becomes idle, ready for the next message.
Real-Life Car Example
• ABS ECU just finished heavy processing.

• Before it can handle the next CAN message, it needs a short

pause.
• It sends an Overload Frame to delay.
• After pause, CAN bus resumes with the next data message.

Simple Line
Overload Frame = Overload Flag (Wait signal) + Overload Delimiter
(Resume signal)
Summary
• Purpose → To delay next message when node is not ready.
• Triggered by → Busy ECU, full buffer, or short processing
delay.
• Parts → Overload Flag (000000) + Overload Delimiter
(11111111).
• Result → Gives extra time, then resumes normal
communication.

Arbitration Process in CAN

1. Purpose
• Arbitration decides which node can send data when more
than one node tries to send at the same time.
2. Message Priority
• Every CAN message has an Identifier (ID).
• The smaller the ID number, the higher the priority.
3. Bitwise Arbitration
• All nodes send their message bit by bit.
• Every node also monitors the bus while sending.
• Dominant bit (0) always wins over Recessive bit (1).
• If a node sends recessive (1) but sees dominant (0) on the
bus → it stops transmitting.
4. Result
• The node with the lowest ID keeps transmitting.
• Others wait until the bus is free.
Step-by-step Arbitration – Three Nodes
Node A: ID = 0x100 → 0001 0000 0000
Node B: ID = 0x200 → 0010 0000 0000
Node C: ID = 0x300 → 0011 0000 0000
Round 1 (A vs B vs C)
• First Bit
A = 0 (dominant),
B = 0 (dominant),
C = 0 (dominant)
→ All same, all continue.
• Second Bit
A = 0 (dominant),
B = 0 (dominant),
C = 0 (dominant)
→ All same, all continue.
• Third Bit
A = 0 (dominant),
B = 1 (recessive),
C = 1 (recessive)
→ Node A wins, B and C stop sending.
Only A continues → A sends full message.
Round 2 (B vs C, after A finishes)
• First Bit
B = 0 (dominant),
 C = 0 (dominant)
→ Both same, continue.
• Second Bit
B = 0 (dominant),
C = 0 (dominant)
→ Both same, continue.
• Third Bit
B = 1 (recessive),
C = 1 (recessive)
→ Both same, continue.
• Fourth Bit
B = 0 (dominant),
C = 1 (recessive)
→ Node B wins, C stops sending.
Only B continues → B sends full message.
Round 3 (Only C left)
• No competition → Node C transmits its message.

Winner Order
• Winner 1: Node A
• Winner 2: Node B
• Winner 3: Node C
Final Transmission Order: Node A → Node B → Node C

Importance of Arbitration (CAN Protocol)

• The highest priority message (lowest ID) always transmits
first.
• It prevents data collisions on the CAN bus.
• Ensures smooth and reliable communication between ECUs.

Simple Line: Arbitration makes sure important messages reach

first without conflict.
Extended CAN (CAN 2.0B)
Extended CAN is a CAN frame format that uses a 29-bit Identifier,
giving a larger range of unique messages compared to Standard CAN
(11-bit Identifier)
Main Highlights
• Identifier length: 29 bits (vs 11 bits in Standard CAN).
• Supports more ECUs and signals in modern vehicles.
• Backward compatible with Standard CAN.
• Data length remains the same: 0–8 bytes.
Field-by-Field Structure

• SOF (Start of Frame) – 1 bit → Marks the start of the frame.

• Identifier – 29 bits → Unique message ID.
• SRR (Substitute Remote Request) – 1 bit → Ensures
compatibility with Standard CAN.
• IDE (Identifier Extension) – 1 bit → Indicates Extended (29-
bit) frame.
• RTR (Remote Transmission Request) – 1 bit → Data (0) or
Request (1).
• Control Field – 6 bits → Defines data length (0–8 bytes).
• Data Field – 0–8 bytes → Carries actual signal values (speed,
RPM, etc.).
• CRC Field – 15 bits + delimiters → Error detection.
• ACK Field – 2 bits → Acknowledgment from receiver.
• EOF (End of Frame) – 7 bits → Marks the end of frame.
Real-Time Automotive Example
1. SOF (Start of Frame) – 1 bit
Marks the start of the message.
 Example: Turning ON the ignition key → “communication
begins.”
2. Identifier – 29 bits
Unique ID of the message, decides priority.
Example: Engine ECU sends Speed = 80 km/h with ID =
0x18FF50E5.
3. SRR (Substitute Remote Request) – 1 bit
Maintains compatibility with Standard CAN.
Example: Infotainment ECU requests song info, and SRR
ensures older ECUs can still understand.
4. IDE (Identifier Extension) – 1 bit
Differentiates Standard (11-bit) vs Extended (29-bit) frame.
Example: ADAS ECU sets IDE = 1 → “This is Extended Frame.”
5. RTR (Remote Transmission Request) – 1 bit
0 = Data Frame, 1 = Remote Frame (request data).
Example: Dashboard ECU sends RTR = 1 asking Engine ECU
for RPM.
6. Control Field – 6 bits
Defines data length (0–8 bytes).
Example: Engine ECU sends Speed → 2 bytes (16 bits).
7. Data Field – 0 to 8 bytes
Carries the actual data.
Example: Engine ECU sends Speed = 80 km/h (2 bytes), Fuel
= 10 liters (2 bytes).
8. CRC Field – 15 bits + delimiters
Used for error detection.
Example: Mileage data sent, but CRC mismatch →
Dashboard ECU rejects it.
9. ACK Field – 2 bits
Receiver confirms successful reception.
Example: Dashboard ECU sends ACK after receiving Speed
data.
10. EOF (End of Frame) – 7 bits
Marks the end of the message.
Example: Like a full stop in a sentence → “message finished.”
 NOTE
➢ IDE = 0 → Standard Frame (11-bit Identifier)
➢ IDE = 1 → Extended Frame (29-bit Identifier)
Simple Line
Extended CAN = 29-bit ID → More messages, better suited for
complex vehicles.

Fault Confinement in CAN

Fault Confinement is a safety feature in CAN where an ECU (node)
with too many errors will automatically limit or stop its
communication so that the whole CAN network remains stable.
Main Points
• Every node maintains two counters:
➢ TEC (Transmit Error Counter): Increases when transmission
errors happen.
➢ REC (Receive Error Counter): Increases when reception errors
happen.
• Based on these error counts, the node changes its state:
Node States in Fault Confinement
1. Error Active (TEC < 128 and REC < 128)
o Normal operation.
o Node can transmit and receive normally.
o Sends Active Error Frames when errors occur.
2. Error Passive (TEC ≥ 128 or REC ≥ 128)
o Too many errors detected.
o Node is still connected but has a limited role.
o Can only send Passive Error Frames (weaker, less
disturbance).
3. Bus Off (TEC ≥ 256)
o Very high errors.
o Node is fully disconnected from the CAN bus.
o Stops all communication to protect the network.
 Real-Time Automotive Example
• Suppose the Engine ECU wiring becomes loose →
transmission errors start.
• At first, ECU stays in Error Active (normal operation).
• As errors grow, ECU shifts to Error Passive → sends weaker
error frames.
• If wiring is not fixed, ECU finally goes Bus Off → completely
stops sending, protecting the bus.
• Effect: Dashboard stops showing engine speed.
Simple Line for Interview:
Fault Confinement = Error Active → Error Passive → Bus Off (based on
TEC/REC limits).

How can we reset the error counters (TEC/REC) in a CAN controller

Error counters (TEC/REC) can be reset only by restarting the CAN
controller — either by power reset or software reset (like UDS).
Methods
1. Power Cycle (Disconnect Power Supply)
➔ Turning OFF and ON the ECU resets the CAN controller.
➔ This clears TEC/REC counters to zero.
➔ Used when physical reset is possible (like restarting the
vehicle).
2. UDS Diagnostic Command (Hard Reset – 0x11 0x01)
➔ UDS service 0x11 (ECU Reset) with sub-function 0x01 (Hard
Reset).
➔ Software-triggered reset of ECU → CAN controller is re-
initialized.
➔ Counters are cleared and ECU rejoins bus communication.

Explain how TEC and REC counters increment and decrement in CAN?

1. Transmit Error Counter (TEC)

→ Increment: On every transmit error → +8
→ Decrement: On every successful transmission → –1
 2. Receive Error Counter (REC)
→ Increment: On every receive error → +1
→ Decrement: On every successful reception → –1
Quick Memory Flow
• TEC grows faster (×8) → node reaches Error Passive/Bus Off quickly
if it keeps transmitting faulty data.
• REC grows slower (×1) → allows tolerance for minor receive errors.

Bus Off Recovery in CAN

Bus Off recovery is the process of bringing a CAN node back online
after it goes into Bus Off state due to too many errors.
Main Points / Methods
1. Automatic Recovery (if supported)
➢ Some microcontrollers allow automatic Bus Off recovery after a
fixed idle period.
2.Manual Recovery
➢ Power Cycle: Turn OFF and ON the ECU to reset the CAN controller
→ TEC/REC counters cleared.
➢ UDS Hard Reset: Send UDS diagnostic command 0x11 0x01 → ECU
performs a hard reset → counters cleared → node rejoins the bus.
Simple Line:
Bus Off recovery = fix errors → reset ECU (power or UDS) → TEC/REC
cleared → node back to normal.

1. Bitrate
Number of bits transmitted per second on the CAN bus
Example: Engine ECU sends speed data to the dashboard at 500
kbps.
2. Baud rate
Number of signal changes per second on CAN bus
3. Bit Time in CAN
Bit Time is the time required to transmit a single bit on the CAN
bus. Measured using Time Quanta (TQ)
 Example: Engine ECU sends speed data at 500 kbps; each bit
lasts ~2 µs, and time quanta synchronize all ECUs for accurate
communication.

CAN FD (Flexible Data-Rate)

CAN FD is an advanced version of the Classical CAN protocol that
allows larger data payloads (0–64 bytes) and faster transmission
during the data phase while remaining backward compatible with
Classic CAN.
Discovery / History
• Introduced by Bosch in 2012,
• Designed to meet modern automotive needs like ADAS,
infotainment, and high-data-rate sensors.
CAN FD key features
→ Identifier: 11-bit (standard) or 29-bit (extended) → same as
Classic CAN
→ Data Field: 0–64 bytes (vs 0–8 bytes in Classic CAN)
→ Bit Rate: Up to 8 Mbps in data phase; arbitration phase
usually ≤ 1 Mbps
→ Backward Compatibility: Can coexist with Classic CAN on
the same bus
→ Efficiency: Larger data in fewer frames → reduces bus load
and increases speed
→ Error Handling: Same as Classic CAN (TEC/REC, error
frames, fault confinement)
Field-by-Field Structure
1. SOF (Start of Frame) – 1 bit → Marks start
2. Identifier – 11/29 bits → Unique message ID
3. RTR – 1 bit → Data (0) / Request (1)
4. IDE (Identifier Extension) – 1 bit
0 = Standard,
1 = Extended
5. r0 – 1 bit → Reserved
6. DLC (Data Length Code) – 4 bits → 0–64 bytes
7. BRS (Bit Rate Switch) – 1 bit → Enables faster data phase
 8. ESI (Error State Indicator) – 1 bit → Shows sender’s error
state
9. Data Field – 0–64 bytes → Actual data
10. CRC Field – 17 bits + delimiter → Error checking
11. ACK Field – 2 bits → Receiver acknowledgment
12. EOF (End of Frame) – 7 bits → Marks end
Real-Time Automotive Examples
• ADAS ECU: Sends camera or radar data → 32–64 bytes per frame,
uses fast data phase for real-time processing.
• Engine ECU: Sends speed and fuel data → smaller frames (standard
CAN or CAN FD small payload).
• Infotainment: Sends media and control data → benefits from larger
frames, reducing bus load.
Simple Line for Interview:
CAN FD = Flexible Data-Rate CAN → 0–64 bytes, faster data phase up to 8
Mbps, introduced in 2012 by Bosch, backward compatible with Classic
CAN.

How to create a Bus Off state in real-time

1. Sending Corrupted Messages
o Transmit wrong bits repeatedly → increments TEC → node
goes Bus Off.

o Example: Engine ECU sends corrupted speed data

continuously.
2. Disabling Acknowledgment (ACK)
o Prevent node from receiving ACK → causes ACK errors → TEC
increases → Bus Off.

o Example: ECU ignores ACK responses from Dashboard.

3. Sending Messages on Faulty Bus
o Transmit when the bus is already in error or disconnected →
generates errors → TEC rises → Bus Off.

o Example: Loose wiring causes continuous collisions →

ECU enters Bus Off.
 Simple Line for Interview:
Bus Off can be created by sending corrupted messages, disabling ACK,
or transmitting on a faulty bus → TEC ≥ 256 → node disconnects.

Difference between CAN and CAN FD

CAN and CAN FD are both communication protocols, but CAN FD is an
advanced version of CAN with some key improvements. The main
differences are:
1. Data Capacity:
→ In Classic CAN we can send only maximum of 8 bytes in one
frame.
→ In CAN FD, we can send up to 64 bytes, which makes it more
efficient for large data transfers.
2. Speed:
→ Classic CAN supports a maximum speed of 1 Mbps,
→ CAN FD allows speeds of up to 8 Mbps during the data
phase, making it much faster.
3. Efficiency:
→ Classic CAN requires multiple messages to send large data,
which increases the load on the bus.
→ CAN FD reduces this by sending larger chunks of data in fewer
messages, making communication faster and more efficient.

CAN Interframe Spacing

Interframe Space is the gap (idle period) on the CAN bus between two
consecutive messages.
• Purpose:
1. Allows controllers to process the previous frame.
2. Prevents overlapping of messages.
3. Provides synchronization time.
• Structure:
Interframe space has 3 parts:
1. Intermission (3 bits) mandatory
o Fixed length of 3 recessive bits.
o Must appear after End of Frame (EOF).
 o Ensures all nodes recognize that the previous message has
completely ended.
o Without this gap, new frames may overlap → bus errors.
2. Bus Idle
o Line stays recessive (logic 1) until the next frame begins.
o No fixed length → can be long or short, depending on when the
next ECU starts transmission.
o Example: If Engine ECU is sending every 10 ms, the bus remains
idle between frames.
3. Suspend Transmission (Optional)
o A temporary wait state some controllers use before sending a
new message.
o Prevents immediate back-to-back transmission by the same
ECU.
o Allows other nodes to try arbitration → avoids one ECU from
“monopolizing” the bus.
Example (Car):
After Engine ECU sends RPM data, there’s a small interframe gap
before ABS ECU sends brake pressure data.

Bug Life Cycle (with Assign Step)

The Bug Life Cycle explains how a defect moves from discovery to
closure. It ensures that every stakeholder (tester, manager,
developer) follows the process in the correct order.
Main Highlights
• Tracks each stage of a defect, including the Assign step.
• Keeps everyone updated on bug status.
• Maintains software quality and process discipline.
Step-by-Step Flow Diagram

Step-by-Step Flow
1. Tester Finds a Defect
Tester notices an issue (e.g., speedometer not showing correct
speed).
2. Tester Logs Defect in Tool → Status = NEW
Tester enters details (description, steps, screenshot,
environment).
3. Manager Reviews Defect
Manager/Lead checks if the defect is valid.
4. Is It Valid?
o No → REJECTED (tester mistake, misunderstanding).
o Yes → Move to scope check.
5. Is It in Scope?
o No → DEFERRED (low priority or not in current release).
o Yes → Proceed.
 6. Is It Already Raised?
o Yes → DUPLICATE (already logged).
o No → Go ahead.
7. ASSIGN Defect → Status = ASSIGNED
Manager assigns the defect to a developer.
8. Developer Starts Work → Status = IN-PROGRESS
Developer investigates and begins fixing.
9. Developer Fixes Code → Status = FIXED
Developer resolves the issue and updates status.
10. Tester Retests → Status = RETEST/PENDING RETEST
Tester verifies the fix in the new build.
11. Is the Bug Fixed?
• No → RE-OPEN (cycle continues, goes back to developer).
• Yes → Verified.
12. Bug Closed → Status = CLOSED
Tester confirms fix is correct → defect marked as closed.

Bug Life Cycle Statuses

• Bug → Created by Tester
Tester raises/creates the bug when they find an issue in the
application.
• Rejected → Set by Developer
If the developer finds that the issue is not a valid defect, they
mark it as Rejected.
• Duplicate → Set by Developer
If the defect is already reported or is the same as another defect,
the developer marks it as Duplicate.
• Deferred → Set by Developer / Project Manager
If the defect is of low priority or can be fixed in a future release, it
is marked as Deferred.

CAN Open Environment (CANoe)

CANoe is a software tool by Vector Informatik (1996), used for
development, testing, and analysis of automotive ECUs and networks.
Main Highlights:
• Supports multiple protocols: CAN, LIN, FlexRay, Ethernet,MOST.
• Provides simulation, diagnostics, automation, and analysis.
• Enables detailed bus monitoring and debugging.
Features:
• Real-time ECU and network simulation.
• Supports protocol testing (CAN, LIN, FlexRay, Ethernet, MOST).
• Automated test sequences (CAPL scripting).
• Bus monitoring, logging, and analysis.
• Diagnostics with fault injection & network management.
• User-friendly interface with strong scripting support.
Applications:
• Development and testing of ECUs and communication.
• Validation of CAN/LIN messages and signal behaviour.
• Troubleshooting networks during integration.
• Automated regression testing.
• Protocol simulation without hardware.
Automotive Example:
Using CANoe, engineers can simulate a speed sensor and verify if the
dashboard shows correct speed even before the real sensor hardware is
available.

Files in CANoe
1. Configuration File (.canoe File)
• Main project configuration file.
• Contains the entire CANoe setup with nodes, hardware, and
network settings.
2. Database Files (.dbc / .ldf / .arxml / .fibex)
• Define network messages and signal structure.
• Used to interpret raw CAN, LIN, FlexRay, or Ethernet data into
meaningful signals.
 3. CAPL (Communication Access Programming Language) Code
(.capl Script File)
• Contains CAPL code.
• Used for simulating ECU behavior, automating test cases, and
handling network events.
4. Panel Files (.pan / .cpf)
• Define graphical user interface (GUI) panels.
• Used to create dashboards, switches, and indicators for
interactive ECU/network testing.
5. (CANdela Studio Description File) (.cdd File)
• Diagnostic description file.
• Defines diagnostic services, DIDs, and requests used in ECU
diagnostic testing.

CREATE A CAN IN CANoe TOOL

Open CANoe Tool → File →New → CAN (CAN 500k Baud) → Save as
CREATE A DATA BASE
Tools → CANdb++ Editor → File → Create Database → Empty Template →
Saveas → Overall View Appears
ADD MESSAGE
Network Nodes → Right Click → New → Name → Messages → Right Click
→New→Name→ID→DLC→Transmitter→Add (messages)

ADD SIGNAL
Signals → Right Click → Name → Length of Bit → Value Type (Unassigned)
→ min & max → messages → Add

VALUE TABLE
View → Value Table → Blank Space (Right Click) → New → Name → Add →
Give Initial Values → pop-up appears → Name → Value Table
SIMMULATION
Open CANoe → Network → Database → Right Click → Add → Adding File →
Right Click → Node Synchronisation → Select Message → Next → Finish
ADD ECU ON CAN BUS
On Bus Right Click → Add IG Block → Simulation → IG → New → Analysis→
Trace → Run
 After that We Can Check Data In 1. Trace Window 2. Graphic Window 3.
Data Window 4. Statics Window 5. Measurement Setup 6. Simulation
Setup 7. Diagnostic Window 8. State Tracker Window 9. Panel Window

1. Trace Window
→ The Trace Window shows all messages transmitted and received on
the bus (CAN, LIN, FlexRay, Ethernet).
→ It is mainly used for debugging CAN communication, finding missing,
wrong, or error messages.
→ By using the Trace Window, we can filter specific CAN IDs or signals
and view the decoded values

2. Graphic Window
→ It visualizes signal behaviour in a graphical manner, like charts and
bar graphs.

3. Data Window
→ The Data Window displays real-time values of selected signals in a
tabular format
→ showing details like signal name, value, and raw value, making it
useful for quick monitoring during simulation.

4. Statistics Window
→ It shows real-time statistics of the CAN bus, such as bus load,
message count, and percentage of bus usage.
→ A high bus load can cause communication interference

5. Analysis Windows
→ It is used for both online analysis (during live simulation) and offline
analysis (using previously logged data)
→ Analysis windows (like Trace, Graphics, Data, Statistics) because
they can show results in real time or from a saved log file.

• Online Analysis: Performs real-time monitoring of messages during

measurement.
• Offline Analysis: Allows analysis of previously logged data.

6. Measurement Setup
→ It is used to configure databases, panels, windows, and tools before
starting simulation.
 7. Simulation Setup Window
→ It is used to configure network nodes and add databases.
→ We can insert CAPL modules, attach them to network nodes, and run
CAPL scripts.

8. Diagnostic Window
→ The Diagnostic Window is used to communicate with the ECU
→ Example: WE can send diagnostic requests (like asking the ECU for
information). We can analyse diagnostic responses (the ECU’s
reply, such as error codes or data).

9. State Tracker Window

→ It displays the state changes of selected signals or systems.

10. Panel Window

→ It is used to create interactive control panels for testing, providing
widgets like analog displays, buttons, checkboxes, LEDs, etc

11. Write Window

→ It displays system messages such as errors and warnings and shows
output from CAPL scripting.

12. Generator Window (IG BLOCK)

→ It is a vital component in CANoe that facilitates communication
between ECUs by generating messages from the predefined
database and sending them on the network.

1. How do you check whether an ECU is receiving signals on the

CAN bus?
✓ First, I check the wiring harness to ensure there are no loose
connections.
✓ Then, I verify the DB9 connector is properly connected.
✓ Next, I check the DBC mapping to confirm the IDs and signals
are mapped correctly.
✓ I make sure the VN1640A interface is detected, and the CAN
channel is configured.
✓ I start measurement in CANoe to begin monitoring.
✓ In the Trace window, I check whether the ECU is receiving or
transmitting messages.
✓ In the Data or Graphics windows, I verify that signal values are
updating as expected.
 NOTE: Harness → DB9 → DBC → VN1640A → Start Measurement → Trace
→ Data/Graphics → Diagnostic → Log.
2. How do you simulate nodes in CAN (in CANoe)?
• Interactive Generator (IG) Block – Used to generate and
simulate CAN messages directly, useful for quick testing.
• Panel – By creating control panels with widgets (buttons,
checkboxes, sliders, LEDs) to interactively simulate node
behaviour.
• CAPL Script – By writing CAPL programs to simulate node logic,
automate message generation, and respond like a real ECU.
3. What are the parameters required to send a CAN message?
→ We need Message ID, DLC (Data Length Code), Data Field, Control
Bits, and Timing/Periodicity to send a CAN message.
4. What Is Network Node?
→ It is nothing but an ECU within the CAN network. It behaves just
like a real ECU and can send and receive CAN messages as if it were
a live system.
5. Symbol Explorer?
→ It displays the network communication structure, including
symbols, messages, nodes, and node definitions.

CAN Transport Protocol (CAN-TP) – ISO 15765-2

→ It is used for sending more than 8 bytes of data over the CAN bus
(ISO 15765-2).
→ This was not possible in normal CAN, as the data field is limited to a
maximum of 8 bytes.
→ CAN-TP supports sending up to 4095 bytes
Applications
• Diagnostics (UDS / OBD): Used to transfer large diagnostic
messages between tester and ECU.
• Infotainment Systems: Sending large multimedia, configuration, or
update messages.
Types of CAN-TP Frames
1. Single Frame (SF → 00)
• Used when data ≤ 7 bytes.
 • Higher nibble of 1st byte → frame type = SF (00).
• Lower nibble of 1st byte → payload length.
• Entire message fits in this single frame.
2. First Frame (FF → 01)
• Used when data > 7 bytes (multi-frame message).
• Higher nibble of 1st byte → frame type = FF (01).
• Lower nibble of 1st byte + 2nd byte → indicate total message
length (12 bits).
• Carries the first chunk of data (usually 6 bytes).
• After FF, sender waits for Flow Control (FC) from the receiver.
3. Consecutive Frame (CF → 10)
• Used to send remaining data after First Frame.
• Higher nibble of 1st byte → frame type = CF (10).
• Lower nibble of 1st byte → sequence number (increments
1,2,3… then wraps at 15).
• Each CF carries up to 7 data bytes.
• Sent continuously according to receiver’s flow control settings.
4. Flow Control Frame (FC → 11)
• Sent by receiver → sender after receiving First Frame.
• Higher nibble of 1st byte → frame type = FC (11).
• Lower nibble of 1st byte → Flow Status:
o 0 (Continue To Send) → sender can keep sending CFs.
o 1 (Wait) → sender must pause.
o 2 (Overflow/Abort) → sender must stop transmission.
• Byte 2 → Block Size (how many CFs before next FC).
• Byte 3 → STmin (Separation Time minimum, i.e. gap between CFs).
→ Block Size (BS) - The maximum number of Consecutive
Frames the sender can transmit
→ Minimum Separation Time (STmin) - The minimum time
interval the sender must wait between consecutive frames
 NOTE
➢ Single Frame = 00 → used when data is 7 bytes or less, sent in one
shot.
➢ First Frame = 01 → used when data is more than 7 bytes, shows total
length and starts multi-frame transfer.
➢ Consecutive Frame = 10 → carries the next parts of data, each with a
sequence number.
➢ Flow Control = 11 → sent by receiver to control sending (Continue to
Send / Wait / Abort).

UDS (Unified Diagnostic Services) - ISO 14229

→ UDS is a protocol on CAN that helps service tools connect with ECUs
to check data, remove faults, and update software.
Applications:
• Vehicle servicing and OBD (On-Board Diagnostics)
• ECU software flashing and reprogramming
• Fault detection and repair assistance
• Calibration and validation in automotive testing
UDS Service IDs
1. 0x10 → Diagnostic Session Control – Start a diagnostic session
2. 0x11 → ECU Reset – Restart the ECU
3. 0x14 → Clear Diagnostic Information – Clear fault codes (DTCs)
4. 0x19 → Read DTC Information – Read fault codes
5. 0x22 – Read Data by Identifier → Read ECU data (like sensor values)
6. 0x2E → Write Data by Identifier (WDBI) – Write or update ECU data
7. 0x27 → Security Access – Unlock ECU with seed/key security
8. 0x28 → Communication Control – Turn ECU communication on/off
9. 0x31 → Routine Control – Run or stop a test routine in ECU
10. 0x3E → Tester Present – Keep session alive, avoid timeout
11. 0x85 → Control DTC Setting – Enable or disable fault logging

1. 0x10 → Diagnostic Session Control

• This service is used to switch the ECU into different diagnostic
sessions.
• It has 3 common sub-functions
 o 0x01 → Default Session – Normal ECU mode -
In Default Session only limited diagnostics are allowed, mostly
basic read functions.
o 0x02 → Programming Session – Used for ECU -
It is used for updating, flashing, or reprogramming the ECU
o 0x03 → Extended Session - This session provides extended
diagnostic capabilities.
• Request: 10 30
0x10 → Service ID
0x30 → Sub-function
• ECU Response: 50 03 00 32 01 F4
0x50 → Positive response to 0x10 service
0x03 → Sub-function echoed back (Extended Session)
00 32 → P2 server
01 F4 → P2 *
P2 Server - The maximum time the ECU can take to send a
normal response after receiving a request. (e.g., 50 ms)
P2* - When the ECU needs more time to process a request, it
can respond within this time (e.g., 500 ms).
• NRC (Negative Response Code) is a code sent by the ECU
when it cannot handle a UDS request correctly.
→ Request: 10 02
Response: 50 02 00 03 01 F4

• Default → Programming session change is possible.

• Default → Extended session change is possible.
• Programming → any other session or Extended → any other
session change is not possible.

2. 0x22 – Read Data by Identifier

• It is used for reading single DID or multiple DID’s

DID - Data Identifier

→ FUEL
Request: 22 3E 56
Response: 62 3E 56 70 (fuel value = 0x70)
→ SPEED
Request: 67 3R
Response: 62 67 3R 80 (speed value =0x80)
 → SPEED&FUEL
Request: 22 3E 56 67 3R
Response:62 67 3R 80 3E 56 70

3. 0x2E – Write Data by Identifier (WDBI)

• It is used to write or modify data in the ECU based on the DID

• Example: Android Auto DID = 1A 23

Values:

o 01 → Wired
o 02 → Wireless
o 03 → Both

Write request (set to Wired)

o Request: 2E 1A 23 01
o Response: 6E 1A 23 (Positive response confirming write)

Read request (check if Wired or not)

o Request: 22 1A 23
o Response: 62 1A 23 02 → Means Wireless is active

Write Request (set to Wireless)

o Request: 2E 1A 23 02 → Write DID 1A23 with value 02 (Wireless)

o Response: 6E 1A 23 → Positive response, confirms DID written

Read Request (check if Wireless or not)

o Request: 22 1A 23 → Read DID 1A 23

o Response: 62 1A 23 02 → ECU replies value = 02 (Wireless)

Write Request (set to Both)

o Request: 2E 1A 23 03 → Write DID 1A23 with value 03 (Both)

o Response: 6E 1A 23 → Positive response, confirms DID written

Read Request (check Both or not)

o Request: 22 1A 23
o Response: 62 1A 23 03 → ECU replies value = 03 (Both)

4. 0x27 – Security Access

• It is used to unlock the secure functions in the ECU.

 • if we want to write data into the ECU, first we must get security
permission. For this, we use Service ID 0x27 (Security Access).

• Security Access has two main sub-functions:

1. 0x01 → Request Seed

2. 0x02 → Send Key

1. 0x01 → Request Seed

o Request: 27 01 → Tester asks ECU for a seed

o Response: 67 01 12 34 56 78 → ECU replies with seed = 12 34 56 78

2. 0x02 → Send Key – (1A 2W 33 ER)

o Request: 27 02 1A 2W 33 ER → Tester sends key

o Response: 67 02 → ECU confirms key is correct, security unlocked

5. 0x31 – Routine Control

• It is used to start, stop, or request the result of a routine on ECU

components, such as sensors or cameras
• In this service, DID is called RID (Routine Identifier).

• Three Sub-functions:

1. 0x01 – Start Routine

2. 0x02 – Stop Routine
3. 0x03 – Request Routine Results

• Example: Camera RID = 48 39

1. Start Routine

o Request: 31 01 48 39
o Response: 71 01 48 39 – Positive Response

2. Stop Routine

o Request: 31 02 48 39
o Response: 71 02 48 39 - Positive Response

3. Request Routine Result

o Request: 31 03 48 39
o Response: 71 03 48 39 - Positive Response
6. 0x28 – Communication Control

• It is used to enable or disable message transmission (TX) and

reception (RX) of messages from the ECU.

• Two Sub-functions:

1. 0x00 → Enable both TX & RX

2. 0x01 → Disable TX & RX (this is further divided into 3 types)

a. 0x01 → Normal communication

b. 0x02 → Network management communication
c. 0x03 → Normal + Network management communication

• Examples:

1. Enable communication

• Request: 28 01 00
• Response: 68 01

2. Disable communication

• Request: 28 01 01
• Response: 68 01

3. Disable normal communication only

• Request: 28 01 03
• Response: 68 01

Why this is needed: When performing software flashing on an ECU, TX &

RX messages should be disabled using Service 0x28. Otherwise, the ECU
might still communicate with other ECUs, which can interrupt the
flashing/update process.

7. 0x85 – Control DTC Setting

• It is used to enable or disable the storing of Diagnostic Trouble

Codes (DTCs) in the ECU.

• Two Sub-functions:

1. 0x01 → Enable DTC setting

2. 0x02 → Disable DTC setting
 • Examples:

1. Enable DTC setting

• Request: 85 01
• Response: C5 01

2. Disable DTC setting

• Request: 85 02
• Response: C5 02

Why this is needed:

• While flashing the ECU, unusual conditions may occur that can
trigger unwanted DTCs.
• If these unnecessary DTCs are stored in ECU memory, it becomes
difficult to identify the real/original faults later.
• To avoid this, we disable DTC setting during flashing and enable it
again afterward.

8. 0x14 – Clear Diagnostic Information

• It is used to clear the stored DTCs (Diagnostic Trouble Codes) and

their related data from ECU memory.

• EXAMPLE

• Request: 14 3E 55 23 → Clear specific DTC 3E5523

• Response: 54 → Positive response (clear successful)
• Request: 14 FF FF FF → Clear all DTCs
• Response: 54 → Positive response (all cleared)

Why this is needed:

• To remove old or resolved fault codes after repair.

• Helps service tools check only current faults, not past issues.
• Keeps ECU memory clean and avoids confusion during
diagnostics.

9. 0x11 – ECU Reset

• This service is used to request the ECU to reset (restart).

• Three Sub-functions

1. 0x01 – Hard Reset → Complete ECU restart (like power cycle)

2. 0x02 – Key Off Reset → ECU simulates ignition OFF–ON reset
 3. 0x03 – Soft Reset → Software reset (application software
restarts without power cycle)

• Examples:
• Hard Reset → Request: 11 01 → Response: 51 01
• Hard Reset → Request: 11 02 → Response: 51 02
• Soft Reset → Request: 11 03 → Response: 51 03

NOTE:

• To apply new configurations or software updates

• To clear temporary errors or recover from faults
• To switch ECU back to a known stable state
• Often used after flashing, writing DIDs, or diagnostics

10. 0x3E – Tester Present

• 0x3E – Tester Present is used to keep a diagnostic session alive

and avoid session timeout (S3 timer).
• S3 timer:

Whenever the tester is in any session (except Default), if no

activity is done, the session will expire after 5 seconds, and the
ECU will move back to Default Session. To avoid this, we use
Service 0x3E (Tester Present).

• Two Sub-functions:

1. 0x00 – Standard
2. 0x80 – Suppress Positive Response

• EXAMPLE
• 0x00 – Standard
• Request: 3E 00
• Response: 7E 00
• 0x80 – Suppress Positive Response
• Request: 3E 80
• Response: No positive response sent (ECU suppresses
reply).

Why this is needed:

• It keeps the ECU in the current diagnostic session

(Programming/Extended) and avoids timeout.
• Without it, after S3 timer (e.g., 5 sec), the ECU would drop back
to Default Session.
11. 0x19 – Read DTC Information

• This service is used to read Diagnostic Trouble Codes (DTCs) stored

in the ECU memory.
• Active DTC: A fault code that is currently present (ongoing issue).
• Passive DTC: A fault code that was detected in the past but is no
longer present.

→ DTC Status Byte Example (93 0D 11)

Each bit in the DTC Status Byte represents the status of the fault.

• Bit 0 → Test Failed

• Bit 2 → Pending
• Bit 3 → Confirmed
• Bit 5 → Test Failed Since Last Clear

Binary Representation (Example)

8421 8421
0010 1101
This corresponds to 2D (Hex) = Availability Mask.

• Examples

When fault is created

DTC Status Byte: 93 0D 11: 25: 0010 0101

Immediately after solving the fault

DTC Status Byte: 93 0D 11: 24: 0010 0100

After one power cycle

DTC Status Byte: 93 0D 11: 20: 0010 0000

When fault is created again

DTC Status Byte: 93 0D 11: 25: 0010 0101

After solving DTC and doing 2 power cycles

DTC Status Byte: 93 0D 11: 29: 0010 1001

After solving the fault

DTC Status Byte: 93 0D 11: 28: 0010 1000

After one more power cycle

DTC Status Byte: 93 0D 11: 20: 0010 0000
 • Five Sub-functions

1. 0x01 – Report Number of DTC by Status Mask

2. 0x02 – Report DTC by Status Mask
3. 0x04 – Report DTC Snapshot Records
4. 0x06 – Report DTC Extended Data Record
5. 0x0A – Report Supported DTC

1. 0x01 – Report Number of DTC by Status Mask

• Used to read the number of active DTCs. It checks the DTC

status byte, where the “Test Failed” bit is set to 1.

Example:

• Request: 19 01
• Response: 59 01 2D 03

2. 0x02 – Read DTC by Status Mask

• Used to retrieve specific DTCs from the ECU based on

their status bits.
• It returns only those DTCs that match certain conditions,
such as:
• Active
• Pending
• Confirmed

EXAMPLE

1. Retrieve DTCs with "Test Failed" bit

• Req: 19 02 04
• Res: 59 02 2D 95 29 19 29 36 29 48 25 94 28 10 29

2. Retrieve DTCs with "Pending" bit

• Request: 19 02 08
• Response: (ECU will return all pending DTCs)

3. Retrieve DTCs with both Pending and Active

• Request: 19 02 0C
• Response: (ECU will return all DTCs that are
both pending and active)
3. 0x04 – Read Snapshot Data

• This service is used to retrieve the snapshot data

associated with a specific DTC
• It provides sensor values such as engine RPM,
temperature, and vehicle speed, captured now the
failure occurred.

Examples of Snapshot Records:

1. Record 01 → Vehicle Speed

2. Record 02 → Engine RPM
3. Record 03 → Coolant Temperature
4. Record 04 → Throttle Position

1. Record 01 → Vehicle Speed

• Request: 19 04 95 29 19 01
• Response: 59 04 2D (Vehicle Speed)

2. Record 02 → Engine RPM

• Req: 19 04 95 29 19 02
• Res: 59 04 2D (Engine RPM)

3. Record 03 → Coolant Temperature

• Req: 19 04 95 29 19 03
• Res: 59 04 2D (Coolant Temperature)

4. Record 04 → Throttle Position

• Req: 19 04 95 29 19 04
• Res: 59 04 2D (Throttle Position)

4. 0x06 – Report DTC Extended Data Record

• This sub-function is used to get extra information
associated with a specific DTC.
Examples
1. Occurrence Counter (01): How many times the DTC
has occurred.

• Request → 19 06 95 29 19 01
• Response → 59 06 2D 95 29 19 01 <occurrence value>
 2. Ageing Counter (02): How long it has been since the
fault first occurred.

• Request → 19 06 95 29 19 02
• Response → 59 06 2D 95 29 19 02 <ageing value>

5. 0x0A – Report Supported DTC

• Used to check which DTCs are supported in your project

• Request: 19 0A
• Response: 59 0A 2D 56 55 44 44 55 22

Negative Response Code in UDS (NRC) - ISO 14229.

• In UDS, NRC is a code sent by the ECU when it cannot perform the
requested diagnostic service.

• Format is always: 7F <Service ID> <NRC Code>.

• 7F → Negative Response identifier

• Service ID → Which service failed (example: 0x22 Read Data by
Identifier)
• NRC Code → Specific reason (like 0x13 = Incorrect length, 0x78 =
Response pending)

→ Common NRC Codes:

1. 0x10 → General Reject.

2. 0x11 → Service Not Supported.
3. 0x12 → Sub-function Not
4. 0x13 → Incorrect Message Length.
5. 0x21 → Busy, Repeat Request
6. 0x22 → Conditions Not Correct
7. 0x24 → Request Sequence Error
8. 0x31 → Request Out of Range
9. 0x33 → Security Access Denied
10. 0x35 → Invalid Key
11. 0x36 → Exceeded Number of Attempts
12. 0x37 → Required Time Delay Not Expired
13. 0x78 → Response Pending
14. 0x7E → Sub-function Not Supported in Active Session
15. 0x7F → Service Not Supported in Active Session
1. 0x10 – General Reject.

• It means the ECU is in a state where it cannot process the

request.

o EXAMPLE - During initialization, shutdown, or software updates.

→ Request: 22 34 10
→ Response: 7F 22 10

2. 0x11 – Service Not Supported

• The ECU does not support the Service ID requested by the tester.

o EXAMPLE

→ Request: 15 35 45
→ Response: 7F 15 11

3. 0x12 – Sub-function Not

• The ECU does not support the sub-function requested by the tester.

o EXAMPLE

→ Request: 10 05
→ Response: 7F 10 12

4. 0x13 – Incorrect Message Length.

• When the ECU receives a request with incorrect length or invalid

format, it sends NRC 0x13.

o EXAMPLE

→ Request: 10 01 01
→ Response: 7F 10 13

5. 0x21 – Busy, Repeat Request

• This NRC is triggered when the ECU is temporarily unable to process

the request because it is busy with another task.

o EXAMPLE

→ Request: 22 12 34
→ Response: 7F 22 21
6. 0x22 – Conditions Not Correct

• If the tester is trying to clear a DTC, first the fault must be solved. Only
then the DTC can be cleared.

o EXAMPLE

→ Request: 14 12 34 56
→ Response: 7F 14 22

7. 0x24 – Request Sequence Error

• Triggered when the ECU detects an error in the sequence of requests

sent by the tester.

o EXAMPLE

→ Request: 27 01 23 45 56 55
→ Response: 7F 27 24

8. 0x31 – Request Out of Range

• Triggered when the ecu receives a request with parameters that are
out of range or not supported.

o EXAMPLE - Invalid DID, invalid RID.

9. 0x33 – Security Access Denied

• This NRC is triggered when the tester tries to perform a secure

operation, such as writing data or modifying configuration, without
obtaining the required security access.

o EXAMPLE

→ Request: 2E 1A 23 02 → Attempt to write DID 1A23

→ Response: 7E 2E 33 → NRC 0x33, Security Access Denied

10. 0x35 – Invalid Key

• This NRC is triggered when the tester sends an incorrect or invalid

security key during the Security Access procedure.

o EXAMPLE

→ Request: 27 02 12 34 56 44 → Tester sends key

→ Response: 7F 27 35 → ECU replies with NRC = Invalid Key
11. 0x36 – Exceeded Number of Attempts

• Triggered when the tester exceeds the maximum number of

attempts to send an incorrect security key.

o EXAMPLE

→ Tester sends wrong security key multiple times using 0x27

– Security Access.
→ ECU response: 7F 27 36 → Indicates maximum attempts
exceeded, ECU locked temporarily.

12. 0x37 – Required Time Delay Not Expired

• This NRC is triggered when the tester sends a wrong security key.
The tester must wait for the defined time before sending the key
again. If the tester sends the key before the defined time, the ECU
responds with this NRC.

o EXAMPLE

→ Tester sends wrong key using service 0x27 → ECU responds

with correct seed.
→ Tester retries too early → ECU responds: 7F 27 37 → NRC 37
(Time Delay Not Expired)

13. 0x78 – Response Pending

• This NRC is not an error code. It indicates that the ECU is still
processing the request and will provide the response later.

o EXAMPLE

→ Request: 10 02 (Programming Session)

→ Response: 7F 10 78 → ECU tells tester: Still processing, wait
for final response

14. 0x7E – Sub-function Not Supported in Active Session

• NRC 0x7E is returned when the tester requests a sub-function that is

invalid or not supported in the current session.

15. 0x7F → Service Not Supported in Active Session

• NRC (7F) is a code sent by the ECU when it cannot process a UDS
request successfully, indicating the reason for rejection
✓ In UDS, why is 0x40 added to the service ID in the positive response?

In UDS, 0x40 is added to the request service ID to form the positive response.
This sets the 6th bit high, indicating a positive response as per ISO 14229
convention.

Test Case

A test case is a set of steps, inputs, and expected results created to check
if a system or feature works correctly.

Step-by-step fields in a test case:

1. Test Case ID – Unique number/name.

2. Test Condition – What to check.
3. Steps – Actions to perform.
4. Input Data – Values given to system.
5. Expected Output – What result should come.
6. Pass/Fail – Final outcome.
7. Comments – Notes if needed.

Test Case Scenario

A test case scenario is a high-level description of what needs to be tested

in the system, written in simple steps without full details.

Types of Testing

1. Smoke testing
Smoke testing, also known as "Build Verification Testing" is a
preliminary type of software testing. It focuses on verifying the main
functionality of a software application are working correctly before
proceeding with more detailed testing.
Purpose is to verify that the if the build is stable enough for further
testing.
Smoke testing is done whenever a new build is deployed.
If the smoke tests pass, the build is considered stable enough for
further testing. If they fail, the build is rejected and sent back to the
development team for fixes.
Smoke Testing → Quick check to ensure main functions work.
Example: After flashing new ECU software, tester checks if ECU powers
ON, communicates on CAN, and responds to 10 01 (default session).
2. Sanity testing
Sanity Testing that focuses on verifying whether a specific
functionality of the application works as expected after a small change
or bug fix. It’s like a "sanity check" to ensure the software is still
functioning properly in the area that was modified.
FM ----Bug
Build release --→
Sanity Testing → Focused testing of one or few changes in the build.
Example: After a bug fix for DTC clearing, tester checks only 14 (Clear
DTCs) service to confirm the fix works.
3. Regression Testing
Regression testing is a type of software testing performed after any
changes or updates are made to the system, such as bug fixes, adding
the feature and deleting the feature, The main goal is to ensure that
these changes have not introduced new issues or broken any of the
existing functionalities that were previously working as expected. It
involves re-test the previously working functionalities to verify that the
software continues to perform as expected after modifications.
Regression Testing →Testing to ensure new changes did not break
existing features.
Example: After adding a new routine control feature, tester rechecks old
services like 22 (Read Data), 27 (Security Access), and 14 (Clear DTCs) to
confirm they still work.
4. Retesting
Whenever developer fixed a bug, tester will test that bug again to verify
that whether the bug is fixed or not is called retesting.
Retesting → Running the same failed test again after the bug is fixed.
Example: Earlier, 2E (Write Data) failed. Developer fixed the bug, so
tester runs the same 2E test again to confirm it passes.
5. Exploratory testing
Exploratory Testing is a type of software testing where testers actively
explore the application without predefined test cases. Instead of
following a strict plan, testers use their creativity, intuition, and
experience to discover defects, usability issues, and unexpected
behaviours, and understand the software’s behaviour.
The main purpose is to uncover defects that might not be found
through structured testing methods.
Exploratory testing →Testing without predefined test cases, exploring
the system freely.
Example: Tester tries random UDS requests like22 with different
unsupported DIDs to see ECU behaviour.

6. Positive testing
Testing the application with valid inputs
Fm: 87.5 MHz to 108 MHz
Enter manual frequency: 87.9
Positive testing → Testing with valid inputs to check correct system
behaviour.
Example: Sending 22 F1 90 (Read VIN DID) and verifying ECU responds
with correct VIN.

7. Negative testing
Testing with invalid inputs to check system handles errors properly.
Example: Sending 22 FF FF (unsupported DID) and ECU should reply with
7F 22 31 (Request Out of Range).
Adhoc Testing/ Monkey testing
Adhoc Testing is an informal and unstructured testing method. it aims
to identify defects through random checking. It does not follow any
predefined test cases or documentation, allowing testers to use their
intuition, experience, and creativity to explore the application and find
issues.
Testers input random data and perform random actions on the
application to see if it breaks. The goal is to identify any unexpected
crashes or bugs that might not be found through structured testing
methods.
Adhoc Testing/ Monkey testing → Random, unstructured testing
without test cases.
Example: Rapidly pressing infotainment volume, navigation, and
back buttons to see if system crashes.
8. KPI (Key performance indicators) Testing:
Key performance metrices: speed and Responsiveness
Requirement: 10 secs (speed)
Requirement: 1 sec below
 KPI testing is performed to verifying whether the application working as
expected under certain conditions and meets the performance metrics
defined in the project
For example, when the infotainment system is powered on, I would verify
that the logo appears within 4 seconds. Following that, the home screen
should be displayed within 7 seconds.
Another key metric would be the responsiveness of the reverse camera
— when I engaged, the camera feed should appear within 500
milliseconds.
Another important KPI is the detection of a USB connection — it should
be recognized within 1 second of being plugged in.
and Navigation Load Time-Verifying that the navigation system loads
the map and provides directions within 3 seconds. These are the kinds of
timing metrics I would focus on to ensure the system is responsive and
performs efficiently."
KPI (Key performance indicators) Testing → Measures performance
against set targets.
Example: Checking if ADAS camera detects lane markings within 200
ms (as per KPI).
9. Field Testing:
Placing the Infotainment ECU in vehicle and test the functionalities,
performance and usability of the system in real-world conditions.
Field Testing → Testing in real-world environment outside lab.
Example: Driving the car on highway and city roads to check ADAS
and infotainment.
10. Functional Testing
Functional testing means we must test whether all functionalities of
the software application are working properly or not according to
specified requirements.

• Smoke Testing (main functionalities verify చేయడం)

• Sanity Testing (small bug fix check)
• Regression Testing (old features break కాలేదా check)
• Integration Testing (modules కలిసి పని చేస్ు తన్ాాయా check)
• System Testing (whole system check)
 • User Acceptance Testing (UAT) (customer validate చేయడం)

Functional Testing → Verifying software functions as per requirements.

Example: Check if pressing “Play” button in infotainment plays audio.
11. Non-Functional testing:
Nonfunctional testing means we must check the system performance
or reliability of the application.
Non-Functional testing → Testing performance, security, usability,
Example: Verify infotainment boots up within 5 seconds
(performance).
12. Black box testing and white box testing:

Aspect White-box Testing Black-box Testing

white-box testing is
Performe Black-box testing is performed
performed by the
d by by the test engineers
developers

Does not require knowledge of

Knowledg Requires knowledge of
the programming languages,
e programming languages,
internal code or
required code, and internal logic.
implementation.

Focuses on source code Focuses on verifying

Focus
and testing the logic of the functionality based on the
area
code. requirement specifications.

Equivalence partitioning,
Test
Statement Coverage, Boundary value analysis, Error
design
Branch Coverage, Path Guessing, Decision Table
techniqu
Coverage. Loop Testing Testing, Cause-effect graph,
es
Use Case Testing

Typically performed at Typically performed at

Applicabl
the unit and integration lev the system and acceptance le
e levels
els. vels.

White box Testing

Testing internal code, logic, and structure.
Example: Checking the C-code logic of CAN communication module.
 Black-box Testing
Testing only inputs/outputs without looking into code.
Example: Sending diagnostic requests (10 01, 22 F1 90) and verifying
ECU responses.
13. Alpha Testing and Beta Testing
Conducted in a controlled environment by internal teams (e.g.,
developers, QA engineers) before releasing the software to external
users.
Focuses on identifying bugs, performance issues, and ensuring the
software meets functional requirements.
• Alpha Testing → Internal testing by developers/testers before customer
release.
Example: Testing infotainment features inside company labs.
• Beta Testing → Testing by real users/customers in real environment
before final release.
Example: Giving test vehicles with new infotainment to selected
drivers for feedback.
14. Grey Box Testing:
Combination of both white box and black box testing
Example: integration testing