Máy chẩn đoán cơ bản

TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT THÀNH PHỐ HỒ CHÍ MINH
KHOA CƠ KHÍ ĐỘNG LỰC


ĐỒ ÁN TỐT NGHIỆP
NGHIÊN CỨU VÀ THỬ NGHIỆM

MÁY CHẨN ĐOÁN CƠ BẢN
SVTH: NGUYỄN TẤN THIỆN

MSSV: 16145607
GVHD: THS. LÊ QUANG VŨ
Tp. Hồ Chí Minh, tháng 8 năm 2020

TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT THÀNH PHỐ HỒ CHÍ MINH

ĐỒ ÁN TỐT NGHIỆP
Chuyên ngành: Công Nghệ Kỹ Thuật Ô tô
Tên đề tài
NGHIÊN CỨU VÀ THỬ NGHIỆM

MÁY CHẨN ĐOÁN CƠ BẢN
SVTH: NGUYỄN TẤN THIỆN

MSSV: 16145607
GVHD: THS. LÊ QUANG VŨ
Tp. Hồ Chí Minh, tháng 8 năm 2020

TRƯỜNG ĐH SƯ PHẠM KỸ THUẬT CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM
TP. HỒ CHÍ MINH Độc Lập – Tự Do – Hạnh Phúc
TP. Hồ Chí Minh, ngày tháng 8 năm 2020
NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP

Họ tên sinh viên: 1. NGUYỄN TẤN THIỆN MSSV: 16145607
(E-mail:16145607@student.hcmute.edu.vn Điện thoại: 0396890790 )
Chuyên ngành: Công nghệ Kỹ thuật Ô tô Mã ngành đào tạo: 52510205
Hệ đào tạo: Đại học Chính quy Mã hệ đào tạo: K16145

Khóa: 2016 – 2020 Lớp: 161451
1. Tên đề tài
“NGHIÊN CỨU VÀ THỬ NGHIỆM MÁY CHUẨN ĐOÁN CƠ BẢN”

2. Nhiệm vụ đề tài
1/ Tìm hiểu chức năng của giắc OBD-II
2/ Tìm hiểu lý thuyết về giao tiếp mạng CAN và các chuẩn truyền trên ô tô
3/ Tìm hiểu các chức năng cơ bản của máy chuẩn đoán thong dụng
4/ Chế tạo thử nghiệm máy chuẩn đoán cơ bản
5/ Thực nghiệm trên một số xe và mô hình động cơ thông dụng

3. Sản phẩm của đề tài: MÁY CHUẨN ĐOÁN CƠ BẢN
4. Ngày giao nhiệm vụ đề tài:

5. Ngày hoàn thành nhiệm vụ:
TRƯỞNG BỘ MÔN CÁN BỘ HƯỚNG DẪN
ThS Lê Quang Vũ
TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT TP. HCM CỘNG HOÀ XÃ HỘI CHỦ NGHĨA VIỆT NAM
KHOA CƠ KHÍ ĐỘNG LỰC Độc lập - Tự do – Hạnh phúc
Bộ môn ……………………………..
PHIẾU NHẬN XÉT ĐỒ ÁN TỐT NGHIỆP
(Dành cho giảng viên hướng dẫn)
Họ và tên sinh viên : NGUYỄN TẤN THIỆN MSSV: 16145607 Hội đồng:………...
Tên đề tài: XÂY DỰNG VÀ THỬ NGHIỆM MÁY CHẨN ĐOÁN CƠ BẢN
Ngành đào tạo: Công nghệ Kỹ thuật Ô tô
Họ và tên GV hướng dẫn: ThS. Lê Quang Vũ
Ý KIẾN NHẬN XÉT
1. Nhận xét về tinh thần, thái độ làm việc của sinh viên
...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
2. Nhận xét về kết quả thực hiện của ĐATN

2.1. Kết cấu, cách thức trình bày ĐATN:
...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
2.2. Nội dung đồ án:

(Cơ sở lý luận, tính thực tiễn và khả năng ứng dụng của đồ án, các hướng nghiên cứu có thể tiếp tục phát triển)
...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
2.3. Kết quả đạt được:

...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
2.4.Những tồn tại (nếu có):

...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
3. Đánh giá:
Điểm tối Điểm đạt
TT Mục đánh giá
đa được
1. Hình thức và kết cấu ĐATN 30
Đúng format với đầy đủ cả hình thức và nội dung của các mục 10
Mục tiêu, nhiệm vụ, tổng quan của đề tài 10
Tính cấp thiết của đề tài 10
2. Nội dung ĐATN 50
Khả năng ứng dụng kiến thức toán học, khoa học và kỹ thuật, khoa 5
học xã hội…
Khả năng thực hiện/phân tích/tổng hợp/đánh giá 10
Khả năng thiết kế chế tạo một hệ thống, thành phần, hoặc quy trình 15
đáp ứng yêu cầu đưa ra với những ràng buộc thực tế.
Khả năng cải tiến và phát triển 15
Khả năng sử dụng công cụ kỹ thuật, phần mềm chuyên ngành… 5
3. Đánh giá về khả năng ứng dụng của đề tài 10
4. Sản phẩm cụ thể của ĐATN 10
Tổng điểm 100
4. Kết luận:
 Được phép bảo vệ
 Không được phép bảo vệ
TP.HCM, ngày tháng 8 năm 2020

Giảng viên hướng dẫn
((Ký, ghi rõ họ tên)
TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT TP. HCM CỘNG HOÀ XÃ HỘI CHỦ NGHĨA VIỆT NAM
KHOA CƠ KHÍ ĐỘNG LỰC Độc lập - Tự do – Hạnh phúc
Bộ môn ……………………………..
PHIẾU NHẬN XÉT ĐỒ ÁN TỐT NGHIỆP

(Dành cho giảng viên phản biện)
Họ và tên sinh viên : NGUYỄN TẤN THIỆN MSSV: 16145607 Hội đồng:………...
Tên đề tài: NGHIÊN CỨU VÀ THỬ NGHIỆM MÁY CHẨN ĐOÁN CƠ BẢN
Ngành đào tạo: Công nghệ Kỹ thuật Ô tô
Họ và tên GV phản biện: (Mã GV) ..................................................................................................
Ý KIẾN NHẬN XÉT

1. Kết cấu, cách thức trình bày ĐATN:
...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
2. Nội dung đồ án:
(Cơ sở lý luận, tính thực tiễn và khả năng ứng dụng của đồ án, các hướng nghiên cứu có thể tiếp tục phát triển)
...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
3. Kết quả đạt được:

...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
4. Những thiếu sót và tồn tại của ĐATN:

...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
...................................................................................................................................................................................
5. Câu hỏi:
.................................................................................................................................................................................
.................................................................................................................................................................................
.................................................................................................................................................................................
.................................................................................................................................................................................
.................................................................................................................................................................................
.................................................................................................................................................................................
.................................................................................................................................................................................
6. Đánh giá:
Điểm tối đa Điểm đạt

TT Mục đánh giá
được
1. Hình thức và kết cấu ĐATN 30
Đúng format với đầy đủ cả hình thức và nội dung của các mục 10
Mục tiêu, nhiệm vụ, tổng quan của đề tài 10
Tính cấp thiết của đề tài 10
2. Nội dung ĐATN 50
Khả năng ứng dụng kiến thức toán học, khoa học và kỹ thuật, 5
khoa học xã hội…
Khả năng thực hiện/phân tích/tổng hợp/đánh giá 10
Khả năng thiết kế, chế tạo một hệ thống, thành phần, hoặc quy 15
trình đáp ứng yêu cầu đưa ra với những ràng buộc thực tế.
Khả năng cải tiến và phát triển 15
Khả năng sử dụng công cụ kỹ thuật, phần mềm chuyên 5
ngành…
3. Đánh giá về khả năng ứng dụng của đề tài 10
4. Sản phẩm cụ thể của ĐATN 10
Tổng điểm 100
7. Kết luận:
 Được phép bảo vệ
 Không được phép bảo vệ
TP.HCM, ngày tháng 8 năm 2020

Giảng viên phản biện
((Ký, ghi rõ họ tên)
TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT
THÀNH PHỐ HỒ CHÍ MINH
XÁC NHẬN HOÀN THÀNH ĐỒ ÁN
Tên đề tài: “NGHIÊN CỨU VÀ THỬ NGHIỆM MÁY CHẨN ĐOÁN CƠ BẢN”
Họ và tên Sinh viên: NGUYỄN TẤN THIỆN MSSV: 16145607
Ngành: Công nghệ Kỹ thuật ô tô
Sau khi tiếp thu và điều chỉnh theo góp ý của Giảng viên hướng dẫn, Giảng viên phản
biện và các thành viên trong Hội đồng bảo về. Đồ án tốt nghiệp đã được hoàn chỉnh đúng
theo yêu cầu về nội dung và hình thức.
Chủ tịch Hội đồng:
Giảng viên hướng dẫn:
Giảng viên phản biện:
Tp. Hồ Chí Minh, ngày tháng 8 năm 2020

LỜI CẢM ƠN
Trong quá trình thực hiện đề tài còn nhiều bỡ ngỡ, hạn chế và gặp không ít khó
khăn nhưng với sự quan tâm, đốc thúc của thầy ThS. Lê Quang Vũ cùng với sự nổ lực của
nhóm, đề tài “NGHIÊN CỨU VÀ THỬ NGHIỆM MÁY CHẨN ĐOÁN CƠ BẢN” đã được
hoàn thành.
Một lần nữa, với tình cảm sâu sắc và chân thành, cho phép chúng em được bày tỏ
lòng biết ơn sâu sắc đến Thầy cùng tất cả quý thầy cô Khoa Cơ khí Động lực – Trường
Đại học Sư phạm Kỹ Thuật Thành phố Hồ Chí Minh, bạn bè và gia đình đã tạo mọi điều
kiện thuận lợi, hỗ trợ chúng em trong quá trình thực hiên và hoàn thiện đề tài.
Dù đã rất cố gắng và nỗ lực để thực hiện đề tài này, nhưng do kiến thức và thời
gian có hạn nên không tránh khỏi những thiếu sót và hạn chế, vì vậy chúng em rất mong
nhận được những ý kiến đóng góp của quý thầy cô cùng các bạn.
Chúng em xin chân thành cảm ơn!
i
TÓM TẮT
Ngành Công nghiệp ô tô là một ngành đang phát triển mạnh mẽ ở nước ta, biểu
hiện của việc này là số lượng ô tô ở các tỉnh đang ngày càng gia tăng đáng kế, doanh số
các xe bán được cũng tăng lên mức đỉnh điểm. Nhưng ngành Công nghiệp ô tô ở nước ta
còn khá non trẻ so với các nước khác trên thế giới, đặc biệt ở phần kỹ thuật – thiết chẩn
đoán. Việc các máy chẩn đoán trên ô tô phát triển cũng cho thấy một chiếc ô tô đang
ngày càng hoàn thiện ở tất cả các mặt hiệu suất làm việc, mức độ an toàn, thông tin giải
trí và cả mặt chẩn đoán sửa chửa nhanh chóng.
Nắm bắt được tình hình đó, nhóm chúng em được đồng ý đã quyết định chọn đề
tài “NGHIÊN CỨU VÀ THỬ NGHIỆM MÁY CHẨN ĐOÁN CƠ BẢN” với sự hướng dẫn
của Thầy Lê Quang Vũ nhầm tạo ra một mô hình nhỏ của máy chẩn đoán với các chức
năng cơ bản như đọc dữ liệu xe, đọc mã lỗi, xóa lỗi dựa trên lập trình đơn giản từ
Arduino. Bao gồm gửi yêu cầu bằng giao thức CAN qua cổng OBD-II trên xe, giải mã tin
nhắn CAN và hiển thị lên màn hình cảm ứng LCD TFT, tích hợp chức năng cảm ứng.
Thử nghiệm đọc dữ liệu, đọc lỗi trên mô hình, trên xe và đồng thời, phát triển một máy
chẩn đoán cầm tay với các chức năng trên.
ii
MỤC LỤC
LỜI CẢM ƠN ......................................................................................................................i

TÓM TẮT .......................................................................................................................... ii
MỤC LỤC......................................................................................................................... iii
DANH MỤC CÁC CHỮ VIẾT TẮT VÀ KÝ HIỆU ................................................... vii
DANH MỤC CÁC HÌNH .................................................................................................ix
DANH MỤC CÁC BẢNG ............................................................................................. xiii
Chương 1. TỔNG QUAN ..................................................................................................1
1.1. Lý do chọn đề tài......................................................................................................1
1.2. Mục tiêu của đề tài ..................................................................................................2
1.3. Mục đích của đề tài..................................................................................................2
1.4. Phương pháp nghiên cứu ........................................................................................ 2
1.5. Hạn chế của đề tài....................................................................................................2
CHƯƠNG 2. LỊCH SỬ PHÁT TRIỂN OBD – TÌM HIỂU VỀ OBD-II ......................3
2.1. Lịch sử phát triển OBD ........................................................................................... 3
2.2. Các giao diện chuẩn trên ô tô .................................................................................4
2.2.1. ALDL ..................................................................................................................4
2.2.2. OBD-I .................................................................................................................5
2.2.3. OBD 1.5 ..............................................................................................................6
2.2.4. OBD-II ................................................................................................................7
2.2.5. EOBD ..................................................................................................................8
2.2.6. EOBD-II .............................................................................................................9
2.2.7. JOBD ..................................................................................................................9
2.2.8. ADR 79/01 & 79/02 (Australian OBD Standard) .............................................9
2.3. Khái quát về OBD – Các giao thức tín hiệu OBD-II tiêu chuẩn ....................... 10
2.3.1. Khái niệm OBD ................................................................................................ 10
iii
2.3.2. Các bộ phận của một hệ thống OBD............................................................... 10
2.3.3. Các giao thức tín hiệu của OBD – II .............................................................. 11
2.3.4. Dữ liệu chẩn đoán của OBD-II .......................................................................13
2.3.5. Phương thức hoạt động ...................................................................................13
2.3.6. Ứng dụng của OBD-II ..................................................................................... 15
Chương 3. CHẨN ĐOÁN – CHỨC NĂNG CỦA MÁY CHẨN ĐOÁN CƠ BẢN .....18
3.1. Kỹ thuật Chẩn đoán ô tô ....................................................................................... 18
3.1.1. Định nghĩa ........................................................................................................18
3.1.2. Mục đích của chẩn đoán..................................................................................18
3.1.3. Công cụ chẩn đoán ô tô ...................................................................................19
3.2. Các chức năng của máy chẩn đoán ......................................................................20
3.2.1. Đọc mã lỗi .........................................................................................................20
3.2.2. Xóa mã lỗi .........................................................................................................20
3.2.3. Dữ liệu động .....................................................................................................21
3.2.4. Trạng thái của trình giám sát ..........................................................................21
3.2.5. Thông tin xe, hộp điều khiển ...........................................................................22
Chương 4. LÝ THUYẾT VỀ MẠNG CAN ...................................................................23
4.1. Nguyên nhân và lịch sử phát triển .......................................................................23
4.1.1. Định nghĩa CAN Bus ....................................................................................... 23
4.1.2. Nguyên nhân ra đời của CAN Bus..................................................................23
4.1.3. Lịch sử về mạng CAN ...................................................................................... 24
4.2. Thuộc tính, ưu điểm và ứng dụng của CAN Bus ................................................25
4.2.1. Thuộc tính và ưu điểm của CAN Bus ............................................................. 25
4.2.2. Phạm vi ứng dụng của CAN Bus ....................................................................26
4.3. Cấu trúc của CAN Bus .......................................................................................... 27
4.3.1. Cấu trúc phân lớp của giao thức CAN............................................................ 27
4.3.2. Các thành phần cơ bản của mạng CAN ......................................................... 28
iv
4.3.3. Trạng thái tín hiệu và các chuẩn truyền trên mạng CAN ............................. 28
4.4. Các loại khung truyền của giao thức CAN ......................................................... 30
4.4.1. Khung dữ liệu (Data Frame) ...........................................................................31
4.4.2. Khung yêu cầu (Remote Frame) .....................................................................35
4.4.3. Khung báo lỗi (Error Frame) ..........................................................................36
4.4.4. Khung báo quá tải (Overload frame) .............................................................. 38
4.5. Khoảng liên khung ................................................................................................ 39
4.5.1. Vai trò và cấu trúc ............................................................................................ 39
4.5.2 Cấu tạo các vùng ............................................................................................... 40
4.6. Quy luật nhồi bit (Bit Stuffing) ............................................................................40
Chương 5. XÂY DỰNG MÔ HÌNH MÁY CHẨN ĐOÁN CƠ BẢN .......................... 42
5.1. Thông tin phần cứng ............................................................................................. 42
5.1.1. Arduino Nano ATmega328p ............................................................................42
5.1.2. Module CAN Bus MCP2515 ............................................................................43
5.1.3. Màn hình LCD TFT 2.4 inch ..........................................................................45
5.1.4. Module hạ áp LM2596 ..................................................................................... 46
5.1.5. Dây cáp DB9 - OBD-II ....................................................................................46
5.2. Phần mềm ...............................................................................................................47
5.2.1. Phần mềm lập trình – Arduino IDE................................................................ 47
5.2.2. Cài đặt thư viện trên Arduino IDE..................................................................48
5.2.3. Xây dựng giao diện hiển thị trên LCD ............................................................ 49
5.2.4. Xây dựng thuật toán gửi và nhận tín hiệu CAN.............................................50
5.2.6. Kết nối các thuật toán ...................................................................................... 55
5.3. Thử nghiệm Module Arduino Uno – CAN Bus Shield – LCD trên xe Vios.....55
5.3.1. Thu thập dữ liệu trên xe Vios qua Arduino IDE ............................................56
5.3.2. Thu thập dữ liệu qua hiển thị LCD .................................................................56
5.4. Xây dựng mô hình thiết bị chẩn đoán cơ bản ..................................................... 58
v
5.4.1. Vỏ thiết bị chẩn đoán ....................................................................................... 58
5.4.2. Thiết kế board mạch thiết bị chẩn đoán .......................................................... 58
Chương 5. KẾT LUẬN VÀ KIẾN NGHỊ ......................................................................61
DANH MỤC TÀI LIỆU THAM KHẢO........................................................................62
vi
DANH MỤC CÁC CHỮ VIẾT TẮT VÀ KÝ HIỆU
ABS Anti-lock Brake System

ALDL Assembly Line Diagnostic Link
CAL CAN Application Layer
CALID Calibration Identification
CAN Controller Area Network
CAN FD CAN flexible data-rate
CEL Check Engine Light
CiA CAN in Automation
CLCC Closed Loop Carburetor Control
DRCS Distributed Realtime Control System
DTCs Diagnostics Trouble Codes
ECM Electronic Control Module
ECU Electronic Control Unit
EGR Exhaust Gas Recirculation
EOBD European On-Board Diagnostics
GM General Motor
HDOBD Heavy truck On-Board Diagnostics
iOBD Intelligent On-Board Diagnostics
JOBD Japan On-Board diagnostics
OBD On-Board Diagnostics
OBD-II PIDs On-Board Diagnostics Parameter Identification Numbers
OSI Open Systems Interconnection
MIL Malfunction Indicator Light
SAE Society of Automotive Engineers
SES Service Engine Soon
PCM Powertrain Control Module
vii
PWM Pulse-width modulation
TCM Transmission Control Module
UART Universal Asynchronous Receiver / Transmitter
VIN Vehicle Identification Number
VPW Variable pulse width
VVT Variable Valve Timming
viii
DANH MỤC CÁC HÌNH
Trang
Hình 2.1. Các giắc nối trên ALDL .................................................................................15
Hình 2.2. Hình dạng các giắc OBD-I các hãng xe......................................................... 16
Hình 2.3. Các chân trên giắc OBD-I của hãng Toyota ..................................................16
Hình 2.4. Các chân giắc ALDL được dùng trong OBD-1.5 ...........................................17
Hình 2.5. Các chân ra của giắc OBD-II theo chuẩn SAE J1962 ...................................18
Hình 2.6. Ý nghĩa các kí tự trong mã lỗi chuẩn đoán ....................................................20
Hình 2.7. Các bộ phận của một hệ thống ECU .............................................................. 21
Hình 2.8. Các chân ra của giắc OBD-II theo chuẩn J1850 PWM .................................22
Hình 2.9. Các chân ra của giắc OBD-II theo chuẩn J1850 VWM .................................22
Hình 2.10. Các chân ra của giắc OBD-II theo chuẩn ISO 9141-2 và KWP2000 ..........23
Hình 2.11. Các chân ra của giắc OBD-II theo chuẩn ISO 15765 CAN......................... 24
Hình 2.12. Máy chuẩn đoán cầm tay với kết nối OBD-II...............................................26
Hình 2.13. Thiết bị chuẩn đoán qua điện thoại Smartphone - iOBD-II ......................... 27
Hình 2.14. Một phần mềm chuẩn đoán OBD qua máy tính – OBDAutoDoctor ............27
Hình 2.15. Thiết bị kiểm tra khí thải AutoLink AL529 tiêu chuẩn EOBD ..................... 28
Hình 3.1. Chuẩn đoán ô tô thông qua máy chuẩn đoán .................................................30
Hình 3.2. Chuẩn đoán ô tô theo phương pháp truyền thống..........................................30
Hình 3.3. Hiển thị mã lỗi trên máy chuẩn đoán ............................................................. 31
Hình 3.4. Chức năng xóa lỗi trên máy chuẩn đoán ....................................................... 31
Hình 3.5. Chức năng hiển thị dữ liệu động trên máy chuẩn đoán .................................32
Hình 3.6. Hiển thị trạng thái của trình giám sát ............................................................ 32
Hình 3.7. Thông tin của xe và bộ điều khiển ..................................................................33
Hình 4.1. Minh họa kết nối các ECU trên ô tô khi chưa sử dụng CAN Bus ..................34
Hình 4.2. Minh họa kết nối các ECU trên ô tô sử dụng CAN Bus .................................35
Hình 4.3. Mạng lưới đường truyền tín hiệu trên ô tô ..................................................... 38
ix
Hình 4.4a. Cấu trúc phân lớp của mạng CAN theo mô hình OSI ..................................38
Hình 4.4b. Cấu trúc phân lớp của mạng CAN theo mô hình OSI ..................................39
Hình 4.5. Các thành phần cơ bản của mạng CAN ......................................................... 39
Hình 4.6. Minh họa mạng CAN tốc độ cao ISO 11898-2 ...............................................40
Hình 4.7. Tín hiệu CAN tốc độ cao ISO 11898-2 ........................................................... 40
Hình 4.8. Minh họa mạng CAN tốc độ thấp ISO 11898-3 .............................................41
Hình 4.9. Tín hiệu CAN tốc độ thấp ISO 11898-3 ......................................................... 41
Hình 4.10. Định dạng khung tiêu chuẩn ........................................................................42
Hình 4.11. Định dạng khung mở rộng ............................................................................42
Hình 4.12. Các phân lớp bit của vùng phân xử.............................................................. 44
Hình 4.13. Giá trị của các bit DLC ................................................................................44
Hình 4.14. Độ dài tối thiểu và tối đa của vùng dữ liệu ..................................................45
Hình 4.15. Các phần của vùng CRC ..............................................................................45
Hình 4.16. Các phần của vùng ACK ..............................................................................46
Hình 4.17. Khung yêu cầu dạng chuẩn ..........................................................................47
Hình 4.18. Các phần của khung báo lỗi .........................................................................47
Hình 4.19. Cờ lỗi chủ động và bị động ..........................................................................48
Hình 4.20. Các phần của khung quá tải .........................................................................49
Hình 4.21. Cấu trúc 1 của khoảng liên khung................................................................ 50
Hình 4.22. Cấu trúc 2 của khoảng liên khung................................................................ 50
Hình 4.23. Phương pháp nhồi bit ...................................................................................51
Hình 5.1. Module Arduino Nano ....................................................................................53
Hình 5.2. Các chân trên Module Arduino Nano ............................................................ 53
Hình 5.3. Module CAN Bus MCP2515 ...........................................................................54
Hình 5.4. Các chân chức năng và Chip xử lí của module MCP2515 ............................ 55
Hình 5.5. Màn hình LCD TFT 2.4 inch ..........................................................................56
Hình 5.6. Module giảm áp .............................................................................................. 57
x
Hình 5.7. Dây cáp DB9 – OBD-II ..................................................................................58
Hình 5.8. Kết nối giữa 2 đầu cáp DB9 – OBD-II ........................................................... 58
Hình 5.9. Giao diện của Arduino IDE............................................................................59
Hình 5.10. Giao diện màn hình chính và màn hình đọc dữ liệu hiện tại ....................... 60
Hình 5.11. Giao diện màn đọc mã lỗi chẩn đoán và màn hình xóa lỗi .......................... 61
Hình 5.12. Cấu trúc ID vùng dữ liệu trong tin nhắn CAN theo tiêu chuẩn OBD-II ......61
Hình 5.13. ID và vùng dữ liệu của tin yêu cầu và tin phản hồi......................................61
Hình 5.14. PID và công thức tính của Tốc độ xe và Tua máy (Engine RPM) ...............62
Hình 5.15. Đường dẫn Code OBD-II mẫu theo thư viện CAN.......................................63
Hình 5.16. Cấu trúc vùng dữ liệu trong tin nhắn CAN yêu cầu .....................................63
Hình 5.17. Vùng dữ liệu trong tin nhắn CAN phẩn hồi tốc độ xe ..................................63
Hình 5.18. Một vài thông số từ ECU trong chế độ đọc dữ liệu hiện tại chuẩn OBD-II 64
Hình 5.19. Chương trình gửi tin nhắn CAN cho các chế độ của OBD-II ...................... 64
Hình 5.20. Vùng dữ liệu tin nhắn CAN phản hồi ........................................................... 64
Hình 5.21. Chuyển đổi hai kí tự đầu trong mã lỗi chẩn đoán OBD-II .......................... 65
Hình 5.22. Chuyển đổi kí tự 3-4-5 trong mã lỗi chẩn đoán OBD-II .............................. 65
Hình 5.23. Sơ đồ khối tổng quát thuật toán của thiết bị chẩn đoán............................... 66
Hình 5.24. Module thử nghiệm thiết bị chẩn đoán ......................................................... 66
Hình 5.25. Dữ liệu thu thập được từ arduino khi khi thử nghiệm module trên xe .........67
Hình 5.26. Dữ liệu đọc được từ xe .................................................................................67
Hình 5.27. Thông số hiển thị trên bảng Taplo xe khi đọc dữ liệu ..................................67
Hình 5.28. Tạo lỗi tại giắc của cảm biến lưu lượng khí nạp .........................................68
Hình 5.29. Mã lỗi thu được sau khi tạo ban và đọc lỗi ..................................................68
Hình 5.30. Tra cứu mã lỗi thu thập được .......................................................................68
Hình 5.31. Xóa lỗi và kiểm tra lỗi lại .............................................................................69
Hình 5.32. Vỏ thiết bị chẩn đoán ....................................................................................69
Hình 5.33. Sơ đồ kết nối các module ..............................................................................70
xi
Hình 5.34. Mạch nguyên lý của thiết bị chẩn đoán ........................................................ 70
Hình 5.35. Bản vẽ mạch điện tử của thiết bị chẩn đoán ................................................71
xii
DANH MỤC CÁC BẢNG
Trang
Bảng 4.1. Liên hệ giữa tốc độ truyền dữ liệu và chiều dài mạng...................................37
Bảng 5.1. Các thông số cơ bản của Arduino Nano ........................................................ 54
Bảng 5.2. Các thông số cơ bản của Module MCP2515 .................................................55
Bảng 5.3. Các thông số cơ bản của LCD .......................................................................56
Bảng 5.4. Các thông số cơ bản của Module hạ áp LM2596 ..........................................57
Bảng 5.5. Các chế độ chẩn đoán của OBD-II ................................................................ 62
xiii
Chương 1. TỔNG QUAN
1.1. Lý do chọn đề tài
Kinh tế nước ta từ khi mở cửa hội nhập và đi theo nền kinh tế thị trường theo định
hướng xã hôi chủ nghĩa đã có những bước phát triễn mạnh mẽ. Khi nền kinh tế phát triển
thì đòi hỏi ngành giao thông cũng phải phát triển mạnh mẽ để đáp ứng nhu cầu vận
chuyển hàng hóa và hành khách ngày càng gia tăng. Để đáp ứng nhu cầu vận chuyển đó
có các loại hình vận chuyển như: đường bộ, đường hàng không, đường biển,… Nhưng
trong đó vận chuyển đường bộ là phát triển mạnh mẽ nhất và đáp ứng phần lớn nhu cầu
vận chuyển của nền kinh tế. Chính vì vậy trong thời gian gần đây số lượng và chủng loại
ô tô nước ta tăng một cách đáng kể. Cùng với quá trình vận hành theo thời gian ô tô sẽ
xảy ra những hiện tượng hư hỏng ảnh hưởng đến khả năng vận chuyển của các loai ô tô.
Để đảm bảo năng suất cũng như kéo dài thời gian sử dụng các loại phương tiện, trong
quá trình hoạt động phải thường xuyên thực hiện công tác kiểm tra, bảo dưỡng, sửa chữa.
Chính vì vậy nhu cầu về công tác bảo dưỡng sửa chữa các loại ô tô càng đòi hỏi cấp thiết.
Trước đây khi ô tô đơn thuần chỉ là một hệ thống cơ khí thì công tác bảo dưỡng
sửa chữa phụ thuộc nhiều vào trình độ của người thợ và công tác sửa chữa tốn rất nhiều
thời gian. Từ những năm 80 của thế kỉ trước các loại vi mạch điện tử đã được con người
bắt đầu sử dụng trên ô tô. Theo thời gian điều khiển điện tử tham gia sâu vào quá trình
điều khiển ô tô thì phương pháp chuẩn đoán điện tử càng xuất hiện nhiều để dễ dàng
giám sát các trạng thái và thông báo tình trạng hỏng hóc của ô tô. Cho đến hiện tại các xe
sản xuất buộc phải có hệ thống tự chuẩn đoán mã lỗi tiêu chuẩn đó là hệ thống mã lỗi tiêu
chuẩn OBD-II (On-Board Diagnostic II) với giao thức CAN.
Trong quá trình học tập của mình, chúng em luôn mong muốn tìm tòi và áp dụng
các kỹ thuật tiên tiến vào công tác bảo dưỡng sửa chữa để công tác bảo dưỡng sủa chữa
được chính xác và tiết kiệm. Do đó chúng em đã nghiên cứu về ứng dụng máy chuẩn
đoán kỹ thuật trong công tác bảo dưỡng xe ô tô. Hiện nay trên thị trường có rất nhiều loại
máy chuẩn đoán cho nhiều chủng loại xe của rất nhiều hãng khác nhau, chúng em rất
mong muốn có thể tìm hiểu về tất cả loại máy này. Do khối lượng và thời gian hoàn
thành đồ án tốt nghiệp có hạn nên em chỉ xin đi tìm hiểu và xây dựng một máy chuẩn
đoán đọc các thông tin cơ bản.
1
1.2. Mục tiêu của đề tài
Nhằm phục vụ cho công tác giảng dạy và tạo điều kiện thuận lợi cho giáo viên
hướng dẫn sinh viên trong quá trình học tập, giúp sinh viên ứng dụng được ngay bài học
lý thuyết vào thực hành.
1.3. Mục đích của đề tài
Trong quá trình nghiên cứu thực hiện đề tài này, bản thân em nhận thấy đây là cơ
hội để cũng cố lại kiến thức mà mình đã được học. Ngoài ra em còn tìm hiểu được những
kiếm thức thực tế mà ở trường chưa được học. Đó là sự bổ ích cho ems au này ra trường.
Thực hiện tiểu luận tốt nghiệp cũng là dịp để chúng em nâng cao các kỹ năng nghề
nghiệp, khả năng nghiên cứu và phương pháp giải quyết các vấn đề.
Cuối cùng việc hoàn thành tiểu luận tốt nghiệp sẽ giúp sinh viên tinh thần trách
nhiệm, lòng say mê học hỏi, sáng tạo. Và quan trọng là lòng yêu nghề.
1.4. Phương pháp nghiên cứu
Trong quá trình thực hiện đề tài chúng em có sử dụng một số phương pháp nghiên
cứu sau:
• Sử dụng kiến thức đã học trong nhà trường và quá trình trải nghiệm của bản
thân, nghiên cứu tài liệu về chuẩn đoán bệnh ô tô.
• Tìm kiếm các thông tin trên internet, các website trong và ngoài nước sau
đó so sánh và sàng lọc để sử dụng thông tin cần thiết và đáng tin cậy.
• Tham khảo ý kiến của giảng viên, các bạn sinh viên trong khoa công nghệ ô
tô, …
• Tổng hợp và phân tích các nguồn dữ liệu thu thập được, từ đó đưa ra những
đánh giá và nhận xét của bản thân.
1.5. Hạn chế của đề tài
Do thời gian và kiến thức có hạn nên không thể, nghiên cứu nhiều hơn xây dựng
một mô hình hoàn thiện cũng như không tránh khỏi những sai sót. Vì vậy chúng em rất
mong được sự đóng góp chỉ bảo của các thầy cô để đề tài được hoàn thiện hơn và đó là
những kinh nghiệm giúp em sau này ra trường.
2
CHƯƠNG 2. LỊCH SỬ PHÁT TRIỂN OBD – TÌM HIỂU VỀ OBD-II
2.1. Lịch sử phát triển OBD
Năm 1968, Volkswagen giới thiệu hệ thống tự chẩn đoán trên xe đầu tiên với khả
năng quét hệ thống phun nhiên liệu trên xe Volkswagen Type 3.
Năm 1978, hệ thống tự chẩn đoán bắt đầu được sử dụng trên các dòng xe như
Nissan Datsun 280Z, phần lớn được thúc đẩy bởi nhu cầu điều chỉnh hệ thống phun nhiên
liệu theo thời gian thực. Lúc này, Hộp điều khiển điện tử ECU đã phát triển mạnh mẽ và
trở nên phổ biến. Hệ thống OBD đơn giản xuất hiện, dù không có sự tiêu chuẩn hóa trong
việc giám sát và mỗi xe lại có một giắc chẩn đoán khác nhau.
Năm 1980, General Motors bổ sung một giao diện và giao thức độc quyền để thử
nghiệm Mô-đun điều khiển động cơ (ECM) trên dây chuyền lắp ghép xe. Các “Bộ đường
truyền liên kết chẩn đoán” (ALDL) giao thức truyền tải với 160bit/s thi hành trên các xe
ở California cho mẫu xe năm 1980, và phần còn lại của Hoa Kỳ năm 1981. Hầu hết các
chủ xe đều có thể đọc mã DTC (Diagnostic Trouble Code) của hệ thống ECM (Mô-đun
điều khiển động cơ) thông qua kiểu nhấp nháy của CEL (Check Engine Light) hoặc MIL
(Malfunction Indicator Light).
Năm 1986, một phiên bản nâng cấp của giao thức ALDL xuất hiện, phiên bản này
truyền tải với 8192 bit/s với tín hiệu UART một chiều. Giao thức này được định nghĩa
trong GM XDE-5024B.
Năm 1988, Hiệp hội các kỹ sư ô tô (SAE) giới thiệu một đầu nối chẩn đoán tiêu
chuẩn và bộ tín hiệu đo kiểm.
Năm 1991, Ban Tài Nguyên & Môi Trường của California yêu cầu tất cả các xe
mới đã bán ở California năm 1991 và các xe mới hơn phải được trang bị hệ thống tự chẩn
đoán OBD cơ bản. Với tên gọi tắt là “OBD-I’’, mặc dù tên này không được ứng dụng cho
đến khi OBD-II được giới thiệu. Đầu kết nối dữ liệu và vị trí của nó không được tiêu
chuẩn hóa, cũng không phải là giao thức dữ liệu.
Năm 1994, Với mong muốn có một chương trình thử nghiệm khí thải trên toàn
tiểu bang, CARB đưa ra tiêu chuẩn OBD-II và yêu cầu áp dụng tiêu chuẩn này cho các
mẫu xe được bán tại California bắt đầu từ năm 1996. Các DTCs và đầu kết nối được đề
xuất bởi SAE được kết hợp chặt chẽ trong các đặc điểm kỹ thuật này.
3
Năm 1996, Tiêu chuẩn OBD-II được bắt buộc cho tất cả các xe sản xuất ở Hoa Kỳ
được bán tại Hoa Kỳ.
Năm 2001, Liên Minh Châu Âu EU áp dụng tiêu chuẩn EOBD đối với tất cả các
xe sử dụng nhiên liệu xăng được bán ở Châu âu, bắt đầu từ tháng 01/2001. Tiêu chuẩn
EOBD cũng được áp dụng trên tất cả các xe sử dụng nhiên liệu Diesel (2003).
Năm 2008, tất cả các xe bán tại Hoa Kỳ đều phải sử dụng tín hiệu tiêu chuẩn ISO
15765 - 4 (một phiên bản của CAN bus).
Năm 2010, Đặc điểm kỹ thuật HDOBD (tải nặng) được bắt buộc thực hiện cho các
động cơ thương mại được bán ở Hoa Kỳ (Không phải xe du lịch).
2.2. Các giao diện chuẩn trên ô tô
2.2.1. ALDL
ALDL (Assembly Line Diagnostic Link) của GM là một giao diện chẩn đoán độc
quyền của General Motors bắt đầu được ứng dụng từ cuối những năm 1970 và đầu những
năm 1980 trên hệ thống điều khiển chế hòa khí khép kín (CLCC - Closed Loop
Carburetor Control) và các hệ thống phun xăng điện tử (EFI) của GM. Đó là một dạng
tiêu chuẩn hóa vì chẩn đoán bằng giắc không thay đổi qua nhiều năm liền nên hãng GM
đã đưa ALDL vào sử dụng.
Hình 2.1 - Các chân trên giắc ALDL
4
Giao thức kết nối này đã được thay đổi với nhiều loại khác nhau và thay đổi theo
các mô-đun điều khiển hệ thống truyền động (PCM, ECM, ECU). Các phiên bản khác
nhau cho thấy sự khác biệt nhỏ trong sơ đồ chân và tốc độ truyền tải dữ liệu. Các phiên
bản trước đã sử dụng 160 bit/s, trong khi các phiên bản sau đó lên đến 8192 bit/s và sử
dụng hình thức giao tiếp hai chiều với PCM hoặc ECM/TCM.
2.2.2. OBD-I
Một tiêu chuẩn của California từ những năm 1991. Mục đích pháp lý của OBD-I
là khuyến khích các nhà sản xuất ô tô thiết kế các hệ thống kiểm soát khí thải đảm bảo
chính xác mà vẫn duy trì được hiệu suất sử dụng của xe. Các mã chẩn đoán (DTC) của xe
OBD-I có thể được tìm thấy mà không cần một máy chẩn đoán đắt tiền. Mỗi nhà sản xuất
đã sử dụng chính giắc liên kết chẩn đoán riêng (DLC) của họ: vị trí DLC, dấu hiệu nhận
biết DTC và quy trình để đọc DTC từ xe. Các DTC từ xe ô tô OBD-I thường được đọc
thông qua kiểu nhấp nháy của đèn ‘Check Enigne’ (CEL – Check Engine Light) hoặc
‘Bảo dưỡng động cơ sớm’ (SES – Service Engine Soon). Bằng cách kết nối một số chân
nhất định của giắc chẩn đoán, đèn ‘Check Engine’ sẽ nhấp nháy ra một tín hiệu số có 2
trạng thái tương ứng với một tình trạng lỗi cụ thể. Tuy nhiên, các DTC của một số xe
OBD-I được giải thích theo những cách khác nhau.
Hình 2.2 – Hình dạng các giắc OBD-I các hãng xe
Hình 2.3. Các chân trên giắc OBD-I của hãng Toyota
5
2.2.3. OBD 1.5
OBD 1.5 có liên quan một phần đến việc bổ sung OBD-II mà GM đã sử dụng cho
một số xe trong năm 1994 và 1995. OBD 1.5 là một thuật ngữ không chính thức. GM
không sử dụng thuật ngữ này trong các tài liệu hướng dẫn sử dụng xe của hãng, chỉ đơn
giản là nó có một phần của OBD và một phần của OBD 2 trong sổ tay bảo dưỡng. Hầu
hết các xe 1994 và 1995 chỉ đơn giản là giắc kết nối dữ liệu ALDL 8196 được nhà cung
cấp lấy dữ liệu từ chân số 9 của giắc J1962, nay được chính thức sử dụng cho OBD-II từ
năm 1996.
Ví dụ: Corvettes 94-95 có một cảm biến oxy phía sau bộ chuyển đổi xúc tác (mặc
dù chúng có hai bộ chuyển đổi xúc tác ), và chỉ có một số ít mã OBD-II được thực hiện.
Đối với Corvette năm 1994 mã OBD-II đã được thực hiện là P0116 -P0118, P0131 -
P0135, P0151 - P0155, P0158, P0160 - P0161, P0171 - P0175, P0420, P1114 - P1115,
P1133, P1153 và P1158.
Hệ thống lai - Hybrid - đã được xuất hiện trên GM H-bodycars năm 94 - 95, các
xe W-body (Buick Regal, Chevrolet Lumina (1995), Chevrolet Monte Carlo (1995),
Pontiac Grand Prix, Oldsmobile Cutlass Supreme năm 94 - 95, Lbody (Chevrolet
Beretta/Corsica) năm 94 - 95, Ybody (Chevrolet Corvette) năm 94 - 95, trên Fbody
(Chevrolet Camaro and Pontiac Firebird) năm 95 và trên JBody (Chevrolet Cavalier and
Pontiac Sunfire) và NBody (Buick Skylark, Oldsmobile Achieva, Pontiac Grand Am)
năm 95 và 96 và cũng trên các xe Saab năm 94 - 95 với hút khí tự nhiên 2.3.
Chân ra để kết nối ALDL trên các xe này như sau:
Hình 2.4. Các chân giắc ALDL được dùng trong OBD – 1.5
Đối với các kết nối ALDL, chân 9 là truyền dữ liệu, chân 4 và 5 nối đấy và chân
16 là điện áp nguồn. Cần có một công cụ quét tương thích với OBD 1.5 để đọc mã được
tạo bởi OBD 1.5.
6
Các mạch chẩn đoán và điều khiển cho một xe cụ thể cũng có sẳn trên kết nối này.
Chẳng hạn, trên Corvette có các giao diện cho loại 2 dòng dữ liệu nối tiếp từ PCM, thiết
bị đầu cuối chẩn đoán CCM, dòng dữ liệu radio, hệ thống túi khí, hệ thống điều khiển đi
xe có chọn lọc, hệ thống cảnh báo áp suất lốp xe thấp và hệ thống khóa từ xa thụ động.
OBD 1.5 cũng được sử dụng trên trên dòng xe Ford Scorpio từ năm 1995.
2.2.4. OBD-II
OBD-II là một cải tiến đối với OBD-I cả về khả năng và tiêu chuẩn hóa. Tiêu
chuẩn OBD-II xác định rõ kiểu của đầu nối chẩn đoán và chân ra của nó, có sẵn các giao
thức truyền tín hiệu điện, và định dạng tin. Nó cũng cung cấp một danh sách dữ liệu các
thông số của xe để theo dõi cùng với việc làm như thế nào để mã hóa cho từng dữ liệu.
Có 1 chân trong đầu nối cung cấp nguồn cho máy chẩn đoán từ ắc quy của xe, điều này
loại bỏ nhu cầu kết nối một máy chẩn đoán với một nguồn điện riêng. Tuy nhiên, một vài
kỹ thuật viên vẫn có thể kết nối máy chẩn đoán đến một nguồn phụ để bảo vệ dữ liệu
trong trường hợp bất thường khi gặp phải sự cố mất điện. Cuối cùng, tiêu chuẩn OBD-II
cung cấp danh sách các mã lỗi DTC chuẩn. Theo kết quả của tiêu chuẩn này, một thiết bị
duy nhất có thể truy vấn các máy tính trên xe cho các thông số này trong bất kỳ dòng xe
nào. Tiêu chuẩn OBD-II được thúc đẩy bởi các yêu cầu về khí thải, dù các mã và dữ liệu
được yêu cầu chỉ liên quan đến khí thải, phần lớn các nhà sản xuất đã thiết kế đầu nối
truyền dữ liệu OBD-II là kết nối chính trong xe, thông qua đó tất cả các hệ thống được
chẩn đoán và lập trình. Mã lỗi OBD-II có 4 chữ số, bắt đầu là chữ cái: P là hệ thống động
cơ và hộp số (Powertrain), B là thân xe (Body), C là khung gầm (Chassis) và U là mạng.
Đặc điểm kỹ thuật của OBD-II cung cấp thiết kế phần cứng được tiêu chuẩn hóa -
Đầu nối Cái J1962 16 chân (2x8). Không giống như đầu nối OBD-I, đôi khi được tìm
thấy dưới mui xe, đầu nối OBD-II được yêu cầu phải nằm trong vòng 2 feet (0,61 m) trên
vô lăng.
Hình 2.5. Các chân ra của giắc OBD-II theo chuẩn SAE J1962
7
Chân 1 : Tùy thuộc nhà sản xuất
Chân 2 : Đường truyền dương của chuẩn SAE J1850 PWM và VPW
Chân 4 : Nối Mass sườn
Chân 5 : Tín hiệu Mass
Chân 6 : CAN-High (ISO 15765-4 và SAE J2284)
Chân 7 : K-line – ISO 9141-2/ISO 14230-4
Chân 10 : Đường dây âm của SAE J1850 PWM
Chân 14 : CAN-Low (ISO 15765-4 và SAE J2284)
Chân 15 : L-line – ISO 9141-2/ISO 14230-4
Chân 16 : + VCC
2.2.5. EOBD
Giao thức EOBD (European on board diagnostics – Chẩn đoán trên dòng xe Châu
Âu) là tiêu chuẩn kết nối của Châu Âu tương đương với OBD 2 và sử dụng cho tất cả các
dòng xe du lịch loại M1 (không quá 8 chỗ ngồi và trọng lượng từ 2,5 tấn trở xuống),
được áp dụng lần đầu cho các nước thành viên EU kể từ 01/01/2001 cho các xe sử dụng
nhiên liệu xăng và kể từ 01/01/2004 đối với xe sử dụng nhiên liệu Diesel.
Đối với các dòng xe được giới thiệu gần đây, các ngày quy định được áp dụng vào
01/01/2000 đối với xe sử dụng nhiên liệu xăng và 01/01/2003 đối với xe sử dụng nhiên
liệu Diesel. Đối với các xe du lịch có tổng trọng lượng lớn hơn 2,5 tấn và các dòng xe
thương mại nhẹ thì ngày quy định bắt đầu được áp dụng từ 01/01/2002 cho các xe sử
dụng động cơ xăng và 01/01/2007 đối với xe sử dụng động cơ Diesel.
Việc áp dụng phương thức kết nối EOBD về cơ bản cũng tương tự như OBD-II,
cùng một kiểu kết nối chẩn đoán tiêu chuẩn SAE J1962 và các giao thức tín hiệu được sử
8
dụng. Với tiêu chuẩn phát thải Euro V và Euro VI, ngưỡng phát thải EOBD thấp hơn
Euro III và IV trước đó.
Mỗi mã lỗi EOBD gồm có 5 ký tự: 1 chữ cái, theo sau là 4 chữ số. Chữ cái mô tả
hệ thống đang được kiểm tra. Ví dụ: Pxxxx là mô tả về hệ thống truyền lực. Ký tự tiếp
theo có thể là số 0 nếu tuân theo tiêu chuẩn EOBD. Vì vậy mã lỗi sẽ được mô tả là
P0xxx.
Hình 2.6. Ý nghĩa các kí tự trong mã lỗi chẩn đoán

2.2.6. EOBD-II
Thuật ngữ “EOBD 2” được sử dụng bởi một vài nhà sản xuất xe ô tô dùng để chỉ
dẫn đến các tính năng cụ thể của nhà sản xuất cụ thể mà không thực sự là một phần của
tiêu chuẩn OBD hoặc EOBD (Enhanced On-Board Diagnostic).
2.2.7. JOBD
JOBD là một phiên bản của OBD-II dành cho các dòng xe tại Nhật Bản.
2.2.8. ADR 79/01 & 79/02 (Australian OBD Standard)
Tiêu chuẩn ADR 79/01 (Úc phát thảo điều lệ 79/01 – Kiểm soát khí thải cho các
dòng xe hạng nhẹ, vào năm 2005) tương đương với OBD 2 của Úc. Tiêu chuẩn này được
áp dụng cho tất cả các xe loại M1 và N1 với tổng trọng lượng từ 3,5 tấn trở xuống, đã
đăng ký từ khi mới ban hàng tại Úc và đã sản xuất từ 01/01/2006 cho các dòng xe sử
dụng động cơ xăng và từ 01/01/2007 cho các dòng xe sử dụng động cơ Diesel. Đối với
9
các dòng xe mới được giới thiệu, các ngày áp dụng sớm hơn 2 năm 01/01/2005 cho các
xe sử dụng động cơ xăng và 01/01/2006 cho các xe sử dụng động cơ Diesel.
Tiêu chuẩn ADR 79/01 được bổ sung bởi tiêu chuẩn ADR 79/02, tiêu chuẩn này
bắt buộc hạn chế khí thải chặt chẽ hơn, áp dụng cho tất cả các xe hạng M1 và N1 với
tổng trọng lượng xe từ 3,5 tấn trở xuống từ 01/07/2008 cho các dòng xe mới. Và ngày
01/10/2010 đối với tất cả các dòng xe. Các bổ sung của tiêu chuẩn này về cơ bản giống
như OBD-II, với giắc kết nối chuẩn SAE J1962 và các giao thức tín hiệu được sử dụng.
2.3. Khái quát về OBD – Các giao thức tín hiệu OBD-II tiêu chuẩn
2.3.1. Khái niệm OBD
OBD (On-Board Diagnostic) là một thuật ngữ về ô tô đề cập đến khả năng tự chẩn
đoán và tự báo cáo kết quả của xe. Hệ thống OBD cung cấp cho chủ xe hoặc kỹ thuật
viên sửa chữa biết tình trạng hoạt động của các hệ thống trên xe. Số lượng thông tin chẩn
đoán có sẵn thông qua OBD đã thay đổi rất nhiều từ khi nó được giới thiệu trong những
năm đầu thập niên 1980 của các phiên bản chẩn đoán trên xe.
2.3.2. Các bộ phận của một hệ thống OBD
Hệ thống OBD được cấu thành từ những bộ phận cơ bản bao gồm hộp ECU
(Electronic Control Unit) điều khiển động cơ, các cảm biến và cơ cấu chấp hành của từng
hệ thống, cổng kết nối và đèn ‘Check Engine’. Và hộp ECU sẽ nhận tín hiệu từ các cảm
trên động cơ như cảm biến trục cơ, trục cam hay cảm biến oxy… để có thể điều khiển các
cơ cấu chấp hành như kim phun, bô bin… nhằm nâng cao sự chính xác trong vận hành
của động cơ.
Hình 2.7. Các bộ phận của một hệ thống ECU
10
ECU sẽ tự chẩn đoán và cài đặt vào bộ nhớ mã lỗi được thiết lập từ trước khi động
cơ gặp phải vấn đề, lúc này đèn Check Engine hoặc MIL (Malfunction Indicator Light) sẽ
sáng lên báo cho các tài xế biết xe đang gặp phải vấn đề và cần sửa chữa kịp thời.
2.3.3. Các giao thức tín hiệu của OBD – II
Có 5 giao thức tín hiệu được chấp nhận đối với chuẩn kết nối OBD-II. Hầu hết các
xe chỉ thực hiện một trong các giao thức. Để biết được giao thức kết nối nào được sử
dụng, ta có thể suy ra dựa trên số chân ra có trên đầu kết nối J1962.
2.3.3.1 SAE J1850 PWM (Điều biến độ rộng xung – 41,6 kbit/s, tiêu chuẩn của
hãng ô tô Ford)
Hình 2.8. Các chân ra của giắc OBD-II theo chuẩn J1850 PWM
Với tiêu chuẩn SAE J1850 PWM, đầu kết nối phải có chân 2 (Bus+), chân 10
(Bus-), chân 4 và 5 (GND), chân 12 (+12V). Các chân còn lại được tùy biến theo từng
nhà sản xuất.
2.3.3.2. SAE J1850 VPW (Độ rộng xung biến thiên - 10,4 kbit/s, tiêu chuẩn của
hãng General Motors)
Hình 2.9. Các chân ra của giắc OBD-II theo chuẩn J1850 VPW
11
Với tiêu chuẩn SAE J1850 VPW, đầu kết nối phải có chân 2 (Bus+), chân 4 và 5
(GND), chân 12 (+12V). Các chân còn lại được tùy biến theo nhà sản xuất.
2.3.3.3. ISO 9141-2
Giao thức này có tốc độ dữ liệu nối tiếp không đồng bộ là 10,4 kbit/s. Tuy nhiên,
các mức tín hiệu khác nhau và sự giao tiếp diễn ra trên một đường truyền 2 chiều riêng
biệt mà không có tín hiệu khác được bổ sung. ISO 9141-2 chủ yếu được sử dụng trong
các dòng xe Chrysler, Châu Âu và Châu Á.
Hình 2.10. Các chân ra giắc OBD-II theo chuẩn ISO 9141-2 và KWP2000
Với tiêu chuẩn SAE J1850 VPW, đầu kết nối phải có chân 7 (K-line), 15 (L-line),
4 - 5 (GND), 12 (+12V). Các chân còn lại được tùy biến theo từng nhà sản xuất.
2.3.3.4. ISO 14230 KWP2000 (Keyword Protocol 2000)
- Chân số 7: Đường K – K-line.
- Chân số 15: Đường L – L-line (tùy chọn).
- Lớp vật lý giống như ISO 9141-2.
- Tốc độ dữ liệu 1,2 đến 10,4 kbit/s.
- Mức điện áp cao: +12V (phút/tối đa 9,6 đến 13,5).
- Số tín hiệu có thể chứa tới 255 bytes trong một trường dữ liệu.
2.3.3.5. ISO 15765 CAN (250 kbit/s hoặc 500 kbit/s).
Giao thức CAN được Bosch phát triển để kiểm soát ô tô và công nghiệp. Không
giống như các giao thức OBD khác, các biến thể được sử dụng rộng tãi bên ngoài ngành
công nghiệp ô tô. Mặc dù không đáp ứng yêu cầu của OBD 2 đối với các dòng xe Mỹ
trước năm 2003, kể từ năm 2008 tất cả các xe bán tại thị trường Mỹ đều phải cài đặt giao
thức CAN.
12
Hình 2.11. Các chân ra của giắc OBD-II theo chuẩn ISO 15765 CAN
- Chân số 6: CAN cao.
- Chân số 14: CAN thấp.
- CAN-H mức điện áp tín hiệu: 3,5V (phút / tối đa 2,75 đến 4,5).
- CAN-L mức điện áp tín hiệu: 1,5V (phút / tối đa 0,5 đến 2,25).
Tất cả các chân ra của OBD-II đề sử dụng cùng một loại kết nối, nhưng các chân
khác được sử dụng tùy biến trừ chân số 4 (âm nguồn) và 16 (dương nguồn).
2.3.4. Dữ liệu chẩn đoán của OBD-II
OBD-II cung cấp nguồn truy cập dữ liệu từ Hộp điều khiển động cơ (ECU) và truy
xuất thông tin dữ liệu khi xe gặp phải vấn đề nào đó. Tiêu chuẩn SAE J1979 là phương
thức để chuyển đổi các dữ liệu chẩn đoán khác nhau và một danh sách các thông số tiêu
chuẩn được có sẵn từ ECU. Các dữ liệu có sẵn được xác định bởi “Parameter
Identification Numbers - Mã số nhận dạng tham số” (số ID hoặc PIDs) được xác định
trong tiêu chuẩn SAE J1979. Đối với một danh sách PIDs cơ bản, các định nghĩa của
chúng, và cách thức để chuyển đổi tín hiệu đầu ra ban đầu của OBD-II thành đơn vị chẩn
đoán có ý nghĩa, chúng ta hãy xem OBD-II PIDs. Các nhà sản xuất không bắt buộc thực
hiện tất cả các PIDs được liệt kê ở tiêu chuẩn J1979 và họ được giữ độc quyền PIDs mà
không cần liệt kê. Hệ thống yêu cầu và truy xuất dữ liệu PIDs cho phép truy cập dữ liệu
trong thời gian thực cũng như các mã DTCs được lưu trữ. Để biết được các OBD-II
DTCs chung được đề xuất bởi SAE, hãy xem ở bảng OBD-II Codes.
2.3.5. Phương thức hoạt động
Dưới đây là thông tin giới thiệu cơ bản đến giao thức giao tiếp cơ bản của OBD-II
theo tiêu chuẩn ISO 15031:
13
Mode $01 để xác định các thông tin truyền động có sẵn đến dụng cụ quét.
Mode $02 hiển thị dữ liệu đóng băng.
Mode $03 liệt kê các mã lỗi “đã ghi nhận” được phát hiện và lưu trữ. Nó hiển thị
chính xác bằng số, các mã 4 số xác định các lỗi.
Mode $04 được sử dụng để xóa thông tin lỗi, bao gồm xóa các mã DTCs đang chờ
xử lý/đã xác nhận và dữ liệu đóng băng.
Mode $05 hiển thị lên màn hình giám sát cảm biến oxy và kiểm tra các kết quả
thu thập được về cảm biến oxy.
Mode $06 là một yêu cầu đối với các kết quả kiểm tra giám sát trên xe cho hệ
thống giám sát liên tục và không liên tục. Thông thường có một giá trị tối thiểu, một giá
trị tối đa và một giá trị hiện tại cho mỗi giám sát không liên tục.
Mode $07 là một yêu cầu về các mã chẩn đoán được phát hiện tại thời điểm hiện
tại hoặc chu kỳ lái xe cuối cùng hoàn thành. Nó cho phép thiết bị kiểm tra bên ngoài thu
được các mã chẩn đoán “đang chờ xử lý” đã được tìm ra. Điều này được sử dụng bởi các
kỹ thuật viên dịch vụ sau khi sửa chữa một chiếc xe, và sau khi xóa các thông tin chẩn
đoán để xem các kết quả kiểm tra sau một chu kỳ lái xe để xác định việc sửa chữa có
khắc phục được sự cố không.
Mode $08 có thể cho phép thiết bị kiểm tra bên ngoài xe để điều khiển hoạt động
của một hệ thống trên xe, kiểm tra, hoặc các thiết bị.
Mode $09 được sử dụng để lấy thông tin của xe. Trong số đó, các thông tin dưới
dây là có sẵn:
- VIN (Vehicle Identification Number): ID nhận dạng của xe.
- CALID (Calibration Identification): ID cho phần mềm đã cài đặt trên ECU.
- CVN (Calibration Verification Number): Số được sử dụng để xác định tình trạng
nguyên vẹn của phần mềm trên xe. Nhà sản xuất chịu trách nhiệm xác định phương pháp
tính các CVN, ví dụ sử dụng tổng kiểm tra.
- Theo dõi hiệu suất trong sử dụng:
+ Động cơ xăng: Bộ xử lý khí xả, cảm biến oxy chính, hệ thống bay hơi, hệ thống
EGR, hệ thống VVT, cảm biến không khí thứ cấp, cảm biến oxy thứ cấp.
14
+ Động cơ diesel: Bộ xử lý khí xả NMHC, Bộ xủ lý khử NOx, Bộ lọc hấp thụ các
hạt NOx, cảm biến khí thải, hệ thống EGR, hệ thống VVT, kiểm soát sự tăng áp suất, hệ
thống nhiên liệu.
Mode $0A liệt kê các mã chẩn đoán đã lưu trữ “vĩnh viễn”. Theo CARB, bất kỳ
mã chẩn đoán nào mà đang điều khiển trên MIL và được lưu trữ trong bộ nhớ ổn định sẽ
được ghi như một mã lỗi vĩnh viễn.
2.3.6. Ứng dụng của OBD-II
Có nhiều thiết bị có thể kết nối với đầu OBD-II trên xe để truy cập các chức năng
của OBD. Những thiết bị này bao gồm các thiết bị thông dụng đơn giản chi phí thấp đến
các thiết bị có công nghệ cao với chi phí cao.
2.3.6.1. Thiết bị chẩn đoán cầm tay
Hình 2.12 - Máy chẩn đoán cầm tay với kết nối OBD-II
Một loạt các thiết bị chẩn đoán phổ biến với tính năng mạnh mẽ như: Đọc/reset
mã lỗi; Truy cập chẩn đoán nâng cao; Đọc thông cố ECU của nhà sản xuất hoặc xe cụ
thể; Truy cập và điều khiển các hệ thống điều khiển, như túi khí hoặc ABS; Giám sát
hoặc truy xuất đồ thị theo thời gian thực các thông số động cơ để thuận tiện cho việc chẩn
đoán hoặc điều chỉnh.
2.3.6.2. Các thiết bị và phân tích trên điện thoại di động
Ứng dụng trên thiết bị di động cho phép các thiết bị như Smartphone, máy tính
bảng hiển thị và thao tác truy cập dữ liệu OBD-II thông qua cáp USB, Bluetooth hoặc
15
WiFi được cắm vào đầu nối OBD-II của xe. Một số thiết bị mới cho phép cổng OBD của
xe truyền dữ liệu trực tiếp tới Internet thông qua kết nối di động.
Hình 2.13 - Thiết bị chẩn đoán qua điện thoại Smartphone – iOBD-II
2.3.6.3. Các công cụ quét dựa trên máy tính và các nền tảng phân tích
Một thiết bị phân tích OBD có thể chuyển đổi các tính hiệu OBD-II thành chuỗi
dữ liệu nối tiếp (USB hoặc cổng nối tiếp) tiêu chuẩn đến máy tính. Phần mềm sẽ giải mã
dữ liệu nhận được và hiển thị lên màn hình trực quan.
Hình 2.14 - Một phần mềm chẩn đoán OBD qua máy tính - OBDAutoDoctor
Ngoài các chức năng của một thiết bị chẩn đoán cầm tay, các thiết bị trên máy tính
thường cung cấp:
- Khả năng lưu trữ dữ liệu lớn và các chức năng khác.
- Màn hình độ phân giải cao hơn các thiết bị cầm tay.
16
- Khả năng sử dụng được nhiều chương trình phần mềm một cách linh hoạt.
- Mức độ mà một máy tính có thể truy cập vào các chương trình chẩn đoán ECU
của nhà sản xuất hoặc một xe cụ thể là khác nhau giữa các sản phẩm phần mềm giống
như các thiết bị chẩn đoán cầm tay.
2.3.6.4. Thu thập dữ liệu
Thu thập dữ liệu được thiết kế để nắm bắt dữ liệu xe trong khi xe đang hoạt động
bình thường để phân tích sau này. Bộ thu thập dữ liệu bao gồm:
- Giám sát động cơ và xe trong quá trình hoạt động bình thường, nhằm mục đích
chẩn đoán hoặc điều chỉnh.
- Một số công ty bảo hiểm đề nghị giảm phí bảo hiểm nếu các bộ thu thập dữ liệu
và các máy quay phim được cài đặt trên xe OBD-II, và nếu các hành động của lái xe đáp
ứng các yêu cầu.
- Giám sát hành vi của lái xe bằng các đội điều khiển xe.
2.3.6.5. Kiểm tra khí thải
Tại Hoa Kỳ, nhiều tiểu bang hiện đang thực hiện kiểm tra OBD-II thay cho việc
kiểm tra đường ống xả đối với các xe đã tuân thủ OBD-II từ năm 1996. Từ khi OBD-II
lữu trữ các mã lỗi, thiết bị kiểm tra có thể truy cập hệ thống điều khiển trên xe, xác minh
rằng không có mã lỗi liên quan đến phát thải và chiếc xe tuân thủ các tiêu chuẩn khí thải
EOBD đối với quy định theo năm sản xuất.
Hình 2.15 - Thiết bị kiểm tra khí thải AutoLink AL529 tiêu chuẩn EOBD
17
Chương 3. CHẨN ĐOÁN – CHỨC NĂNG CỦA MÁY CHẨN ĐOÁN CƠ BẢN
3.1. Kỹ thuật Chẩn đoán ô tô
3.1.1. Định nghĩa
Kỹ thuật chẩn đoán ô tô là một loại hình tác động kỹ thuật vào quá trình khai thác
sử dụng ôtô nhằm đảm bảo cho ôtô hoạt động có độ tin cậy, an toàn hiệu quả cao bằng
cách phát hiện và dự báo kịp thời các hư hỏng và tình trạng kỹ thuật hiện tại mà không
cần phải tháo rời ôtô hay tổng thành máy của ô tô.
Kỹ thuật viên phải quan tâm hiểu rõ đến hai thông số sau: Thông số kết cấu là tập
hợp các thông số kỹ thuật thể hiện đặc điểm kết cấu của cụm chi tiết hay chi tiết. Chất
lượng các cụm, các chi tiết do các thông số kết cấu quyết định: Hình dáng, kích thước, vị
trí tương quan, độ bóng bề mặt, chất lượng lắp ghép… Thông số biểu hiện trạng thái của
kết cấu là các thông số biểu thị các quá trình lý hoá, phản ánh tình trạng kỹ thuật bên
trong của đối tượng khảo sát. Các thông số này con người hay thiết bị có thể nhận biết
được và chỉ xuất hiện khi đối tượng khảo sát hoạt động hay ngay sau khi vừa hoạt động.
Kỹ thuật chẩn đoán sẽ sử dụng Thông số biểu hiện trạng thái của kết cấu để đánh
giá gián tiếp Thông số kết cấu từ đó khẳng định sự hỏng hóc và đi đến quyết định tháo ở
đâu để thay thế và sửa chữa.
3.1.2. Mục đích của chẩn đoán
Trước khi xuất hiện các chẩn đoán xe hơi, việc xác định các vấn đề hư hỏng rất
tốn thời gian và chi phí. Vì thế, việc kỹ thuật chẩn đoán và các công cụ chẩn đoán trên ô
tô ra đời đã mang lại nhiều lợi ích như sau:
• Giúp xác định chính xác và nhanh chóng khu vực gây ra các vấn đề, hỏng hóc
mà không phải tốn công tháo từng bộ phận ra kiểm tra, tối ưu hóa thời gian và
chi phí sửa chữa.
• Một số bộ phận của ô tô được vi tính hóa để có thể phát hiện các vấn đề trước
khi chúng gây ra sự cố. Các đèn báo lỗi trên taplo sẽ sáng khi phát hiện sự cố.
• Các công cụ chẩn đoán cũng có thể kiểm tra hệ thống máy tính của ô tô để biết
thông báo của nhà sản xuất và thông tin được lưu trữ về lịch sử của xe, cung cấp
cho các kỹ thuật viên một bức tranh hoàn chỉnh để thực hiện sửa chữa tốt nhất
có thể.
18
Kỹ thuật chẩn đoán ô tô cũng là một công cụ hữu ích khi bạn kiểm tra một chiếc
xe đã qua sử dụng hay chưa trước khi bạn cam kết mua một chiếc xe mới từ các cửa hàng
tư nhân.
3.1.3. Công cụ chẩn đoán ô tô
Nhờ việc tin học hóa các bộ phận của ô tô, kỹ thuật viên có thêm công cụ hiện đại
nữa là phần mềm chuyên dụng và máy chẩn đoán sẽ nhanh chóng và chính xác để chỉ ra
các khu vực có vấn đề nhờ bộ xử lý, vi mạch và cảm biến tích hợp.
Hình 3.1. Chẩn đoán ô tô thông qua máy chẩn đoán

Tuy nhiên với bộ phận thuần cơ khí thì chúng sẽ bị hạn chế, nên kỹ thuật viên vẫn
phải sử dụng các trang bị dụng cụ kỹ thuật cơ bản, phương pháp và trình tự để tiến hành
đo đạc, phân tích và đánh giá tình trạng kỹ thuật.
Hình 3.2. Chẩn đoán ô tô theo phương pháp truyền thống
19
Đối với các dòng máy cao cấp hoặc đối với các thiết bị chẩn đoán chuyên hãng
còn có thêm các tính năng như reset, cài đặt, lập trình các hộp ECU. chúng có thể truy
cập vào mọi hệ thống điện, điện điều khiển trên xe để đọc được hết tất cả các thông số
điều khiển trên xe.
3.2. Các chức năng của máy chẩn đoán
3.2.1. Đọc mã lỗi
Khi đèn báo lỗi động cơ sáng lên tức là đã có một hư hỏng trong động cơ. Chúng
ta sẽ đọc mã lỗi trong OBD2 để biết xe đang bị lỗi gì, ví dụ:
P0100: Mạch Lưu Lượng Hay Khối Lượng Khí Nạp
Hình 3.3. Hiển thị mã lỗi trên máy chẩn đoán
3.2.2. Xóa mã lỗi
Sau khi sửa chữa xong mã lỗi, chúng ta sử dụng chức năng này để xóa mã lỗi và
làm tắt đèn báo lỗi. Nếu không xóa lỗi thì đèn báo lỗi sẽ tiếp tục sáng mặc dù lỗi đã sửa
xong.
Hình 3.4 - Chức năng xóa mã lỗi trên máy chẩn đoán
20
3.2.3. Dữ liệu động
Chúng ta có thể xem thông số trực tiếp từ xe để biết các hoạt động của các cảm
biến, van, bộ chấp hành như thế nào. Các thông tin này rất hữu ích trong quá trình chẩn
đoán và sửa chữa một hư hỏng trên xe.
Hình 3.5. Chức năng hiển thị dữ liệu động trên máy chẩn đoán
3.2.4. Trạng thái của trình giám sát
Trình giám sát là một chương trình tích hợp trong chế độ OBD2 nhằm giám sát
hoạt động của xe. Khi sửa chữa xong một mã lỗi, chúng ta xóa mã lỗi để làm tắt đèn báo
lỗi, điều này cũng reset trạng thái của trình giám sát. Lúc này điều cần làm là lái xe trên
đường để các trình giám sát hoạt động nhằm xác nhận kết quả sửa chữa. Nếu mã lỗi xuất
hiện trở lại có nghĩa là hư hỏng vẫn chưa giải quyết xong, nếu không có mã lỗi xuất hiện
có nghĩa là quá trình sửa chữa đã hoàn thành, xe đã sẵn sàng giao cho khách hàng.
Hình 3.6 - Hiển thị trạng thái của trình giám sát
21
3.2.5. Thông tin xe, hộp điều khiển
Cho biết thông tin về số VIN của xe và thông tin hộp điều khiển. VIN là số khung
xe, ngày nay thông tin VIN được nạp vào bộ điều khiển của xe luôn. Thông tin CALID
(Calibration Identification) và CVN (Calibration Verification Numbers) là version của bộ
điều khiển.
Hình 3.7 - Thông tin của xe và bộ điều khiển
22
Chương 4. LÝ THUYẾT VỀ MẠNG CAN
4.1. Nguyên nhân và lịch sử phát triển
4.1.1. Định nghĩa CAN Bus
Controller Area Network (CAN), là giao thức truyền thông nối tiếp hỗ trợ mạnh
cho những hệ thống điều khiển thời gian thực phân bố (Distributed Realtime Control
System) với độ ổn định, bảo mật và đặc biệt chống nhiễu cực kỳ tốt.
Ý tưởng của mạng CAN được nhóm kỹ sư tại GmbH Robert Bosch
(https://www.bosch.com/), Đức, nghiên cứu từ đầu thập niên 1980. Họ đã nghiên cứu
một công nghệ bus mới dùng trong xe ô tô mà có thể cho phép đưa thêm nhiều chức năng
vào nữa mà số lượng dây nối không quá lớn.
4.1.2. Nguyên nhân ra đời của CAN Bus
Chuẩn CAN ra đời với mục đích ban đầu là phục vụ cho ngành công nghiệp xe ô
tô. Trước khi sử dụng chuẩn CAN, việc kết nối giữa các bộ điều khiển (Controller) trên
xe hơi rất phức tạp và yêu cầu nhiều dây nối. Khi ngành công nghiệp xe ô tô phát triển,
các khối điều khiển điện tử với nhiều chức năng phức tạp (điều khiển thân xe, điều khiển
cửa, điều khiển động cơ, thu thập dữ liệu các cảm biến, định vị xe, ...) trong xe ngày càng
nhiều làm việc bố trí kết nối càng trở nên phức tạp, tốn kém và bảo trì khó khăn.
Hình 4.1. Minh họa kết nối các ECU trên ô tô khi chưa sử dụng CAN Bus
CAN ra đời đã giải quyết các vấn đề tồn tại. Các module chỉ cần 2 dây để kết nối
với nhau. Việc thêm hay bớt module trong bus CAN dễ dàng. Việc truyền dữ liệu có độ
tin cậy cao, tốc độ nhanh.
23
Hình 4.2 Minh họa kết nối các ECU trên ô tô sử dụng CAN Bus
4.1.3. Lịch sử về mạng CAN
Năm 1983, công ty Robert Bosch GmbH đã bắt đầu phát triển mạng CAN
Năm 1986, giao thức được chính thức công bố ở đại hội của hội Kĩ sư ô tô
(Society of Automotive Engineers - SAE) ở Detroit, Michigan, Mỹ.
Năm 1987, những chip điều khiển CAN (CAN controller chip) đầu tiên được Intel
và Phillips sản xuất và xuất hiện trên thị trường.
Năm 1991, Bosch đã xuất bản một số phiên bản kỹ thuật của mạng CAN và phiên
bản mới nhất là CAN 2.0.
Năm 1992, Thành lập nhóm các nhà sử dụng và sản xuất CAN quốc tế: Hội CAN
tự động hóa (CAN in Automation, CiA). Hội CiA xuất bản giao thức Lớp ứng dụng CAN
(CAN Application Layer, CAL). Những chiếc xe Mercedes-Benz đầu tiên được trang bị
CAN tiếp theo xuất hiện, Mercedes-Benz W140.
Năm 1993, Tổ chức Tiêu chuẩn hóa Quốc tế (ISO) đã phát hành tiêu chuẩn CAN
ISO 11898.
Năm 1994, CiA tổ chức Hội nghị CAN quốc tế lần thứ nhất. Allen-Bradley giới
thiệu giao thức DeviceNet. Hiệp hội Kỹ sư ô tô – SAE phát hành SAE J1939.
Từ năm 1994, một số giao thức cấp cao hơn đã được chuẩn hóa trên CAN, chẳng
hạn như CANopen và DeviceNet. Các thị trường khác đã áp dụng rộng rãi các giao thức
bổ sung này, hiện là tiêu chuẩn cho truyền thông công nghiệp.
24
Năm 2012, Bosch đã phát hành CAN FD 1.0 hoặc CAN với Tốc độ Dữ liệu linh
hoạt. Kỹ thuật này sử dụng một định dạng khung khác nhau cho phép một chiều dài dữ
liệu khác nhau cũng như các tùy chọn chuyển đổi để tốc độ bit nhanh hơn. CAN FD
tương thích với mạng CAN 2.0 hiện có để các thiết bị của chúng có thể cùng hoạt động
trên cùng một mạng với nhau.
CAN bus là một trong năm giao thức được sử dụng trong việc chẩn đoán trên xe
(OBD-II). Tiêu chuẩn OBD-II bắt buộc phải có đối với tất cả các xe ô tô và xe tải nhẹ
bán tại Hoa Kỳ từ năm 1996. Và sau này đã được áp dụng cho tất cả các xe trên thế giới.
4.2. Thuộc tính, ưu điểm và ứng dụng của CAN Bus
4.2.1. Thuộc tính và ưu điểm của CAN Bus
CAN Bus có cấu tạo đơn giản, chỉ có 2 dây kết nối các module điều khiển với
nhau dễ dàng hơn cách làm truyền thống, chi phí thấp, dễ lắp đặt và dễ sửa chữa, bảo trì
khi có sự cố.
CAN Bus là một giao thức chung để nhiều nhà cung cấp khác nhau có thể phát
triển các module điều khiển tương thích với nhau.
CAN Bus truyền thông điệp theo mức độ ưu tiên, đảm bảo hiệu quả cao theo thời
gian thực. Mỗi thông điệp được truyền đều có một mức ưu tiên. Khi nhiều thông điệp
được truyền ra từ một nút (Node) hay trạm (Station) trên mạng CAN cùng lúc thì thông
điệp có mức ưu tiên cao nhất sẽ được truyền. Các thông điệp có mức ưu tiên thấp hơn sẽ
tạm dừng và được truyền lại khi cổng CAN rảnh. Việc xác định mức ưu tiên dựa trên cấu
trúc thông điệp và cơ chế phân xử quy định trong chuẩn CAN.
CAN Bus cho phép người dùng thiết lập các thông số kỹ thuật của thông điệp một
cách linh hoạt: cấu hình thời gian bit, đồng bộ, độ dài dữ liệu truyền - nhận,…
CAN Bus cho phép nhận dữ liệu đa điểm với sự đồng bộ thời gian. Một thông điệp
có thể được nhận bởi nhiều node khác nhau trên mạng cùng lúc. Tất cả các node trên
mạng đều có thể thấy thông điệp đang truyền, tùy vào cấu hình ở mỗi node mà node sẽ
quyết định có chấp nhận thông điệp này hay không.
CAN Bus cho phép nhiều bộ điều khiển (Multimaster) cùng kết nối đồng thời vào
mạng và nhận thông điệp từ các bộ phận đầu vào (Slaver) như cảm biến tốc độ, cảm biến
nhiệt độ,…
25
CAN Bus có khả năng phát hiện và báo hiệu lỗi. Mỗi thông điệp có kèm theo mã
CRC (Cyclic Redundancy Code) để kiểm tra lỗi. Nếu lỗi xuất hiện, Node nhận sẽ bỏ qua
thông điệp và truyền khung báo lỗi (Error frame) lên mạng CAN. Mỗi Node có thể tự xác
định trạng thái lỗi và ngắt khỏi mạng nếu lỗi xuất hiện quá nhiều.
CAN Bus tự động truyền lại các thông điệp bị lỗi khi mạng rảnh giúp đảm bảo
tính toàn vẹn dữ liệu trên mạng CAN. Một thông điệp được truyền ra mang nếu bị lỗi thì
Node truyền thông điệp này sẽ giữ lại và tự động phát lại thông điệp này khi cổng CAN
rảnh cho đến khi thành công.
Tốc độ bit của CAN có thể khác nhau trong các hệ thống khác nhau nhưng trong
một hệ thống cho trước thì tốc độ bit đồng nhất và cố định. Tốc độ bit còn tùy thuộc vào
chiều dài đường truyền. Tốc độ tối đa có thể lên đến 1 Mbit/s. Đảm bảo cho mức độ phản
hồi nhanh chóng của mạng CAN trong phạm vi nhỏ.
Bus Length Bit rate Bit time
25 meters 1000 kbit/s 1 µs
50 meters 800 kbit/s 1.25 µs
Bảng 4.1. Liên hệ giữa tốc độ truyền dữ liệu và chiều dài mạng
4.2.2. Phạm vi ứng dụng của CAN Bus
Hiện nay CAN được ứng dụng trong rất nhều lĩnh vực khác nhau như: Xe ô tô, tàu
khách và tàu hàng, hệ thống điện tử hàng hải, điện tử hàng không, tự động hóa nhà máy,
điều khiển máy công nghiệp, tự động hóa tòa nhà, thang máy (thang nâng và thang trượt),
thiết bị phụ tùng y tế,….với tốc độ bit có thể lên đến 1 Mbit/s.
26
Hình 4.3. Mạng lưới đường truyền tín hiệu trên ô tô
4.3. Cấu trúc của CAN Bus
4.3.1. Cấu trúc phân lớp của giao thức CAN
Giao thức CAN, giống như nhiều giao thức mạng khác, có thể được phân tách
thành các lớp tượng trưng sau đây: Ứng dụng (Application Layer), Đối tượng (Object
Layer), Truyền tải (Transfer Layer) và Vật lý (Physical Layer).
Hình 4.4a. Cấu trúc phân lớp của mạng CAN theo mô hình OSI
27
Hình 4.4b. Cấu trúc phân lớp của mạng CAN theo mô hình OSI
4.3.2. Các thành phần cơ bản của mạng CAN
CAN là một chuỗi mạng đa chủ thế để kết nối các thiết điều khiển điện tử (ECU)
đến các bộ chấp hành và các cảm biến đầu vào, còn được gọi là các nút mạng (Nodes).
Các nút mạng này có thể giao tiếp với nhau. Tất cả các nút mạng được kết nối với nhau
thông qua hai dây là CANH (CAN High) và CANL (CAN Low). Hai dây này là một cặp
xoắn trong quá trình truyển tải. Ở đầu cuối là một điện trở 120 Ω nối giữa hai dây.
Hình 4.5. Các thành phần cơ bản của mạng CAN

4.3.3. Trạng thái tín hiệu và các chuẩn truyền trên mạng CAN
4.3.3.1. Trạng thái tín hiệu trên mạng CAN
Trang thái tín hiệu truyền tải trên mạng CAN có 2 dạng:
• Trạng thái "Dominant - Trội" mã hóa bit dữ liệu 0 (CANH > CANL).
28
• Trạng thái "Recessive - Lặn" mã hóa bit dữ liệu 1 (CANH ≤ CANL).
4.3.3.2. Các chuẩn truyền phổ biến trên mạng CAN
Tiêu chuẩn ISO 11898-2, còn được gọi là CAN tốc độ cao (tốc độ 1Mbit/s trên
CAN, 5Mbit/s trên CAN-FD), sử dụng một cổng tuyến tính và kết thúc với điện trở
120Ω.
Hình 4.6. Minh họa mạng CAN tốc độ cao ISO 11898-2
Tín hiệu CAN tốc độ cao điều khiển dây CANH về phía 5V và dây CANL về 0V
khi truyền trạng thái trội (0) với mức điện áp chênh lệch có giá trị danh định là 2V; trong
khi đó nếu không có thiết bị nào truyền tín hiệu, thì các điện trở đầu cuối sẽ trả lại dây
dẫn trạng thái lặn (1) có điện áp chênh lệch danh nghĩa là 0V (hoặc nhỏ hơn 0,5V).
Hình 4.7. Tín hiệu CAN tốc độ cao ISO 11898-2

Tiêu chuẩn ISO 11898-3, được gọi là CAN có tốc độ thấp hoặc CAN chịu lỗi, sử
dụng mạng tuyến tính, mạng sao hoặc mạng nhiều sao kết nối với mạng tuyến tính và
được kết thúc tại mỗi nút mạng bằng một phần nhỏ của điện trở đầu cuối tổng thể. Điện
trở đầu cuối tổng thể có giá trị lớn hơn hoặc gần bằng 100 Ω.
29
Hình 4.8. Minh họa mạng CAN tốc độ thấp ISO 11898-3
Tín hiệu CAN tốc độ thấp hoạt động tương tự như CAN tốc độ cao, nhưng có điện
áp lớn hơn. Trạng thái trội (0) được truyền bằng cách điều khiển CANH về phía điện áp
nguồn của thiết bị (5V hoặc 3,3V) và CANL về 0V, trong khi các điện trở đầu cuối sẽ
làm giảm điện áp ở trạng thái lặn trong mạng với CANH về 0V và CANL về 5V. Điều
này cho phép thiết bị nhận đơn giản hơn khi chỉ việc xem xét tín hiệu của CANH −
CANL.
Hình 4.9. Tín hiệu CAN tốc độ thấp ISO 11898-3

4.4. Các loại khung truyền của giao thức CAN
Có bốn loại khung cơ bản trong tin nhắn (Frame) truyền trên CAN Bus là:
- Khung dữ liệu (Data Frame): chứa dữ liệu từ một nút để truyền.
- Khung yêu cầu (Remote Frame): yêu cầu dữ liệu truyền từ một nút cụ thể.
30
- Khung lỗi (Error Frame): khung được truyền bởi bất kỳ nút nào phát hiện lỗi.
- Khung quá tải (Overload Frame): tạo độ trễ giữa các khung truyền.
4.4.1. Khung dữ liệu (Data Frame)
Khung dữ liệu là khung duy nhất để truyền dữ liệu. Mạng CAN hỗ trợ hai đinh
dạng khung khác nhau: Định dạng khung tiêu chuẩn - Standard Frame Format (được sử
dụng trong cả CAN 2.0A và 2.0B) và Định dạng khung mở rộng - Extended Frame
Format (chỉ sử dụng trong CAN 2.0B). Sự khác biệt quan trọng của hai dạng khung là
phần định danh - Identifier. Phần định danh của khung tiêu chuẩn có 11 bit và khung mở
rộng là 29 bit.
Hình 4.10. Định dạng khung tiêu chuẩn
Hình 4.11. Định dạng của khung mở rộng

Khung dữ liệu của CAN 2.0A và CAN 2.0B có trình tự truyền tin nhắn tương tự
nhau. Cấu trúc khung dữ liệu gồm các vùng: Vùng khởi đầu (Start of frame - SOF), Vùng
phân xử (Arbitration field), Vùng điều khiển (Control field), Vùng dữ liệu (Data field),
Vùng kiểm tra (CRC field), Vùng báo nhận (ACK field), Vùng kết thúc khung (End of
frame – EOF).
31
4.4.1.1. Vùng khởi đầu (Start Of Frame)
Khi cổng CAN thể hiện trạng thái Lặn - Recessive thì hệ thống CAN ở chế độ chờ.
Khi ở trạng thái Trội - Dominant thì hệ thống bắt đầu quá trình truyền tin, nhồi bit (bit
stuffing) và đồng bộ hóa tất cả các nút. CAN 2.0A và CAN 2.0B có vùng khởi đầu giống
nhau.
4.4.1.2. Vùng phân xử (Arbitration Field)
Định dạng vùng phân xử là khác nhau đối với dạng khung chuẩn và dạng khung
mở rộng.
Đối với khung tiêu chuẩn, vùng phân xử gồm có 12 bit:
• 11 bit Định danh chuẩn.
• 1 bit Yêu cầu truyền từ xa (RTR - Remote Transmission Request).

Đối với khung mở rộng, vùng phân xử gồm có 32 bit:
• 11 bit Định danh chuẩn.
• 1 bit Yêu cầu thay thế từ xa (SRR - Substitute Remote Request).
• 1 bit Mở rộng mã định danh (IDE – Identifier Extension Bit).
• 18 bit Định danh mở rộng.
• 1 bit Yêu cầu truyền từ xa (RTR - Remote Transmission Request).

Bit RTR (Remote Transmission Request) là bit dùng để phân biệt Data Frame và
Remove Frame. Bit này luôn bằng 0 (bit Dominant) đối với Data Frame và bằng 1 (bit
Recessive) đối với Remove Frame, luôn ngay sau ID của khung.
Bit SRR (Substitute Remote Request) chỉ có ở Khung mở rộng. Đây là bit
Recessive (1). So sánh với Khung chuẩn, vị trí của bit này trùng với vị trí của bit RTR
nên có tên gọi là bit thay thế (Subsitute) cho bit RTR ở khung chuẩn. Giả sử có hai Node
cùng truyền, một Node truyền khung dữ liệu chuẩn, một Node truyền khung dữ liệu mở
rộng có ID giống nhau thì Node truyền khung chuẩn sẽ thắng phân xử vì đến vị trí sau
Base ID, ở Khung chuẩn là bit RTR = 0, còn Khung mở rộng là bit SRR = 1. Như vậy,
khung chuẩn chiếm ưu thế hơn so với khung mở rộng khi có Base ID như nhau.
Bit IDE (IDentifier Extension) là bit phân biệt giữa loại Base Frame và Extended
Frame. Bit IDE = 0 (Dominant) thì là Base Frame, IDE = 1 (Recessive) thì là Extended
32
Frame. Bit này thuộc: Vùng phân xử với Extended Frame và Vùng điều khiển với Base
Frame.
Hình 4.12. Các phân lớp bit của vùng phân xử

4.4.1.3. Vùng điều khiển (Arbitration Field)
Vùng điều khiển có 6 bit, có cấu trúc khác nhau giữa Base Frame (CAN 2.0A) và
Extended Frame (CAN 2.0B). Base Frame gồm IDE, r0 (Reserved Bit) và DLC .
Extended Frame gồm r1, r0 và DLC.
Hình 4.13. Giá trị của các bit DLC

Bit r1 và r0 là hai bit dự trữ. Tuy hai bit này phải được truyền là bit Recessive (1)
nhưng bộ nhận không quan tâm đến giá trị 2 bit này. Bộ nhận không coi đó là lỗi mà bỏ
qua và nhận thông điệp bình thường.
Mã độ dài dữ liệu DLC (Data Length Code) có độ dài 4 bit quy định số byte Data
Field của Data Frame. Chỉ được mang giá trị từ 0 đến 8 tương ứng Data Field có từ 0
đến 8 byte dữ liệu. Như vậy, Data Frame có thể không có byte dữ liệu nào khi DLC = 0.
33
4.4.1.4. Vùng dữ liệu (Data Field)
Vùng dữ liệu chứa các dữ liệu chính của tin nhắn (0-8 byte) với độ dài dữ liệu
được thể hiện ở vùng DLC. Một khung dữ liệu có thể được dùng để đồng bộ hóa các dữ
liệu riêng lẻ, bằng một tin nhắn riêng biệt, ví dụ: nhiệt độ, tốc độ động cơ,…
Hình 4.14. Độ dài tối thiểu và tối đa của vùng dữ liệu

4.4.1.5. Vùng kiểm tra (CRC – Cyclic Redundanct Check)
Vùng kiểm tra gồm 16 bit và được chia làm hai phần là chuỗi CRC (CRC
Sequence) và phần phân cách CRC (CRC Delimiter) để phân cách vùng CRC và vùng
ACK. CRC Sequence gồm 15bit CRC tuần tự. Mọi tính toán cho CRC Sequence là phép
chia đa thức (hay chia bằng các bit nhi phân) và đều dùng Modulo-2 (phép toán tìm số
dư của phép chia cho 2).
Hình 4.15. Các phần của vùng CRC

Mã kiểm tra CRC phù hợp nhất cho các khung mà chuỗi bit có chiều dài dưới 127
bit, mã này thích hợp cho việc phát hiện các trường hợp sai nhóm (Burst Error). Ở đây,
tổng bit từ vùng SOF đến vùng dữ liệu tối đa là 83 bit (Base Frame) và 103 bit (Extended
Frame). Bộ nhận cũng sẽ tính toán CRC như bộ truyền khi đã nhận dữ liệu và so sánh kết
quả đó với CRC Sequence mà nó đã nhận được, nếu khác nhau tức là đã có lỗi, nếu giống
nhau tức là đã nhận đúng từ vùng SOF đến vùng dữ liệu.
34
CRC Delimiter theo ngay sau CRC Sequence, nó là một bit Recessive làm nhiệm
vụ phân cách vùng CRC với vùng ACK.
4.4.1.6. Vùng báo nhận (ACK – Acknowledge)
Vùng báo nhận có độ dài 2 bit và bao gồm hai phần là khe ACK (ACK Slot) và
phần phân cách ACK (ACK delimiter).
Hình 4.16. Các phần của vùng ACK

ACK slot có độ dài 1 bit, một Node truyền dữ liệu sẽ thiết lập bit này là Recessive.
Khi một hoặc nhiều Node nhận chính xác giá trị tin nhắn (không lỗi và so sánh CRC
Sequence trùng khớp) thì nó sẽ báo lại cho bộ truyền bằng cách truyền ra một bit
Dominant ngay vị trí ACK Slot để ghi đè lên bit Recessive của bộ truyền.
ACK delimiter có độ dài 1 bit, nó luôn là một bit Recessive. Như vậy, ta thấy rằng
ACK Slot luôn được đặt giữa hai bit Recessive là CRC Delimiter và ACK Delimiter.
4.4.1.7. Vùng kết thúc (EOF – End of Frame)
Vùng kết thúc là vùng thông báo kết thúc một khung dữ liệu hay khung yêu cầu.
Vùng này gồm 7 bit Recessive (1).
4.4.2. Khung yêu cầu (Remote Frame)
Một Node hoạt động như một bộ nhận đang cần một dữ liệu, thì Node sẽ gửi một
Remote Frame đến một Node nguồn để nhận dữ liệu này. Remote Frame có tác dụng
thông báo cho Node nguồn biết để Node này truyền dữ liệu.
Một khung yêu cầu có thể là định dạng chuẩn hay định dạng mở rộng. Dù thuộc
định dạng nào thì khung yêu cầu cũng gồm sáu vùng bit khác nhau là: Vùng bắt đầu
35
khung (Start Of Frame), Vùng phân xử (Arbitration Field), Vùng điều khiển (Control
Field), Vùng kiểm tra (CRC Field), Vùng ACK (ACK Field), Vùng kết thúc khung (End
Of Frame).
Hình 4.17. Khung yêu cầu dạng chuẩn

Cấu tạo và ý nghĩa các vùng trong Remote Frame giống như ở Data Frame ngoại
trừ một số điểm. Thứ nhất, Remote Frame không có vùng dữ liệu (Data Field) nên không
phụ thuộc vào giá trị của DLC, DLC có thể nhận bất kỳ giá trị nào từ 0 đến 8. Nhưng giá
trị DLC của Remote Frame lại chỉ ra độ dài dữ liệu trong Data Frame tương ứng sẽ trả
về, tức DLC của khung dữ liệu trả về giống DLC của khung yêu cầu đã gửi. Và khung dữ
liệu trả về có số byte bằng với giá trị DLC này. Thứ hai, Bit RTR (thuộc Vùng phân xử)
của Khung yêu cầu là bit Recessive (1). Nó khác với khung dữ liệu vì ở Khung dữ liệu nó
là một bit Dominant (0).
4.4.3. Khung báo lỗi (Error Frame)
Hình 4.18. Các phần của khung báo lỗi

Khung báo lỗi (Error frame) được truyền trên mạng CAN bởi các Node phát hiện
thấy điều kiện lỗi. Khung báo lỗi gồm hai vùng khác nhau: Vùng chồng lấn của các cờ
báo lỗi (Superposition of Error Flags) và Vùng phân cách khung báo lỗi (Error
Delimiter).
36
4.4.3.1. Cờ lỗi (Error Flag)
Cờ lỗi có 2 dạng là cờ lỗi chủ động (Active Error Flag) và cờ lỗi bị động (Passive
Error Flag). Cờ lỗi chủ động có 6 bit Dominant liên tiếp. Cờ lỗi bị động có 6 bit
Recessive liên tiếp.
Hình 4.19. Cờ lỗi chủ động và bị động

Một Node đang trong trạng thái chủ động với lỗi (Error Active Station) sẽ truyền
cờ lỗi chủ động khi phát hiện một điều kiện lỗi. Dạng cờ lỗi chủ động sẽ vi phạm luật
chèn bit (bit stuffing) được quy định bởi chuẩn này. Luật này áp dụng từ vùng SOF đến
hết vùng CRC của khung dữ liệu và khung yêu cầu. Đồng thời, dạng cờ lỗi chủ động
cũng không giống bất kỳ định dạng nào của vùng ACK hay EOF.
Tất cả các Node phát hiện điều kiện lỗi đều phải truyền cờ báo lỗi. Vì có thể có
nhiều Node cùng phát hiện lỗi và truyền cờ lỗi nên các cờ lỗi được phát ra cổng CAN sẽ
chồng lên nhau tạo thành vùng chồng chập. Với cờ lỗi chủ động, vùng chồng chập này sẽ
tạo ra một chuỗi bit dominant (0), tối thiểu là 6 bit và tối đa là 12 bit.
Một Node đang trong trạng thái bị động với lỗi (Passive Error Station) sẽ cố gắng
báo hiệu bằng một cờ lỗi bị động khi nó phát hiện điều kiện lỗi. Cờ lỗi bị động có thể bị
ghi đè bởi cờ lỗi chủ động được phát từ các Node ở trạng thái chủ động với lỗi. Vì vậy,
Node truyền cờ lỗi bị động sẽ chờ cho đến khi phát hiện được 6 bit liên tiếp cùng trạng
thái từ lúc bắt đầu phát cờ lỗi bị động của nó. Việc truyền cờ lỗi bị động được xem là
hoàn thành khi 6 bit bằng nhau liên tiếp đã được phát hiện.
4.4.3.2. Vùng phân cách khung báo lỗi (Error Delimiter)
Vùng phân cách khung báo lỗi gồm 8 bit Recessive (1) liên tiếp. Sau khi truyền
xong cờ lỗi, các Node bắt đầu phát các bit recessive và giám sát cho đến khi nhận được
một bit recessive thì bit này là bit đầu tiên của vùng phân cách khung báo lỗi. Lúc này,
các Node tiếp tục phát thêm 7 bit recessive nữa để hoàn thành vùng này.
37
4.4.4. Khung báo quá tải (Overload frame)
4.4.4.1. Vai trò và cấu trúc khung
Khung báo quá tải được các Node trong mạng CAN sử dụng để tạo thêm độ trễ
giữa các khung dữ liệu và khung điều khiển. Một Node có thể phát nhiều khung báo quá
tải liên tiếp nhau để tạo ra độ trễ bus phù hợp.
Khung báo quá tải gồm hai vùng: Vùng chồng lấn các cờ báo quá tải
(Superposition of Overload flags) là vùng các Node trên bus cùng phát cờ báo quá tải
(Overload Flag) gồm 6 bit dominant; Vùng phân cách khung báo quá tải (Overload
Delimiter) gồm 8 bit recessive.
Hình 4.20. Các phần của khung quá tải

4.4.4.2. Vị trí phát khung
Khi gặp điều kiện quá tải thì một Node sẽ phát khung báo quá tải ở các vị trí sau:
Ngay sau EOF của một khung dữ liệu hoặc khung yêu cầu. Nếu trên bus đang truyền
khung dữ liệu hoặc khung yêu cầu, một Node phải nhận thông điệp và chờ đến hết vùng
EOF mới được phép phát khung báo quá tải; Ngay sau vùng phân cách (Delimiter) của
một khung báo lỗi hoặc một khung báo quá tải khác.
4.4.4.3. Điều kiện báo quá tải
Một Node có thể phát khung báo quá tải khi gặp một trong các điều kiện sau:
Điều kiện 1: Do điều kiện hoạt động nội bộ của bộ nhận, một bộ nhận không xử lý
kịp các thông điệp được gửi đến có thể phát khung báo quá tải để tạm dừng truyền tiếp
các khung dữ liệu và khung yêu cầu.
Điều kiện 2: Phát hiện bit dominant (0) tại vị trí bit thứ nhất và bit thứ hai của
vùng INTERMISSION trong khoảng liên khung.
38
Điều kiện 3: Nếu một Node phát hiện một bit dominant(0) ở vị trí bit thứ 8 (bit
cuối cùng) của ở vùng DELIMITER của khung báo lỗi hay khung báo quá tải, nó sẽ
truyền ngay một khung báo quá tải.
4.5. Khoảng liên khung
4.5.1. Vai trò và cấu trúc
Khoảng liên khung dùng để phân tách giữa các khung dữ liệu và khung yêu cầu
với khung vừa phát trước đó. Khung trước đó có thể là khung dữ liệu, khung yêu cầu,
khung báo lỗi hoặc khung báo quá tải. Khoảng liên khung không bao giờ đặt ngay trước
các khung báo lỗi và khung báo quá tải.
Nhiều khung báo quá tải liên tiếp nhau thì sẽ truyền liên tục, không bị phân tách
bởi khoảng liên khung. Có hai cấu trúc khoảng liên khung như sau:
Đối với Node không trong trạng thái lỗi bị động (Passive Error) hoặc Node là bộ
nhận và vừa mới nhận xong một thông điệp trước đó thì khoảng liên khung gồm vùng
INTERMISSION và BUS IDLE.
Hình 4.21. Cấu trúc 1 của khoảng liên khung

Đối với Node trong trạng thái lỗi bị động (Passive Error) và vừa mới truyền xong
một thông điệp ngay trước đó thì khoảng liên khung gồm vùng INTERMISSION, vùng
SUSPEND TRANSMISSION và vùng BUS IDLE.
Hình 4.22. Cấu trúc 2 của khoảng liên khung
39
4.5.2 Cấu tạo các vùng
Vùng INTERMISSION là vùng ngưng truyền chứa 3 bit recessive liên tiếp. Trong
vùng này, không Node nào được phép bắt đầu truyền khung dữ liệu hoặc khung điều
khiển. Chỉ một hoạt động được phép thực hiện là báo hiệu quá tải bằng cách truyền
khung quá tải. Việc xuất hiện bit dominant ở vị trí bit thứ 1 hoặc thứ 2 của vùng
INTERMISSION sẽ được xem như sự xuất hiện của khung báo quá tải. Đối với bit thứ 3
của vùng INTERMISSION, nếu bit dominant xuất hiện thì đó xem như là SOF của khung
dữ liệu hoặc khung yêu cầu.
Vùng bus rảnh (BUS IDLE) là vùng có độ dài không xác định. Lúc này, bất kỳ
Node nào có thông điệp cần truyền đều có thể phát bắt đầu với SOF.
Vùng cấm truyền (SUSPEND TRANSMISSION) là vùng gồm 8 bit recessive được
thêm vào dành cho Node ở trạng thái bị động và vừa truyền xong một thông điệp. Sau
thông điệp vừa truyền, Node này phải truyền 3 bit recessive của vùng INTERMISSION,
tiếp theo phải truyền 8 bit recessive trước khi bắt đầu truyền một thông điệp khác hoặc
ghi nhận trạng thái bus rảnh (Bus Idle).
Có thể thấy một Node đang ở trong trạng thái lỗi bị động sau khi truyền xong một
thông điệp sẽ phải chịu một khoảng cấm truyền và trở nên kém ưu tiên hơn các Node
khác trong mạng CAN.
4.6. Quy luật nhồi bit (Bit Stuffing)
Hình 4.23. Phương pháp nhồi bit

Phương pháp mã hóa NRZ là tín hiệu không có giới hạn trong sự tái đồng bộ. Vì
vậy, phương pháp nhồi bit được dùng để đảm bảo sự đồng bộ tất cả các nút trên Bus.
40
Nhồi bit quy ước rằng mỗi khung dữ liệu hoặc khung yêu cầu từ xa có tối đa 5 bit liên
tiếp có trạng thái giống nhau tin nhắn. Khi năm bit có trạng thái giống nhau được truyền
kế tiếp thì thiết bị gửi sẽ kèm theo một bit có trạng thái ngược lại. Thiết bị nhận sẽ xóa
những bit được chèn sau khi nhận. Phương pháp này cho phép phát hiện các lỗi như:
ngắn mạch, nhiễu sóng,… giúp cho bộ nhận không nhầm lẫn khi đọc dữ liệu.
Phương pháp nhồi bit được áp dụng cho khung dữ liệu hoặc khung yêu cầu từ xa
trong vùng bắt đầu (SOF), vùng phân xử (Arbitration fields), vùng điều khiển (Control
fields), vùng dữ liệu (Data fields), vùng kiểm tra vòng lặp thường (CRC fields).
41
Chương 5. XÂY DỰNG MÔ HÌNH MÁY CHẨN ĐOÁN CƠ BẢN
5.1. Thông tin phần cứng
5.1.1. Arduino Nano ATmega328p
Arduino Uno là một board mạch vi điều khiển được phát triển bởi Arduino.cc,
một nền tảng điện tử mã nguồn mở chủ yếu dựa trên vi điều khiển AVR Atmega328P.
Với Arduino chúng ta có thể xây dựng các ứng dụng điện tử tương tác với nhau thông
qua phần mềm và phần cứng hỗ trợ.
Như các Arduino khác, Arduino Nano cũng hỗ trợ các chuẩn giao tiếp SPI, I2C,
UART,… Hỗ trợ phần lớn cho việc kết nối các module khác trong quá trình xây dựng
và phát triển mô hình trực quan.
Hình 5.1. Module Arduino Nano
Hình 5.2. Các chân trên Module Arduino Nano
42
Trong quá trình thử nghiệm và lập trình trên Arduino Uno thì yêu cầu đề tài cần
thu gọn kích thước phần cứng để phù hợp với một máy chẩn đoán nên Arduino Nano là
lựa chọn phù hợp vì các chức năng và thông số cơ bản gần như giống hoàn toàn với
Arduino Uno nhưng kích thước nhỏ gọn, tiện dụng.
Vi điều khiển ATmega328 (họ 8bit)

Điện áp hoạt động 5V – DC
Tần số hoạt động 16 MHz
Dòng tiêu thụ 30mA
Điện áp vào khuyên dùng 7-12V – DC
Điện áp vào giới hạn 6-20V – DC
Số chân Digital I/O 14 (6 chân PWM)
Số chân Analog 8 (độ phân giải 10bit)
Dòng tối đa trên mỗi chân I/O 40 mA
Dòng ra tối đa (5V) 500 mA
Dòng ra tối đa (3.3V) 50 mA
Bộ nhớ flash 32 KB với 2KB bootloader
SRAM 2 KB (ATmega328)
EEPROM 1 KB (ATmega328)
Kích thước 1.85cm x 4.3cm
Bảng 5.1. Các thông số cơ bản của Arduino Nano
5.1.2. Module CAN Bus MCP2515
Hình 5.3. Module CAN Bus MCP2515
43
Hình 5.4. Các chân chức năng và Chip xử lí của module MCP2515
Module CAN Bus MCP2515 dùng chip CAN Controller MCP2515 và CAN
Transceiver TJA1040 là module mở rộng ngoại vi CAN cho vi điều khiển không
tích hợp chuẩn giao tiếp hiện đại này. MCP2515 sử dụng giao tiếp SPI nên bất kỳ
một loại vi điều khiển nào cũng có thể giao tiếp với nó thông qua ngoại vi SPI có
sẵn hoặc thậm chí là dùng các chân IO thông thường.
Vi điều khiển MCP2515

Chip chuyển đổi CAN TJA1040
Điện áp hoạt động 2.7V – 5.5V DC
Tần số hoạt động 8 MHz
Dòng làm việc 5mA
Giao thức CAN hỗ trợ V2.0B
Chuẩn giao tiếp SPI
Tốc độ truyền dữ liệu 1 Mbps
Vùng dữ liệu 8 Byte
Kích thước 2.8cm x 4.4cm
Bảng 5.2. Các thông số cơ bản của Module MCP2515
44
5.1.3. Màn hình LCD TFT 2.4 inch
Hình 5.5. Màn hình LCD TFT 2.4 inch

Màn hình cảm ứng Arduino TFT Shield 2.4 inch là màn hình cảm ứng điện trở
được thiết kế dạng shield để có thể gắn trực tiếp lên Arduino Uno, Mega2560 một cách
dễ dàng thực hiện chức năng hiển thị và điều khiển qua cảm ứng điện trở trên màn hình,
màn hình có kích thước nhỏ gọn, tiện lắp đặt, bộ thư viện và code mẫu đi kèm màn hình
đầy đủ, dễ lập trình, màn hình có chất lượng hiển thị tốt, cảm ứng có độ nhạy cao, phù
hợp cho các ứng dụng hiển thị và điều khiển qua màn hình cảm ứng chuyên nghiệp.
Vi điều khiển ILI9341

Chip chuyển đổi CAN TJA1040
Điện áp hoạt động 3.3V – 5.5V DC
Độ phân giải 240x320 px
Màu sắc 18 bit, lên đến 262,000 màu
Đèn nền LED trắng
Chuẩn giao tiếp SPI
Loại cảm ứng Điện trở
Kích thước 71 x 52 x 7 mm
Bảng 5.3. Các thông số cơ bản của Module MCP2515
45
5.1.4. Module hạ áp LM2596
Hình 5.6. Module giảm áp

Do thiết bị chẩn đoán hoạt động dựa trên nguồn điện trực tiếp từ xe nhận qua cổng
OBD-II là 12V, vượt quá điện áp hoạt động của các module điện tử trên được kết nối nên
yêu cầu cần giảm điện áp về mức 5V để đảm bảo thiết bị chẩn đoán hoạt động tốt nhất,
hạn chế hư hỏng trong quá trình sử dụng và nâng cao tuổi thọ thiết bị.
Vi điều khiển LM2596S DC-DC

Điện áp vào 3.2V~40V
Điện áp ra 1.25V~35V
Dòng ra 3A
Hiệu suất chuyển đổi 92%
Tần số xung 65 kHz
Nhiệt độ hoạt động -45℃ ~ +85℃
Loại cảm ứng Điện trở

Kích thước 71 x 52 x 7 mm
Bảng 5.4. Các thông số cơ bản của Module hạ áp LM2596
5.1.5. Dây cáp DB9 - OBD-II
Dây cáp này một đầu là giắc cái 9 chân DB9 nối tiếp RS232 kết nối với giắc DB9
của CAN Bus Shield, đầu còn lại là giắc đực OBD-II 16 chân theo tiêu chuẩn SAE J1962
kết nối với đầu kết nối OBD-II trên xe.
46
Hình 5.7. Dây cáp DB9 – OBD-II
Hình 5.8. Kết nối giữa 2 đầu cáp DB9 – OBD-II

5.2. Phần mềm
5.2.1. Phần mềm lập trình – Arduino IDE
Arduino IDE được viết tắt (Arduino Integrated Development Environment) là một
trình soạn thảo văn bản, giúp bạn viết code để nạp vào bo mạch Arduino.
47
Hình 5.9. Giao diện của Arduino IDE
Để sử dụng được Arduino IDE, ta tiến hành cài đặt Java Runtime Environment
(JRE) vì ngôn ngữ lập trình của Arduino được viết theo ngôn ngữ lập trình JAVA, sau đó
tải về và cài đặt Arduino IDE. Và để máy tính giao tiếp với Board Arduino Uno R3 thì ta
cài thêm Driver tương thích. Quá trình và các bước cài đặt phần mền được trình bày chi
tiết trên trang web Arduino.vn.
Đường link tải: http://arduino.vn/bai-viet/68-cai-dat-driver-va-arduino-ide
5.2.2. Cài đặt thư viện trên Arduino IDE
5.2.2.1. Thư viện cho CAN Bus Shield – MCP2515
Để CAN Bus Shield hoạt động, chúng ta cần cài đặt thư viện thích hợp và giúp
cho CAN Bus Shield giao tiếp với cổng OBD-II trên xe. Thư viện chứa các lệnh chuyên
dụng được thiết lập sẳn để CAN Bus Shield hoạt động đúng theo tiêu chuẩn. Ta tải thư
viện CAN Bus Shield từ GitHub.com – một trang chuyên về các phần mềm lập trình và
thư viện hoạt động. Sau khi thay thế bằng Module CAN Bus MCP2515 để phù hợp kích
thước của thiết bị chẩn đoán thì thư viện của CAN Bus Shield vẫn hoạt động tốt trên
Module MCP2515. Nhưng trước khi sử dụng, cần điều chỉnh tần số thạch anh (Clockset)
48
từ 16MHz thành 8MHz vì thư viện của CAN Bus Shield được viết theo tần số thạch anh
16MHz.
Đường link tải: https://github.com/Seeed-Studio/CAN_BUS_Shield
5.2.2.2. Thư viện cho LCD TFT 2.4 inch
Đầu tiên là thư viện đồ họa cho các màn hình LCD – Adafruit GFX Library, cung
cấp các tài nguyên liên quan đến đồ họa (nền, điểm, đường, vòng tròn,…) và cần kết hợp
với thư viện của từng loại màn hình để điều khiển màn hình hiển thị, ở đây là thư viên
MCUFRIEND_kbv cho màn hình LCD TFT 2.4 inch. Ngoài ra còn có thư viện cảm ứng
cho màn hình khi thiết lập thêm chức năng cảm ứng.
Link tải thư viện Adafruit GFX Library:
https://github.com/adafruit/Adafruit-GFX-Library
Link tải thư viện MCUFRIEND_kbv:
https://github.com/prenticedavid/MCUFRIEND_kbv
Linh tải thư viên Adafruit_TouchScreen
https://github.com/adafruit/Adafruit_TouchScreen
5.2.3. Xây dựng giao diện hiển thị trên LCD
Giao diện hiển thị trên LCD được xây dựng dựa trên các chức năng của một máy
chấn đoán cơ bản với một vài chức năng tối thiểu như đọc dữ liệu hiện tại, đọc mã lỗi
chẩn đoán, xóa mã lỗi. Để nâng cao sự tiện dụng của thiết bị chẩn đoán, tính năng cảm
ứng cũng được tích hợp vào thiết bị.
Hình 5.10. Giao diện màn hình chính và màn hình đọc dữ liệu hiện tại
49
Hình 5.11. Giao diện màn đọc mã lỗi chẩn đoán và màn hình xóa lỗi
5.2.4. Xây dựng thuật toán gửi và nhận tín hiệu CAN
Thuật toán tín hiệu CAN cũng được xây dựng đi kèm với các chế độ hiển thị.
5.2.3.1. ID và vùng dữ liệu trong tin nhắn CAN
Thư viện CAN đã cài đặt có ví dụ về cách gửi và nhận tin nhắn trong mạng CAN.
Do mạng CAN được phổ biến khá rộng rãi trên ô tô nên thư viên CAN đi kèm một ví dụ
có liên quan đến OBD-II, đọc các thông số của động cơ thông qua giao thức CAN trên
ECU động cơ. Trước khi chạy thử code mẫu, chúng ta phải biết rằng chúng ta chỉ can
thiệp vào tin nhắn CAN ở vùng điều khiển (ID) và vùng dữ liệu của tin nhắn ở cả tin
nhắn gửi đi và nhận về với các yêu cầu theo tiêu chuẩn OBD-II.
Hình 5.12. Cấu trúc ID vùng dữ liệu trong tin nhắn CAN theo tiêu chuẩn OBD-II
Để hiểu rõ hơn về từng byte trong vùng dữ liệu, chúng ta có ví dụ sau về việc yêu
cầu và nhân thông tin về Tốc độ xe qua mạng CAN.
Hình 5.13. ID và vùng dữ liệu của tin yêu cầu và tin phản hồi
50
Identifier (ID): Đối với các thông báo OBD-II, mã ID theo chuẩn 11-bit và được
sử dụng để phân biệt giữa “Request Massages” (ID 7DF) và “Response Massages” (ID
7E8 đến 7EF). Với ID 7E8 thường sẽ là nơi động cơ chính hoặc ECU phản hồi.
Length: Byte đầu tiên của Vùng dữ liệu phản ánh độ dài theo số byte của dữ liệu
còn lại (03 - 06). Đối với ví dụ về Tốc độ Xe, nó là 02 cho yêu cầu (vì chỉ có 01 và 0D
theo sau), trong khi đối với phản hồi là 03 vì cả 41, 0D và 32.
Mode: Đối với các yêu cầu, điều này sẽ nằm trong khoảng 01-0A. Đối với các tin
nhắn phản hồi, số 0 được thay thế bằng 4 (tức là 41, 42,…, 4A). Có 10 chế độ như được
mô tả trong tiêu chuẩn SAE J1979 OBD2.
Mode (HEX) Mô tả
01 Hiển thị dữ liệu hiện tại
02 Hiển thị dữ liệu khung đóng băng
03 Hiển thị mã lỗi đã lưu trữ
04 Xóa mã lỗi và giá trị đã lưu
05 Các kết quả kiểm tra, giám sát cảm biến oxy
06 Các kết quả kiểm tra, giám sát các thành phần/hệ thống khác
07 Hiển thị mã lỗi đang chờ xử lý trong chu kì lái xe cuối cùng
08 Kiểm tra hoạt động của các thành phần/hệ thống trên xe
09 Yêu cầu thông tin xe
0A Hiển thị các mã lỗi đã xuất hiện (đã xóa)
Bảng 5.5. Các chế độ chẩn đoán của OBD-II
PID: Đối với mỗi chế độ, chúng ta có một danh sách các PID OBD-II tiêu chuẩn
đầy đủ được tổng hợp trên Wikipedia OBD-II PIDs và mỗi PID có một mô tả và một số
có công thức chuyển đổi và tối thiểu/tối đa được chỉ định. Ví dụ: trong Chế độ 01, PID
0D là Tốc độ Xe với công thức tính là A.
Công thức cho tốc độ: A, có nghĩa là byte dữ liệu A (ở dạng HEX) được chuyển
đổi thành số thập phân để nhận giá trị được chuyển đổi km/h (32 trở thành 50 km/h).
Hình 5.14. PID và công thức tính của Tốc độ xe và Tua máy (Engine RPM)
51
A, B, C, D: Đây là các byte dữ liệu trong HEX, cần được chuyển đổi sang dạng
thập phân trước khi chúng được sử dụng trong tính toán công thức PID. Lưu ý rằng byte
dữ liệu cuối cùng (sau byte D) không được sử dụng.
5.2.3.2. Code mẫu chế độ “Đọc dữ liệu hiện tại”
Hình 5.15. Đường dẫn Code OBD-II mẫu theo thư viện CAN
Hình 5.16. Cấu trúc vùng dữ liệu trong tin nhắn CAN yêu cầu
Hình 5.17. Vùng dữ liệu trong tin nhắn CAN phẩn hồi tốc độ xe
Như vậy, cấu trúc tin nhắn CAN yêu cầu và phản hồi luôn tuân theo tiêu chuẩn
OBD-II cho Vùng điều khiển (ID) và Vùng dữ liệu. Từ một thông số đơn giản có thể phát
triển thành nhiều thông số yêu cầu khác như RPM, Nhiệt độ nước làm mát động cơ,… để
đáp ứng yêu cầu đọc dữ liệu hiện tại của thiết bị chẩn đoán. Dưới đây là một vài thông số
khác đọc được từ ECU động cơ theo cách tương tự. Mọi thử nghiệm đều được tiến hành
trên Mô hình mô phỏng ECU động cơ Kia Morning 2011.
52
Hình 5.18. Một vài thông số từ ECU trong chế độ đọc dữ liệu hiện tại chuẩn OBD-II
5.2.3.3. Chế độ đọc mã lỗi lưu trữ
Hình 5.19. Chương trình gửi tin nhắn CAN cho các chế độ của OBD-II
1 2 3 4 5 6 7 8
Hình 5.20. Vùng dữ liệu tin nhắn CAN phản hồi

Cấu trúc gửi và nhận tương tự bằng cách thay đổi byte thứ nhất (Length) thành
0x01 và byte thứ hai (Mode) thành 0x03 và gửi yêu cầu.
53
Với tin nhắn phản hồi, ta có các Byte dữ liệu 1 và 2 như ở chế độ “Đọc dữ liệu
hiện tại”. Byte dữ liệu thứ 3 là số mã lỗi trong 1 tin nhắn CAN, có từ 0 đến 2 mã lỗi cho 1
tin nhắn (0x00 – 0x02) với hai byte dữ liệu 4 và 5 cho một mã lỗi, 6 và 7 cho một mã lỗi.
Khi có được các byte dữ liệu, chúng ta cần chuyển đổi các byte đấy thành các Mã lỗi
chẩn đoán OBD-II theo cấu trúc sau:
Hình 5.21. Chuyển đổi hai kí tự đầu trong mã lỗi chẩn đoán OBD-II
Với 4 bit theo hệ Nhị phân, tức số đầu tiên trong byte dữ liệu thứ 4 đã nhận được,
chúng ta chuyển đổi thành 2 kí tự đầu trong một mã lỗi “P0,P1,…,U3,U4”.
Với các kí tự còn lại trong mã lỗi chẩn đoán OBD-II tương ứng với số còn lại
trong byte dữ liệu thứ 4 và 2 số trong byte dữ liệu thứ 5 theo hệ Thập lục phân. Với byte
dữ liệu thứ 6 và 7 cũng chuyển đổi tương tự. Trường hợp không có mã lỗi thì byte dữ liệu
thứ 3 là 0x00 và các byte dữ liệu sau đó đều 0x00. Trường hợp có 1 mã lỗi, byte dữ liệu
thứ 3 là 0x01 và chỉ có dữ liệu ở byte dữ liệu thứ 4 và 5, byte dữ liệu 6 và 7 đều là 0x00.
Trường hợp có nhiều hơn 2 mã lỗi thì ECU sẽ gửi nhiều khung tương tự liên tiếp nhau để
thể hiện toàn bộ mã lỗi hiện tại.
Hình 5.22. Chuyển đổi kí tự 3-4-5 trong mã lỗi chẩn đoán OBD-II
54
5.2.3.4. Chế độ xóa mã lỗi
Tương tự các chế độ trên, chế độ xóa mã lỗi cũng tương tự với byte dữ liệu thứ 2
trong tin nhắn CAN yêu cầu là 0x04 và không có tin nhắn CAN phản hồi từ ECU.
5.2.6. Kết nối các thuật toán
Từ các thuật toán đơn lẽ theo các chế độ gửi – nhận tin nhắn CAN và giải mã, màn
hình hiển thị các chế, cảm ứng và nút bấm,…. Chúng ta kết hợp lại để có thuât toán, mô
hình tổng quan nhầm đảm bảo các yêu cầu ban đầu là đọc được, giải mã được, hiển thị
được.
Hình 5.23. Sơ đồ khối tổng quát thuật toán của thiết bị chẩn đoán
5.3. Thử nghiệm Module Arduino Uno – CAN Bus Shield – LCD trên xe Vios
Ta kết hợp các module như hình để tiến hành thử nghiệm trên xe.
Hình 5.24. Module thử nghiệm thiết bị chẩn đoán
55
5.3.1. Thu thập dữ liệu trên xe Vios qua Arduino IDE
Hình 5.25. Dữ liệu thu thập được từ arduino khi khi thử nghiệm module trên xe
Khi mới khởi động xe và để xe ở tốc độ cầm chừng, các số liệu thu thập được
tương đối chính xác như tốc độ xe, tua máy, độ mở bướm ga,… Từ đó xác định được
phần code thu thập dữ liệu xe chính xác so với ví dụ mẫu.
5.3.2. Thu thập dữ liệu qua hiển thị LCD
5.3.2.1. Đọc dữ liệu hiện tại
Hình 5.27. Dữ liệu đọc được từ xe
Hình 5.28. Thông số hiển thị trên bảng Taplo xe khi đọc dữ liệu
56
5.3.2.2. Đọc mã lỗi chẩn đoán
Trước khi tiến hành đọc lỗi, ta kiểm tra lỗi của xe và hoàn toàn không có lỗi. Sau
đó tiến hành tạo Ban tại cảm biến lưu lượng khí nạp.
Hình 5.29. Tạo lỗi tại giắc của cảm biến lưu lượng khí nạp
Kiểm tra lỗi bằng thiết bị, ta thu được mã lỗi P0102 và P0113.
Hình 5.30. Mã lỗi thu được sau khi tạo ban và đọc lỗi
Hình 5.31. Tra cứu mã lỗi thu thập được
57
Tiến hành gắn lại ban, xóa lỗi và kiểm tra lại
Hình 5.32. Xóa lỗi và kiểm tra lỗi lại

5.4. Xây dựng mô hình thiết bị chẩn đoán cơ bản
5.4.1. Vỏ thiết bị chẩn đoán
Hình 5.33. Vỏ thiết bị chẩn đoán

Phần vỏ thiết bị được thiết kế dựa theo các loại máy chẩn đoán phổ biến gồm vị trí
hiển thị và vị trí các nút điều khiển.
5.4.2. Thiết kế board mạch thiết bị chẩn đoán
Trước khi thiết kế, ta cần quan tâm đến kết nối cái module cần thiết, các module
được kết nối theo sơ đồ sau.
58
Hình 5.34. Sơ đồ kết nối các module
Sau khi có sơ đồ kết nối, chúng ta tiến hành thiết kế bản vẽ nguyên lý và bản vẽ
điện tử của thiết bị thông qua phần mềm Proteus.
Hình 5.34. Mạch nguyên lý của thiết bị chẩn đoán
59
Hình 5.34. Bản vẽ mạch điện tử của thiết bị chẩn đoán
60
Chương 5. KẾT LUẬN VÀ KIẾN NGHỊ
Sau quá trình nghiên cứu và phát triển máy chẩn đoán, chúng em đã biết được
nguyên lý và cách thức hoạt động của Giao thức CAN và chuẩn OBD-II trên xe ô tô. Từ
đó, đã ứng dụng được mạng CAN để đọc dữ liệu hiện tại của xe, đọc lỗi và xóa lỗi thực
nghiệm trên xe TOYOTA VIOS, hiển thị thông số lên LCD. Với những ứng dụng đó,
chúng em đã áp dụng được lý thuyết mạng CAN, lý thuyết về OBD và các thuật toán lập
trình cơ bản trên Arduino IDE để xây dựng được thuật toán đọc và giải mã tín hiệu CAN,
đồng thời hiển thị thông số lên LCD. Bên cạnh những điều đã đạt được cũng có những
điều còn hạn chế, đó là chưa thiết kế được một thiết bị chẩn đoán hoàn chỉnh, đáp ứng
yêu cầu ban đầu đặt ra cùng với kì vọng của đề tài. Dựa trên những mặt còn thiếu sót,
chúng em mong muốn đề tài được phát triển hơn khi mạch điện tử của thiết bị được gia
công chỉnh chu hơn, phát triển thêm tính năng đọc số VIN của xe, mã của ECU động cơ
và các tính năng khác từ cổng OBD-II trên ô tô.
61
DANH MỤC TÀI LIỆU THAM KHẢO
[1] CCS Electronics, OBD2 Explain – A Simple Intro (2020),

https://www.csselectronics.com/screen/page/simple-intro-obd2-explained/language/en
[2] Wikipedia , OBD-II PIDs, https://en.wikipedia.org/wiki/OBD-II_PIDs
[3] Wikipedia, On-Board Diagnostics, https://en.wikipedia.org/wiki/On-
board_diagnostics#OBD-II_Diagnostic_Trouble_Codes
[4] Nguyễn Quân, [CAN2.0][Controller Area Network],
http://nguyenquanicd.blogspot.com/
[5] STVMAC11, Car to Arduino Communication: CAN Bus Sniffing and
Broadcasting With Arduino, https://www.instructables.com/id/CAN-Bus-Sniffing-and-
Broadcasting-with-Arduino/
[6] Microduinoinc, https://wiki.microduinoinc.com/
62

Máy chẩn đoán cơ bản

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Máy chẩn đoán cơ bản

Uploaded by

Copyright:

Available Formats

TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT THÀNH PHỐ HỒ CHÍ MINH

KHOA CƠ KHÍ ĐỘNG LỰC

NGHIÊN CỨU VÀ THỬ NGHIỆM

SVTH: NGUYỄN TẤN THIỆN

Tp. Hồ Chí Minh, tháng 8 năm 2020

NGHIÊN CỨU VÀ THỬ NGHIỆM

SVTH: NGUYỄN TẤN THIỆN

Tp. Hồ Chí Minh, tháng 8 năm 2020

TP. Hồ Chí Minh, ngày tháng 8 năm 2020

NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP

Chuyên ngành: Công nghệ Kỹ thuật Ô tô Mã ngành đào tạo: 52510205

Hệ đào tạo: Đại học Chính quy Mã hệ đào tạo: K16145

“NGHIÊN CỨU VÀ THỬ NGHIỆM MÁY CHUẨN ĐOÁN CƠ BẢN”

1/ Tìm hiểu chức năng của giắc OBD-II

5/ Thực nghiệm trên một số xe và mô hình động cơ thông dụng

4. Ngày giao nhiệm vụ đề tài:

TRƯỞNG BỘ MÔN CÁN BỘ HƯỚNG DẪN

2. Nhận xét về kết quả thực hiện của ĐATN

2.2. Nội dung đồ án:

2.3. Kết quả đạt được:

2.4.Những tồn tại (nếu có):

TP.HCM, ngày tháng 8 năm 2020

KHOA CƠ KHÍ ĐỘNG LỰC Độc lập - Tự do – Hạnh phúc

PHIẾU NHẬN XÉT ĐỒ ÁN TỐT NGHIỆP

Ý KIẾN NHẬN XÉT

3. Kết quả đạt được:

4. Những thiếu sót và tồn tại của ĐATN:

Điểm tối đa Điểm đạt

TP.HCM, ngày tháng 8 năm 2020

Ngành: Công nghệ Kỹ thuật ô tô

Chủ tịch Hội đồng:

Giảng viên hướng dẫn:

Giảng viên phản biện:

Tp. Hồ Chí Minh, ngày tháng 8 năm 2020

LỜI CẢM ƠN ......................................................................................................................i

ABS Anti-lock Brake System

Hình 2.1 - Các chân trên giắc ALDL

Hình 2.2 – Hình dạng các giắc OBD-I các hãng xe

Hình 2.6. Ý nghĩa các kí tự trong mã lỗi chẩn đoán

Hình 2.7. Các bộ phận của một hệ thống ECU

Hình 3.1. Chẩn đoán ô tô thông qua máy chẩn đoán

Hình 3.2. Chẩn đoán ô tô theo phương pháp truyền thống

Hình 3.7 - Thông tin của xe và bộ điều khiển

Bus Length Bit rate Bit time

25 meters 1000 kbit/s 1 µs

50 meters 800 kbit/s 1.25 µs

100 meters 500 kbit/s 2 µs

250 meters 250 kbit/s 4 µs

500 meters 125 kbit/s 8 µs

1000 meters 50 kbit/s 20 µs

2500 meters 25 kbit/s 50 µs

Hình 4.5. Các thành phần cơ bản của mạng CAN

Hình 4.7. Tín hiệu CAN tốc độ cao ISO 11898-2

Hình 4.9. Tín hiệu CAN tốc độ thấp ISO 11898-3

Hình 4.10. Định dạng khung tiêu chuẩn

Hình 4.11. Định dạng của khung mở rộng

• 11 bit Định danh chuẩn.

• 1 bit Yêu cầu truyền từ xa (RTR - Remote Transmission Request).

• 11 bit Định danh chuẩn.

• 1 bit Yêu cầu thay thế từ xa (SRR - Substitute Remote Request).

• 1 bit Mở rộng mã định danh (IDE – Identifier Extension Bit).

• 18 bit Định danh mở rộng.

• 1 bit Yêu cầu truyền từ xa (RTR - Remote Transmission Request).

Hình 4.12. Các phân lớp bit của vùng phân xử