Protokol KWP2000 telah menjadi standar de facto dalam aplikasi diagnostik otomotif. Ini distandarisasi sebagai ISO 14230-3. KWP2000 menjelaskan implementasi berbagai layanan diagnostik yang dapat Anda lakukan melalui protokol. Anda dapat menjalankan KWP2000 pada beberapa lapisan transport seperti K-line (serial) atau CAN.

Transport Protocol

Karena KWP2000 menggunakan pesan dengan panjang byte variabel, protokol transport diperlukan pada layer dengan hanya panjang pesan yang didefinisikan (pendek), seperti CAN. Protokol transport membagi pesan KWP2000 panjang menjadi potongan-potongan yang dapat ditransfer melalui jaringan dan mengumpulkan kembali potongan-potongan tersebut untuk memulihkan pesan asli.

KWP2000 berjalan pada BISA pada berbagai protokol transport seperti ISO TP (ISO 15765-2), TP 1,6, TP 2. 0 (Volkswagen), dan SAE J1939-21. Untuk KWP2000, Set Perintah Diagnostik Otomotif hanya mendukung ISO TP (standar dalam ISO 15765-2) dan protokol transportasi khusus TP TP produsen.

Layanan Diagnostik

Layanan diagnostik yang tersedia di KWP2000 dikelompokkan dalam unit fungsional dan diidentifikasi oleh kode satu-byte (ServiceId). Standar tidak mendefinisikan semua kode; untuk beberapa kode, standar mengacu pada standar SAE atau ISO lainnya, dan beberapa dicadangkan untuk ekstensi khusus pabrik. Set Perintah Diagnostik Otomotif mendukung layanan berikut:

• Manajemen Diagnostik

• Transmisi Data

• Transmisi Data Tersimpan (Diagnostic Trouble Codes)

• Kontrol Input / Output

• Aktivasi Jauh Rutin

Unggah / Unduh dan layanan Diperpanjang bukan bagian dari Kumpulan Perintah Diagnostik Otomotif.

Format Layanan Diagnostik

Layanan diagnostik memiliki format pesan umum. Setiap layanan mendefinisikan Pesan Permintaan, Pesan Respons Positif, dan Pesan Respons Negatif. Pesan Permintaan memiliki ServiceId sebagai byte pertama, ditambah parameter tambahan yang ditentukan oleh layanan. Pesan Tanggapan Positif memiliki gema dari ServiceId dengan bit 6 ditetapkan sebagai byte pertama, ditambah parameter respons yang ditetapkan oleh layanan.

Pesan Respons Negatif biasanya pesan tiga-byte: ia memiliki Layanan Respons NegatifId sebagai byte pertama , gema dari ServiceId yang asli sebagai byte kedua, dan ResponseCode sebagai byte ketiga. Satu-satunya pengecualian untuk format ini adalah respons negatif terhadap layanan EscapeCode; di sini, byte ketiga adalah gema dari kode layanan yang ditentukan pengguna, dan byte keempat adalah ResponseCode. Standar KWP2000 sebagian mendefinisikan ResponseCodes, tetapi ada ruang tersisa untuk ekstensi khusus produsen. Untuk beberapa ResponseCodes, KWP2000 mendefinisikan prosedur penanganan kesalahan. Karena respons positif dan negatif memiliki gema dari layanan yang diminta, Anda selalu dapat menetapkan tanggapan ke permintaan yang sesuai.

Menghubungkan / Memutuskan

KWP2000 mengharapkan sesi diagnostik untuk dimulai dengan StartDiagnosticSession dan diakhiri dengan StopDiagnosticSession. Namun, StartDiagnosticSession memiliki parameter DiagnosticMode yang menentukan jenis sesi diagnostik. Tergantung pada jenis ini, ECU mungkin atau mungkin tidak mendukung layanan diagnostik lain, atau beroperasi dalam mode terbatas di mana tidak semua fungsi ECU tersedia. Nilai parameter DiagnosticMode adalah pabrikan yang spesifik dan tidak didefinisikan dalam standar. Untuk sesi diagnostik agar tetap aktif, ia harus menjalankan layanan TesterPresent secara berkala jika tidak ada layanan lain yang dijalankan. Jika layanan TesterPresent hilang untuk jangka waktu tertentu, sesi diagnostik dihentikan, dan ECU kembali ke mode operasi normal.

GetSeed / Unlock

Mekanisme GetSeed / Unlock dapat melindungi beberapa layanan diagnostik. Namun, layanan yang berlaku diserahkan kepada pabrikan dan tidak ditentukan oleh standar. Anda dapat menjalankan mekanisme GetSeed / Unlock melalui layanan SecurityAccess. Ini menentukan beberapa tingkat keamanan, tetapi pabrikan menetapkan level ini ke layanan tertentu.

Baca / Tulis Memori

Gunakan layanan Read / WriteMemoryByAddress untuk mengunggah / mengunduh data ke alamat memori tertentu pada ECU. Alamatnya adalah kuantitas tiga-byte dalam KWP2000 dan kuantitas lima-byte (empat-byte alamat dan satu-byte ekstensi) dalam protokol kalibrasi. Layanan unit fungsional Upload / Unduhan sangat spesifik untuk pabrikan dan tidak terdefinisi dengan baik dalam standar, jadi itu bukan cara yang baik untuk menyediakan mekanisme pengunggahan / unduhan umum.

Pengukuran

Gunakan layanan ReadDataByLocal / CommonIdentifier untuk mengakses data ECU dengan cara yang mirip dengan daftar DAQ. Lokal / CommonIdentifier menjelaskan daftar kuantitas ECU yang kemudian ditransfer dari ECU ke penguji. Transfer dapat berupa nilai tunggal atau berkala, dengan kecepatan transfer yang lambat, sedang, atau cepat. Tingkat transfer adalah produsen khusus; Anda dapat menggunakan layanan SetDataRates untuk mengaturnya, tetapi pengaturan ini khusus untuk pabrikan. Set Perintah Diagnostik Otomotif mendukung pengukuran satu titik.

Kode Masalah Diagnostik

Fitur diagnostik utama adalah pembacaan Diagnostic Trouble Codes (DTCs). KWP2000 mendefinisikan beberapa layanan yang mengakses DTC berdasarkan grup atau status mereka.

Kontrol Input / Output

KWP2000 mendefinisikan layanan untuk memodifikasi sinyal ECU internal atau eksternal. Salah satu contoh adalah mengarahkan input sensor ECU ke sinyal yang distimulasi. Parameter kontrol dari perintah ini adalah pabrikan yang spesifik dan tidak didefinisikan dalam standar.

Aktivasi Jauh Rutin

Layanan ini serupa dengan fungsi ActionService dan DiagService dari CCP. Anda dapat memanggil rutin internal ECU yang diidentifikasi oleh Local / CommonIdentifier atau alamat memori. Bertentangan dengan kasus PKC, pelaksanaan rutin ini dapat bersifat asynchronous; yaitu, ada layanan Start, Stop, dan RequestResult yang terpisah. Parameter kontrol dari perintah ini adalah pabrikan yang spesifik dan tidak didefinisikan dalam standar.

Referensi Eksternal

Untuk informasi lebih lanjut tentang Standar KWP2000, lihat standar ISO 14230-3.