मानक OBD से वाहन से संवाद कर पाना अपने आप में फ़ॉल्ट डायग्नोसिस पूरा नहीं करता। इस 2009 W204 C63 पर हम मानक OBD से मिली जानकारी के अलावा SAM, EIS और ESP की जानकारी भी देखना चाहते थे। इसलिए हमने पास मौजूद OBDLink EX से निर्माता-विशिष्ट डायग्नोस्टिक्स की तैयारी आगे बढ़ाई।

अभी तक जो पूरा हुआ है, वह रीड प्रोग्राम और उसका ऑफ़लाइन सत्यापन है। इस वाहन पर SAM, EIS या ESP अभी तक पढ़े नहीं गए हैं।

SAM सिग्नल प्राप्ति और एक्चुएशन मॉड्यूल है, EIS इलेक्ट्रॉनिक इग्निशन स्विच है, और ESP वाहन का इलेक्ट्रॉनिक स्टेबिलिटी प्रोग्राम है। उद्देश्य उन प्रणालियों की स्थिति जाँचना है जिन्हें मानक OBD कैप्चर ने नहीं देखा।

तैयारी कहाँ तक पहुँची #

एडाप्टर की क्षमता बनाम वाहन-विशिष्ट परिभाषाएँ #

सबसे पहले हमने एडाप्टर क्या कर सकता है और किसी विशेष वाहन का डायग्नोसिस कैसे होता है, इन दोनों का अंतर स्पष्ट किया। CAN से जुड़ सकने वाला हार्डवेयर होने पर भी यह अलग से जानना पड़ता है कि किस गंतव्य को, किस प्रोटोकॉल से और क्या अनुरोध भेजना है। लौटे हुए डेटा का प्रारूप और अर्थ भी समझना होता है। केवल "डिवाइस CAN का समर्थन करता है" से यह निष्कर्ष नहीं निकाला जा सकता कि किसी विशेष मॉडल वर्ष का SAM डायग्नोस किया जा सकता है।

OBDLink के आधिकारिक दस्तावेज़ों में ISO-TP, जो CAN पर खंडित संदेश ले जाता है, और रिसीव फ़िल्टर तथा फ़्लो कंट्रोल की सेटिंग्स का वर्णन है। ये रीड प्रक्रिया बनाने की नींव हैं। दूसरी ओर, हर वाहन की ECU पता तालिकाएँ और फ़ॉल्ट कोड के विवरण उन दस्तावेज़ों से नहीं मिलते। यहाँ भी हमने हार्डवेयर विनिर्देश की जाँच और वाहन की संचार परिभाषाओं की खोज को अलग रखा। (OBDLink आधिकारिक विनिर्देश)

दूसरे वाहन के डेटा से उम्मीदवार तैयार करना #

EIS और ESP के उम्मीदवारों के लिए हमने मूल डेवलपर द्वारा प्रकाशित 2011 C207 के संचार रिकॉर्ड इस्तेमाल किए। उनमें विशिष्ट भेजने-प्राप्त करने के मार्ग, डायग्नोस्टिक सत्र और फ़ॉल्ट-कोड अनुरोधों के उत्तर हैं। लेकिन वह हमारी 2009 W204 C63 से अलग वाहन है। सामग्री में मापे गए मान होना और उसकी सेटिंग्स का सामने खड़ी कार पर लागू होना, दो अलग-अलग जाँच के विषय हैं। कार्यान्वयन में "उम्मीदवार" लेबल बना रहता है और ये मार्ग डिफ़ॉल्ट रूप से नहीं चलते। (MBLINK की प्रकाशित परिभाषाएँ, C207 उत्तर रिकॉर्ड)

प्रकाशित रिकॉर्ड के प्रारूप की भी सीमाएँ थीं। उसमें व्यवस्थित किए गए डायग्नोस्टिक संदेश हैं, कच्चे CAN फ़्रेम नहीं। केवल उस रिकॉर्ड से खंडित संचार की नियंत्रण जानकारी या विस्तारित पते के उपयोग का निर्धारण नहीं किया जा सकता। अगली बार हमें वास्तविक उत्तर सहेजकर केवल गंतव्य ही नहीं, फ़्रेम का प्रारूप भी मिलाना होगा।

SAM के लिए, आगे और पीछे दोनों में, इस वाहन पर उपयोग योग्य कोई पुष्ट मार्ग नहीं मिला है। दूसरे मॉडल के पते जैसे के तैसे लगाने के बजाय हमने पहले पहचान जानकारी प्राप्त करने का चरण जोड़ा। डिज़ाइन सार्वजनिक सामग्री में मिले उम्मीदवार मार्गों के नियम का उपयोग करके थोड़े-थोड़े करके जाँच करता है। सामान्यतः यह एक बार में 6 स्लॉट को लक्ष्य करता है, और सभी 47 मार्गों पर स्वचालित रूप से एक-एक करके प्रयास नहीं करता। उम्मीदवारों की संख्या का अर्थ मापे गए मॉड्यूल की संख्या नहीं है।

अपहचाने मार्गों पर केवल एक निश्चित पहचान अनुरोध भेजा जाता है। उत्तर आने पर भी प्रोग्राम वहाँ से अपने आप फ़ॉल्ट कोड पढ़ने या सत्र बदलने तक नहीं बढ़ता। लौटी पहचान स्ट्रिंग और अतिरिक्त प्रमाण जाँचने के बाद ही मार्ग वाहन की परिभाषाओं में जोड़ा जाता है। उत्तर न आने पर गंतव्य, प्रोटोकॉल, बिजली की स्थिति आदि की जाँच बाकी रहती है। केवल उत्तर न मिलने से SAM को खराब नहीं ठहराया जा सकता।

उत्तर की स्थितियों में अंतर करना #

कुछ प्राप्त होने पर भी परिणाम का वर्गीकरण मायने रखता है। हमने उस फ़ॉल्ट-कोड सूची को, जो सही तरीके से खाली लौटती है, उस सूची से अलग रखा जो प्राप्त ही नहीं हो सकी। NO DATA, नकारात्मक उत्तर, उत्तर लंबित और बीच में कटा उत्तर, हर एक को उसकी अपनी स्थिति के रूप में दर्ज किया जाता है।

UDS (Unified Diagnostic Services) वह डायग्नोस्टिक सेवा है जिससे ECU और डायग्नोस्टिक उपकरण जानकारी का आदान-प्रदान करते हैं। उसके फ़ॉल्ट-कोड उत्तरों में हम लंबाई से जाँचते हैं कि हर कोड अपनी स्थिति-जानकारी के साथ जोड़ी में है। कोड जैसा कुछ दिखने पर भी, अगर अंतिम स्थिति-जानकारी गायब है, तो उसे पूर्ण परिणाम के रूप में स्वीकार नहीं किया जाता।

यह अंतर AI द्वारा बनाई गई प्रोसेसिंग की समीक्षा में भी काम आया। एक ऐसे सिम्युलेटेड उत्तर से, जिसमें सामान्य खाली सूची में CAN त्रुटि मिली हुई थी, हमने सत्यापित किया कि उसे शून्य नहीं माना जाता। संचार त्रुटियाँ पहले जाँची जाती हैं, और कच्चा डेटा रखते हुए कैप्चर रोक दिया जाता है। पढ़ने योग्य सारांश बनाने से पहले यह पुष्टि ज़रूरी थी कि उत्तर वैध है। जिन निर्माता-विशिष्ट कोड का अर्थ हम पुष्ट नहीं कर सके, उन्हें अनुमानित विवरण नहीं दिए गए।

चलाने की शर्तें और ऑफ़लाइन सत्यापन #

ध्यान दें कि "केवल पढ़ने" वाले संचालन में भी वाहन को अनुरोध भेजे जाते हैं। मानक OBD भी जानकारी माँगने और उत्तर प्राप्त करने वाला संचार है। खंडित उत्तर प्राप्त करते समय आवश्यक फ़्लो कंट्रोल संदेश भी भेजे जाते हैं। इस डिज़ाइन में रीड अनुरोध निश्चित हैं, और DTC मिटाना, ECU रीसेट, सुरक्षा एक्सेस, राइट, एक्चुएटर टेस्ट आदि अनुमति-सूची में नहीं हैं। डायग्नोस्टिक सत्र बदलने के लिए अलग से स्पष्ट विकल्प चाहिए, और यह केवल उन EIS और ESP उम्मीदवार मार्गों तक सीमित है जिनके लिए दस्तावेज़ उपलब्ध हैं।

अगले वास्तविक-कार मोड के लिए चाबी ON, इंजन बंद, स्थिर बिजली आपूर्ति और उम्मीदवार चलाने का स्पष्ट निर्देश ज़रूरी है। यह जुड़े डिवाइस और लक्ष्य वाहन का मिलान करता है, और चलते समय भी वोल्टेज जाँचता रहता है। डिफ़ॉल्ट न्यूनतम वोल्टेज 12.0 V और अतिरिक्त अनुरोधों की 30 सेकंड की समय सीमा इस प्रोग्राम के लिए तय की गई रोकने की शर्तें हैं, न कि ऐसे मान जिन्हें निर्माता के सर्विस विनिर्देश के रूप में उद्धृत किया जा सके। शर्तें पूरी न होने पर भी डिज़ाइन तब तक जुटाए गए प्रमाण सुरक्षित रखता है।

अब तक पास हुए 51 टेस्ट मेमोरी में सिम्युलेटेड डिवाइस और उत्तरों का उपयोग करने वाला ऑफ़लाइन सत्यापन हैं। इस निर्माता-डायग्नोस्टिक तैयारी में कार को भेजे गए अनुरोध शून्य हैं। हमने खंडित उत्तर, गलत लक्ष्य, वोल्टेज गिरावट, निषिद्ध अनुरोध, बीच में कटाव आदि की हैंडलिंग जाँची, लेकिन ये ऐसे टेस्ट नहीं हैं जो Windows पर वास्तविक पोर्ट इनपुट/आउटपुट या W204 पर निर्माता डायग्नोस्टिक्स की सफलता सिद्ध करें।

AI की मदद से जो आगे बढ़ा, वह था दस्तावेज़ व्यवस्थित करना, उम्मीदवारों को लागू करना और असामान्य उत्तरों सहित व्यवहार का सत्यापन। आगे हमें पुष्टि करनी है कि उम्मीदवार मार्ग वास्तविक कार पर काम करते हैं या नहीं, कौन-सी ECU उत्तर दे रही है, और क्या उत्तर सही तरीके से जोड़े जा सकते हैं। केवल वही मदें वाहन की सेटिंग में अपनाई जाएँगी जिनके परिणाम पूरे हों; अपुष्ट मदें आगे भी अपुष्ट ही मानी जाएँगी।