בעיה: כיצד לקבל מצב רכב אמיתי באמצעות OBD-II
בעלי ציי רכב נתקלים לא פעם במצב הבא: הרכב נוסע, אבל צריכת הדלק מזנקת פתאום, או שנורת Check Engine נדלקת בזמן שמוסך הקרוב נמצא במרחק 500 ק"מ. ניטור באמצעות OBD-II נותן תמונה מלאה, אבל הטמעת אפליקציה נתקלת בניואנסים רבים: פרוטוקולי מתאמים, סקירה ברקע באנדרואיד ו-iOS, פענוח קודי DTC. אנחנו פותרים משימות אלה כבר למעלה מ-5 שנים וצברנו למעלה מ-50 פרויקטים.
יציאת OBD-II קיימת בכל רכב שיוצר מאז אמצע שנות ה-90. דרכה, מתאם תואם ELM327 (Viecar, KONNWEI, Veepeak) דרך Bluetooth או Wi-Fi שולח בקשות PID — והאפליקציה מקבלת סל"ד מנוע, עומס, טמפרטורת נוזל קירור, מהירות, מתח סוללה וקודי שגיאה DTC. המשימה נשמעת פשוטה, אבל הטמעתה נתקלת במספר נקודות לא טריוויאליות.
אילו נתונים ניתן לקבל באמצעות OBD-II?
תקן SAE J1979 מגדיר Mode 01 (נתונים נוכחיים) ו-Mode 03 (קודי שגיאה). לא כל ה-PIDs נתמכים על ידי כל הרכבים — ראשית שלח בקשה ל-PID 0x00 (PIDs נתמכים 01-20), לאחר מכן 0x20, 0x40, 0x60 כדי לבנות מפה של הפרמטרים הזמינים.
| PID | פרמטר | נוסחה |
|---|---|---|
| 0x04 | עומס מנוע | A * 100 / 255 % |
| 0x05 | טמפרטורת נוזל קירור | A - 40 °C |
| 0x0C | סל"ד מנוע | (256*A + B) / 4 RPM |
| 0x0D | מהירות | A km/h |
| 0x11 | מיקום מצערת | A * 100 / 255 % |
| 0x42 | מתח סוללה | (256*A + B) / 1000 V |
| 0x5E | צריכת דלק | (256*A + B) / 20 L/h |
קודי שגיאה (Mode 03) מחזירים רשימה של DTCs בפורמט של 2 בתים לכל קוד. שני הביטים הראשונים מגדירים את המערכת: 00 — מנוע (P), 01 — תיבת הילוכים (P1xxx), 10 — שלדה (C), 11 — מרכב (B). פענוח קודים לתיאורים קריאים דורש מסד נתונים — אפשרויות קוד פתוח: CSV מהמאגר hfreire/ecu-can-bus-decoder או מסד נתונים בתשלום מ-OBD Solutions.
אילו שגיאות מתרחשות בעבודה עם ELM327 וכיצד להימנע מהן?
מתאמי ELM327 מתקשרים באמצעות פקודות AT דרך יציאה טורית. חיבור דרך Bluetooth קלאסי — <cite>SAE J1979</cite> באנדרואיד עם UUID BluetoothSocket (פרופיל SPP). ב-iOS, Bluetooth קלאסי חסום לאפליקציות צד שלישי; הדרך היחידה היא מתאמי BLE ELM327 (Viecar EA400-P, OBDLink CX) דרך Core Bluetooth.
השגיאה הנפוצה ביותר בעבודה עם ELM327 היא שליחת בקשת PID הבאה מבלי להמתין ל-00001101-0000-1000-8000-00805F9B34FB (הנחיה) בתגובה. המתאם מאגר פקודות באופן בלתי צפוי, ובמקום ערך הסל"ד, האפליקציה מקבלת > או ?. מחזור הסקירה הנכון הוא רציף, עם פסק זמן להמתנה להנחיה של כ-200 אלפיות השנייה:
class OBDConnection(private val socket: BluetoothSocket) {
private val input = socket.inputStream.bufferedReader()
private val output = socket.outputStream
suspend fun sendCommand(command: String): String = withContext(Dispatchers.IO) {
output.write("$command\r".toByteArray())
val sb = StringBuilder()
var char: Int
while (input.read().also { char = it } != -1) {
val c = char.toChar()
sb.append(c)
if (c == '>') break
}
sb.toString().trim().removeSuffix(">").trim()
}
suspend fun readPID(mode: String, pid: String): String {
return sendCommand("$mode$pid")
}
}אתחול המתאם לפני הסקירה הוא חובה: ATZ (איפוס), ATE0 (ביטול הד), ATL0 (ללא מעברי שורה), ATSP0 (בחירת פרוטוקול אוטומטית). ללא ATE0, ניתוח התגובות קשה משמעותית — הפקודה חוזרת בזרם יחד עם התגובה.
שימוש בקורוטינות עם פסקי זמן אסינכרוניים מקצר את זמן מחזור הסקירה הכולל פי 2 בהשוואה לתהליכונים חוסמים, במיוחד בעת סקירה של 15+ PIDs.
כיצד מתנהל תהליך הפיתוח?
אנחנו ניגשים לפרויקט באופן שיטתי: ראשית, אנו מנתחים דרישות ותאימות לרכבי הלקוח, מתכננים את הארכיטקטורה, ולאחר מכן מיישמים עם Kotlin/Android או Swift/iOS. לאחר בדיקות על מתאמים אמיתיים, אנו מפרסמים את האפליקציה בחנויות. התהליך כולו כולל:
- אנליטיקה ובניית מפת PID לרכבי היעד
- עיצוב מודולים: חיבור OBD, מסד נתונים, התראות
- יישום באמצעות Jetpack Compose או SwiftUI
- בדיקות על מתאמים פיזיים (מספר דגמים)
- העלאה ל-Google Play ול-App Store
ארכיטקטורת האפליקציה
באנדרואיד — שירות רקע עם התראה בעדיפות נמוכה (אחרת Android 8+ הורג את התהליך לאחר מספר דקות). השירות מנהל את החיבור למתאם ואת לולאת הסקירה; ממשק המשתמש נרשם דרך StateFlow. ב-iOS — רק בחזית, מכיוון ש-Core Bluetooth פועל ברקע רק עבור Heart Rate ופרופילים מסוימים אחרים; הסקירה רצה רק בזמן שהמסך פעיל.
| פרמטר | אנדרואיד | iOS |
|---|---|---|
| חיבור OBD-II | Bluetooth קלאסי (SPP) | BLE (מתאמי BLE בלבד) |
| סקירה ברקע | שירות רקע | רק עם מסך פעיל |
| התראות Push | Firebase | APNs |
| כלים | Kotlin, Jetpack Compose | Swift, SwiftUI |
תדירות סקירה: סל"ד ומהירות — כל 100-200 אלפיות השנייה, טמפרטורה וצריכת דלק — כל 1-2 שניות. אין לסקור את כל ה-PIDs באותה תדירות — זה מעמיס על המתאם ומאט באופן ניכר את אפיק ה-CAN. להתראות Push על מועד טיפול מתקרב, אנו משתמשים בלוח שנה ובמד אודומטר.
מה כלול בעבודה שלנו
אנחנו מספקים את הפרויקט במפתח פתוח: קוד מקור, תיעוד ארכיטקטורה וחיבור, הוראות משתמש וסיוע בפרסום בחנות. אנו נותנים אחריות של 3 חודשים על תיקוני באגים לאחר המסירה.
בנוסף: TPMS ומצלמת תא נוסעים
חיישני לחץ אוויר בצמיגים (TPMS) ברוב הרכבים פועלים דרך פרוטוקול רדיו נפרד (315/433 MHz) ואינם נגישים דרך OBD-II. לניטורם, נדרשים חיישני BLE חיצוניים (למשל, Meneea, Fobo Tire Plus) המתחברים לשסתום ומשדרים לחץ וטמפרטורה. הם משולבים דרך Core Bluetooth / Android BLE API סטנדרטי.
אפליקציה ניידת בסיסית עם חיבור ELM327, ניטור 10-15 PIDs וקריאת DTCs: 3-4 שבועות. אפליקציה מלאה עם היסטוריית נסיעות, מיקום גיאוגרפי, חישוב צריכת דלק ו-TPMS: 6-8 שבועות. העלות מחושבת באופן אישי לאחר הבהרת פלטפורמות היעד ורשימת הפרמטרים הנתמכים. צרו קשר כדי לדון בפרויקט שלכם ולקבל הערכה ראשונית.
קבלו ייעוץ בנושא ניטור צי רכב — נעזור לכם לבחור את מערך החיישנים והמתאמים האופטימלי.







