وقتی برای خرید یک خودروی کارکرده وقت می‌گذارید، اتصال دستگاه دیاگ یکی از بخش‌های مهم بررسی است؛ اما نتیجه دیاگ فقط زمانی ارزش دارد که درست تفسیر شود. دیدن عبارت «بدون خطا» روی نمایشگر به این معنا نیست که خودرو از نظر موتور، گیربکس، بدنه و شاسی بی‌عیب است. از طرف دیگر، وجود یک کد خطا نیز همیشه به معنی خرابی قطعه‌ای گران‌قیمت نیست. کد ممکن است به یک ایراد مقطعی، ضعف اتصال، افت ولتاژ باتری یا مشکلی نیازمند بررسی بیشتر اشاره کند.
در این راهنما توضیح می‌دهیم دیاگ خودرو قبل از خرید چه اطلاعاتی میدهد، چه محدودیت‌هایی دارد و چرا باید در کنار بررسی فنی و بازدید ظاهری استفاده شود.
یک اسکن قابل اتکا فقط فهرست کدها نیست؛ باید زمان اسکن، وضعیت سوییچ و موتور، دمای خودرو، ولتاژ تغذیه، واحدهای خوانده‌شده، وضعیت هر کد و داده‌های همراه ثبت شوند. بدون این زمینه، یک کد یا عبارت «بدون خطا» ممکن است بیش از آنچه واقعاً دیده شده معنا پیدا کند.
در معامله بهتر است پیش از هر پاکسازی، خروجی اولیه حفظ شود. سپس داده‌ها با استارت سرد، گرم‌شدن، بار واقعی و رانندگی کنترل‌شده تطبیق داده شوند. پاک‌کردن کد برای آزمایش، اگر لازم باشد، باید بعد از ثبت شواهد و با اطلاع طرفین انجام شود؛ نه پیش از شروع بازدید.
دیاگ خودرو دقیقاً چیست؟
خودروهای مجهز به واحدهای کنترل الکترونیکی، وضعیت بعضی حسگرها و سامانه‌ها را پایش می‌کنند. وقتی واحد کنترل شرایطی خارج از محدوده مورد انتظار تشخیص دهد، ممکن است یک کد خطا ذخیره کند یا چراغ هشدار را روشن کند. دستگاه دیاگ از طریق درگاه تشخیصی با این واحدها ارتباط می‌گیرد و بسته به مدل خودرو و سطح دسترسی دستگاه، کدهای ثبت‌شده و بخشی از داده‌های لحظه‌ای را نمایش میدهد.
دامنه اطلاعات در همه خودروها یکسان نیست. در بعضی مدلها فقط اطلاعات عمومی موتور و آلایندگی در دسترس است؛ در برخی خودروها می‌توان به واحدهای بیشتری مانند گیربکس، ترمز، کیسه هوا، تهویه و تجهیزات بدنه دسترسی داشت. بنابراین کیفیت بررسی فقط به دستگاه وابسته نیست و سازگاری نرم‌افزار، مدل خودرو و نحوه تفسیر داده‌ها نیز اهمیت دارد.
نقشه پوشش دیاگ؛ اسکن عمومی با اسکن همه واحدها فرق دارد
اتصال به درگاه خودرو به‌تنهایی نشان نمی‌دهد همه واحدها بررسی شدهاند. ابزار عمومی ممکن است فقط کدهای استاندارد موتور و آلایندگی را بخواند؛ درحالی‌که دسترسی به گیربکس، ABS، SRS، فرمان، تهویه یا تجهیزات بدنه به خودرو، نرم‌افزار، مجوز و پروتکل سازگار نیاز دارد.
| سطح بررسی | خروجی محتمل | محدودیت مهم | عبارت دقیق در گزارش |
|---|---|---|---|
| خواندن عمومی موتور | کدهای استاندارد و بخشی از داده موتور | سایر واحدها ممکن است اصلاً اسکن نشده باشند | «واحد موتور در سطح عمومی خوانده شد» |
| اسکن چند واحد | فهرست واحدهای پاسخدهنده و کدهای هرکدام | پاسخ‌ندادن یک واحد علت را مشخص نمیکند | نام واحدهای قابل‌دسترسی و غیرقابل‌دسترسی ثبت شود |
| داده زنده | مقادیر حسگر و فرمان در همان لحظه | عدد بدون دما، دور، بار و شرایط آزمون قابل تفسیر نیست | مقدار همراه زمان و شرایط ثبت شود |
| آزمون یا عملکرد ویژه | فرمان محدود به عملگر یا روال سازنده | برای همه خودروها و همه ابزارها در دسترس یا ایمن نیست | فقط آزمون مجاز و انجام‌شده نوشته شود |
برچسب «فول دیاگ» دامنه استاندارد و ثابتی ندارد. پیش از بازدید باید روشن شود کدام واحدها و چه نوع داده‌ای برای همان مدل قابل‌خواندن است.
اسکن ABS با خواندن عمومی موتور یکسان نیست
ابزاری که فقط ECU موتور و کدهای آلایندگی را می‌خواند، لزوماً به واحد ABS، داده سرعت چرخ یا وضعیت کنترل پایداری دسترسی ندارد. گزارش باید نام واحد اسکن‌شده، کدهای فعال و تاریخی، امکان مشاهده داده زنده و محدودیت ابزار را ذکر کند. مسیر تطبیق کد با حسگر، تایر، بلبرینگ، ولتاژ و رفتار چراغ در راهنمای دیاگ و بررسی چراغ ABS پیش از خرید آمده است.
شناسنامه جلسه دیاگ پیش از تفسیر
دو اسکن از یک خودرو می‌توانند فقط به دلیل تفاوت شرایط نتیجه متفاوتی داشته باشند. شناسنامه جلسه کمک میکند مشخص باشد هر داده در چه وضعیتی ثبت شده است.
| داده زمینه‌ای | چرا مهم است؟ | نمونه ثبت |
|---|---|---|
| زمان و مرحله آزمون | رابطه اسکن با استارت سرد، گرم‌شدن یا رانندگی را روشن میکند | پیش از روشن‌کردن، پس از استارت، پس از گرم‌شدن، پس از مسیر کنترل‌شده |
| وضعیت موتور و سوییچ | بعضی واحدها یا داده‌ها فقط در یک وضعیت پاسخ می‌دهند | سوییچ باز/موتور خاموش یا موتور روشن |
| دمای آب، هوای ورودی و محیط | برای سنجش معقول‌بودن داده سرد و گرم مفید است | مقادیر گزارش‌شده همراه با شرایط واقعی محل |
| ولتاژ باتری و شارژ | افت ولتاژ میتواند ارتباط شبکه و بعضی خطاها را تحت تأثیر قرار دهد | قبل از استارت، هنگام استارت و در حالت روشن در صورت دسترسی ایمن |
| ابزار و دامنه اسکن | پوشش اسکن عمومی با اسکن سازنده و همه واحدها یکسان نیست | نام ابزار، نسخه، پروفایل خودرو و فهرست واحدهای پاسخ‌داده |
| اقدام قبلی | قطع باتری، پاکسازی کد یا برنامه‌ریزی میتواند سابقه را تغییر دهد | ادعای فروشنده، فاکتور یا نشانه‌های قابل مشاهده |
Stored، Pending، Permanent و History چه تفاوتی دارند؟
نامگذاری و دسترسی با واحد کنترل، سازنده و ابزار متفاوت است؛ بنابراین برچسب‌ها باید دقیقاً همان‌طور که ابزار نشان میدهد ثبت شوند. بااین‌حال تفکیک وضعیت کد از خود شماره کد ضروری است.
| وضعیت رایج | برداشت محتاطانه | اشتباه رایج |
|---|---|---|
| Stored / Confirmed | شرط تشخیص در منطق واحد به سطح ثبت رسیده است | برابر دانستن آن با خرابی قطعی قطعه نام‌برده |
| Pending | شرطی دیده شده اما ممکن است هنوز معیار ثبت نهایی کامل نشده باشد | نادیده‌گرفتن چون چراغ هشدار روشن نیست |
| Permanent در OBD عمومی | در برخی خطاهای آلایندگی تا تکمیل منطق تأیید سامانه باقی می‌ماند | تصور اینکه با پاک‌کردن معمولی فوراً حذف میشود یا در همه واحدها وجود دارد |
| History / Past / Intermittent | رخدادی قبلی یا متناوب ثبت شده است | قطعیت‌دادن به فعال‌بودن فعلی یا بی‌اهمیت دانستن کامل آن |
| Current / Active | واحد در زمان یا شرایط فعلی خطا را فعال می‌بیند | تعویض مستقیم قطعه بدون بررسی تغذیه، اتصال و داده زنده |
در گزارش باید وضعیت، واحد ثبت‌کننده و زمان مشاهده کنار کد نوشته شود. یک شماره یکسان در دو واحد یا دو وضعیت الزاماً معنای یکسانی ندارد.
دیاگ پیش از خرید چه چیزهایی را نشان میدهد؟
۱. کدهای خطای ثبت‌شده
کد خطا مسیر بررسی را مشخص میکند، نه نتیجه نهایی تعمیر را. برای مثال، یک کد مرتبط با سنسور اکسیژن میتواند به خود سنسور، سیمکشی، نشتی هوا یا شرایط کارکرد موتور مربوط باشد. به همین دلیل، تعویض قطعه صرفاً بر اساس نام کد تصمیم مطمئنی نیست.
۲. خطاهای فعال، موقت و ذخیره‌شده
بسته به خودرو و دستگاه، ممکن است وضعیت خطا به‌صورت فعال، موقت یا ذخیره‌شده نمایش داده شود. خطای فعال اکنون توسط واحد کنترل دیده میشود؛ خطای موقت هنوز ممکن است شرایط لازم برای روشن‌کردن چراغ هشدار را کامل نکرده باشد؛ خطای ذخیره‌شده نیز سابقه‌ای است که باید با وضعیت فعلی خودرو مقایسه شود.
۳. داده‌های زنده برخی حسگرها
دور موتور، دمای مایع خنک‌کننده، ولتاژ، وضعیت بعضی حسگرها و اصلاحات سوخت از جمله داده‌هایی هستند که در بسیاری از خودروها قابل مشاهده‌اند. این اعداد باید در شرایط درست—مانند موتور سرد، دمای کاری یا هنگام تست رانندگی—خوانده شوند. یک عدد بدون دانستن شرایط آزمون ممکن است گمراه‌کننده باشد.
۴. وضعیت برخی سامانه‌های الکترونیکی
در خودروهای سازگار، امکان بررسی خطاهای واحدهایی مانند گیربکس اتوماتیک، ABS، کیسه هوا یا سامانه‌های رفاهی وجود دارد. دسترسی واقعی به این بخش‌ها به مدل خودرو و ابزار مورد استفاده بستگی دارد و نباید برای همه خودروها یکسان فرض شود.
دیاگ چه چیزهایی را ثابت نمیکند؟
- سلامت رنگ، بدنه و شاسی: دیاگ آثار رنگ‌شدگی، بتونه، تعویض قطعه بدنه یا آسیب سازه‌ای را تشخیص نمی‌دهد. برای این بخش به بازدید چشمی، ابزار سنجش ضخامت رنگ و بررسی تخصصی نیاز است. راهنمای تشخیص رنگ خودرو توضیح بیشتری در این زمینه ارائه میکند.
- سلامت مکانیکی کامل موتور: صدای غیرعادی، نشتی روغن، افت فشار، دود، لرزش یا فرسودگی قطعات ممکن است بدون ثبت کد خطا وجود داشته باشد.
- سلامت کامل گیربکس: کیفیت تعویض دنده، ضربه، تأخیر یا لغزش باید در تست رانندگی و بررسی فنی ارزیابی شود؛ نبود کد خطا به‌تنهایی کافی نیست.
- کارکرد واقعی خودرو: عدد کیلومتر نمایش‌داده‌شده باید همراه با سابقه سرویس، وضعیت کابین، فرسودگی قطعات و داده‌های قابل دسترس خودرو بررسی شود. دیاگ همیشه امکان تأیید قطعی کیلومتر واقعی را ندارد.
- اصالت و وضعیت حقوقی: دیاگ جای بررسی اسناد، اصالت شماره‌های شناسایی، مالکیت، توقیف یا استعلام‌های قانونی را نمی‌گیرد.
اگر خطاها قبل از بازدید پاک شده باشند چه میشود؟
پاک‌کردن کدهای خطا ممکن است چراغ هشدار را موقتاً خاموش کند، اما علت اصلی ایراد را برطرف نمیکند. بعضی خطاها پس از چند دقیقه یا چند چرخه رانندگی دوباره ثبت می‌شوند. همچنین در برخی خودروها نشانه‌هایی مانند کامل‌نبودن آزمونهای داخلی یا نبود سابقه مورد انتظار میتواند نیاز به بررسی بیشتر را نشان دهد. این نشانه‌ها قطعی نیستند و باید در کنار وضعیت باتری، تعمیرات اخیر و تست رانندگی تفسیر شوند.
بهتر است خودرو در حالت سرد نیز بررسی شود، سپس پس از رسیدن موتور به دمای کاری و انجام تست رانندگی، اسکن دوباره انجام گیرد. این کار احتمال مشاهده ایرادهایی را که فقط در شرایط خاص رخ می‌دهند افزایش میدهد.
شرایط آزمون را پیش از تفسیر داده ثبت کنید
یک کد یا مقدار میتواند با تغییر دمای موتور، ولتاژ باتری، ارتفاع، بار موتور یا حالت گیربکس معنای متفاوتی داشته باشد. گزارش باید شرایطی را که داده در آن خوانده شده از خود داده جدا نکند.
- مدل، سال، تیپ و نوع موتور و گیربکس با خودرو تطبیق داده شود.
- دمای اولیه موتور و اینکه خودرو پیش از حضور روشن شده یا نه ثبت شود.
- ولتاژ در حالت خاموش، هنگام استارت و در زمان کارکرد فقط در صورت دسترسی و با ابزار مناسب بررسی شود.
- چراغ‌های هشدار پیش از اتصال و پاک‌کردن داده مشاهده و عکس‌برداری شوند.
- هیچ کدی قبل از ثبت شماره، وضعیت و واحد مربوط پاک نشود.
- اگر رانندگی یا اسکن مجدد انجام نمی‌شود، این محدودیت در نتیجه بماند.
Freeze Frame، وضعیت مانیتورها و چرخه رانندگی چه کمکی می‌کنند؟
در بعضی خودروها همراه کد موتور، تصویری از شرایط لحظه ثبت خطا ذخیره میشود که ممکن است دور، دما، بار یا سرعت را نشان دهد. این داده علت قطعی را تعیین نمیکند، اما کمک میکند بدانیم خطا در چه شرایطی رخ داده است. وضعیت آزمونهای داخلی آلایندگی نیز ممکن است پس از قطع باتری یا پاک‌کردن خطا کامل نباشد.
| یافته | برداشت محتاطانه | اقدام بعدی |
|---|---|---|
| کد همراه داده لحظه ثبت | شرایط رخداد بهتر قابل بازسازی است | نشانه فیزیکی و داده زنده در همان شرایط تطبیق شود |
| چند مانیتور ناقص | ممکن است پاک‌شدن اخیر، قطع باتری یا کامل‌نشدن چرخه مطرح باشد | سابقه تعمیر، باتری و امکان رانندگی تکمیلی بررسی شود |
| همه مانیتورها کامل اما بدون کد | در حوزه قابل‌خواندن نشانه جاری ثبت نشده است | سلامت مکانیکی و سایر واحدها همچنان مستقل بررسی شوند |
| داده در دسترس نیست | محدودیت خودرو، ابزار یا سطح دسترسی محتمل است | نبود داده به‌صورت «سالم» تفسیر نشود |
مانیتورهای آمادگی چگونه احتمال پاکسازی اخیر را ارزیابی می‌کنند؟
Readiness نشان میدهد آزمونهای خودکار قابل پشتیبانی در سامانه آلایندگی، پس از پاکسازی یا قطع تغذیه، شرایط لازم را طی کرده‌اند یا نه. «Not Ready» میتواند با پاک‌شدن حافظه سازگار باشد، اما به‌تنهایی زمان و علت را قطعی نمیکند؛ شرایط رانندگی، دما، سطح سوخت، نوع سامانه و خرابی فعال نیز روی تکمیل آزمون‌ها اثر دارند.
| مشاهده | برداشت قابل بررسی | اقدام تکمیلی |
|---|---|---|
| چند مانیتور پشتیبانی‌شده ناتمام است | امکان پاکسازی یا قطع باتری مطرح است | ثبت زمان، مسافت ادعاشده و وضعیت کدها؛ بدون تعیین تاریخ قطعی |
| یک مانیتور خاص ناتمام مانده است | ممکن است شرایط اجرای همان آزمون فراهم نشده باشد | بررسی الزامات همان مدل و وجود کد فعال یا Pending |
| همه مانیتورهای قابل پشتیبانی کامل‌اند | برخی چرخه‌های لازم طی شدهاند | نبود ایراد مکانیکی یا خطای غیرفعال را ثابت نمیکند |
| ابزار مانیتوری را Unsupported نشان میدهد | سامانه یا خودرو ممکن است آن آزمون را پشتیبانی نکند | Unsupported با Not Ready اشتباه نشود |
قواعد معاینه یا تعداد مجاز مانیتور ناتمام میتواند با بازار، سال و سامانه متفاوت باشد؛ در کارشناسی خرید، هدف ثبت وضعیت و سازگاری شواهد است، نه اعلام قبولی قانونی بدون مرجع.
Freeze Frame را چگونه بدون نتیجه‌گیری بیش از حد بخوانیم؟
Freeze Frame تصویری از بخشی از داده‌ها هنگام ثبت یک رویداد است. همه واحدها، کدها و ابزارها داده یکسانی ارائه نمی‌کنند و ممکن است فقط یک فریم عمومی یا چند رکورد سازنده در دسترس باشد.
| فیلد نمونه | پرسش تفسیری | محدودیت |
|---|---|---|
| دور موتور و سرعت | رویداد در توقف، شتاب یا حرکت رخ داده است؟ | شرایط کامل مسیر و رفتار راننده را نشان نمی‌دهد |
| بار موتور و دریچه گاز | کد زیر بار یا بار کم ثبت شده است؟ | تعریف بار محاسبه‌شده با بار واقعی یکسان نیست |
| دمای آب و هوای ورودی | موتور سرد، در حال گرم‌شدن یا گرم بوده است؟ | حسگر نادرست میتواند خود داده زمینه‌ای را مخدوش کند |
| Fuel Trim یا وضعیت حلقه | سامانه در چه حالت کنترلی بوده است؟ | یک عکس لحظه‌ای روند و علت را ثابت نمیکند |
| ولتاژ واحد | شرایط تغذیه هنگام رخداد مناسب بوده است؟ | ولتاژ گزارش‌شده محل دقیق افت یا سلامت باتری را قطعی نمیکند |
فریم باید با وضعیت فعلی، داده زنده و امکان بازتولید ایمن نشانه مقایسه شود. پاک‌شدن یا نبود Freeze Frame نیز به‌تنهایی اثبات‌کننده دستکاری نیست.
چک‌لیست درست استفاده از دیاگ هنگام خرید
- پیش از پاک‌کردن هر خطا، کدها و وضعیت آن‌ها ثبت شوند.
- ولتاژ باتری و شرایط روشن یا خاموش‌بودن موتور هنگام خواندن اطلاعات مشخص باشد.
- داده‌های زنده در حالت سرد، دور آرام و دمای کاری مقایسه شوند.
- در صورت امکان، پس از تست رانندگی اسکن دوباره انجام شود.
- هر کد خطا با نشانه‌های فیزیکی، صدای موتور و رفتار خودرو تطبیق داده شود.
- نتیجه دیاگ کنار بررسی رنگ، بدنه، شاسی و تست فنی قرار گیرد.
ولتاژ باتری چگونه نتیجه دیاگ را تغییر میدهد؟
ولتاژ پایین هنگام استارت یا تغذیه ناپایدار میتواند باعث ریست واحد، خطای ارتباطی و ثبت کدهای متعدد شود. این وضعیت دلیل نادیده‌گرفتن همه کدها نیست؛ باید مشخص شود کدام کد با افت ولتاژ هم‌زمان بوده، پس از تثبیت تغذیه بازمی‌گردد یا با نشانه فیزیکی همراه است.
- ولتاژ از داده واحد، اندازه‌گیری مستقیم یا هر دو منبع با ذکر روش ثبت شود.
- تعویض یا قطع اخیر باتری با Readiness، ساعت و تنظیمات خودرو تطبیق داده شود.
- کدهای شبکه در چند واحد بر اساس زمان، وضعیت و ترتیب رخداد کنار هم دیده شوند.
- پاک‌کردن گروهی کدها پیش از حفظ گزارش اولیه انجام نشود.
- اگر ابزار حین اسکن باعث افت تغذیه یا ارتباط ناپایدار میشود، محدودیت ابزار ثبت شود.
داده زنده را با «معقول‌بودن» شروع کنید، نه با عدد جادویی
حدود طبیعی بسیاری از داده‌ها به موتور، دما، ارتفاع، سوخت، بار و منطق سازنده وابسته است. پیش از مقایسه با یک عدد عمومی، باید سنسورها با شرایط واقعی و با یکدیگر سازگار باشند.
| گروه داده | کنترل معقول‌بودن | نیاز به تطبیق |
|---|---|---|
| دمای آب و هوای ورودی پیش از استارت | پس از توقف کافی معمولاً باید با شرایط محیط ناسازگاری آشکار نداشته باشند | مدت توقف، محل سنسور و گرمای باقی‌مانده |
| فشار یا جریان هوای ورودی | تغییر آن با دور و بار دنبال شود | نوع سنسور، نشتی هوا و ارتفاع محل |
| اصلاح سوخت و حسگر اکسیژن | روند و واکنش در حالت‌های مناسب بررسی شود | دمای کار، حلقه کنترل، سوخت و نشتی |
| شمارنده بدسوزی | واحد، بازه و شرایط افزایش ثبت شود | همه خودروها دسترسی یا معنای یکسان ندارند |
| دمای گیربکس و وضعیت دنده | با استارت سرد، گرم‌شدن و رفتار واقعی هماهنگ باشد | نوع گیربکس، منطق سازنده و دامنه ابزار |
خط زمانی اسکن از سرد تا گرم
- پیش از استارت: ولتاژ، دماها، وضعیت مانیتورها و کدهای اولیه ثبت شوند.
- لحظه استارت: افت تغذیه، دور اولیه، چراغ‌ها و برقراری ارتباط واحدها مشاهده شود.
- دور آرام سرد: داده‌های پایه و تغییرات غیرعادی بدون شتاب‌دادن بی‌مورد ثبت شوند.
- گرم‌شدن: روند دما، کنترل سوخت و فعال‌شدن سامانه‌ها دنبال شود.
- رانندگی کنترل‌شده: داده‌های مجاز موتور و گیربکس با رفتار واقعی تطبیق داده شوند.
- پس از توقف: اسکن دوباره برای کدهای برگشته، Pending و اختلاف با مرحله اول انجام شود.
این خط زمانی باید با کارشناسی فنی سرد و گرم خودرو هماهنگ باشد؛ اسکن جدا از مشاهده و رانندگی، بخش مهمی از زمینه تشخیص را از دست میدهد.
از کد خطا تا علت؛ نام قطعه را با تشخیص اشتباه نگیرید
متن دستگاه معمولاً مدار، سامانه یا شرطی را معرفی میکند که واحد کنترل تشخیص داده است. مسیر علت میتواند از قطعه، سیمکشی، کانکتور، تغذیه، نشتی، شرایط مکانیکی یا حتی داده واحد دیگر عبور کند. بنابراین گزارش نباید کد را مستقیماً به تعویض قطعه تبدیل کند.
- واحد و کد: نام واحد، شماره کامل کد و وضعیت جاری، موقت یا تاریخی ثبت شود.
- شرایط رخداد: داده لحظه ثبت و وضعیت سرد یا گرم بررسی شود.
- نشانه فیزیکی: صدا، بو، نشتی، لرزش، چراغ یا رفتار رانندگی تطبیق داده شود.
- مسیر مشترک: تغذیه، اتصال بدنه، شبکه و سیمکشی پیش از محکوم‌کردن قطعه دیده شوند.
- آزمون تأییدی: فقط آزمون مجاز و متناسب با راهنمای همان خودرو پیشنهاد شود.
- سطح اطمینان: یافته قطعی، علت محتمل و موضوع نیازمند بررسی جدا نوشته شوند.
خطاهای کنیستر و EVAP را چگونه تفسیر کنیم؟
کد EVAP ناحیه یا نوع ناسازگاری را نشان میدهد و به‌تنهایی حکم تعویض کنیستر نیست. وضعیت فعال یا تاریخی، Freeze Frame، آماده‌بودن مانیتور و شواهد بوی سوخت باید کنار هم خوانده شوند. جزئیات در راهنمای سیستم کنیستر، شیر پرج و خطای EVAP آمده است.
دیاگ موتور و گیربکس چگونه با رانندگی تطبیق داده شود؟
| سامانه | داده یا کد قابل‌بررسی | نشانه فیزیکی مکمل | محدودیت |
|---|---|---|---|
| موتور و سوخت | دمای مایع، اصلاح سوخت، فشار یا وضعیت حسگرهای قابل‌دسترسی | استارت، دود، لرزش، بو، صدا و نشتی | نبود کد، فشار مکانیکی و فرسودگی را رد نمیکند |
| خنک‌کاری | دمای گزارش‌شده و فرمان برخی عملگرها | سطح مایع، نشتی، فن، بخاری و رفتار دما | عدد یک لحظه، رفتار زیر بار را کامل نشان نمی‌دهد |
| گیربکس اتوماتیک | کدها، دما و بعضی پارامترهای تعویض در مدل سازگار | تأخیر درگیری، ضربه، لغزش و تفاوت سرد و گرم | رفتار مکانیکی ممکن است بدون کد باقی بماند |
| ABS و ترمز | کد حسگر، تغذیه یا ارتباط در واحد قابل‌دسترسی | چراغ، پدال، صدا، انحراف و وضعیت ناحیه چرخ | اسکن جای آزمون ایمن ترمز و بازدید فیزیکی نیست |
برای تفسیر رفتار واقعی موتور و گیربکس، صفحه کارشناسی فنی خودرو پیش از خرید را در کنار دیاگ بخوانید. اگر مشکل به نوع صدا وابسته است، داده الکترونیکی فقط یکی از سرنخ‌هاست.
داده زنده گیربکس چگونه با رفتار رانندگی تطبیق داده میشود؟
در صورت پشتیبانی خودرو و ابزار، دنده درخواستی و واقعی، دور ورودی و خروجی، دمای سیال، وضعیت قفل مبدل و داده‌های تطبیقی باید دقیقاً هنگام رخداد ثبت شوند. یک عدد منفرد یا نبود کد خطا سلامت گیربکس را ثابت نمیکند؛ تأخیر، لغزش، Flare، لرزش و تعویض خشن باید با زمان، دما و بار مقایسه شوند.
راهنمای کارشناسی گیربکس اتوماتیک قبل از خرید آزمون سرد و گرم AT، CVT، DCT و e-CVT را به داده TCM و بازدید مکانیکی متصل میکند. اگر خطاها یا تطبیق‌ها تازه پاک شده باشند، این محدودیت باید پیش از تصمیم مالی ثبت شود.
خطای ارتباط با واحد کنترل چه معنایی دارد؟
عبارت «عدم ارتباط» میتواند به انتخاب نرم‌افزار نامناسب، خاموش‌بودن واحد، مشکل تغذیه، شبکه، سیمکشی، فیوز، تغییرات قبلی یا محدودیت ابزار مربوط باشد. نبود پاسخ، نبود خطا یا سلامت واحد را ثابت نمیکند. ابتدا باید مشخص شود آیا آن واحد اصولاً در این تیپ وجود دارد و دستگاه برای آن پشتیبانی معتبر دارد.
سطح ابزار و دسترسی را در گزارش مشخص کنید
| سطح دسترسی | کاربرد | محدودیت مهم |
|---|---|---|
| OBD عمومی | بخشی از داده و کدهای استاندارد آلایندگی | پوشش همه واحدهای بدنه، گیربکس یا SRS را تضمین نمیکند |
| اسکن چندواحدی | خواندن واحدهای بیشتری با پروفایل خودرو | نام و عمق داده به ابزار و مجوز وابسته است |
| دسترسی سازنده یا تخصصی | داده، آزمون یا رویه‌های ویژه همان برند | نیازمند دانش، اشتراک و انتخاب دقیق تیپ است |
| آزمون فعال یا دوطرفه | فرمان محدود به عملگر برای تشخیص تخصصی | اجرای ناآگاهانه میتواند خطر یا تغییر وضعیت ایجاد کند و برای هر بازدید لازم نیست |
در خرید خودرو هدف بیشترین تعداد منو نیست؛ هدف ثبت شواهد مرتبط با ریسک معامله بدون تغییر تنظیمات، کدنویسی یا اجرای آزمون ناایمن است.
بسته تحویل گزارش دیاگ چه اجزایی دارد؟
- شناسه خودرو و پروفایل انتخاب‌شده در ابزار
- زمان، دما، ولتاژ و مرحله سرد یا گرم اسکن
- فهرست واحدهای اسکن‌شده، پاسخ‌داده و بدون ارتباط
- کد، وضعیت Stored/Pending/Active و متن دقیق ابزار
- Freeze Frame، Readiness و داده زنده مرتبط در صورت دسترسی
- تطبیق با نشانه فیزیکی، رانندگی و سوابق تعمیر
- محدودیت ابزار و اقدام بعدی بدون حکم تعویض قطعه از روی نام کد
خروجی تصویری یا فایل اسکن باید قبل و بعد از هر اقدام مجاز جدا نگهداری شود تا کد اولیه با نتیجه پس از رانندگی یا بررسی تکمیلی اشتباه نشود.
گزارش دیاگ قابل استفاده باید چه اجزایی داشته باشد؟
| جزء گزارش | نمونه ثبت دقیق | عبارت نامناسب |
|---|---|---|
| دامنه | واحدهای خوانده‌شده و واحدهای بدون دسترسی | «فول دیاگ شد» بدون فهرست |
| شرایط | سرد یا گرم، روشن یا خاموش، پیش یا پس از رانندگی | عدد بدون زمان و وضعیت |
| کد | شماره کامل، واحد و وضعیت کد | فقط نام احتمالی قطعه |
| داده | مقدار، واحد اندازه‌گیری و شرایط ثبت | «اعداد نرمال بود» بدون شاهد |
| تطبیق | ارتباط با چراغ، صدا، نشتی یا رانندگی | نتیجه صرفاً بر پایه نمایشگر |
| محدودیت | واحد پشتیبانینشده، نبود رانندگی یا پاک‌شدن قبلی | تبدیل بخش بررسی‌نشده به سلامت |
| اقدام بعدی | بازبینی، آزمون تخصصی یا توقف پرداخت تا رفع ابهام | پیشنهاد تعویض قطعه بدون تشخیص |
ماتریس تصمیم؛ کدام نتیجه برای معامله مهم‌تر است؟
| وضعیت | سطح ریسک | اقدام پیش از تصمیم مالی |
|---|---|---|
| اسکن کامل دامنه توافق‌شده، بدون کد و بدون نشانه متناقض | در همان دامنه، نشانه الکترونیکی فعالی دیده نشده | کارشناسی مکانیکی، بدنه، شاسی و مدارک ادامه یابد |
| کد تاریخی با علت و تعمیر مستند و بدون بازگشت | نیازمند تطبیق سابقه و شرایط فعلی | مدرک، اسکن مجدد و آزمون مرتبط بررسی شود |
| کد جاری، چراغ هشدار یا رفتار ناسازگار | ابهام فنی فعال | تشخیص تکمیلی پیش از قیمت‌گذاری یا پرداخت |
| عدم ارتباط با واحد مهم | دامنه بررسی ناقص | ابزار سازگار، بررسی تغذیه یا متخصص همان سامانه |
| نشانه پاکسازی اخیر همراه با پاسخ مبهم | سابقه الکترونیکی قابل اتکا نیست | چرخه آزمون مناسب و اسکن مجدد در صورت امکان |
وقتی نتیجه دیاگ با رفتار موتور یکسان نیست چه کنیم؟
نبود کد خطا، سلامت مکانیکی موتور را ثابت نمیکند و وجود یک کد نیز نام قطعه معیوب را قطعی نمی‌سازد. اگر لرزش، دود، نشتی، تغییر صدا یا رفتار غیرعادی در استارت سرد و گرم با نتیجه اسکن همخوان نیست، تصمیم پرداخت باید تا تکمیل کارشناسی فنی موتور از استارت سرد تا بازبینی گرم متوقف بماند. گزارش باید تعارض میان مشاهده مکانیکی و داده الکترونیکی را صریح ثبت کند.
تفاوت دیاگ با کارشناسی کامل خودرو
دیاگ یکی از ابزارهای کارشناسی است، نه کل کارشناسی. در یک بررسی کامل، وضعیت بدنه و رنگ، شاسی و ستون‌ها، موتور، گیربکس، تعلیق، ترمز، تجهیزات و رفتار خودرو در تست رانندگی کنار داده‌های الکترونیکی ارزیابی می‌شوند. صفحه کارشناسی خودرو در محل دامنه کلی خدمات را توضیح میدهد و برای آگاهی از عوامل هزینه نیز می‌توانید راهنمای هزینه کارشناسی خودرو را بخوانید.
آیا دیاگ میتواند علت صدای خودرو را مشخص کند؟
دیاگ صدا را تحلیل نمیکند و بسیاری از ایرادهای مکانیکی کد خطا ندارند. با این حال داده‌های موتور، گیربکس یا سامانه‌های کنترلی می‌توانند در کنار شرایط ایجاد صدا به محدودکردن دامنه علت کمک کنند. برای دسته‌بندی صداها و تشخیص موارد نیازمند توقف، راهنمای تشخیص صدای خودرو را ببینید.
برای بررسی دقیق‌تر این موضوع، راهنمای تشخیص دستکاری کیلومتر خودرو روش تطبیق داده‌های دیاگ با سوابق سرویس، فرسودگی و وضعیت فنی را توضیح میدهد.
دیاگ ایربگ و SRS پیش از خرید چه اطلاعاتی میدهد؟
دیاگ سامانه SRS میتواند کدهای خطای قابل‌دسترسی، وضعیت ارتباط واحد کنترل و در بعضی خودروها داده‌های مرتبط با مدارها یا رویداد ثبت‌شده را نشان دهد. دامنه اطلاعات به مدل خودرو، نسخه نرم‌افزار و سازگاری دستگاه بستگی دارد. بنابراین نتیجه «بدون خطا» فقط وضعیت قابل‌مشاهده در همان لحظه و همان سطح دسترسی را توصیف میکند و تأیید قطعی وجود یا سلامت همه ایربگ‌ها نیست.
| نوع یافته دیاگ | چه برداشتی می‌توان داشت؟ | چه چیزی ثابت نمی‌شود؟ |
|---|---|---|
| خطای مدار یا مقاومت | نیاز به بررسی کانکتور، سیمکشی یا جزء مرتبط مطرح میشود | محل عیب فقط از متن عمومی کد قطعی نمی‌شود |
| خطای ولتاژ یا تغذیه | وضعیت باتری، اتصال بدنه و تغذیه واحد باید بررسی شود | به‌تنهایی بازشدن ایربگ را نشان نمی‌دهد |
| خطای ارتباط | دسترسی به واحد یا شبکه خودرو کامل نیست | نبود پاسخ را نباید معادل نبودن خطا دانست |
| کد تاریخی یا ذخیره‌شده | رویداد گذشته یا عیب متناوب محتمل است | شدت تصادف و کیفیت تعمیر فقط با کد مشخص نمی‌شود |
| بدون کد قابل‌خواندن | در سطح دسترسی فعلی خطایی گزارش نشده است | اصالت قطعات، پاک‌نشدن سابقه و سلامت کامل تضمین نمی‌شود |
چرا چراغ SRS و نتیجه دیاگ باید کنار هم دیده شوند؟
رفتار چراغ هشدار در مدل‌های مختلف متفاوت است و باید با دفترچه همان خودرو مقایسه شود. روشن‌ماندن، روشن‌شدن دوباره یا اصلاً روشن‌نشدن چراغ هنگام بازکردن سوییچ میتواند نیازمند بررسی باشد. از سوی دیگر، عملکرد ظاهراً عادی چراغ نیز جای خواندن واحد SRS و بازدید فیزیکی را نمی‌گیرد.
آیا پاک‌کردن خطا مشکل ایربگ را حل میکند؟
پاک‌کردن کد فقط حافظه قابل‌پاک‌شدن را تغییر میدهد و علت اصلی را تعمیر نمیکند. اگر خطا بازگردد، متناوب باشد یا واحد پاسخ ندهد، باید علت با روش سازنده پیگیری شود. مقاومت‌گذاری، تغییر سیمکشی یا خاموش‌کردن چراغ راه تأیید سلامت سامانه نیست و در کارشناسی باید به‌عنوان محدودیت یا نشانه نیازمند بررسی ثبت شود.
روش شش‌مرحله‌ای تفسیر دیاگ ایربگ
- مدل، سال و مشخصات خودرو را برای انتخاب نرم‌افزار و پروتکل درست تطبیق دهید.
- رفتار چراغ هشدار را پیش از اتصال دستگاه مشاهده و ثبت کنید.
- ورود واقعی به واحد SRS را از اسکن عمومی سایر واحدها تفکیک کنید.
- کد، وضعیت کد و توضیح دستگاه را بدون نتیجه‌گیری عجولانه ثبت کنید.
- یافته‌ها را با قاب فرمان و داشبورد، کمربندها، پیش‌کشنده‌ها و آثار تصادف تطبیق دهید.
- اگر دسترسی ناقص یا شواهد متناقض است، نتیجه را مشروط به بررسی تخصصی بنویسید.
گزارش دیاگ ایربگ باید چه محدودیت‌هایی را بنویسد؟
گزارش مناسب نام واحد بررسی‌شده، امکان یا عدم امکان برقراری ارتباط، کدهای مشاهده‌شده، وضعیت چراغ و محدودیت دستگاه را جداگانه ذکر میکند. عبارت «در زمان بازدید کد جاری قابل‌مشاهده نبود» دقیق‌تر از «ایربگ کاملاً سالم است» است. اگر سابقه ضربه یا تعمیر بدنه وجود دارد، نتیجه باید با بررسی ایربگ و تشخیص خودرو تصادفی و وضعیت شاسی تطبیق داده شود.
چه زمانی بررسی تخصصی SRS لازم است؟
روشن‌ماندن چراغ، نبود ارتباط با واحد، کدهای بازگشتی، آثار بازشدن قاب‌ها، تعویض کمربند یا سابقه ضربه در ستون و شاسی از مواردی هستند که بررسی تخصصی را توجیه می‌کنند. در بازدید عادی نباید قاب ایربگ باز، کانکتورهای سامانه دستکاری یا مدار فعال‌ساز مستقیماً آزمایش شود؛ ادامه کار باید طبق دستورالعمل سازنده همان خودرو انجام شود.
برای ارزیابی فیزیکی تسمه، قفل، جمع‌کننده، نقاط اتصال و نشانه‌های فعال‌شدن پیش‌کشنده، راهنمای بررسی کمربند و پیش‌کشنده خودرو پیش از خرید را نیز ببینید؛ دیاگ فقط یکی از منابع تصمیم است.
دیاگ و بررسی کیلومتر؛ به‌جای یک عدد، زنجیره شواهد بسازید
در برخی خودروها مسافت، ساعت کار، شمارنده سرویس یا داده مرتبط در یک یا چند واحد دیده میشود؛ در برخی دیگر چنین داده‌ای در دسترس نیست یا معنای آن با کیلومتر صفحه آمپر یکسان نیست. اختلاف نیز باید با تعویض واحد، تعمیر، برنامه‌ریزی، سوابق و فرسودگی تطبیق داده شود.
- عدد صفحه آمپر و تاریخ مشاهده ثبت شود.
- واحد و نام دقیق داده قابل‌دسترسی نوشته شود.
- سوابق سرویس، فاکتور، معاینه و تاریخ‌های قابل اتکا کنار هم قرار گیرند.
- فرسودگی کابین و وضعیت فنی فقط به‌عنوان شاهد مکمل استفاده شوند.
- نتیجه با درجه اطمینان نوشته شود، نه ادعای عدد قطعی بدون منبع.
راهنمای تشخیص دستکاری کیلومتر خودرو روش تطبیق این شواهد را کامل میکند.
صورتبرداری ماژول‌ها؛ «اسکن کامل» را با فهرست پاسخ‌ها ثابت کنید
عبارت «دیاگ کامل انجام شد» بدون فهرست واحدهای مورد انتظار و پاسخدهنده قابل بازبینی نیست. یک جلسه حرفه‌ای ابتدا تیپ دقیق خودرو و تجهیزات نصب‌شده را مشخص میکند، سپس نتیجه شناسایی خودکار شبکه را با واحدهای محتمل همان خودرو تطبیق میدهد. نبود نام یک واحد ممکن است به‌دلیل تجهیزنبودن خودرو، انتخاب تیپ اشتباه، محدودیت ابزار، افت ولتاژ، مشکل شبکه یا خرابی همان واحد باشد.
| ستون صورتبرداری | چه چیزی ثبت شود؟ | برداشت مجاز |
|---|---|---|
| واحد مورد انتظار | نام سامانه بر اساس تیپ، تجهیزات و شواهد فیزیکی خودرو | فقط نشان میدهد بررسی حضور یا دسترسی لازم است |
| واحد پاسخدهنده | نام کامل، شناسه نرم‌افزار یا قطعه در صورت نمایش و وضعیت ارتباط | پاسخ‌دادن به معنی سلامت کامل سامانه نیست |
| بدون پاسخ | زمان، ولتاژ، ابزار، مسیر انتخاب‌شده و کدهای ارتباطی واحدهای دیگر | نبود پاسخ باید علت‌یابی شود؛ «بدون خطا» نیست |
| پشتیبانینشده | پیام دقیق ابزار و سطح مجوز یا نرم‌افزار | محدودیت ابزار از وضعیت خودرو جدا می‌ماند |
| واحد ناشناخته یا اضافی | شناسه، رابطه با تجهیزات نصب‌شده و سابقه تعویض احتمالی | سرنخ برای کنترل کدنویسی یا قطعه؛ نه حکم قطعی |
اسکن عمومی OBD موتور، اسکن شبکه همه واحدها و دسترسی تخصصی سازنده سه دامنه متفاوت‌اند. گزارش باید دقیقاً بنویسد کدام سطح انجام شده و چه واحدهایی خارج از دسترس مانده‌اند.
Snapshot پیش از پاکسازی؛ بسته خام جلسه دیاگ چه اجزایی دارد؟
پیش از پاک‌کردن کد، قطع باتری، اجرای Reset یا آغاز آزمون دوطرفه، وضعیت اولیه باید به شکلی ثبت شود که بعداً با جلسه دوم مقایسه شود. عکس چند کد بدون نام واحد و زمان کافی نیست.
- هویت جلسه: خودرو، تیپ، تاریخ، وضعیت سوئیچ، دمای تقریبی موتور و ولتاژ ثبت شود.
- فهرست شبکه: واحدهای پاسخدهنده، بدون پاسخ و پشتیبانینشده در یک خروجی نگهداری شوند.
- کدها: شماره کامل، متن ابزار، وضعیت Current/Pending/History/Permanent و واحد مالک کد ثبت شود.
- زمینه رویداد: Freeze Frame، شمارنده رخداد، مسافت یا زمان از آخرین پاکسازی فقط با نام و واحد دقیق ذخیره شود.
- وضعیت آمادگی: Supported، Ready و Not Ready از هم جدا و زمان مشاهده نوشته شود.
- نسخه خام: فایل خروجی یا تصاویر کامل بدون ویرایش حفظ و تفسیر کارشناسی در نسخه جدا افزوده شود.
اگر داده‌ای قابل‌استخراج نیست، همان محدودیت نوشته شود. نبود Snapshot اجازه نمی‌دهد زمان پاکسازی یا تاریخچه حذف‌شده بازسازی شود و باید در سطح اطمینان گزارش اثر بگذارد.
مالک هر داده کدام واحد است و چرا این موضوع اهمیت دارد؟
ممکن است ابزار یک مقدار را زیر منوی موتور نمایش دهد، اما داده از واحد دیگری روی شبکه آمده باشد؛ یا چند منو یک منبع مشترک را تکرار کنند. نام محل نمایش با منشأ تولید داده یکسان فرض نمی‌شود. این موضوع در کیلومتر، سرعت چرخ، زاویه فرمان، دمای سامانه و وضعیت ترمز اهمیت ویژه دارد.
| پرسش | کنترل لازم | خطای رایج |
|---|---|---|
| کدام واحد کد را ذخیره کرده؟ | نام واحد مالک کد و وضعیت ارتباط همان واحد | نسبت‌دادن هر کد به ECU موتور |
| داده مستقیم است یا شبکه‌ای؟ | تعریف پارامتر در همان مدل و مقایسه با منبع فیزیکی | شمردن یک داده تکرارشده به‌عنوان چند شاهد مستقل |
| مقدار خام است یا تبدیل‌شده؟ | واحد، مقیاس، نام پارامتر و تنظیمات ابزار | مقایسه کیلومتر با مایل یا مقدار محاسباتی |
| واحد تعویض یا برنامه‌ریزی شده؟ | شناسه قطعه، نسخه نرم‌افزار، فاکتور و تاریخ تعمیر | تعبیر اختلاف داده به دستکاری قطعی |
| آیا مقدار در همان لحظه معتبر است؟ | وضعیت سوئیچ، موتور، دما، ولتاژ و امکان بازتولید | قضاوت از یک نمونه خارج از شرایط آزمون |
برای بررسی اختصاصی اختلاف کارکرد، صفحه تشخیص دستکاری کیلومتر و تعارض داده ماژول‌ها را ببینید. داده الکترونیکی باید کنار وضعیت فیزیکی و سوابق تعمیر خوانده شود.
اعتبارسنجی تعمیر؛ پاک‌شدن کد به معنی رفع علت نیست
برای ارزیابی تعمیر ادعاشده، جلسه قبل و بعد باید قابل مقایسه باشد. حذف کد یا خاموش‌شدن چراغ تنها یک تغییر حافظه است و بدون بازگشت به شرایط ایجاد ایراد، موفقیت تعمیر را ثابت نمیکند.
| مرحله | ثبت لازم | معیار ادامه |
|---|---|---|
| خط مبنای قبل | Snapshot، نشانه فیزیکی، شرایط رخداد و محدودیت دسترسی | معلوم باشد دقیقاً چه ایرادی قرار است رفع شود |
| شرح اقدام | قطعه یا سیمکشی، تنظیم، برنامه‌ریزی، تاریخ و سند ارائه‌شده | ادعای تعمیر از نتیجه آزمون جدا بماند |
| اسکن اولیه پس از تعمیر | فهرست واحدها، کدهای جاری و تاریخی، ولتاژ و چراغ‌ها | واحد هدف پاسخ دهد و خطای فعال فوری روشن شود |
| بازآفرینی ایمن شرایط | استارت، گرم‌شدن، بار یا رانندگی فقط در محدوده ایمن و مجاز | شرایط مرتبط با ایراد قبلی تا حد ممکن تکرار شود |
| اسکن دوم | بازگشت کد، تغییر داده زنده، Readiness و نشانه فیزیکی | نتیجه به همان سامانه و همان آزمون محدود شود |
| خروجی | تأیید در دامنه آزمون، ایراد بازگشته، یا نیازمند آزمون تخصصی | از ضمانت آینده خودرو یا تعمیم به همه سامانه‌ها پرهیز شود |
برای خطاهای ABS و چراغ چک، راهنمای Snapshot، کدهای Permanent و آزمون پس از تعمیر و برای اتصال نتیجه به وضعیت خودرو، کارشناسی فنی پیش از خرید تکمیل‌کننده این مسیر هستند.
مرز خواندن داده با فرمان‌دادن به خودرو
خواندن کد و داده زنده با اجرای Active Test، کالیبراسیون، Reset Adaptation یا برنامه‌ریزی یکسان نیست. برخی فرمان‌ها می‌توانند موتور، فن، پمپ، ترمز پارک، دریچه یا اجزای دیگر را فعال کنند یا داده‌های تطبیقی را تغییر دهند. در کارشناسی پیش از خرید، اقدام تغییردهنده فقط با ضرورت روشن، ابزار سازگار، شرایط ایمن و اجازه مالک انجام میشود.
- پیش از هر فرمان، Snapshot خام و وضعیت خودرو حفظ شود؛
- نام دقیق آزمون، پیش‌شرط و اثر احتمالی آن مشخص باشد؛
- آزمون در محیط نامناسب، نزدیک افراد یا با دسترسی فیزیکی ناایمن اجرا نشود؛
- Reset یا کدنویسی برای «تمیزکردن گزارش» انجام نشود؛
- هر تغییر در گزارش با زمان، مسئول و نتیجه قابل بازگشت ثبت شود.
اگر انجام آزمون ریسک یا تغییر پایدار دارد، مسیر درست ارجاع تعمیرگاهی است. «قابل اجرا بودن» یک فرمان در دستگاه به معنی مناسب‌بودن آن برای جلسه معامله نیست.
باتری و تغذیه برق؛ خط مبنای دیاگ پیش از اولین استارت
بازکردن در، روشن‌شدن چراغ‌ها، فعال‌شدن Keyless و اتصال دستگاه میتواند شبکه خودرو را بیدار کند. بنابراین «ولتاژ قبل از استارت» فقط وقتی قابل مقایسه است که زمان و وضعیت بیداری واحدها ثبت شود. یک عدد منفرد روی نمایشگر، ظرفیت باتری، توان استارت و سلامت مسیر کابل‌ها را هم‌زمان ثابت نمیکند.
| مرحله | ثبت لازم | چه چیزی هنوز قطعی نیست؟ |
|---|---|---|
| پیش از بیدارکردن کامل | مدت توقف اعلام‌شده، دما، نوع دسترسی و مصرف‌کننده‌های فعال | ولتاژ یک لحظه‌ای، ظرفیت واقعی باتری را تعیین نمیکند |
| سوییچ باز | افت ولتاژ، چراغ‌ها، صدای رله‌ها و برقراری ارتباط ماژول‌ها | افت ممکن است از باتری، اتصال یا بار غیرعادی باشد |
| لحظه استارت | کمینه/شکل افت، سرعت چرخش، زمان درگیری و ریست واحدها | عدد بدون دما، روش ابزار و جریان استارت قابل تعمیم نیست |
| پس از روشن‌شدن | ولتاژ و جریان در زمان، دما، بار و فرمان شارژ | یک ولتاژ ثابت، سلامت کامل دینام و باتری را ثابت نمیکند |
اگر خودرو با باتری کمکی روشن شده است، همان رویداد قبل از پاکسازی کدها ثبت شود. جامپ‌استارت میتواند نشانه اصلی افت تغذیه را تغییر دهد و نتیجه جلسه باید میان «پیش از کمک» و «پس از تثبیت موقت» تفاوت بگذارد.
هویت باتری، وضعیت شارژ و وضعیت سلامت را با هم یکی نکنید
نوع باتری، ظرفیت نامی، فناوری AGM یا EFB، تاریخ یا کد تولید قابل خواندن، سابقه تعویض و سازگاری با سامانه مدیریت انرژی باید ثبت شوند. وضعیت شارژ فعلی با فرسودگی و توان ذخیره یکسان نیست؛ باتری فرسوده ممکن است بعد از شارژ سطحی ولتاژ مناسب نشان دهد ولی هنگام استارت یا بار افت کند.
- برچسب، ظرفیت و فناوری باتری با نیاز قابل استعلام همان خودرو تطبیق داده شوند؛
- نتیجه تستر همراه روش، دما و وضعیت شارژ ثبت شود؛ عبارت «باتری صددرصد سالم» بدون شرایط آزمون قابل بازبینی نیست؛
- آثار سولفاته‌شدن، شل‌بودن بست، تعمیر کابل و نشتی یا تورم ظاهری بررسی شوند؛
- در خودروهای دارای مدیریت باتری، ثبت یا تطبیق تعویض باتری و داده حسگر جریان بررسی شود؛
- قطع اخیر باتری با ساعت، تنظیمات، Readiness و کدهای کمولتاژ تطبیق داده شود.
در خودروهای هیبریدی یا برقی نیز شبکه کمولتاژ نقش راه‌اندازی واحدها را دارد، اما مدار ولتاژبالا خارج از بازدید عمومی است. کابل‌ها و قطعات دارای هشدار ولتاژبالا باز یا دستکاری نمی‌شوند و فقط به فرد آموزش‌دیده ارجاع می‌شوند.
استارت کند؛ باتری، استارتر یا افت مسیر کابل؟
استارت کند را نباید فوراً به باتری یا استارتر نسبت داد. دمای موتور، روغن، وضعیت مکانیکی، اتصال مثبت، اتصال بدنه، رله/فرمان و خود استارتر همگی روی سرعت چرخش اثر دارند. هدف آزمون، ساختن زنجیره‌ای از ولتاژ، زمان و رفتار واقعی است.
| شاهد | کنترل هدفمند | خروجی ایمن |
|---|---|---|
| افت شدید هم‌زمان با چرخش کند | باتری زیر بار، مسیر مثبت و اتصال بدنه | افت تغذیه تأیید میشود؛ منشأ با تست مسیر محدود میشود |
| ولتاژ مناسب ولی چرخش کند | جریان استارت، اتصال‌ها و بار مکانیکی | باتری به‌تنهایی محکوم نمی‌شود |
| کلیک بدون چرخش | فرمان رله، ولتاژ روی استارتر و افت کابل | مسیر فرمان و مسیر قدرت جدا بررسی می‌شوند |
| ریست ساعت یا چند ماژول | کمینه تغذیه، بست‌ها، بدنه و کدهای Undervoltage | ریست با زمان استارت تطبیق داده میشود |
تست افت ولتاژ باید در همان مسیر و زیر بار انجام شود. اندازه‌گیری مقاومت روی مدار بی‌بار ممکن است اتصال ضعیفی را که فقط هنگام استارت افت می‌سازد پنهان کند. دسترسی به نقاط چرخان یا داغ باید ایمن باشد و اتصال کوتاه ابزار قابل قبول نیست.
دینام هوشمند؛ چرا یک عدد ثابت برای شارژ کافی نیست؟
در بسیاری از خودروهای جدید، ولتاژ شارژ با دما، وضعیت باتری، بار، کاهش سرعت و فرمان ECU تغییر میکند. بنابراین پایین یا بالا بودن لحظه‌ای ولتاژ بدون مشاهده فرمان شارژ و شرایط آزمون، خرابی دینام را ثابت نمیکند. یک گزارش مناسب روند را در چند وضعیت ثبت میکند.
| وضعیت آزمون | داده یا اندازه‌گیری | هدف |
|---|---|---|
| دور آرام با بار کم | ولتاژ باتری، جریان یا بار دینام و فرمان مدیریت انرژی | ثبت خط مبنا، نه حکم نهایی |
| افزایش بار مجاز | چراغ، فن، گرمکن قابل استفاده و تغییر ولتاژ/جریان | توان پاسخ و افت مسیر تغذیه |
| تغییر دور کنترل‌شده | روند شارژ، صدا، تسمه و نوسان | تفکیک رفتار مکانیکی و الکتریکی |
| ریپل | مولفه AC با ابزار و اتصال مناسب | سرنخ دیود یا خروجی ناپایدار؛ ابزار نامناسب میتواند گمراه کند |
| پس از خاموشی | افت یا بازیابی ولتاژ و مصرف‌کننده باقی‌مانده | بررسی پیوستگی خط مبنا و آغاز خواب شبکه |
صدای تسمه، پولی یا بلبرینگ باید کنار خروجی شارژ ثبت شود؛ صدای مکانیکی دینام با نقص الکتریکی یکسان نیست. برای تفکیک منشأ صدا، صفحه تشخیص صدای خودرو پیش از خرید تکمیل‌کننده است.
شجره کدهای کمولتاژ و خطای ارتباطی را بسازید
باتری ضعیف میتواند چند واحد را هم‌زمان دچار ریست یا خطای ارتباط کند، اما این توضیح اجازه حذف همه کدها را نمی‌دهد. باید مشخص شود کدام واحد کد را ذخیره کرده، وضعیت Current/History چیست، زمان یا شمارنده رخداد چه می‌گوید و پس از تثبیت تغذیه کدام خطا بازمی‌گردد.
- Snapshot اولیه: همه واحدها، کدهای ولتاژ و ارتباط، وضعیت سوئیچ و ولتاژ پیش از هر پاکسازی حفظ شوند.
- هم‌زمانی: کدهای چند واحد براساس Freeze Frame، شمارنده یا نشانه ریست گروه‌بندی شوند.
- منبع مشترک: باتری، بدنه، جعبه‌فیوز و تغذیه مشترک واحدهای درگیر بررسی شوند.
- تثبیت ایمن: پس از رفع یا پشتیبانی تغذیه، اسکن دوم بدون پاک‌کردن شواهد خام انجام شود.
- بازگشت: کدهای فعال یا برگشتی از کدهای تاریخی جدا شوند.
صفحه راهنمای گزارش کارشناسی خودرو روش نگهداری نسخه خام و اصلاحیه را توضیح میدهد. نتیجه نباید یک کد شبکه‌ای را بدون بررسی تغذیه و سیمکشی به تعویض ماژول تبدیل کند.
مصرف برق در حالت خاموش؛ زمان خواب شبکه را ثبت کنید
اندازه‌گیری مصرف خاموش بلافاصله پس از قفل‌کردن خودرو معمولاً نماینده خواب کامل نیست. بعضی واحدها، چراغ‌ها، ردیاب، سیستم صوتی و Keyless مدتی فعال می‌مانند و بازکردن در یا نزدیک‌شدن کلید میتواند شبکه را دوباره بیدار کند.
- زمان قفل، محل کلید، وضعیت درها و تجهیزات غیرفابریک ثبت شود؛
- جریان در طول زمان دیده شود، نه فقط یک عدد اولیه؛
- روش اندازه‌گیری نباید با قطع ناگهانی مدار، داده خواب یا حافظه را تغییر دهد؛
- در صورت باقی‌ماندن مصرف، شاخه‌یابی فیوز فقط در محیط مناسب و با اجازه مالک انجام شود؛
- نبود زمان کافی به‌صورت «آزمون خواب کامل نشد» گزارش شود.
این آزمون در بازدید کوتاه سیار ممکن است کامل نشود. وظیفه گزارش تعیین زمان مشاهده، روند و سؤال ارجاع است؛ نه ساختن نتیجه قطعی از چند دقیقه نخست.
اعتبارسنجی تعویض باتری، تعمیر دینام یا استارتر
| تعمیر اعلام‌شده | بازآزمایی لازم | خروجی محدود |
|---|---|---|
| تعویض باتری | هویت باتری، ثبت/تطبیق سامانه، استارت و اسکن کدهای ولتاژ | سازگاری و رفتار فعلی؛ نه تضمین عمر آینده |
| تعمیر یا تعویض دینام | روند شارژ در بار و دور، ریپل، صدا و افت کابل | عملکرد در شرایط آزموده‌شده |
| تعمیر استارتر | استارت سرد/گرم، زمان درگیری، افت ولتاژ و مسیر بدنه | رفع نشانه در شرایط بازپخش‌شده |
| رفع برق‌دزدی | زمان خواب، روند جریان و بازتولید شرایط پارک | نتیجه همان بازه؛ تجهیزات دوره‌ای باید جدا بررسی شوند |
نسخه قبل از تعمیر حذف نمی‌شود. گزارش دوم باید مشخص کند کدام شرایط بازپخش شده، چه داده‌ای تغییر کرده و چه بخشی به دلیل زمان یا دسترسی هنوز آزموده نشده است.
پیش از تحلیل، نوع سامانه هیبریدی یا برقی را دقیق مشخص کنید
برچسب Hybrid یا EV به‌تنهایی معماری باتری و مسیر انرژی را نشان نمی‌دهد. خودروی HEV، پلاگین‌هیبرید، برقی کامل یا هیبرید سبک میتواند ولتاژ، ظرفیت، شیمی، محل باتری و راهبرد خنک‌کاری متفاوتی داشته باشد. تیپ، VIN، واحدهای قابل‌دسترسی، شماره قطعه و چیدمان واقعی باید با هم تطبیق داده شوند.
| نوع سامانه | تمرکز کارشناسی | خطای رایج |
|---|---|---|
| هیبرید معمولی HEV | باتری کششی، موتور/ژنراتور، اینورتر و خنک‌کاری | رفت‌وآمد شارژ باتری در رانندگی لزوماً خرابی نیست |
| پلاگین‌هیبرید PHEV | باتری بزرگ‌تر، درگاه شارژ، OBC و کارکرد دو منبع انرژی | برد برقی ادعایی بدون دما و شرایط قابل مقایسه نیست |
| برقی BEV | پک، مدیریت حرارتی، شارژ AC/DC، اینورتر و موتور | عدد شارژ نمایشگر ظرفیت واقعی را به‌تنهایی ثابت نمیکند |
| هیبرید سبک | معماری 48V، استارتر/ژنراتور و DC/DC | با باتری کششی HEV یا BEV یکسان فرض میشود |
| محور برقی e‑AWD | باتری، اینورتر و موتور محور دوم در کنار انتقال قدرت | نبود میل‌گاردان به معنی نبود محور دوم نیست |
هیچ قاب، کابل نارنجی، Service Disconnect یا اتصال ولتاژ بالا در بازدید عمومی باز نمی‌شود. شناسایی سامانه برای تعیین داده‌ها و ارجاع ایمن است، نه مجوز دستکاری مدار.
SoC، SoH، ظرفیت قابل استفاده و مقاومت داخلی یک عدد واحد نیستند
SoC تخمین شارژ فعلی است؛ SoH برآوردی از وضعیت فرسودگی نسبت به مرجع تعریف‌شده همان سازنده است. ظرفیت قابل استفاده، ظرفیت اسمی، انرژی قابل تحویل، مقاومت و محدودیت توان نیز مفاهیم جدا هستند. درصد SoH از یک ابزار عمومی بدون نام پارامتر، نسخه نرم‌افزار و شرایط محاسبه، نتیجه قطعی نمی‌سازد.
| داده | زمینه لازم | محدودیت نتیجه |
|---|---|---|
| SoC | دما، زمان توقف، شارژ/دشارژ اخیر و روش BMS | شارژ فعلی با سلامت یا ظرفیت برابر نیست |
| SoH | تعریف سازنده، واحد گزارش‌دهنده و سابقه Reset/تعویض | درصد میان برندها قابل مقایسه مستقیم نیست |
| ظرفیت/انرژی تخمینی | دامنه SoC، دما، بارهای جانبی و روش آزمون | یک مسیر کوتاه ظرفیت کامل را اندازه نمی‌گیرد |
| مقاومت داخلی | دما، جریان، SoC و روش محاسبه | عدد منفرد بدون مرجع همان پک قابل حکم نیست |
| محدودیت توان | درخواست، دما، شارژ و کدهای فعال | کاهش لحظه‌ای توان میتواند راهبرد حفاظتی باشد |
اگر BMS یا پک تعویض یا بازبرنامه‌ریزی شده باشد، سابقه Reset و تطبیق شمارنده‌ها باید در کنار SoH خوانده شود. عدد «۱۰۰٪» بلافاصله پس از تعمیر، عمر آینده یا ظرفیت واقعی را تضمین نمیکند.
اختلاف بلوک یا سلول را در زمان، دما و بار بخوانید
یک Snapshot در حالت بی‌بار ممکن است اختلافی را که زیر بار یا شارژ ظاهر میشود پنهان کند. نامگذاری پارامترها میان خودروها متفاوت است و گاهی ابزار فقط ولتاژ بلوک را نشان میدهد، نه تک‌سلول. معیار مجاز باید از مرجع همان پک گرفته شود؛ حد ثابت عمومی برای همه شیمی‌ها و معماری‌ها معتبر نیست.
- شماره و ترتیب بلوک‌ها، کمینه، بیشینه و Spread همراه با SoC و دما ثبت شود.
- وضعیت کنتاکتورها، جریان باتری و محدودیت شارژ/دشارژ کنار ولتاژها خوانده شود.
- در شتاب یا بازیابی ملایم و ایمن، بلوکی که زودتر افت یا جهش میکند زمان‌دار ثبت شود.
- پس از توقف یا تغییر دما، برگشت ولتاژها با Snapshot اولیه مقایسه شود.
- کدهای Current، Pending و History بدون پاکسازی شواهد خام حفظ شوند.
| الگو | تفسیر محتاطانه | اقدام بعدی |
|---|---|---|
| Spread کم در سکون، افزایش زیر بار | ضعف نسبی یک بلوک محتمل است | تکرار در دما/SoC قابل مقایسه و مرجع همان پک |
| اختلاف دمای موضعی | خنک‌کاری، حسگر یا مقاومت داخلی مطرح است | مسیر هوا/مایع و داده چند حسگر بررسی شود |
| کد تاریخی بدون بازگشت | رویداد قبلی یا تعمیر ممکن است | Freeze Frame، سابقه و بازپخش ایمن لازم است |
| SoH مناسب ولی محدودیت توان | دما، خطای جانبی یا تعریف SoH کافی نیست | علت Derate در واحدهای مرتبط دنبال شود |
خنک‌کاری باتری؛ مسیر هوا یا مایع را با دمای سلول‌ها تطبیق دهید
پک‌های هواخنک به ورودی کابین، فیلتر، مجرا و فن وابسته‌اند؛ پک‌های مایع‌خنک به سطح و کیفیت سیال، پمپ، شیر، رادیاتور، Chiller و گاهی گرمکن نیاز دارند. صدای فن یا کارکرد پمپ فقط نشان میدهد فرمانی در حال اجراست و گردش مؤثر را به‌تنهایی ثابت نمیکند.
| سامانه | کنترل غیرمخرب | نشانه قابل پیگیری |
|---|---|---|
| هواخنک | ورودی، آلودگی، انسداد، صدای فن و چند دمای پک | افزایش اختلاف دما یا فن دائم با زمینه بار |
| مایع‌خنک | سطح قابل مشاهده، نشتی، پمپ/شیر و دمای ورود/خروج | دمای نامتوازن، کد جریان یا آثار تعمیر |
| Chiller مشترک با کولر | فرمان سامانه حرارتی و رفتار دمای پک | ضعف تهویه میتواند مدیریت باتری را محدود کند |
| گرمایش باتری | دما، توان محدود و فرمان گرمکن در شرایط مجاز | سرما و فرسودگی بدون زمینه از هم جدا نمی‌شوند |
ارتباط مدار تهویه و Chiller در راهنمای کارشناسی کولر و مدیریت حرارتی تکمیل میشود. بازکردن مدار مبرد یا خنک‌کننده ولتاژ بالا جزو بازدید سیار نیست.
HVIL، عایق و کنتاکتور؛ خطای ایمنی را با تعویض حدسی قطعه یکی نکنید
حلقه Interlock، مانیتور عایق، کنتاکتورهای اصلی، Pre‑charge و واحدهای کنترل برای جلوگیری از برقدارشدن ناایمن مدار کار می‌کنند. خطای Isolation یا HVIL میتواند از پک، کابل، کانکتور، اینورتر، کمپرسور برقی یا نفوذ مایع باشد و پاک‌کردن کد علت را رفع نمیکند.
| داده/نشانه | آنچه ثبت میشود | مرز ایمنی |
|---|---|---|
| Isolation DTC | واحد ثبت‌کننده، Freeze Frame، رطوبت و تعمیر اخیر | آزمون مستقیم فقط توسط فرد آموزش‌دیده و روش سازنده |
| HVIL Open | محل تعمیر، کانکتورهای قابل مشاهده و سابقه بازشدن | بای‌پس یا اتصال موقت حلقه ممنوع است |
| Pre‑charge/Contactor | فرمان، وضعیت، ولتاژهای گزارش‌شده و کدها | بازکردن پک یا تحریک دستی انجام نمی‌شود |
| Service Disconnect | وجود، پلمب/قاب و آثار دستکاری ظاهری | در بازدید عمومی خارج یا لمس نمی‌شود |
اگر بوی غیرعادی، صدای جوشش، داغی موضعی، تغییر شکل، دود، اخطار شدید یا نشتی در مجاورت اجزای HV دیده شود، آزمون متوقف و خودرو در وضعیت ایمن به مرکز تخصصی ارجاع میشود.
شارژ AC/DC و برد نمایشگر را به‌عنوان آزمون ظرفیت تفسیر نکنید
توان شارژ میتواند با SoC، دمای پک، دمای محیط، محدودیت ایستگاه، کابل، پیش‌شرط‌سازی و راهبرد حفاظتی تغییر کند. سرعت شارژ یک جلسه و برد تخمینی پشت آمپر برای اثبات ظرفیت کافی نیستند. در PHEV نیز بنزین، سبک رانندگی و استفاده از تهویه باید از بخش برقی جدا شوند.
| بخش | ثبت لازم | خطای نتیجه‌گیری |
|---|---|---|
| شارژ AC | ولتاژ/جریان، OBC، کابل، خطا و زمان | محدودیت برق محل به خرابی خودرو نسبت داده میشود |
| شارژ DC | SoC آغاز، دما، منحنی توان و خطاها | قله توان تبلیغاتی معیار همه شرایط فرض میشود |
| برد تخمینی | مصرف اخیر، دما، تهویه و SoC | عدد نمایشگر ظرفیت اندازه‌گیری‌شده تلقی میشود |
| بازده مسیر | انرژی تحویلی قابل دسترس، مسافت و بارهای جانبی | یک مسیر کوتاه یا پرترافیک به کل عمر تعمیم داده میشود |
پک زیرکف را با زیربندی، نفوذ آب و نقاط جک پیوند دهید
در بسیاری از خودروهای برقی، محفظه باتری بخشی بزرگ از زیر خودرو است. ضربه کف، جک‌زدن نامناسب، فرورفتگی کاور، پیچ متفاوت، درزگیر تازه یا خوردگی باید با مسیر ضربه و سابقه بازشدن تطبیق داده شوند. ظاهر صاف کاور، سلامت ماژول‌ها یا آب‌بندی داخل را ثابت نمیکند.
- نقاط جک و بالابر با مرجع همان خودرو انتخاب شوند و هیچ تکیه‌گاهی زیر پک قرار نگیرد.
- کاور، ریل‌های محافظ، پیچ‌ها، درزها و مسیر برخورد از جلو/عقب ثبت شوند.
- آثار آب، گل، نمک، شست‌وشوی تازه یا تعمیر در اطراف اتصالات با کدهای عایق تطبیق یابد.
- بازدید دقیق زیر خودرو به کارشناسی شاسی، نقاط جک و زیربندی متصل شود.
- در صورت سابقه آب‌گرفتگی، مسیر تشخیص نفوذ آب و خوردگی خودرو جدا اجرا شود.
اعتبارسنجی تعمیر باتری ولتاژ بالا؛ هویت قطعه و نسخه قبل/بعد را حفظ کنید
عبارت‌هایی مانند «سلول عوض شده»، «پک بالانس شده» یا «باتری نو است» بدون هویت قطعه و گزارش بازآزمایی کافی نیست. تعمیر ماژولی، تعویض کامل پک، تعویض BMS و اصلاح خنک‌کاری خروجی‌های متفاوتی دارند و هیچ ادعای عمر یا ضمانت بدون سند رسمی ساخته نمی‌شود.
| تعمیر ادعاشده | مدرک لازم | بازآزمایی |
|---|---|---|
| تعویض ماژول/بلوک | محل، شماره قطعه، علت، ولتاژ/ظرفیت و روش بالانس | Spread زیر بار، دما و کدهای بازگشتی |
| تعویض کامل پک | هویت پک، سازگاری تیپ، کارکرد/منشأ مستند و کدنویسی | شناخت BMS، شارژ/دشارژ و سامانه حرارتی |
| تعویض یا Reset BMS | نسخه نرم‌افزار، علت و داده‌های قبل از عملیات | معناداری SoH و شمارنده‌ها با سابقه تطبیق یابد |
| رفع خنک‌کاری | پمپ/فن/فیلتر/سیال و نشتی پیش از تعمیر | توزیع دما و محدودیت توان در شرایط نزدیک |
| رفع Isolation/HVIL | محل عیب، قطعه و روش ایمن | اسکن همه واحدها و آزمون تخصصی مستند |
گزارش نهایی میان «داده مشاهده‌شده»، «تعمیر ادعاشده»، «مدرک ارائه‌شده»، «بخش آزموده‌نشده» و «نیاز به ارجاع» تفاوت می‌گذارد. اسکن و ثبت منشأ داده طبق چارچوب دیاگ پیش از خرید انجام میشود.
مسیر انرژی را قبل از نامگذاری قطعه ترسیم کنید
در خودروی هیبریدی یا برقی، «روشن‌نشدن»، افت توان، شارژنشدن یا صدای غیرعادی میتواند از شبکه 12 ولت، باتری کششی، کنتاکتورها، اینورتر، موتور، شارژر داخلی یا مدار خنک‌کاری آغاز شود. تعویض حدسی یک قطعه گران‌قیمت بدون ثبت مسیر انرژی، تشخیص قابل دفاعی نیست. ابتدا نوع خودرو، وضعیت Ready، حالت شارژ، جهت جریان انرژی و واحد ثبت‌کننده خطا مشخص میشود.
| بخش | وظیفه اصلی | داده قابل پیگیری |
|---|---|---|
| باتری ولتاژ بالا | ذخیره و تحویل انرژی کششی | SoC، دما، جریان، ولتاژ و محدودیت توان |
| اینورتر | تبدیل DC باتری به AC موتور و برعکس در بازیابی | ولتاژ DC Link، دما، فرمان گشتاور و کدها |
| موتور/ژنراتور | تولید گشتاور یا بازیابی انرژی | دور، گشتاور درخواستی/واقعی، دما و موقعیت روتور |
| OBC | تبدیل برق AC ورودی به DC مناسب باتری | ولتاژ و جریان ورودی، توان خروجی، دما و خطای شارژ |
| DC/DC | تغذیه شبکه 12 ولت از سامانه ولتاژ بالا | ولتاژ 12V در Ready، بار، دما و فرمان مبدل |
| کنترلر شارژ/درگاه | مذاکره، قفل سوکت و مدیریت جلسه شارژ | وضعیت اتصال، Interlock، خطا و مرحله شارژ |
نام PID و دسترسی آن میان سازندگان یکسان نیست. نبود یک پارامتر در دیاگ عمومی، سلامت قطعه را ثابت نمیکند؛ همان‌طور که وجود یک کد تاریخی نیز بدون بازگشت و زمینه، حکم تعویض قطعه نیست.
اینورتر و موتور برقی را با فرمان، پاسخ و دما بسنجید
موتور الکتریکی میتواند در سکوت خودرو را حرکت دهد و در رهاسازی پدال نقش ژنراتور بگیرد. بنابراین نتیجه باید در چند وضعیت ثبت شود: Ready بدون حرکت، شتاب ملایم، بار ثابت، بازیابی و توقف گرم. اختلاف میان گشتاور درخواستی و واقعی فقط زمانی معنا دارد که وضعیت باتری، کنترل کشش، دما و محدودیت‌های حفاظتی نیز ثبت شده باشند.
| وضعیت آزمون | شاهد لازم | خطای رایج تفسیر |
|---|---|---|
| Ready و سکون | ولتاژ DC Link، وضعیت کنتاکتور، دمای اینورتر و هشدار | سکوت موتور با خاموش‌بودن سامانه اشتباه میشود |
| شتاب ملایم | گشتاور درخواستی/واقعی، جریان، دور موتور و Derate | محدودیت باتری به خرابی موتور نسبت داده میشود |
| بار ثابت | لرزش، صدا، دمای موتور/اینورتر و سرعت خودرو | صدای تایر یا گیربکس کاهنده به موتور نسبت داده میشود |
| بازیابی | توان منفی، SoC، دما و محدودیت Regen | کاهش بازیابی در شارژ بالا یا سرما خرابی تلقی میشود |
| Heat-soak | افزایش دما، عملکرد پمپ/فن و کد بازگشتی | فقط نسخه سرد ملاک سلامت قرار می‌گیرد |
صدای وابسته به سرعت خودرو از صدای وابسته به دور موتور جدا ثبت میشود. برای محور برقی عقب، مسیر کارشناسی AWD، موتور محور دوم و انتقال قدرت نیز باید بررسی شود.
OBC و درگاه شارژ؛ سمت برق محل را از سمت خودرو جدا کنید
شارژنشدن AC الزاماً خرابی OBC نیست. پریز یا ایستگاه، ارت، افت ولتاژ، کابل، قفل سوکت، زمانبندی شارژ، دمای پک و تنظیم محدودیت جریان می‌توانند جلسه را متوقف کنند. آزمون معتبر، یک متغیر را در هر مرحله تغییر میدهد و زمان، پیام خودرو و کدهای واحدهای مرتبط را حفظ میکند.
- نوع منبع، توان نامی ادعایی، کابل و وضعیت ظاهری سوکت ثبت شود.
- SoC، دمای باتری، محدودیت شارژ و زمانبندی داخل خودرو پیش از اتصال ثبت گردد.
- مراحل اتصال، قفل سوکت، مذاکره، شروع جریان و توقف احتمالی زمان‌دار شوند.
- ولتاژ و جریان گزارش‌شده در سمت ورودی و خروجی OBC با هم مقایسه شوند.
- کدهای OBC، کنترلر شارژ، BMS و شبکه بدنه بدون پاکسازی شاهد خوانده شوند.
| الگو | احتمال قابل پیگیری | نتیجه مجاز |
|---|---|---|
| شارژ با یک منبع، عدم شارژ با منبع دیگر | منبع، کابل، استاندارد یا تنظیمات مطرح است | OBC بدون آزمون متقاطع محکوم نمی‌شود |
| قفل‌نشدن سوکت | عملگر قفل، موقعیت سوکت یا کنترلر درگاه | واردکردن فشار یا بای‌پس قفل ممنوع است |
| شروع و قطع پس از گرم‌شدن | خنک‌کاری OBC، اتصال یا محدودیت حرارتی | زمان و دما برای بازپخش لازم است |
| شارژ DC سالم، AC ناموفق | مسیر OBC و ورودی AC پررنگ‌تر میشود | سلامت کامل باتری یا درگاه ثابت نمی‌شود |
بازکردن OBC، اندازه‌گیری مستقیم ولتاژ بالا یا دستکاری ارت و Interlock جزو کارشناسی عمومی نیست. آزمون تکمیلی برقی باید با تجهیزات و رویه سازنده انجام شود.
DC/DC و باتری 12 ولت؛ علت را در لحظه تغییر حالت پیدا کنید
شبکه 12 ولت حتی در خودروی برقی، قفل‌ها، کنترلرها و فرایند ورود به Ready را تغذیه میکند. باتری 12 ولت ضعیف میتواند خطاهای ارتباطی متعدد بسازد؛ در مقابل، مبدل DC/DC معیوب یا محدودشده نیز شارژ 12 ولت را مختل میکند. یک اندازه‌گیری در حالت خاموش برای جداکردن این دو کافی نیست.
| لحظه | ثبت لازم | تفسیر محتاطانه |
|---|---|---|
| خودرو خاموش | ولتاژ، زمان توقف و بارهای فعال | عدد بی‌بار ظرفیت یا توان استارت سامانه را قطعی نمیکند |
| Wake-up | افت ولتاژ، ریست نمایشگر و کدهای Undervoltage | افت لحظه‌ای میتواند منشأ خطاهای زنجیره‌ای باشد |
| ورود به Ready | افزایش ولتاژ، جریان 12V و وضعیت DC/DC | افزایش ولتاژ بدون آزمون بار سلامت کامل مبدل نیست |
| بار الکتریکی | چراغ، فن، گرمکن و افت/پایداری ولتاژ | محدودیت حفاظتی با خرابی دائم تفکیک شود |
| پس از توقف گرم | دما، خطای بازگشتی و رفتار راه‌اندازی مجدد | نسخه سرد به شرایط گرم تعمیم داده نشود |
مسیر پایه باتری کمولتاژ، افت ولتاژ و کدهای شبکه در بخش دیاگ باتری و برق خودرو حفظ شده است. نتیجه گزارش باید مشخص کند خطا از باتری 12V، فرمان DC/DC، بار مصرفی یا بخش آزموده‌نشده محتمل‌تر است.
خنک‌کاری مشترک؛ یک پمپ یا شیر میتواند چند سامانه را محدود کند
باتری، اینورتر، موتور، OBC و گاهی کمپرسور برقی ممکن است مدارهای جدا یا به‌هم‌پیوسته داشته باشند. سطح سیال، هواگرفتگی، پمپ، شیر چندراهه، رادیاتور و Chiller باید طبق معماری همان خودرو تفسیر شوند. روشن‌بودن پمپ یا نبود نشتی ظاهری، جریان کافی و انتقال حرارت مؤثر را ثابت نمیکند.
| شاهد | زمینه لازم | مسیر پیگیری |
|---|---|---|
| اختلاف دمای ورودی/خروجی | بار، زمان، فرمان شیر و دمای محیط | پمپ، گرفتگی، هوا یا حسگر بررسی شود |
| Derate پس از ترافیک یا شارژ | دمای باتری، اینورتر، موتور و OBC | منشأ محدودیت از روی چند واحد جدا شود |
| افت عملکرد کولر هم‌زمان | فرمان Chiller و کمپرسور برقی | مدیریت حرارتی و تهویه خودرو بررسی شود |
| سیال یا بست تازه | تاریخ تعمیر، نوع سیال و هواگیری | بازپخش گرم پس از تعمیر لازم است |
اختلاط سیال نامناسب، بازکردن مدار یا هواگیری بدون دستور سازنده انجام نمی‌شود. هر نشتی نزدیک اجزای ولتاژ بالا، کد عایق یا داغی غیرعادی باعث توقف آزمون و ارجاع تخصصی است.
کد خطا را در همه واحدهای مرتبط و به ترتیب رخداد بخوانید
کد ثبت‌شده در اینورتر میتواند پیامد افت 12 ولت، قطع ارتباط، دمای باتری یا خطای کنترل شارژ باشد. ترتیب زمانی، Current/Pending/History، Freeze Frame و شمارنده رخداد از متن کوتاه کد مهم‌ترند. پاک‌کردن کد پیش از ثبت، امکان تشخیص منشأ را کاهش میدهد.
| خانواده خطا | واحدهای همراه | شاهد تکمیلی |
|---|---|---|
| Over/Under Voltage | BMS، DC/DC، شبکه 12V و اینورتر | لحظه Wake-up، Ready و بار ثبت شود |
| Over Temperature | پمپ، شیر، فن، OBC و کنترل تهویه | بار و دما پیش از خطا بازسازی شود |
| Resolver/Position | موتور، اینورتر و دسته‌سیم | دور، گشتاور و تکرار در شرایط ایمن |
| Isolation/HVIL | پک، کابل، OBC، کمپرسور و درگاه | رطوبت، تعمیر یا ضربه اخیر مستند شود |
| Communication | Gateway، 12V و چند کنترلر | اولین واحد و زمان رخداد جدا شود |
اعتبارسنجی تعمیر اینورتر، OBC یا موتور؛ «خطا پاک شد» کافی نیست
تعمیر ادعایی باید به هویت قطعه، علت اولیه، نرم‌افزار، مدار خنک‌کاری و نسخه آزمون متصل باشد. قطعه استوک یا تعمیرشده بدون شماره فنی و سازگاری تیپ، مسیر آینده را مبهم میکند. هیچ عمر، ضمانت یا هزینه‌ای بدون سند رسمی در گزارش ساخته نمی‌شود.
| تعمیر ادعاشده | مدرک لازم | بازآزمایی |
|---|---|---|
| تعویض یا تعمیر اینورتر | شماره قطعه، علت، کدنویسی و وضعیت سیال | Ready، فرمان/پاسخ گشتاور، Regen و Heat-soak |
| تعویض موتور برقی | هویت موتور، گیربکس کاهنده و علت خرابی | صدا، لرزش، دما و عملکرد زیر بار/بازیابی |
| تعمیر OBC یا درگاه | نوع خطا، قطعه، کابل/سوکت و منبع آزمون | جلسه AC در شرایط ثبت‌شده و اسکن مجدد |
| تعویض DC/DC | کدها، علت، شبکه 12V و نسخه نرم‌افزار | خاموش، Wake-up، Ready و بار الکتریکی |
| رفع خنک‌کاری | پمپ/شیر/سیال، نشتی و روش هواگیری | توزیع دما و عدم بازگشت Derate در نسخه نزدیک |
خروجی به چهار دسته «تأیید شد»، «در شرایط آزمون تکرار نشد»، «داده ناکافی» و «نیازمند ارجاع تخصصی» تقسیم میشود. ایمنی ولتاژ بالا بر تکمیل آزمون اولویت دارد.
کارشناسی شبکه CAN و خطاهای U-code پیش از خرید خودرو
در خودروهای چندماژولی، روشن‌شدن چند چراغ یا ثبت چند U-code الزاماً به معنی خرابی هم‌زمان چند ECU نیست. یک افت ولتاژ هنگام استارت، اتصال بدنه ضعیف، بیدارشدن ناقص شبکه، اختلال Gateway، سوکت مرطوب یا یک شاخه معیوب میتواند چند واحد را در یک بازه زمانی درگیر کند. بنابراین گزارش دیاگ باید «کدام واحد خطا را گزارش کرده»، «ارتباط با کدام واحد از دست رفته» و «خطا در چه وضعیت برقی و زمانی ثبت شده» را جدا کند.
این بخش برای غربال پیش از خرید است و جای آزمون تهاجمی شبکه یا بازکردن دسته‌سیم را نمی‌گیرد. اندازه‌گیری مقاومت، شکل موج یا جداسازی شاخه فقط در محیط مجهز، با نقشه همان خودرو و رعایت ایمنی انجام میشود.
U-code دقیقاً چه نوع اطلاعاتی میدهد؟
U-code معمولاً به ارتباط بین واحدها، اعتبار پیام یا عملکرد شبکه مربوط است؛ اما متن کد نام قطعه معیوب نیست. «عدم ارتباط با واحد» میتواند از خاموش‌بودن خود واحد، نبود تغذیه یا بدنه، قطعی مسیر، خطای Gateway، محدودیت ابزار یا ثبت تاریخی ناشی شود. «داده نامعتبر» نیز لزوماً به فرستنده محدود نیست و ممکن است داده از حسگر بالادست، کدگذاری اشتباه یا وضعیت موقت خودرو آمده باشد.
| نوع یافته | برداشت عجولانه | بررسی معتبرتر |
|---|---|---|
| Lost Communication | ECU مقصد سوخته است | پاسخ مستقیم واحد، تغذیه، بدنه، مسیر و زمان رخداد بررسی شود |
| Invalid Data Received | واحد فرستنده حتماً خراب است | مالک داده، حسگر بالادست، نسخه نرم‌افزار و هم‌زمانی کدها تطبیق داده شود |
| Bus Off یا خطای شبکه | کل سیمکشی باید تعویض شود | دامنه شبکه، شاخه درگیر، وضعیت ولتاژ و امکان تکرار خطا مشخص شود |
| کد تاریخی کمولتاژ | ایراد فعال شبکه وجود دارد | زمان، ولتاژ، سابقه باتری و بازگشت کد پس از چرخه کنترل‌شده ثبت شود |
نقشه توپولوژی؛ قبل از تفسیر، واحدهای پاسخ‌گو را فهرست کنید
اسکن کامل باید فهرست واحدهای مورد انتظار و پاسخ‌گو را نشان دهد. شبکه ممکن است شامل CAN پرسرعت، CAN بدنه، LIN، زیرشبکه‌های اختصاصی، Ethernet خودرو یا مسیرهای عبوری از Gateway باشد. نبود یک واحد در فهرست ابزار میتواند ناشی از تیپ خودرو، محدودیت دستگاه یا دسترسی امنیتی باشد؛ پس «اسکن همه واحدها» بدون ثبت ابزار، نسخه خودرو و فهرست پاسخ‌ها قابل اثبات نیست.
- VIN، تیپ، سال، سطح تجهیزات و واحدهای مورد انتظار ثبت شوند.
- نام ابزار، نسخه نرم‌افزار و نوع دسترسی معمول یا امنیتی نوشته شود.
- واحدهای پاسخ‌گو، بدون پاسخ و دارای کد در سه فهرست جدا قرار گیرند.
- کدهای هم‌زمان بر اساس زمان، ولتاژ و وضعیت سوییچ گروه‌بندی شوند.
- پس از تغییر وضعیت خودرو، همان فهرست بدون پاکسازی عجولانه بازخوانی شود.
Gateway و Security Gateway چه محدودیتی ایجاد می‌کنند؟
Gateway مسیر تبادل میان چند شبکه را مدیریت میکند و در بعضی خودروها دسترسی تشخیصی نیز از آن عبور میکند. ابزار ناسازگار، مجوز ناکافی یا محدودیت امنیتی ممکن است بخشی از واحدها را نمایش ندهد یا فقط خواندن محدود را ممکن کند. گزارش باید «عدم دسترسی» را از «عدم وجود واحد» و «عدم ارتباط واقعی» جدا بنویسد؛ دورزدن حفاظت امنیتی یا اجرای فرمان ناشناخته در کارشناسی پیش از خرید قابل قبول نیست.
افت ولتاژ چگونه شبکه سالم را شبیه شبکه معیوب نشان میدهد؟
ECUها در ولتاژ پایین، افت مسیر مثبت یا بدنه ضعیف ممکن است در لحظه‌های متفاوت ریست شوند. نتیجه میتواند مجموعه‌ای از کدهای کمولتاژ، عدم ارتباط و داده نامعتبر باشد. یک عدد باتری در حالت خاموش کافی نیست؛ خط زمانی باید وضعیت پیش از سوییچ، هنگام بیداری، استارت، دور آرام، روشن‌شدن مصرف‌کننده‌ها و خاموش‌شدن شبکه را پوشش دهد.
- ولتاژ و وضعیت شارژ باتری ۱۲ ولت پیش از اولین استارت ثبت شود.
- افت مسیر مثبت و بدنه فقط با روش ایمن و در بار مناسب همان مدار بررسی شود.
- زمان ریست واحدها با لحظه افت ولتاژ یا فعال‌شدن مصرف‌کننده تطبیق داده شود.
- در خودرو هیبریدی یا برقی، نقش DC/DC و تغییر حالت Ready از باتری ۱۲ ولت جدا شود.
برای پیوند این یافته‌ها با تحلیل تغذیه، صفحه کارشناسی فنی موتور و برق پایه و برای کنترل واحدهای ایمنی، راهنمای فرمان، EPS و ESC مفید است.
مقاومت انتهایی CAN؛ چرا «حدود ۶۰ اهم» حکم سلامت نیست؟
در یک شبکه کلاسیک با دو مقاومت انتهایی ۱۲۰ اهمِ موازی، اندازه‌گیری نزدیک ۶۰ اهم میتواند با انتظار نقشه سازگار باشد؛ اما این عدد قانون همگانی همه خودروها و همه شاخه‌ها نیست. شبکه باید خاموش و از منبع تغذیه ایمن جدا شده باشد، خازن‌ها و واحدها فرصت تخلیه داشته باشند و نقطه اندازه‌گیری طبق نقشه انتخاب شود. مقدار ظاهراً درست، اتصال مقطعی، نویز، خوردگی سوکت یا اختلال هنگام لرزش و گرما را رد نمیکند.
اندازه‌گیری اهم روی مدار برق‌دار، پل‌زدن پین‌ها یا جداسازی تصادفی واحدها در بازدید معامله میتواند آسیب‌زا باشد. اگر یافته اولیه نیازمند مقاومت یا اسیلوسکوپ است، گزارش باید آن را «ارجاع تخصصی» ثبت کند.
شکل موج CAN چه چیزی اضافه میکند؟
اسیلوسکوپ میتواند تقارن سیگنال، نویز، لبه‌ها، بازتاب، اتصال کوتاه یا اختلال مقطعی را نشان دهد، اما تفسیر بدون سرعت شبکه، نقطه اندازه‌گیری، مرجع بدنه و نقشه معتبر ناقص است. فقط مشاهده نوسان روی CAN-H یا CAN-L برای اعلام سلامت کافی نیست؛ اختلاف دو خط و رفتار هنگام رخداد باید کنار هم دیده شوند.
| الگوی احتمالی | علت‌های قابل بررسی | چیزی که هنوز ثابت نشده |
|---|---|---|
| یک خط نزدیک تغذیه یا بدنه مانده | اتصال کوتاه، واحد یا دسته‌سیم | محل دقیق بدون جداسازی مرحله‌ای |
| بازتاب یا لبه نامنظم | انتهای نامناسب، انشعاب، اتصال یا کابل | اینکه کدام قطعه مقصر نهایی است |
| اختلال فقط هنگام حرکت یا گرما | سوکت، کشش دسته‌سیم، رطوبت یا واحد حساس به دما | سلامت در حالت پارک و سرد |
| شکل موج مناسب اما U-code باقی است | کد تاریخی، نرم‌افزار، داده نامعتبر یا شبکه دیگر | رفع علت فقط با یک مشاهده کوتاه |
شبکه خواب و مصرف برق؛ واحدی که بیدار می‌ماند چه اثری دارد؟
بازبودن در، حضور کلید هوشمند، اتصال ابزار دیاگ، شارژر، ردیاب یا تجهیزات جانبی میتواند شبکه را بیدار نگه دارد. بنابراین زمان خواب باید با شرایط آزمون ثبت شود. اگر باتری پس از توقف خالی میشود، نسبت‌دادن فوری مشکل به یک ECU بدون ثبت جریان، زمان و رخداد بیدارشدن معتبر نیست.
- همه ورودی‌های بیدارباش و تجهیزات افزوده فهرست شوند.
- لحظه قفل، خاموش‌شدن نمایشگرها و تغییر جریان در خط زمانی قرار گیرد.
- بیدارشدن دوره‌ای با رویدادهای مجاز خودرو از خطای واقعی جدا شود.
- ردیاب، دزدگیر، مولتی‌مدیا یا سیمکشی غیرفابریک به‌عنوان متغیر مستقل ثبت شود.
تصادف و نفوذ آب چگونه به خطای ارتباطی تبدیل می‌شوند؟
کشش دسته‌سیم، پایه شکسته واحد، اتصال بدنه تعمیرشده، رطوبت زیر صندلی یا کف، خوردگی پین و تغییر مسیر کابل پس از تعمیر می‌توانند خطای مقطعی بسازند. هنگام مشاهده U-code در خودروی تصادفی یا آب‌خورده، محل فیزیکی تعمیر باید با شبکه واحدهای درگیر تطبیق داده شود. راهنمای تشخیص خودرو تصادفی و ADAS و صفحه تشخیص نفوذ آب و خوردگی این مسیر را تکمیل می‌کنند.
پس از تعویض ECU، فقط پاک‌شدن کد کافی نیست
واحد جایگزین ممکن است به Coding، Variant Configuration، تطبیق ایموبلایزر، همسان‌سازی کیلومتر، Initialization یا به‌روزرسانی نرم‌افزار نیاز داشته باشد. گزارش معتبر باید هویت قطعه و نسخه قبل و بعد، عملیات انجام‌شده، کدهای باقی‌مانده و آزمون عملکرد را ثبت کند. استفاده از واحد استوک یا Clone بدون مدرک و بدون تطبیق کامل میتواند داده‌های هویتی و شبکه را ناسازگار کند.
درخت تصمیم ایمن برای U-code
- پیش از پاکسازی، گزارش خام همه واحدها و وضعیت ولتاژ ذخیره شود.
- مشخص شود کدام واحد کد را نوشته و کدام واحد مقصد پیام بوده است.
- کد جاری، تاریخی، مقطعی و بازگشته از هم جدا شوند.
- خطاهای کمولتاژ و ریست واحدها روی یک خط زمانی قرار گیرند.
- توپولوژی و مسیر Gateway برای شاخه درگیر بررسی شود.
- مشاهده فیزیکی سوکت، بدنه، تعمیر تصادف یا رطوبت با داده تطبیق داده شود.
- اگر آزمون تهاجمی لازم است، خودرو به مرکز مجهز ارجاع و دامنه انجام‌نشده ثبت شود.
- پس از تعمیر، اسکن همه واحدها و آزمون در همان شرایط رخداد تکرار شود.
بسته تحویل کارشناسی شبکه باید چه داشته باشد؟
| رکورد | حداقل محتوای قابل پیگیری |
|---|---|
| هویت جلسه | VIN، تیپ، زمان، دما، وضعیت باتری و حالت خودرو |
| نقشه پاسخ | واحدهای مورد انتظار، پاسخ‌گو، بدون پاسخ و محدودشده |
| Snapshot | کد، وضعیت، واحد گزارش‌کننده و داده همراه پیش از پاکسازی |
| خط زمانی | سوییچ، استارت، Ready، مصرف‌کننده، حرکت، Heat-soak و خواب |
| شواهد فیزیکی | تغذیه، بدنه، سوکت، آب‌خوردگی یا تعمیر قابل‌مشاهده |
| نتیجه | تأییدشده، تکرارنشده، نیازمند ارجاع و دامنه انجام‌نشده |
U-code باید بخشی از زنجیره شواهد باشد، نه برچسب قطعه. تصمیم خرید زمانی قابل دفاع‌تر است که گزارش خام، شرایط رخداد، محدودیت ابزار و آزمون پس از تعمیر کنار هم حفظ شوند.
استارت کند یا باتری خالی؛ راهنمای تخصصی مسیر بعدی
اگر مسئله اصلی No-crank، چرخش کند، افت ولتاژ هنگام Cranking یا تخلیه باتری پس از پارک است، جزئیات حفظ نخستین استارت، تفکیک مسیر فرمان و قدرت، جریان استارتر و خواب شبکه در راهنمای استارت کند و برق‌دزدی خودرو آمده است. این راهنمای مستقل مکمل فصل شارژ هوشمند است و جای اسکن اولیه یا بررسی دینام را نمی‌گیرد.
انتخاب مسیر کارشناسی بر اساس محل واقعی خودرو
دیاگ باید در کنار بازدید جامع و در محل مناسب انجام شود. برای مسیر اصلی از کارشناسی خودرو تهران شروع کنید. اگر خودرو در محدوده‌های شرقی قرار دارد، هاب کارشناسی خودرو شرق تهران و برای محدوده‌های غربی، صفحه کارشناسی خودرو غرب تهران مسیرهای تخصصی و محلی را نشان می‌دهند. برای مقایسه پیشنهادها نیز دامنه اسکن، رانندگی و گزارش را در صفحه هزینه کارشناسی خودرو یکسان کنید.
جمع‌بندی
دیاگ خودرو قبل از خرید یک ابزار ثبت شواهد الکترونیکی است. ارزش آن به سازگاری ابزار، دامنه واحدهای خوانده‌شده، شرایط آزمون و تفسیر کنار مشاهده فیزیکی وابسته است. «بدون خطا» فقط باید به دامنه و لحظه اسکن اشاره کند و کد خطا نیز به‌تنهایی حکم تعویض قطعه نیست. نتیجه مناسب، کد، داده، محدودیت و اقدام بعدی را از هم جدا میکند.
کارشناسی دینام و سیستم شارژ هوشمند؛ یک عدد ثابت کافی نیست
در خودروهای قدیمی‌تر، اندازه‌گیری ولتاژ روی باتری بخشی از ارزیابی دینام بود؛ اما در سامانه شارژ هوشمند، واحد کنترل میتواند بر اساس دمای باتری، وضعیت شارژ، بار مصرف‌کننده‌ها، شتاب یا کاهش سرعت و راهبرد مصرف سوخت، فرمان خروجی را تغییر دهد. بنابراین دیدن یک عدد پایین یا بالا در یک لحظه، بدون دانستن حالت فرمان، خرابی دینام را ثابت نمیکند.
| داده | پرسش کارشناسی | خطای تفسیر رایج |
|---|---|---|
| ولتاژ باتری | در چه دما، دور، بار و حالت رانندگی ثبت شده است؟ | تبدیل یک Snapshot به حکم قطعی |
| ولتاژ یا جریان هدف | ECU چه فرمانی داده و پاسخ واقعی چه بوده است؟ | مقایسه خروجی با یک عدد عمومی |
| State of Charge | روش محاسبه و اعتبار حسگر باتری مشخص است؟ | اعتماد مطلق به درصدی که هنوز Learn نشده است |
| بار دینام | با روشن‌شدن مصرف‌کننده‌ها و تغییر دور چه رفتاری دارد؟ | نادیده‌گرفتن افت مسیر مثبت یا اتصال بدنه |
| DTC و Freeze Frame | کد در کدام واحد و تحت چه شرایطی ثبت شده است؟ | پاک‌کردن کد پیش از ثبت شواهد |
پرونده باید داده زنده، وضعیت مصرف‌کننده‌ها و شرایط آزمون را کنار هم نگه دارد. برای ثبت Snapshot چندواحدی و خطاهای ارتباطی، چارچوب همین راهنمای دیاگ خودرو ملاک است و نتیجه فقط در دامنه آزمون انجام‌شده نوشته میشود.
معماری شارژ را پیش از آزمون شناسایی کنید
نام «دینام» به‌تنهایی معماری را روشن نمیکند. یک خودرو ممکن است رگولاتور داخلی ساده، دینام فرمان‌پذیر از طریق LIN، حسگر هوشمند باتری، باتری کمکی، سامانه Stop/Start یا مبدل DC/DC داشته باشد. در خودرو هیبریدی یا برقی نیز معمولاً باتری ۱۲ ولت از مبدل DC/DC تغذیه میشود و نتیجه‌گیری بر مبنای روش خودرو بنزینی میتواند اشتباه باشد.
- VIN و تیپ تجهیز با محل باتری، تعداد باتری‌ها و نقشه فیوزها تطبیق داده شود؛
- نوع و ظرفیت اسمی باتری از روی برچسب و داده ثبت‌شده در خودرو بررسی شود؛
- وجود حسگر روی قطب منفی، کابل سیگنال و مسیر اتصال بدنه مستند گردد؛
- واحد فرمان‌دهنده شارژ و پارامترهای قابل خواندن با ابزار مشخص شود؛
- تعمیر اخیر دینام، باتری، استارت، جعبه‌فیوز یا دسته‌سیم در خط زمانی قرار گیرد.
وجود سوکت فرمان روی دینام به‌تنهایی سالم‌بودن ارتباط را ثابت نمیکند. پین، قفل سوکت، کشش سیم، نفوذ روغن یا آب و تعمیر غیراصولی باید طبق راهنمای کارشناسی برق، سوکت و دسته‌سیم خودرو بررسی شود.
LIN، BSD یا مسیر فرمان؛ هدف و پاسخ را کنار هم ببینید
نام شبکه میان سازندگان متفاوت است و نباید یک اصطلاح را به همه خودروها تعمیم داد. آنچه اهمیت دارد تفکیک تغذیه اصلی، اتصال بدنه و خط فرمان/بازخورد است. اگر واحد موتور فرمان شارژ می‌فرستد اما پاسخ ژنراتور نمی‌رسد، ایراد میتواند از خود دینام، رگولاتور، سوکت، سیم یا شبکه باشد؛ و اگر فرمانی صادر نمی‌شود، باید پیش‌شرط‌های ECU، حسگر باتری و راهبرد مدیریت انرژی بررسی شوند.
| شاهد | کنترل مکمل | نتیجه مجاز |
|---|---|---|
| خطای ارتباط ژنراتور | تغذیه، بدنه، پین، پیوستگی و شکل سیگنال | مسیر ارتباط نیازمند تفکیک است |
| فرمان هدف بدون پاسخ | خروجی واقعی، بار، دما و افت کابل‌ها | پاسخ سامانه با فرمان همخوان نیست |
| پاسخ متناوب | لرزش، گرما، حرکت دسته‌سیم و Fretting | ایراد مقطعی محتمل؛ قطعه هنوز قطعی نیست |
| نبود پارامتر در اسکنر | پوشش واقعی ابزار و واحد انتخاب‌شده | نبود داده برابر با نبود قابلیت نیست |
Back-probe یا دستکاری شبکه بدون نقشه و ابزار مناسب میتواند اتصال کوتاه یا آسیب ماژول ایجاد کند. اندازه‌گیری تهاجمی در کارشناسی سیار فقط وقتی انجام میشود که روش و دسترسی ایمن باشد؛ در غیر این صورت محدودیت ثبت می‌گردد.
حسگر هوشمند باتری؛ جریان، دما و مرجع اتصال بدنه
حسگر باتری معمولاً اطلاعاتی مانند جریان، ولتاژ و دما را برای برآورد وضعیت شارژ فراهم میکند. نصب کابل جانبی در سمت اشتباه حسگر، تعویض قطب یا اتصال بدنه غیراستاندارد میتواند بخشی از جریان را از مسیر اندازه‌گیری خارج کند. در نتیجه سامانه ممکن است بر پایه داده ناقص تصمیم بگیرد، حتی اگر موتور روشن و خودرو ظاهراً عادی باشد.
- محل حسگر، جهت نصب، شکستگی بدنه و قفل سوکت عکس‌برداری شود.
- کابل‌های اضافه دزدگیر، صوتی یا لوازم جانبی نسبت به نقطه اندازه‌گیری ثبت شوند.
- دمای گزارش‌شده با شرایط واقعی و قرارگیری باتری مقایسه گردد.
- جریان خواب، بیداری و تغییر بار در یک بازه زمانی معنادار دیده شود.
- پس از قطع یا تعویض باتری، وضعیت Learn/Registration و پیام‌های انرژی بررسی شود.
زنگ‌زدگی، رطوبت یا رسوب روی قطب و کابل فقط مسئله ظاهری نیست. منشأ نفوذ آب و مسیر مویینگی باید با کارشناسی نفوذ آب و خوردگی خودرو تطبیق داده شود.
افت ولتاژ مسیر مثبت و منفی را زیر بار اندازه بگیرید
تست مقاومت در حالت خاموش ممکن است اتصال ضعیف را پنهان کند. کابل مثبت دینام تا باتری، فیوزهای پرجریان، اتصال موتور به بدنه و اتصال بدنه به باتری باید هنگام عبور جریان بررسی شوند. افت غیرعادی میتواند باعث کم‌شارژی، داغ‌شدن اتصال، خطای ماژول‌ها یا اختلاف ولتاژ میان دینام و باتری شود.
| مسیر | شرط مشاهده | شاهد تکمیلی |
|---|---|---|
| خروجی دینام تا باتری | بار الکتریکی کنترل‌شده و ثبت هم‌زمان دو سر | فیوز، اتصال پرس‌شده، کابل و آثار گرما |
| بدنه دینام/موتور تا باتری منفی | استارت یا بار شارژ با روش ایمن | بند اتصال بدنه، پیچ، رنگ، خوردگی و تعمیر |
| جعبه‌فیوز تا مصرف‌کننده | فعال‌بودن همان مدار | پایه فیوز، رله، سوکت و تغییر رنگ حرارتی |
| مرجع ECU و حسگر | مقایسه داده اسکن با اندازه‌گیری مرجع | اختلاف زمین و تغذیه مشترک چند کد |
عدد افت باید با شرایط آزمون، ابزار و نقاط دقیق اندازه‌گیری گزارش شود. یک عدد بدون ذکر بار و مسیر، برای مقایسه تعمیر قبل و بعد ارزش محدودی دارد.
Ripple دینام؛ مولتی‌متر AC جای شکل موج را نمی‌گیرد
خرابی دیود، سیم‌پیچ یا اتصال میتواند مؤلفه متناوب روی خط DC ایجاد کند. برخی مولتی‌مترها در حالت AC رفتار متفاوت دارند و عدد آن‌ها بدون دانستن پهنای باند و روش اتصال قابل تعمیم نیست. مشاهده شکل موج با تنظیم و اتصال ایمن، همراه با دور موتور و بار، شواهد دقیق‌تری از ریپل و رویدادهای تکرارشونده میدهد.
- پایه DC، مؤلفه AC و نویز ناشی از سوئیچینگ از هم جدا تفسیر شوند؛
- مقیاس، کوپلینگ، محل اتصال و بار الکتریکی در تصویر موج ثبت گردد؛
- فرکانس یا الگوی تکرار با دور موتور مقایسه شود، نه فقط دامنه یک قله؛
- روشن‌شدن فن، کمپرسور یا گرمکن شیشه به‌عنوان تغییر بار علامت‌گذاری شود؛
- موج غیرعادی با افت کابل، اتصال بدنه و وضعیت باتری تطبیق داده شود.
وجود نویز به‌تنهایی دیود معیوب را قطعی نمیکند و نبود عدد بزرگ در مولتی‌متر نیز سلامت کامل را ثابت نمیکند. اگر شکل موج یا دسترسی ایمن در محل فراهم نیست، نتیجه «اندازه‌گیری تخصصی انجام‌نشده» باقی می‌ماند.
پولی آزاد، تسمه و کشنده؛ عیب مکانیکی را از خروجی الکتریکی جدا کنید
دینام بخشی از مسیر مکانیکی متعلقات موتور نیز هست. پولی یک‌طرفه، کشنده، هرزگرد، هم‌راستایی تسمه یا بلبرینگ میتواند صدا، نوسان کشنده یا لغزش ایجاد کند. افزایش بار الکتریکی هم‌زمان گشتاور دینام را تغییر میدهد؛ بنابراین تغییر صدا با روشن‌شدن مصرف‌کننده، الزاماً عیب الکتریکی نیست.
| نشانه | تفکیک | احتیاط |
|---|---|---|
| جیرجیر یا سوت | هم‌راستایی، آلودگی، کشش و بار دینام | اسپری روی تسمه روش تشخیص نیست |
| حرکت شدید کشنده | پولی آزاد، ضربان موتور، کمپرسور و تسمه | نزدیک‌کردن دست یا ابزار به قطعه گردان ممنوع |
| صدای گرم | بلبرینگ، بار شارژ و انبساط قطعات | صدای منتقل‌شده میتواند منشأ را جابه‌جا نشان دهد |
| بوی داغی | لغزش تسمه، اتصال برقی یا قطعه داغ | ادامه آزمون برای تشدید بو ایمن نیست |
مسیر شنیداری و تفکیک متعلقات در راهنمای تشخیص صدای موتور و دینام تکمیل میشود.
ثبت یا تطبیق باتری پس از تعویض؛ نوع، ظرفیت و سابقه را نگه دارید
برخی خودروها پس از تعویض باتری به ثبت تعویض، تطبیق نوع یا ظرفیت و بازآموزی مدیریت انرژی نیاز دارند. این عملیات مدل‌محور است و نباید برای همه خودروها یکسان فرض شود. نصب باتری با فناوری یا ظرفیت متفاوت، بدون بررسی سازگاری، میتواند راهبرد شارژ و عمر باتری را تغییر دهد.
- برچسب باتری، تاریخ قابل مشاهده، نوع و ظرفیت با فاکتور تطبیق داده شود.
- تعداد باتری‌ها و نقش باتری کمکی در Stop/Start مشخص گردد.
- سوابق Registration/Replacement در واحد مناسب خوانده شود، اگر ابزار پوشش میدهد.
- کدگذاری انجام‌شده با قطعه نصب‌شده تطبیق یابد؛ پیام موفقیت عمومی کافی نیست.
- پس از عملیات، داده وضعیت شارژ، پیام‌های انرژی و استارت مجدد کنترل شود.
نبود سابقه ثبت، به‌تنهایی اثبات نمیکند باتری حتماً نادرست نصب شده؛ اما پرسشی مستند برای فروشنده و تعمیرکار ایجاد میکند.
Stop/Start، باتری کمکی و مصرف‌کننده‌های پرتوان
غیرفعال‌بودن Stop/Start همیشه به معنی خرابی باتری نیست. دمای موتور و کابین، درخواست کولر، وضعیت کمربند و درها، زاویه فرمان، شیب، بازتولید فیلتر یا بار الکتریکی ممکن است پیش‌شرط را محدود کنند. هم‌زمان، باتری ضعیف یا برآورد نامعتبر مدیریت انرژی نیز میتواند سامانه را غیرفعال نگه دارد.
| شرط | داده لازم | نتیجه محتاطانه |
|---|---|---|
| درخواست سرمایش/گرمایش | فرمان کمپرسور، فن، دمای کابین و محدودیت انرژی | اولویت آسایش میتواند Stop/Start را لغو کند |
| باتری اصلی/کمکی | ولتاژ، جریان، DTC و نقش هر باتری | یک تست روی باتری اصلی کل سامانه را پوشش نمی‌دهد |
| پیش‌شرط موتور | دما، کدها و وضعیت آماده | سامانه ممکن است به دلیل دیگری اجازه توقف ندهد |
| مصرف‌کننده جانبی | ردیاب، صوتی، دوربین و نحوه اتصال | بار یا بیدارسازی شبکه باید جدا سنجیده شود |
برای سنجش اثر کمپرسور، گرمکن PTC و مصرف‌کننده‌های کابین، کارشناسی کولر و تهویه خودرو به پرونده شارژ متصل میشود.
خودرو هیبریدی و برقی؛ DC/DC جای دینام را می‌گیرد
در بسیاری از خودروهای هیبریدی و برقی، مبدل DC/DC از مدار ولتاژ بالا، شبکه ۱۲ ولت را تغذیه میکند. روشن‌بودن پشت‌آمپر الزاماً به معنی فعال‌بودن حالت آماده و مبدل نیست. آزمون باید وضعیت Ready، فرمان مبدل، ولتاژ دو سمت ۱۲ ولت، بارها، دما و کدهای واحدهای مرتبط را ثبت کند.
- حالت خاموش، بیدار، Ready و شارژ خارجی از هم جدا شوند؛
- هرگز مدار ولتاژ بالا یا کانکتور نارنجی بدون صلاحیت و تجهیزات باز نشود؛
- افت ولتاژ سمت ۱۲ ولت با کابل، فیوز و اتصال بدنه بررسی گردد؛
- محدودیت حرارتی یا خنک‌کاری مبدل کنار کدهای شارژ خوانده شود؛
- باتری ۱۲ ولت ضعیف میتواند خطاهای چندواحدی ایجاد کند و باید در ترتیب رخداد دیده شود.
اگر دمای مبدل یا مدار حرارتی عامل محدودیت است، مسیر در کارشناسی خنک‌کاری موتور، باتری و اینورتر ادامه پیدا میکند.
ماتریس آزمون سرد، گرم، بار و رهاسازی
یک تست کوتاه در دور آرام، رفتار واقعی شارژ را پوشش نمی‌دهد. پرونده پیش از خرید باید چند حالت قابل تکرار را بدون اعمال بار خطرناک مقایسه کند. انتخاب حالت‌ها به معماری خودرو و دسترسی ایمن وابسته است.
| نسخه آزمون | ثبت هم‌زمان | پرسش |
|---|---|---|
| پیش از استارت سرد | ولتاژ، دما، خواب شبکه و وضعیت شارژ | خط مبنای باتری حفظ شده است؟ |
| استارت | افت ولتاژ، دور، زمان و کدهای ولتاژ پایین | افت از باتری است یا مسیر و استارت؟ |
| دور آرام با بار | فرمان شارژ، پاسخ، جریان و افت کابل‌ها | سامانه زیر بار کنترل‌شده پایدار است؟ |
| کاهش سرعت/رهاسازی | تغییر فرمان و ولتاژ در سامانه هوشمند | راهبرد شارژ با حالت رانندگی تغییر میکند؟ |
| Heat-soak و استارت گرم | دما، اتصال مقطعی و بازگشت خطا | عیب فقط پس از گرم‌شدن ظاهر میشود؟ |
آزمون تخصصی موتور، استارت و افت توان در کارشناسی فنی موتور پیش از خرید قرار می‌گیرد. نتیجه شارژ باید با رفتار استارت، لرزش و دمای موتور تناقض نداشته باشد.
اعتبارسنجی تعمیر دینام و شارژ؛ قبل و بعد را قابل مقایسه کنید
فاکتور «تعویض دینام» یا پاک‌شدن چراغ باتری، به‌تنهایی کیفیت تعمیر را ثابت نمیکند. قطعه نصب‌شده، مسیر کابل‌ها، Coding یا Registration لازم، داده قبل و بعد و تکرار آزمون در همان شرایط باید قابل تطبیق باشند.
| لایه | مدرک حداقل | خروجی گزارش |
|---|---|---|
| قطعه | شماره، نوع، فاکتور و آثار نصب | سازگاری مشاهده‌شده یا نیاز به استعلام |
| اتصال | سوکت، کابل، فیوز، بدنه و گشتاور ظاهری اتصال | مسیر سالم، مشکوک یا آزموده‌نشده |
| فرمان | هدف، پاسخ، کد ارتباط و Freeze Frame | همخوانی یا اختلاف تحت شرایط ثبت‌شده |
| خروجی | ولتاژ، جریان، افت و Ripple در نسخه قابل تکرار | بهبود، عدم تغییر یا داده ناکافی |
| بازگشت | استارت گرم، بار و اسکن نهایی | تأیید در دامنه آزمون یا ارجاع تخصصی |
این گزارش تضمین عمر آینده قطعه نیست. هر موردی که به اسیلوسکوپ، کلمپ جریان، نقشه اختصاصی یا دسترسی ولتاژ بالا نیاز دارد و در محل انجام نشده، صریحاً به‌عنوان محدودیت باقی می‌ماند.
هویت ماژول، پیش‌اسکن و پس‌اسکن؛ پاک‌شدن خطا با تکمیل تعمیر یکی نیست
برای خودرویی که سابقه تصادف، بازشدن داشبورد، تعویض شیشه یا سپر، تعمیر سیمکشی، تعویض ECU، بازشدن صندلی یا ادعای کالیبراسیون دارد، یک اسکن لحظه‌ای فقط «وضعیت اکنون» را نشان میدهد. پرسش خرید این است که آیا می‌توان هویت واحدها، وضعیت پیش از تعمیر، تغییرات حین کار و نتیجه پس از تعمیر را در یک زنجیره قابل مقایسه بازسازی کرد؟ نبود چراغ هشدار یا نمایش عبارت No DTC به‌تنهایی پاسخ این پرسش نیست.
این مسیر باید مدل‌محور باشد. موضع GM درباره اسکن پیش و پس از تعمیر برخورد بر ثبت DTC پیش از تعمیر و اسکن دوباره پس از تکمیل کار تأکید میکند تا هم رفع خطا و هم ایجادنشدن خطای تازه بررسی شود. Honda/Acura نیز توضیح میدهد که بعضی سامانه‌های کمک‌راننده ممکن است بدون DTC همچنان به بازرسی، نشانه‌روی یا کالیبراسیون نیاز داشته باشند. این مواضع، الزام همه خودروهای بازار ایران را تعیین نمی‌کنند؛ اصل قابل انتقال آن‌ها این است که دستور همان سازنده، مدل، سال و نوع تعمیر باید مرجع باشد.
صورتبرداری واحدها را از «تعداد خطا» جدا کنید
گزارش کامل ابتدا باید بگوید ابزار انتظار داشته با کدام واحدها ارتباط بگیرد و کدام واحدها واقعاً پاسخ داده‌اند. فهرست پاسخ‌ها ممکن است شامل موتور، گیربکس، ABS/ESC، SRS، فرمان برقی، بدنه، تهویه، درگاه، دوربین، رادار، کنترل باتری یا واحدهای دیگری باشد. تعداد واحدها در همه تیپ‌ها ثابت نیست؛ بنابراین کم‌بودن یک عدد بدون نقشه تجهیزات همان خودرو اثبات حذف ماژول نیست.
| ستون صورتبرداری | چه چیزی ثبت شود؟ | پرسش کنترلی | مرز نتیجه |
|---|---|---|---|
| واحد مورد انتظار | نام OEM، نشانی شبکه یا گروه سامانه | آیا این تیپ واقعاً آن تجهیز را دارد؟ | فهرست عمومی اینترنتی جای پیکربندی همان خودرو را نمی‌گیرد |
| وضعیت پاسخ | پاسخ‌گو، بدون ارتباط، قفل امنیتی یا پشتیبانینشده | آیا مشکل از خودرو، ابزار، Gateway یا سطح دسترسی است؟ | No Communication به‌تنهایی خرابی ECU را ثابت نمیکند |
| هویت گزارش‌شده | VIN در صورت پشتیبانی، شماره نرم‌افزار، سخت‌افزار و کالیبراسیون | آیا داده با خودرو و سابقه تعمیر هم‌راستاست؟ | نبود VIN در یک واحد الزاماً غیرعادی نیست |
| وضعیت DTC | Current، History، Pending، Permanent و زمان/شمارنده موجود | کد اکنون فعال است یا شاهد یک رخداد قبلی؟ | متن کد نام قطعه معیوب را قطعی نمیکند |
| شرایط جلسه | ولتاژ، KOEO/KOER، دما، کیلومتر نمایشگر و زمان | آیا دو اسکن قابل مقایسه‌اند؟ | اسکن سرد و گرم را نباید یک نسخه فرض کرد |
هویت واحد را با VIN، شماره نرم‌افزار و پیکربندی بررسی کنید
بعضی واحدها VIN کامل یا بخشی از شناسه خودرو، شماره قطعه، نسخه نرم‌افزار یا شناسه کالیبراسیون را گزارش می‌کنند و بعضی واحدها چنین داده‌ای در دسترس ابزار عمومی نمی‌گذارند. اختلاف هویت میتواند از تعویض ماژول، برنامه‌ریزی ناقص، ابزار محدود، قطعه دست‌دوم یا تفاوت نامگذاری ناشی شود. نتیجه درست «اختلاف ثبت شد و نیاز به تطبیق مدل‌محور دارد» است، نه اعلام قطعی دستکاری یا سرقت.
- VIN بدنه و مدارک از مسیر قانونی و جداگانه کنترل شود؛
- VIN یا شناسه گزارش‌شده هر واحد بدون دستکاری در خروجی خام حفظ شود؛
- شماره سخت‌افزار، نرم‌افزار و Calibration ID در صورت دسترسی ثبت گردد؛
- پیکربندی تجهیز با امکانات واقعی خودرو و فهرست آپشن‌ها مقایسه شود؛
- واحد بدون پاسخ با ابزار دوم، برق، زمین، شبکه و سطح دسترسی بررسی شود؛
- هر اختلاف هویت تا دریافت سابقه تعویض یا روش برنامه‌ریزی «باز» بماند.
این کنترل جای تطبیق اصالت شماره‌های شناسایی یا استعلام رسمی را نمی‌گیرد. هدف آن فقط یافتن ناسازگاری الکترونیکی برای بررسی تکمیلی است.
پیش‌اسکن باید نسخه قابل بازگشت بسازد
پیش‌اسکن مفید قبل از پاک‌کردن کد، بازکردن کانکتور، قطع باتری، برنامه‌ریزی، تعویض واحد یا اجرای Reset ثبت میشود. فایل یا گزارش باید زمان، شناسه خودرو، فهرست واحدهای پاسخ‌گو، همه DTCها با وضعیت، Freeze Frame موجود، ولتاژ و محدودیت ابزار را نگه دارد. عکس پراکنده از یک صفحه دستگاه، صورتبرداری کامل نیست.
- ورودی V0: وضعیت خودرو پیش از روشن‌کردن یا تغییر محل؛
- ورودی V1: اسکن همه واحدهای قابل دسترس و فهرست بدون ارتباط‌ها؛
- ورودی V2: جزئیات کد، وضعیت، شمارنده و داده زمینه‌ای قابل استخراج؛
- ورودی V3: رخدادهای تعمیر شامل قطع باتری، بازشدن قطعه یا برنامه‌ریزی؛
- ورودی V4: اسکن پس از مونتاژ و تکمیل مراحل یادگیری یا کالیبراسیون؛
- ورودی V5: بازآزمایی هم‌شرایط، تست عملکرد و موارد باز روز تحویل.
اگر V0 یا V1 موجود نیست، اسکن فعلی همچنان ارزش دارد اما نمی‌تواند ثابت کند کدام خطا پیش از تعمیر وجود داشته یا چه چیزی در جریان تعمیر ایجاد شده است.
پس‌اسکن را با پیش‌اسکن سطر به سطر مقایسه کنید
پس‌اسکن فقط فشردن Clear DTC و مشاهده صفحه خالی نیست. ابتدا باید تعمیر و مونتاژ کامل باشند، ولتاژ پایدار و شرایط لازم همان خودرو فراهم شود؛ سپس فهرست واحدها، DTCها، وضعیت ارتباط، هویت و نیازهای Initialization یا Calibration با نسخه پیش‌اسکن مقایسه شوند. کدی که از Current به History رفته با کدی که پس از پاکسازی و یک چرخه کوتاه هنوز بازنگشته یک معنی ندارد.
| مقایسه | نتیجه قابل دفاع | نتیجه غیرقابل دفاع |
|---|---|---|
| واحدهای پاسخ‌گو | همه واحدهای مورد انتظار پاسخ می‌دهند یا محدودیت مستند است | «اسکن کامل» بدون فهرست واحدها |
| DTC پیش/پس | هر کد رفع‌شده، باقی‌مانده یا تازه جدا ثبت شده است | فقط تصویر No DTC پس از پاکسازی |
| هویت و نسخه | تغییر نرم‌افزار، واحد یا پیکربندی توضیح و مستند شده است | شماره نسخه جدید بدون ارتباط با دستور تعمیر |
| یادگیری و کالیبراسیون | رویه لازم، شرایط، نتیجه و خطاهای پس از اجرا ثبت شدهاند | برداشت «نبود DTC یعنی کالیبره است» |
| آزمون عملکرد | رفتار زنده با دستور و تست مجاز تطبیق یافته است | صرفاً خاموش‌بودن چراغ پشت‌آمپر |
Programming، Coding، Initialization، Learn، Zero‑point و Calibration یکسان نیستند
در گزارش‌های تعمیر این واژه‌ها گاهی به جای هم استفاده می‌شوند، اما کارکردشان میتواند متفاوت باشد. برنامه‌ریزی معمولاً نوشتن نرم‌افزار یا کالیبراسیون روی واحد است؛ Coding یا Configuration تجهیز و گزینه‌های خودرو را به واحد معرفی میکند؛ Initialization یا Learn یک وضعیت پایه یا رابطه اجزا را می‌آموزد؛ Zero‑point مرجع صفر یک حسگر یا سامانه را تعیین میکند؛ Calibration یا Aiming خروجی حسگر را با هدف، هندسه یا شرایط تعریف‌شده سازنده هم‌راستا می‌سازد.
| عمل | نمونه پرسش | مدرک لازم | چیزی که ثابت نمیکند |
|---|---|---|---|
| Programming | چه نرم‌افزار یا Calibration ID نوشته شد؟ | نسخه قبل/بعد، روش و نتیجه برنامه‌ریزی | سلامت سیمکشی یا مکانیک را ثابت نمیکند |
| Coding/Configuration | واحد با تیپ و آپشن خودرو همسان شد؟ | پیکربندی، VIN و فهرست تجهیز | نشانه‌روی دوربین یا رادار را جایگزین نمیکند |
| Initialization/Learn | حالت پایه یا محدوده حرکت آموخته شد؟ | شرایط اجرا و نتیجه روی ابزار | هندسه بدنه یا نصب مکانیکی را اصلاح نمیکند |
| Zero‑point | مرجع صفر حسگر با خودرو هم‌راستاست؟ | وضعیت سطح، فرمان، ارتفاع یا شروط OEM | کالیبراسیون همه سامانه‌های وابسته را ثابت نمیکند |
| Calibration/Aiming | هدف، فاصله، سطح، نور و هندسه طبق روش بود؟ | روش مدل‌محور، ابزار، شرایط و خروجی قبولی | نبود DTC به‌تنهایی آن را تأیید نمیکند |
برای نمونه مدل‌محور، صفحه I‑CAR درباره SRS تویوتا پریوس ۲۰۱۱ انجام Zero‑point و Sensitivity Check را پس از مراجعه ناشی از تصادف ذکر میکند. این حکم فقط نمونه همان اطلاعات تعمیر است و نباید به همه خودروها تعمیم داده شود.
SRS؛ رخداد برخورد، وضعیت قطعات و حافظه را از هم جدا کنید
چراغ SRS، کدهای واحد ایربگ، وضعیت مدار چاشنی‌ها، حسگرهای ضربه، Pretensioner، سامانه تشخیص سرنشین و سابقه تعمیر باید در کنار بررسی فیزیکی دیده شوند. خاموش‌بودن چراغ میتواند با وضعیت عادی، پاکسازی، تعمیر، دستکاری مدار یا شرایط دیگری همراه باشد؛ اسکن نیز به‌تنهایی وجود و کیفیت کیسه، کمربند یا قطعه نصب‌شده را تأیید نمیکند.
- رفتار چراغ در KOEO بدون فرمان یا پاکسازی ثبت شود؛
- هویت و وضعیت ارتباط واحد SRS در فهرست ماژول‌ها بیاید؛
- DTCهای Current و History و اطلاعات رخداد قابل دسترس ذخیره شوند؛
- کمربند، Pretensioner، صندلی، کانکتور و قطعات مرتبط غیرمخرب بررسی شوند؛
- قطعات تعویضی و روش مجاز تعمیر یا تعویض از اطلاعات همان خودرو تطبیق یابند؛
- پس از مونتاژ، اسکن، یادگیری یا Zero‑point لازم و آزمون چراغ تکرار شود؛
- هر داده‌ای که ابزار عمومی نمایش نمی‌دهد به‌عنوان محدودیت نوشته شود.
پاک‌شدن Crash Event یا DTC بدون مدرک قطعات، روش تعمیر و کنترل پس از مونتاژ، «بازگشت کامل سامانه ایمنی» را ثابت نمیکند. در مقابل، وجود یک کد History نیز بدون وضعیت فعلی و زمینه رخداد الزاماً خرابی فعال نیست.
نبود DTC کالیبراسیون را تأیید نمیکند
دوربین، رادار، حسگر زاویه فرمان، شتاب جانبی، ارتفاع، Occupant Classification و بعضی واحدهای دیگر ممکن است پس از تعویض، جابه‌جایی، تنظیم هندسه، بازشدن شیشه یا تعمیر سازه به رویه‌ای مستقل نیاز داشته باشند. رویداد محرک در هر مدل متفاوت است و گاهی سامانه بدون DTC هم به نشانه‌روی نیاز دارد؛ همان نکته‌ای که Honda/Acura در موضع اسکن و کالیبراسیون خود تصریح کرده است.
پیش از پذیرش عبارت «کالیبره شد»، این شواهد درخواست شوند: دستور همان خودرو، رویداد محرک، ابزار یا هدف استفاده‌شده، شرایط سطح و هندسه، اندازه‌های ورودی، خروجی Pass/Complete، DTCهای پیش/پس و تست عملکرد مجاز. رسید دستگاه بدون شناسه خودرو و شرایط آزمون برای پیوند به همان معامله کافی نیست.
سه دروازه توقف پیش از تصمیم مالی
| دروازه | نشانه توقف | اقدام بعدی |
|---|---|---|
| هویت | VIN یا نسخه ناسازگار، واحد مورد انتظار بدون پاسخ یا پیکربندی نامعلوم | تطبیق شماره، سابقه تعویض، ابزار دوم و روش OEM |
| تعمیر | فقط پس‌اسکن موجود است یا کدها بلافاصله پیش از بازدید پاک شدهاند | V0 تا V5، اسکن قبل، فاکتور جزئی و بازآزمایی هم‌شرایط |
| ایمنی/کالیبراسیون | تعمیر SRS، شیشه، سپر، فرمان یا سازه بدون مدرک رویه لازم | بررسی تخصصی مدل‌محور پیش از پرداخت یا تحویل |
این مسیر با اعتبار تعمیر شاسی و جنس سازه، نقشه پنل و بدنه و کارشناسی فنی پیش از خرید پیوند دارد. نسخه محلی برای حفظ پیش‌اسکن سرد در تهرانپارس و برای بازپخش پس‌اسکن تعمیر در ستاری توضیح داده شده است.
موجودی شبکه دیاگ؛ ماژول موردانتظار، قابل‌دسترسی و غایب را تفکیک کنید
عبارت «همه یونیت‌ها اسکن شد» فقط وقتی قابل ارزیابی است که ابتدا بدانیم برای همان خودرو، تیپ، آپشن و بازار چه واحدهایی انتظار می‌رود و ابزار به کدام شبکه‌ها دسترسی دارد. فهرست کوتاه ECUها ممکن است ناشی از پیکربندی واقعی خودرو، پوشش محدود ابزار، Gateway، وضعیت خواب یا بیداری، افت ولتاژ، قطع یک شاخه یا تعمیر قبلی باشد. بنابراین واحدی که در خروجی دیده نمی‌شود نباید بدون شاهد دوم «خراب»، «حذف‌شده» یا «تعویض‌شده» گزارش شود.
دفتر N0 تا N7؛ از هویت خودرو تا بازپخش ارتباط
| نسخه | پرسش شبکه | ثبت لازم | مرز نتیجه |
|---|---|---|---|
| N0 ـ هویت خودرو | کدام تیپ، بازار و سطح آپشن بررسی میشود؟ | شناسه‌های قابل تطبیق، تیپ اعلامی و تجهیزات قابل مشاهده | فهرست ECU یک تیپ به تیپ دیگر تعمیم داده نشود |
| N1 ـ جلسه ابزار | ابزار و نرم‌افزار چه پوششی دارند؟ | نام ابزار، نسخه، روش Auto‑scan/انتخاب دستی و پیام‌های دسترسی | پشتیبانی‌نشدن ابزار با غیبت ECU یکی نشود |
| N2 ـ موجودی موردانتظار | چه واحدهایی بر اساس تجهیز خودرو باید بررسی شوند؟ | فهرست مدل‌محور از اطلاعات سرویس، پیکربندی یا شواهد تجهیز | وجود تجهیز ظاهری به‌تنهایی مالک شبکه را تعیین نمیکند |
| N3 ـ موجودی پاسخ‌گو | کدام واحدها هویت و داده معتبر برگرداندند؟ | نام واحد، شناسه نرم‌افزار/سخت‌افزار در صورت دسترسی و وضعیت کدها | پاسخ‌دادن ECU به معنی سلامت کامل عملکردی نیست |
| N4 ـ مسیر ارتباط | دسترسی مستقیم است یا از Gateway و شبکه دیگر عبور میکند؟ | پیام امنیتی، شبکه/مسیر اعلامی ابزار و واحد واسط | رد دسترسی یا Gateway بسته با خرابی سیمکشی برابر نیست |
| N5 ـ تعارض U‑code | چه واحدی فقدان ارتباط را گزارش کرده و وضعیت کد چیست؟ | واحد ثبت‌کننده، کد، Current/History، زمینه ولتاژ و زمان جلسه | تعداد زیاد U‑code الزاماً به معنی خرابی چند ECU نیست |
| N6 ـ حالت توان | ولتاژ، سوییچ، استارت، خواب/بیداری و شارژ چگونه بوده‌اند؟ | حالت KOEO/Running، رخداد افت ولتاژ و مصرف‌کننده‌های فعال | اسکن در دو حالت متفاوت مستقیماً مقایسه نشود |
| N7 ـ بازپخش | پس از استارت، مسیر یا تعمیر چه چیزی تغییر کرد؟ | اسکن دوم با همان دامنه، واحدهای تازه/حذف‌شده و کدهای تازه | پاک‌شدن کد بدون بازگشت ارتباط، تکمیل تعمیر نیست |
پنج وضعیت گزارش برای هر ماژول
- موردانتظار و پاسخ‌گو: واحد با هویت قابل ثبت پاسخ داده است؛ عملکرد آن همچنان به کد، داده و آزمون وابسته است.
- موردانتظار و غیرقابل‌دسترسی: بر اساس پیکربندی انتظار می‌رود اما پاسخ معتبر ندارد؛ علت هنوز باز است.
- پشتیبانینشده یا دسترسی محدود: ابزار، مجوز، Gateway یا روش جلسه مانع ارزیابی است؛ این وضعیت درباره سلامت ECU داوری نمیکند.
- نامرتبط با این پیکربندی: شاهد مدل‌محور نشان میدهد واحد برای این خودرو انتظار نمی‌رود؛ نبود آن خطا نیست.
- بررسی‌نشده: دامنه سفارش، زمان یا شرایط اجازه بررسی نداده است؛ نباید به «بدون خطا» تبدیل شود.
U‑code را از واحد گزارش‌کننده بخوانید، نه فقط از نام کد
| الگو | کنترل بعدی | نتیجه‌ای که نباید ساخته شود |
|---|---|---|
| چند ECU فقدان ارتباط با یک واحد را ثبت کرده‌اند | حالت کدها، تغذیه واحد هدف، Gateway و موجودی N2/N3 | تعویض قطعی واحد هدف بدون آزمون تغذیه و مسیر |
| یک ECU چند U‑code تاریخی دارد | افت ولتاژ، قطع باتری، تعمیر قبلی و بازپخش N7 | خرابی هم‌زمان همه شبکه‌ها |
| ابزار فقط چند واحد عمومی را می‌بیند | پوشش ابزار، انتخاب خودرو، پروتکل و پیام Gateway | نبود تمام واحدهای اختصاصی خودرو |
| پس از تعمیر واحدی تازه پاسخ میدهد اما کدهای دیگر باقی‌اند | پس‌اسکن هم‌دامنه، وضعیت Current و آزمون عملکردی | تکمیل کل تعمیر فقط بر پایه پاسخ ارتباطی |
| ارتباط با تکان، دما یا مسیر قطع و وصل میشود | ثبت رخداد، کانکتور/شاخه و در صورت ارجاع آزمون فیزیکی شبکه | سلامت شبکه از یک Snapshot ثابت |
مرز اسکن منطقی با آزمون فیزیکی شبکه
اسکن میتواند نشان دهد چه واحدی پاسخ داده، چه واحدی U‑code ثبت کرده و کدام داده در دسترس است؛ اما از خروجی اسکن به‌تنهایی نمی‌توان شکل موج، سلامت سیم، اتصال زمین یا محل قطعی شاخه را اثبات کرد. اگر تعارض موجودی، قطع متناوب یا چند واحد غیرقابل‌دسترسی باقی ماند، پرونده باید با پرسش مشخص به نقشه سیمکشی و آزمون فیزیکی مناسب همان خودرو ارجاع شود. راهنمای Pico درباره لایه فیزیکی CAN اندازه‌گیری CAN‑H/CAN‑L را یک آزمون جدا معرفی میکند؛ مطلب Pico درباره عیب شاخه یک Node نیز نشان میدهد ممکن است بخشی از شبکه برقرار بماند و یک واحد به‌دلیل شاخه خود نتواند داده را Decode کند.
برای تعمیرات برخورد، اصل ثبت پیش و پس از کار در مواضع GM Pre/Post Scan و ملاحظات مدل‌محور Honda/Acura ADAS به حفظ زنجیره شواهد کمک میکند. این منابع برای ساخت الزام عمومی همه خودروهای بازار، عدد ثابت مقاومت، نرخ شبکه یا نتیجه قطعی ECU استفاده نشده‌اند.
مسیر محلی تهرانپارس و ستاری
در تهرانپارس، موجودی N0 تا N3 پیش از اولین استارت و در ولتاژ ثبت‌شده تهیه میشود تا ECU تازه‌بیدارشده با ECU غایب اشتباه نشود. در ستاری، ورود گرم، تعمیر اخیر و Gateway بازشده یا برنامه‌ریزی‌شده در نسخه ورود ثبت و با اسکن روز تحویل مقایسه می‌شوند. محل، دسترسی قطعی همه پروتکل‌ها یا ابزارها را تضمین نمیکند؛ دامنه همان سفارش باید تأیید شود.
Gateway و U-code در دیاگ خودرو؛ نقشه مسیر و ترتیب رخداد را حفظ کنید
اسکن سراسری فقط فهرست کدها نیست؛ یک Snapshot زمان‌دار از مسیرهای ارتباطی است. در معماری‌های جدید ممکن است ابزار از درگاه OBD ابتدا به Gateway برسد و Gateway درخواست را به چند شبکه، Domain یا Zone هدایت کند. بنابراین «ماژول دیده نشد» میتواند از نبود واقعی واحد، خواب‌بودن، تغذیه یا زمین نامناسب، پوشش ابزار، رد دسترسی، وضعیت Gateway، شاخه شبکه یا تغییر پیکربندی ناشی شود. گزارش پیش از خرید باید بین واحد موردانتظار، مسیر دسترسی، واحد گزارش‌دهنده U-code و هدف پیام ازدست‌رفته فرق بگذارد.
توضیح فنی Bosch درباره Central Gateway آن را رابط میان Domainهای خودرو، درگاه دیاگ و ارتباط بیرونی معرفی میکند. صفحه Vehicle Communication Interface بوش نیز نشان میدهد VCI واسط برنامه دیاگ و ECUهاست. این منابع معماری را توضیح می‌دهند؛ از آن‌ها برای فرض‌کردن یک توپولوژی، پروتکل یا سطح دسترسی یکسان برای همه خودروها استفاده نمی‌شود.
دفتر G0 تا G9؛ Snapshot قابل بازسازی شبکه
| کد | ثبت حداقلی | چرا لازم است؟ |
|---|---|---|
| G0 هویت | VIN/شناسه قابل تطبیق، تیپ، بازار، آپشن و معماری اعلامی | موجودی ECU یک تیپ به تیپ دیگر منتقل نمی‌شود |
| G1 جلسه | تاریخ/زمان، ابزار، نرم‌افزار، رابط، انتخاب خودرو و حالت Auto/Manual | پوشش جلسه از سلامت خودرو جدا می‌ماند |
| G2 توان | KOEO/Running/Crank، ولتاژ، شارژر/Jump، مصرف‌کننده و مدت خاموشی | Reset و خواب/بیداری بدون زمینه تفسیر نمی‌شوند |
| G3 موجودی انتظار | ماژولهای مدل‌محور و منبع انتظار: تجهیز، پیکربندی یا اطلاعات سرویس | غیبت فقط نسبت به فهرست انتظار معنا دارد |
| G4 موجودی پاسخ | نام واحد، شناسه نرم‌افزار/کالیبراسیون در دسترس و شبکه/مسیر | پاسخ‌دادن با سلامت عملکردی یکی نیست |
| G5 Gateway/دسترسی | پیام رد، مجوز، Session، شبکه پشت Gateway و محدودیت ابزار | رد امنیتی به خرابی ECU تبدیل نمی‌شود |
| G6 رابطه U-code | واحد گزارش‌دهنده، واحد/سیگنال هدف، وضعیت Current/History و Freeze Frame | نام کد به‌تنهایی مالک عیب را تعیین نمیکند |
| G7 ترتیب رخداد | افت ولتاژ، قطع باتری، Clear، Reset، Programming، Wake و اولین بازگشت کد | کد پیامد از کد آغازگر جدا میشود |
| G8 آزمون دوم | دامنه همسان، حالت توان همسان و Delta ماژول‌ها/کدها پس از مسیر یا تعمیر | دو اسکن ناهم‌شرط مقایسه مستقیم نمی‌شوند |
| G9 تحویل | نسخه سرد/گرم، تغییر پس از کارشناسی، فایل‌ها و اصلاحیه گزارش | نسخه معامله با Snapshot قبلی اشتباه نمی‌شود |
U-code سه نقش دارد: گزارش‌دهنده، هدف و مسیر
وقتی یک کنترل‌گر «فقدان ارتباط با واحد دیگر» را ثبت میکند، واحد اول گزارش‌دهنده و واحد دوم هدف است؛ Gateway، شاخه شبکه، تغذیه، زمین و وضعیت توان می‌توانند بخشی از مسیر باشند. ثبت یک کد در گزارش‌دهنده، خرابی قطعی هدف یا Gateway را ثابت نمیکند. برای هر U-code ردیف جدا ساخته میشود و واحدی که کد را ذخیره کرده، وضعیت کد و زمان نخستین مشاهده کنار نام هدف می‌آیند.
| الگو | فرضیه‌های باز | شاهد تفکیک‌کننده |
|---|---|---|
| چند واحد، یک هدف مشترک را گم کرده‌اند | توان/زمین هدف، شاخه مشترک، Gateway، خواب یا خود هدف | پاسخ هدف، تغذیه زیر بار، مسیر مدل‌محور و ترتیب G7 |
| یک گزارش‌دهنده، چند هدف را گم کرده است | توان گزارش‌دهنده، شاخه خودش، Gateway یا رخداد Reset | کدهای سایر واحدها و Snapshot هم‌زمان |
| U-code فقط History است | افت ولتاژ، قطع باتری، تعمیر، برنامه‌ریزی یا رخداد متناوب | Freeze Frame، زمان Clear و بازگشت در G8 |
| هدف پاسخ میدهد اما U-code باقی است | ارتباط بازگشته، کد حافظه‌ای، پیام خاص غایب یا کالیبراسیون | وضعیت Current/History، داده زنده و پس‌اسکن هم‌دامنه |
| ابزار به شاخه‌ای دسترسی ندارد | پوشش ابزار، مجوز Gateway، انتخاب خودرو یا قطع شبکه | پیام جلسه، ابزار/روش دوم مجاز و اطلاعات سرویس |
در یک بولتن رسمی GM در پایگاه NHTSA، Gateway برای U-codeها Freeze Frame می‌سازد و حتی بیدارشدن Bus هنگام برنامه‌ریزی میتواند کد ایجاد کند. این نمونه نشان میدهد زمان، وضعیت توان و نقش واحد ثبت‌کننده مهم‌اند؛ رفتار همان خودرو یا همه برندها از این بولتن تعمیم داده نمی‌شود.
افت ولتاژ، Reset و Wake؛ ترتیب را پیش از پاک‌کردن حافظه ثبت کنید
ماژول‌ها الزاماً در یک ولتاژ یا لحظه یکسان خاموش و بیدار نمی‌شوند. در فلوچارت رسمی Nissan برای CAN تصریح شده که در وضعیت کمولتاژ، واحدهای مدل‌های مشمول ممکن است در ولتاژهای متفاوت از ارتباط خارج شوند و ترتیب تشخیص کدهای ارتباطی اهمیت دارد. عدد ذکرشده در آن بولتن، مشخصه عمومی همه خودروها نیست؛ در گزارش دژکار مقدار مرجع از اطلاعات همان خودرو گرفته میشود.
- نسخه P0: پیش از Clear، Jump، شارژر یا قطع باتری، اسکن کامل و وضعیت توان ذخیره شود.
- نسخه P1: نخستین KOEO و Crank با ولتاژ، دور و واحدهای ناپدید/بازگشته ثبت شود.
- نسخه P2: بعد از Running، موجودی و Current/History بدون تغییر دامنه دوباره خوانده شود.
- نسخه P3: هر Reset، Registration، Programming، تعویض ECU یا بازشدن Gateway با زمان و عامل ثبت شود.
- نسخه P4: پس از خاموشی کافی، Wake و اسکن سرد روز تحویل با نسخه نخست مقایسه شود.
اگر کدها قبل از P0 پاک شدهاند، گزارش میتواند وضعیت فعلی و Readiness را ثبت کند اما نباید تاریخچه ازدست‌رفته را بازسازی یا نبود عیب قبلی را نتیجه‌گیری کند. «پس از Clear بازنگشت» فقط به دامنه و مدت همان بازپخش محدود است.
دسترسی امنیتی و پوشش ابزار؛ «قابل مشاهده نبود» با «وجود ندارد» یکی نیست
| وضعیت جلسه | عبارت گزارش | عبارت نادرست |
|---|---|---|
| رد دسترسی/احراز | واحد پشت Gateway در این جلسه قابل ارزیابی نبود | ECU خراب یا حذف شده است |
| شناسه خودرو اشتباه/ناقص | انتخاب دستی و VIN با خودرو تطبیق داده شود | شبکه خودرو ناقص است |
| ابزار فقط OBD عمومی | دامنه فقط واحدها/داده‌های پشتیبانی‌شده عمومی است | همه یونیت‌ها بدون خطا هستند |
| Session در میانه قطع شد | فایل ناقص و نقطه قطع جلسه نگه داشته شود | واحدهای پس از نقطه قطع غایب‌اند |
| ابزار دوم فهرست متفاوت دارد | نسخه، انتخاب خودرو، مجوز و نامگذاری مقایسه شود | ابزار با فهرست بلندتر الزاماً درست‌تر است |
خط زمانی E0 تا E6؛ کد آغازگر را از آبشار پیامدها جدا کنید
| ایستگاه | رخداد | ثبت | پرسش تصمیم |
|---|---|---|---|
| E0 ورود | سرد/گرم، مسیر، چرخه سوییچ و تعمیر قبلی | زمان و شرایط قبل از اتصال ابزار | خط مبنا دست‌نخورده است؟ |
| E1 اتصال | شناسه، Gateway، شبکه‌های قابل دسترس | ابزار، نسخه و پیام‌های جلسه | دامنه واقعی اسکن چیست؟ |
| E2 Crank/Start | افت ولتاژ، Reset و بیدارشدن واحدها | ولتاژ، دور، زمان و Delta موجودی | قطع ارتباط هم‌زمان با افت توان است؟ |
| E3 Running | بازگشت ارتباط یا U-code تازه | گزارش‌دهنده، هدف، Current/History | کدام واحد نخستین شاهد را دارد؟ |
| E4 مسیر/Heat-soak | قطع متناوب با دما، تکان یا بار | Timestamp، محل رخداد و Snapshot | آیا عیب قابل تکرار است؟ |
| E5 تعمیر/تغییر | Clear، باتری، کانکتور، ECU یا برنامه‌ریزی | فاکتور، قطعه، فایل قبل/بعد و عامل تغییر | چه چیزی بین دو نسخه عوض شد؟ |
| E6 تحویل | سرد، موجودی هم‌دامنه و کدهای باقی‌مانده | Delta و اصلاحیه | نسخه معامله با گزارش یکی است؟ |
چه زمانی اسکن به آزمون فیزیکی شبکه ارجاع شود؟
اگر چند ماژول هم‌زمان غیرقابل‌دسترسی‌اند، ارتباط با تکان یا دما قطع میشود، Gateway یک شاخه را نمی‌بیند یا U-codeهای Current پس از تثبیت توان بازمی‌گردند، خروجی اسکن باید سؤال دقیق برای محل مجهز بسازد: کدام شاخه، کدام حالت توان، کدام واحد گزارش‌دهنده و چه زمانی. آزمون مقاومت، ولتاژ، شکل موج، افت زمین یا جداسازی Node بدون نقشه و روش همان خودرو انجام نمی‌شود. اتصال اسیلوسکوپ یا بازکردن شاخه در خودروی هیبرید/برقی نیز به‌عنوان کار عمومی پیش از خرید معرفی نمی‌شود.
بازپخش تعمیر شبکه؛ V0 تا V6
| نسخه | شاهد لازم | مرز نتیجه |
|---|---|---|
| V0 پیش از تعمیر | فایل کامل، موجودی، U-code، توان و رخداد | Screenshot ناقص جای فایل قابل بازسازی نیست |
| V1 تشخیص | نقشه مسیر، تغذیه/زمین و آزمون هدفمند | تعویض ECU از روی نام U-code پذیرفته نمی‌شود |
| V2 عملیات | سیم/کانکتور/واحد، شماره قطعه و پیکربندی | نام قطعه بدون دامنه کار کافی نیست |
| V3 برنامه‌ریزی | نسخه نرم‌افزار، برق پایدار، Reset و نتیجه Session | پاسخ ECU، تکمیل کالیبراسیون را تضمین نمیکند |
| V4 پس‌اسکن | همان ابزار/دامنه، Current/History و موجودی | Clear بدون بازگشت ارتباط، پایان کار نیست |
| V5 عملکرد | وظیفه‌های وابسته، مسیر/دما و رخداد متناوب | شبکه سالم لزوماً عملکرد همه سامانه‌ها را ثابت نمیکند |
| V6 تحویل سرد | Wake، موجودی، کدها، Readiness و اصلاحیه | یک بازپخش، دوام آینده را تضمین نمیکند |
برای پارکینگ سرد از مسیر Gateway و U-code در تهرانپارس و برای ورود گرم یا تعمیر اخیر از بازپخش شبکه در ستاری استفاده کنید. این مسیرهای محلی، وجود ابزار، دسترسی امنیتی یا تکمیل همه آزمون‌ها در هر محل را تضمین نمی‌کنند.
دیاگ خودرو وارداتی؛ Session، دسترسی Gateway و فایل اسکن را قابل بازسازی کنید
عبارت «دیاگ کامل» زمانی برای تصمیم خرید قابل پیگیری است که معلوم باشد ابزار در چه Session و شرایطی به خودرو متصل شده، کدام ماژول‌ها را انتظار داشته، کدام واحدها پاسخ داده‌اند، Gateway چه سطح دسترسی داده، کدام DTC و داده زمینه‌ای استخراج شده و دقیقاً چه فایل یا گزارش مشتقی تحویل شده است. نام برند، وارداتی‌بودن یا نمایش صفحه No DTC به‌تنهایی پوشش اسکن، سلامت شبکه یا تکمیل تعمیر را ثابت نمیکند.
| کد | ثبت اجباری جلسه | خطای استنباط |
|---|---|---|
| D0 هویت | VIN/شناسه سفارش، مدل‌سال و بازار ادعایی | فایل هم‌نام را متعلق به همین خودرو فرض نکنید |
| D1 ابزار | سازنده/مدل ابزار، نسخه نرم‌افزار و تاریخ | نام ابزار پوشش همه واحدها را تضمین نمیکند |
| D2 شرایط | KOEO/KOER، سرد/گرم، ولتاژ، زمان و آخرین حرکت | دو Session ناهم‌شرایط را هم‌سطح ندانید |
| D3 Gateway | باز، محدود، احراز‌شده، پشتیبانینشده یا نامعلوم | قابل‌مشاهده‌نبودن را غیبت ماژول نخوانید |
| D4 موجودی | موردانتظار، پاسخ‌گو، بدون ارتباط و کشف‌نشده | تعداد کمتر را بدون نقشه تجهیز حذف ECU ندانید |
| D5 هویت واحد | VIN در صورت پشتیبانی، سخت‌افزار، نرم‌افزار و Calibration ID | اختلاف را بدون سابقه تعویض دستکاری قطعی نخوانید |
| D6 DTC | کد، واحد گزارش‌دهنده، وضعیت و شرح خام ابزار | متن کد را نام قطعه خراب قطعی ندانید |
| D7 Snapshot | Freeze Frame، شمارنده، Readiness و داده زمینه‌ای موجود | نبود داده را پاک‌شدن قطعی حافظه تلقی نکنید |
| D8 فایل | نام، فرمت، حجم، زمان، منبع و نسخه خام/مشتق | PDF خلاصه را جای خروجی خام ننشانید |
| D9 محدودیت | ماژول، داده، دسترسی، آزمون یا فایل انجام‌نشده | بخش انجام‌نشده را سالم گزارش نکنید |
خودرو وارداتی؛ وضعیت دسترسی Gateway را از وضعیت خود ماژول جدا کنید
در بعضی خودروها ابزار عمومی فقط بخشی از شبکه را می‌بیند، بعضی عملیات به حساب، مجوز، اتصال یا ابزار مدل‌محور نیاز دارند و بعضی نام‌ها میان بازارها متفاوت‌اند. نتیجه باید بگوید «چه چیزی با این ابزار و این سطح دسترسی دیده شد»، نه اینکه هر واحد دیده‌نشده وجود ندارد یا خراب است. دورزدن دسترسی امنیتی، برنامه‌ریزی یا فرمان فعال خارج از مجوز این دامنه نیست.
| وضعیت | نشانه قابل ثبت | اقدام بعدی | نتیجه ممنوع |
|---|---|---|---|
| پاسخ کامل | هویت، DTC و داده مورد انتظار قابل خواندن است | فایل خام و شرایط Session ذخیره شود | پاسخ کامل مساوی سلامت مکانیکی نیست |
| پاسخ محدود | هویت یا DTC هست اما داده/عملیات ناقص است | محدودیت ابزار و سطح دسترسی نوشته شود | داده ناقص «بدون ایراد» نیست |
| Gateway محدود | پیام مجوز، Authentication یا Function unavailable | مسیر رسمی و ابزار مناسب همان خودرو بررسی شود | محدودیت دسترسی خرابی ECU نیست |
| No communication | واحد مورد انتظار در این Session پاسخ نمی‌دهد | تغذیه، شبکه، بیداری، پیکربندی و ابزار دوم بررسی شود | تعویض قطعه بدون آزمون ساخته نشود |
| پشتیبانینشده | ابزار نام/پروتکل یا داده را نمی‌شناسد | فهرست پوشش و مرجع مدل‌محور تطبیق یابد | غیبت از ابزار غیبت از خودرو نیست |
Manifest فایل؛ خروجی خام، گزارش مشتق و عکس صفحه سه مدرک متفاوت‌اند
فایل خام یا Export ابزار باید تا حد ممکن بدون ویرایش نگهداری شود. گزارش PDF، جدول فارسی یا اسکرین‌شات میتواند برای خواندن مفید باشد اما نسخه مشتق است و باید به منبع خود وصل بماند. نام فایل به‌تنهایی این اتصال را ثابت نمیکند؛ Manifest تاریخ‌دار، شناسه Session، ابزار، خودرو، نوع Export و مسئول دریافت را کنار فایل نگه می‌دارد.
| لایه | نمونه محتوا | ثبت منشأ | کاربرد |
|---|---|---|---|
| Raw | Export اصلی ابزار، فهرست واحدها و جزئیات کد | نام اولیه، زمان، حجم و ابزار | بازبینی بدون خلاصه‌سازی |
| Rendered | PDF یا HTML تولیدشده از همان Export | نسخه نرم‌افزار و رابطه با Raw | خواندن و تحویل |
| Excerpt | جدول، عکس صفحه یا بخش انتخاب‌شده | صفحه/ردیف و دلیل انتخاب | تمرکز روی پرسش معامله |
| Redacted | نسخه با پوشاندن داده شخصی غیرضروری | آنچه پوشانده شده و نگهدارنده اصل | اشتراک کمینه |
| Delta | تفاوت V0 و V5 ماژول، کد، هویت یا فایل | دو ورودی و روش مقایسه | اعتبارسنجی تعمیر |
راهنمای حفظ شواهد دیجیتال NIST به چالش نگهداری اشیای دیجیتال و حفظ قابلیت اتکا می‌پردازد. استفاده از Manifest یا اثرانگشت فایل در این صفحه فقط کنترل تمامیت و منشأ است؛ اصالت حقوقی، مالکیت یا صحت تشخیص خودرو را به‌تنهایی ثابت نمیکند.
DTC، Freeze Frame و Readiness را در خط زمانی یک Session بخوانید
کد خطا بدون واحد گزارش‌دهنده، وضعیت و داده زمینه‌ای ممکن است معنای نادرست بسازد. Freeze Frame اگر پشتیبانی و حفظ شده باشد شرایط یک رخداد را نشان میدهد؛ Readiness و شمارنده‌ها نیز فقط در چارچوب همان خودرو و چرخه‌های انجام‌شده تفسیر می‌شوند. نبود Snapshot میتواند از طراحی سامانه، نوع کد، محدودیت ابزار، پاکسازی یا شرایط دیگر ناشی شود و علت بدون شاهد تعیین نمی‌شود.
- T0: وضعیت سرد/گرم، ولتاژ و رفتار چراغ‌ها پیش از اتصال.
- T1: کشف واحدها و ثبت Gateway پیش از Clear، Reset یا برنامه‌ریزی.
- T2: DTC با Status، Reporter، Counter و Freeze Frame موجود.
- T3: Readiness، زمان/مسافت از Clear در صورت ارائه و محدودیت ابزار.
- T4: تعمیر، قطع باتری، بیداری شبکه، Coding یا عملیات انجام‌شده.
- T5: پس‌اسکن پس از شرایط لازم و پیش از اعلام پایان تعمیر.
- T6: بازآزمایی هم‌شرایط و نسخه روز تحویل.
تغییر از Current به History، بازنگشتن کد پس از یک چرخه کوتاه یا Completeشدن یک مانیتور سه نتیجه متفاوت‌اند. آستانه، مسافت یا تعداد چرخه عمومی برای همه خودروها در این صفحه ساخته نمی‌شود.
پیش‌اسکن و پس‌اسکن؛ Delta فایل را پیش از نتیجه تعمیر بسازید
تعاریف I‑CAR برای پیش‌اسکن، پس‌اسکن و کالیبراسیون این وظایف را از هم جدا میکند و مراجعه به اطلاعات همان سازنده را لازم می‌داند. این تعریف مختص زمینه تعمیر برخورد است و الزام عمومی همه خودروهای بازار را ایجاد نمیکند؛ برای معامله، اصل مفید آن جداسازی «ثبت پیش از تغییر»، «کنترل پس از تعمیر» و «کالیبراسیون مدل‌محور» است.
| ردیف Delta | V0 پیش از تغییر | V5 پس از تعمیر | پرسش باز |
|---|---|---|---|
| موجودی واحدها | پاسخ‌گو/غایب/محدود | پاسخ‌گو/غایب/محدود | پوشش ابزار و پیکربندی همسان بود؟ |
| هویت | HW/SW/Calibration ID | HW/SW/Calibration ID | تغییر به فاکتور و دستور وصل است؟ |
| DTC | Current/History/Pending/Permanent | رفع‌شده/باقی/تازه | Clear یا چرخه میان دو فایل چه بود؟ |
| Gateway | سطح دسترسی و ابزار | سطح دسترسی و ابزار | تفاوت پوشش با تفاوت خودرو اشتباه نشده؟ |
| یادگیری/کالیبراسیون | محرک و وضعیت اولیه | رویه، شرایط و خروجی | مدرک همان مدل‌سال موجود است؟ |
| آزمون عملکرد | نشانه و محدودیت | بازپخش هم‌شرایط | نبود DTC جای آزمون را نگرفته؟ |
تحویل فایل؛ گیرنده، نسخه، Redaction و محدودیت را پیش از اشتراک ببندید
خروجی دیاگ ممکن است VIN، کیلومتر نمایش‌داده‌شده، شناسه واحد، موقعیت زمانی، نام فایل، حساب ابزار یا اطلاعات دیگری داشته باشد. گزارش باید برای پرسش خرید کافی باشد اما داده غیرضروری را بی‌دلیل تکثیر نکند. مشخص شود اصل نزد چه کسی می‌ماند، چه نسخه‌ای به خریدار یا فروشنده می‌رسد، چه داده‌ای پوشانده شده و اصلاحیه بعدی چگونه به نسخه قبل متصل میشود.
| کنترل تحویل | ثبت | مرز |
|---|---|---|
| گیرنده | نقش، مجوز و کانال تحویل | پرداخت‌کننده لزوماً مالک همه داده نیست |
| نسخه | Raw/Rendered/Excerpt/Redacted/Delta | خلاصه جای اصل را نمی‌گیرد |
| تمامیت | نام، زمان، حجم و در صورت استفاده Hash | Hash صحت تشخیص را ثابت نمیکند |
| محدودیت | ماژول و داده انجام‌نشده یا نامطمئن | سکوت گزارش «سالم» نیست |
| اصلاحیه | نسخه قبل، علت، تغییر و تأییدکننده | فایل قبلی حذف یا بازنویسی نشود |
دامنه تجاری و فایل تحویلی در راهنمای هزینه و پوشش دیاگ خودرو وارداتی و روش پیوست در راهنمای گزارش کارشناسی جدا می‌مانند.
نسخه V0 تا V6؛ از پذیرش خودرو تا فایل روز تحویل
| نسخه | ثبت | دروازه |
|---|---|---|
| V0 پذیرش | هویت، شرایط، ابزار، مجوز و فایل‌های قبلی | خودرو و Session قفل شود |
| V1 کشف | Gateway، موجودی واحدها و محدودیت | غیبت با عدم دسترسی جدا شود |
| V2 Snapshot | DTC، Freeze Frame، Readiness و هویت واحد | پیش از Clear/Reset ذخیره شود |
| V3 تعمیر | قطع باتری، قطعه، Coding، Programming و فاکتور | هر تغییر به مجری وصل شود |
| V4 پس‌اسکن | واحدها، کدها، دسترسی و خروجی کالیبراسیون | فایل مستقل حفظ شود |
| V5 بازپخش | شرط همسان، آزمون عملکرد و Delta | محدودیت حل‌نشده باز بماند |
| V6 تحویل | نسخه فایل، گیرنده، Redaction و اصلاحیه | اصل و مشتق قابل ردیابی باشند |
این دفتر روش ثبت و مقایسه را میدهد؛ تعداد ماژول، آستانه داده زنده، پوشش ابزار، الزام کالیبراسیون یا نتیجه قطعه باید از همان خودرو و مرجع مدل‌محور تعیین شود. رتبه، ضمانت تعمیر یا سلامت آینده از این Session ساخته نمی‌شود.
دیاگ پس از تعمیر شاسی و بدنه؛ محرک کالیبراسیون، پیش‌شرط و فایل نتیجه را تطبیق دهید
پس از تعمیر برخورد، تعویض شیشه یا بازشدن سپر، «اسکن بدون خطا» و «کالیبراسیون انجام شد» دو ادعای جدا هستند. اسکن وضعیت ارتباط و DTCهای قابل‌دسترسی را در یک Session ثبت میکند؛ کالیبراسیون یا Aiming باید به حسگر مشخص، محرک مشخص، دستور همان خودرو و پیش‌شرط‌های مکانیکی وصل باشد. گزارش کارشناسی پیش از خرید باید نشان دهد چه چیزی تغییر کرده، کدام سامانه ممکن است متأثر باشد، چه روشی انتخاب شده و فایل نتیجه متعلق به کدام خودرو و مرحله تعمیر است.
دفتر C0 تا C9؛ از آسیب تا فایل روز تحویل
| کد | ردیف پرونده | شاهد | نتیجه ممنوع |
|---|---|---|---|
| C0 هویت | VIN، مدل‌سال، بازار و تجهیز ADAS | Build data/مرجع همان خودرو | نام آپشن در آگهی اثبات تجهیز نیست |
| C1 آسیب | جهت ضربه، ناحیه و قطعات مجاور | نقشه عکس‌دار پیش از تعمیر | نبود شکستگی حسگر یعنی بی‌اثر بودن نیست |
| C2 تعمیر | شاسی، براکت، سپر، شیشه یا تعلیق | فاکتور، عکس مرحله‌ای و روش تعمیر | نام کلی «صافکاری» محرک را نمی‌بندد |
| C3 موجودی | حسگر، دوربین، ECU و ورودی‌های مرتبط | نقشه تجهیز و پیش‌اسکن | غیبت از ابزار مساوی حذف قطعه نیست |
| C4 محرک | رویداد احتمالی Calibration/Initialization/Aiming | دستور همان مدل‌سال | محرک یک خودرو به همه خودروها تعمیم داده نشود |
| C5 پیش‌شرط | هندسه، نصب، تایر، بار، سطح و ولتاژ | Checklist روش مدل‌محور | شروع ابزار، پیش‌شرط کامل را ثابت نمیکند |
| C6 Session | ابزار، نسخه، روش Static/Dynamic/Hybrid و زمان | Manifest فایل | نام Calibration بدون زمینه کافی نیست |
| C7 نتیجه | موفق، ناموفق، لغوشده یا انجام‌نشده | خروجی ابزار و محدودیت | No DTC جای نتیجه Calibration نیست |
| C8 پس‌اسکن | موجودی، DTC و آزمون عملکرد پس از کار | فایل مستقل پس از تعمیر | فایل پیشین بازنویسی نشود |
| C9 تحویل | Delta، موارد باز، اصلاحیه و گیرنده | گزارش نسخه‌دار روز معامله | تحویل خودرو ضمانت عملکرد آینده نیست |
نقشه آسیب تا سامانه؛ ابتدا مسیر فیزیکی را بسازید
حسگر ممکن است مستقیماً آسیب ندیده باشد اما محل نصب، براکت، پنل مجاور، شیشه، سپر یا هندسه‌ای که زاویه آن را تعیین میکند تغییر کرده باشد. برعکس، بازشدن یک قطعه همیشه الزام یکسان برای همه خودروها ایجاد نمیکند. بنابراین محرک از ترکیب VIN، محل حسگر، عملیات واقعی تعمیر و اطلاعات فنی همان مدل‌سال استخراج میشود.
| ناحیه تعمیر | پرسش فیزیکی | پرسش دیاگ/ADAS | مدرک بعدی |
|---|---|---|---|
| شیشه جلو/سقف | شیشه، براکت یا محل دوربین تغییر کرده؟ | دوربین/سنسور باران/ورودی‌های دیگر حاضرند؟ | روش نصب و گزارش مدل‌محور |
| سپر/جلوپنجره | Radome، رنگ، براکت یا هندسه نصب تغییر کرده؟ | رادار/پارک/دمای بیرون پاسخ میدهد؟ | محدودیت تعمیر و Calibration مربوط |
| گوشه عقب/ربع | ناحیه نصب یا پنل مجاور تعمیر شده؟ | Blind Spot و شبکه مرتبط قابل‌دسترسی است؟ | محرک همان خودرو و آزمون عملکرد |
| تعلیق/فرمان | ارتفاع، Toe، محور یا SAS تغییر کرده؟ | Zero point/Steering angle/ESC چه وضعی دارد؟ | هندسه، Alignment و رویه لازم |
| سازه جلو/عقب | Datum و محل نصب سنسور حفظ شده؟ | کدام سامانه از این هندسه ورودی می‌گیرد؟ | فایل اندازه‌گیری و Calibration |
Best Practice شناسایی ADAS و الزامات کالیبراسیون I‑CAR بر استفاده از VIN/build data، پیش‌اسکن، محل قطعه و اطلاعات OEM تأکید دارد. این راهنما برای تعمیر برخورد نوشته شده است؛ در این صفحه فقط الگوی شناسایی و مستندسازی آن استفاده میشود و الزام عمومی بازار ایران ساخته نمی‌شود.
پیش‌اسکن؛ Snapshot پیش از بازکردن، Clear یا قطع باتری را حفظ کنید
پیش‌اسکن مفید فقط فهرست DTC نیست. موجودی واحدها، وضعیت Gateway، هویت نرم‌افزاری در صورت پشتیبانی، چراغ‌های صفحه‌آمپر، ولتاژ، KOEO/KOER، دمای خودرو، قطعات از قبل جداشده و محدودیت ابزار باید کنار فایل بماند. اگر آسیب اجازه اسکن ایمن نمی‌دهد، علت و نخستین زمانی که اسکن ممکن شده ثبت میشود.
| Snapshot | ثبت | دلیل |
|---|---|---|
| S0 خودرو | VIN، کیلومتر نمایش‌داده‌شده، مدل و تجهیز | انتساب فایل و نقشه واحدها |
| S1 شرایط | سرد/گرم، ولتاژ، KOEO/KOER و هشدارها | قابلیت مقایسه بعدی |
| S2 شبکه | واحد موردانتظار، پاسخ‌گو و بدون ارتباط | تفکیک غیبت از محدودیت ابزار |
| S3 کد | Reporter، Status، Freeze Frame و Counter موجود | خط زمانی رخداد |
| S4 عملیات | قطعه جدا، قطع برق، Clear/Reset قبلی | مرز داده پیش از تغییر |
| S5 فایل | Raw/Rendered، ابزار، زمان و گیرنده | نسخه قابل بازبینی |
فرایند تشخیص تعمیر برخورد ADAS در I‑CAR نیز پیش‌اسکن، ثبت DTC و مراجعه به اطلاعات OEM را از Calibration و پس‌اسکن جدا میکند. این تفکیک مبنای گزارش است؛ نبود کد به‌تنهایی نشان نمی‌دهد که Aim یا Calibration لازم نیست.
دروازه‌های مکانیکی؛ فایل موفق روی هندسه نامطمئن بسته نمی‌شود
بسیاری از رویه‌ها به وضعیت مکانیکی و محیطی خودرو حساس‌اند. اگر شاسی، براکت، شیشه، سپر، تایر، ارتفاع، فرمان یا Alignment هنوز مورد باز دارد، فایل Calibration باید همان محدودیت را منعکس کند. کارشناس نباید از یک پیام «Complete» نتیجه بگیرد که تمام پیش‌شرط‌ها خارج از ابزار کنترل شدهاند.
| دروازه | سؤال کنترل | اگر پاسخ روشن نیست |
|---|---|---|
| G0 سازه | نقاط مرجع و محل نصب مطابق پرونده تعمیر است؟ | به گزارش شاسی ارجاع شود |
| G1 قطعه | شماره، سمت، براکت و جهت نصب درست است؟ | انتساب/نصب باز بماند |
| G2 سطح عبور | شیشه/Radome/رنگ/پوشش در محدوده مجاز همان خودروست؟ | روش سازنده بررسی شود |
| G3 وضعیت | تایر، فشار، بار، ارتفاع و فرمان ثبت شده؟ | Session نامقایسه شود |
| G4 محیط | سطح، نور، هدف، فاصله یا مسیر لازم مهیاست؟ | روش انجام‌نشده/ناموفق ثبت شود |
| G5 برق/شبکه | ولتاژ و ارتباط واحدها پایدار است؟ | علت اختلال پیش از تفسیر بررسی شود |
جزئیات نقشه فیزیکی، اتصال و اندازه‌گیری در پرونده شواهد تعمیر شاسی نگهداری میشود؛ صفحه دیاگ فقط Session، واحدها، محرک و خروجی دیجیتال را به همان پرونده متصل میکند.
Manifest کالیبراسیون؛ نام ابزار را به نتیجه قابل انتساب تبدیل کنید
| فیلد | حداقل ثبت | کنترل تعارض |
|---|---|---|
| Case/Vehicle | Case ID، VIN، مدل‌سال و تجهیز | فایل خودروی دیگر کنار گذاشته شود |
| Trigger | قطعه/تعمیر/کد/هندسه‌ای که بررسی را آغاز کرد | محرک با فاکتور تطبیق یابد |
| Procedure | Static/Dynamic/Hybrid/Initialization و منبع روش | نام روش بدون Revision کافی نیست |
| Setup | ابزار، نسخه، هدف، محیط و وضعیت خودرو | شرایط ناقص پنهان نشود |
| Result | موفق/ناموفق/لغو/انجام‌نشده و پیام خام | No DTC جای نتیجه ننشیند |
| Post-scan | واحدها، کدهای باقی/تازه و زمان | فایل مستقل حفظ شود |
| Function | آزمون عملکرد مجاز و محدودیت | عملکرد خارج از دامنه ادعا نشود |
| Version | Raw، PDF، اصلاحیه و گیرنده | نسخه قبل حذف نشود |
Delta سه‌گانه؛ پیش‌اسکن، Calibration و پس‌اسکن را یکی نکنید
| ردیف | پیش از تعمیر | پس از تعمیر/کالیبراسیون | وضعیت |
|---|---|---|---|
| موجودی واحدها | پاسخ‌گو/غایب/محدود | همان چهارچوب ابزار و دسترسی | Resolved/Persistent/New/Incomparable |
| DTC | Reporter، Status و Snapshot | باقی، رفع، تازه یا انجام‌نشده | Clear و چرخه ثبت شود |
| هویت واحد | HW/SW/Calibration ID موجود | تغییر و فاکتور مرتبط | تطبیق/تعارض باز |
| محرک | آسیب یا عملیات برنامه‌ریزی‌شده | رویه انجام‌شده و منبع | پوشش کامل/ناقص |
| پیش‌شرط | مورد باز سازه/نصب/هندسه | شاهد بسته‌شدن یا محدودیت | آماده/نامشخص |
| عملکرد | نشانه و محدودیت اولیه | بازپخش مجاز هم‌شرایط | تکرار/عدم تکرار/نامقایسه |
اگر ابزار، Gateway، دما، وضعیت خودرو یا دامنه دو فایل متفاوت باشد، اختلاف به‌جای «رفع‌شده» در وضعیت Incomparable باقی می‌ماند. قالب کامل نگهداری Raw، PDF، Delta و اصلاحیه در راهنمای فایل دیاگ و اصلاحیه گزارش است.
تعارض فاکتور، فایل و وضعیت خودرو را حذف نکنید
- R0: ادعای تعمیرگاه، مشاهده فیزیکی و فایل ابزار در سه منبع جدا ثبت شوند.
- R1: VIN، Session، ابزار، زمان و مرحله تعمیر هر فایل بررسی شود.
- R2: پیام موفق، DTC، موجودی شبکه و وضعیت پیش‌شرط‌ها مستقل خوانده شوند.
- R3: برای هر تعارض، شاهد موافق، مخالف و آزمون تفکیک‌کننده نوشته شود.
- R4: اگر آزمون ممکن نیست، اثر تعارض بر تصمیم خرید باز بماند.
- R5: فایل تازه با Addendum یا Reinspection به نسخه قبل متصل شود.
بازپخش V0 تا V6؛ از ورود خودرو تا فایل روز تحویل
| نسخه | ثبت | دروازه |
|---|---|---|
| V0 پذیرش | هویت، آسیب، تعمیر و فایل‌های قبلی | Case به همین خودرو وصل باشد |
| V1 پیش‌اسکن | شرایط، موجودی، DTC و Raw | پیش از تغییر محفوظ شود |
| V2 محرک | قطعه، محل، عملیات و روش همان خودرو | تعمیم مدل‌سال ممنوع |
| V3 پیش‌شرط | سازه، نصب، هندسه، برق و محیط | مورد باز ثبت شود |
| V4 Calibration | روش، ابزار، Setup، نتیجه و فایل | نام عملیات کافی نیست |
| V5 پس‌اسکن | واحد، DTC، Delta و آزمون عملکرد | فایل مستقل بماند |
| V6 تحویل | موارد باز، محدودیت، اصلاحیه و گیرنده | نسخه قبلی حذف نشود |
این دفتر برای مستندسازی پیش از خرید است؛ از آن قیمت، ضمانت، الزام عمومی کالیبراسیون، سلامت آینده یا بهبود رتبه جست‌وجو ساخته نمی‌شود.
پرسش‌های متداول دیاگ خودرو پیش از خرید
آیا درصد SoH دیاگ، ظرفیت واقعی باتری هیبریدی را قطعی نشان میدهد؟
خیر. تعریف SoH، الگوریتم BMS، دما، SoC و سابقه Reset یا تعویض مهم‌اند. درصد باید همراه اختلاف بلوک‌ها، دما، کدها و روش همان سازنده تفسیر شود.
آیا اختلاف ولتاژ سلول یا بلوک همیشه به معنی تعویض باتری است؟
خیر. اختلاف باید در دما، SoC و بار قابل مقایسه تکرار شود و خنک‌کاری، حسگر و سابقه تعمیر نیز بررسی شوند. حد عمومی برای همه پک‌ها معتبر نیست.
آیا شارژنشدن AC همیشه به معنی خرابی OBC است؟
خیر. منبع برق، ارت، کابل، قفل سوکت، تنظیم زمانبندی، دمای باتری و محدودیت جریان نیز باید ثبت شوند. آزمون متقاطع و کدهای OBC و BMS پیش از نامگذاری قطعه لازم است.
چطور خرابی باتری 12 ولت از مبدل DC/DC جدا میشود؟
ولتاژ و رفتار شبکه در حالت خاموش، Wake-up، ورود به Ready و زیر بار مقایسه میشود. یک اندازه‌گیری بی‌بار یا یک کد Undervoltage برای محکوم‌کردن هرکدام کافی نیست.
چطور بفهمیم واقعاً همه ماژولهای خودرو اسکن شدهاند؟
گزارش باید فهرست واحدهای مورد انتظار، پاسخدهنده، بدون پاسخ و پشتیبانینشده را نشان دهد. عبارت «فول دیاگ» بدون این صورتبرداری، دامنه واقعی بررسی را مشخص نمیکند.
آیا پاک‌شدن کد پس از تعمیر، رفع ایراد را تأیید میکند؟
خیر. Snapshot قبل، شرح اقدام، بازآفرینی ایمن شرایط ایراد و اسکن دوباره لازم است. نتیجه فقط همان سامانه و دامنه آزمون انجام‌شده را پوشش میدهد.
آیا نبود کد خطا یعنی خودرو سالم است؟
خیر. بسیاری از ایرادهای مکانیکی، بدنه، شاسی یا مشکلات مقطعی ممکن است کد ایجاد نکنند یا خارج از دامنه ابزار باشند. نتیجه فقط واحدها و شرایط بررسی‌شده را توصیف میکند.
آیا هر کد خطا یعنی قطعه باید تعویض شود؟
خیر. کد سامانه یا شرط تشخیصدادهشده را نشان میدهد. سیمکشی، تغذیه، اتصال، داده زنده و نشانه فیزیکی باید پیش از تصمیم تعمیر بررسی شوند.
آیا دیاگ خطاهای پاکشده را بازیابی میکند؟
همیشه نه. دسترسی به سابقه به طراحی واحد، نحوه پاکسازی و ابزار وابسته است. داده لحظه ثبت یا وضعیت آزمونهای داخلی ممکن است سرنخ بدهد، اما دلیل قطعی نیست.
آیا دیاگ میتواند کیلومتر واقعی را قطعی مشخص کند؟
در بعضی مدلها داده مرتبط در چند واحد دیده میشود، اما این قابلیت عمومی نیست. نتیجه باید با سوابق، تاریخها و وضعیت خودرو تطبیق داده شود.
آیا دیاگ جای تست رانندگی و کارشناسی فنی را می‌گیرد؟
خیر. رفتار موتور، گیربکس، ترمز، تعلیق و صدا ممکن است فقط در حرکت یا شرایط سرد و گرم آشکار شود. اسکن باید مکمل بازدید و رانندگی ایمن باشد.
اگر دستگاه با یک واحد ارتباط نگرفت چه کنیم؟
ابتدا وجود آن واحد در همان تیپ و سازگاری ابزار بررسی شود. سپس تغذیه، شبکه و سیمکشی یا نیاز به ابزار تخصصی مطرح است؛ نبود ارتباط نباید به سلامت یا خرابی قطعی تعبیر شود.
آیا Not Ready بودن مانیتورها حتماً یعنی خطاها پاک شدهاند؟
خیر. پاکسازی یا قطع باتری یکی از علت‌های ممکن است، اما شرایط رانندگی، دما، سطح سوخت، خرابی فعال و پشتیبانی همان خودرو نیز بر تکمیل مانیتورها اثر دارند. وضعیت باید همراه با کدها و سابقه ثبت شود.
آیا باتری ضعیف میتواند کد خطای متعدد ایجاد کند؟
بله، افت ولتاژ میتواند ارتباط شبکه یا عملکرد بعضی واحدها را مختل کند؛ اما این توضیح به‌تنهایی همه کدها را بی‌اعتبار نمیکند. زمان رخداد، ولتاژ، بازگشت کد و نشانه فیزیکی باید تطبیق داده شوند.
آیا ولتاژ مناسب در حالت روشن، سلامت دینام را ثابت میکند؟
خیر. سامانه شارژ ممکن است فرمان‌پذیر باشد و باید در دما، دور و بار مشخص همراه با افت کابل و ریپل بررسی شود. یک عدد لحظه‌ای نتیجه همه شرایط نیست.
آیا بعد از تعویض باتری باید ثبت یا کدنویسی انجام شود؟
به طراحی همان خودرو بستگی دارد. در خودروهای دارای مدیریت باتری، نوع و ظرفیت باتری و فرایند ثبت تعویض باید طبق مرجع همان مدل بررسی شود؛ این کار برای همه خودروها یکسان نیست.
آیا ثبت U-code یعنی ECU مقصد خراب است؟
خیر. تغذیه، بدنه، مسیر شبکه، Gateway، وضعیت ولتاژ، محدودیت ابزار و تاریخی یا جاری‌بودن کد باید پیش از نسبت‌دادن خرابی به ECU بررسی شوند.
آیا مقاومت حدود ۶۰ اهم سلامت شبکه CAN را ثابت میکند؟
خیر. این مقدار فقط در برخی توپولوژی‌ها و شرایط خاموش میتواند با انتظار نقشه سازگار باشد؛ اتصال مقطعی، نویز، خوردگی و اختلال هنگام گرما یا حرکت را رد نمیکند.
آیا پایین‌بودن لحظه‌ای ولتاژ، خرابی دینام هوشمند را ثابت میکند؟
خیر. فرمان شارژ، دما، وضعیت باتری، بار، حالت رانندگی و افت مسیر مثبت و منفی باید هم‌زمان بررسی شوند.
بعد از تعویض باتری، Registration یا کدگذاری همیشه لازم است؟
خیر؛ این نیاز به معماری و روش همان خودرو بستگی دارد. نوع و ظرفیت باتری و وضعیت ثبت‌شده باید با دستور سازنده تطبیق داده شود.
