एक CAN बस में SAME ID के साथ विभिन्न संदेशों का प्रसारण


12

क्या आईडी के साथ मध्यस्थता की जा सकती है, और बस में कोई भी नोड किसी भी आईडी के साथ संचारित कर सकता है (आदर्श रूप से यह नहीं होना चाहिए, लेकिन एक बुरा नोड)।

क्या होगा यदि एक ही कैन पर जुड़े दो अलग-अलग नोड्स एक ही आईडी से संदेश भेज सकते हैं लेकिन अलग-अलग डेटा बाइट्स?

मेरी सोच: इससे बस में कचरा पैदा होगा। जिनके पास प्रमुख बिट्स हैं वे केवल संचारित होंगे।


1
मुझे यकीन नहीं है कि उन्होंने ऐसा क्यों किया। मैंने सोचा होगा कि पूरे संदेश पर लागू होने के लिए मध्यस्थता के लिए अधिक समझदारी होगी।
रॉकेटमैग्नेट

जवाबों:


12

कर सकते हैं कल्पना की धारा 6.1 :

BIT ERROR: एक इकाई जो बस में थोड़ा भेजती है, वह बस पर भी नज़र रखती है। BIT ERROR का उस बिट समय पर पता लगाया जाना चाहिए, जब निगरानी की जाने वाली बिट वैल्यू को भेजे गए बिट वैल्यू से अलग हो। एक अपवाद ARBITRATION FIELD की भरी हुई बिट स्ट्रीम के दौरान या ACK SLOT के दौरान एक 'रिसेसिव' बिट भेजने का है।

तो, नोड जो पहले '1' को प्रसारित करता है, जब दूसरा '0' संचारित कर रहा है, एक बिट त्रुटि को नोट करेगा और फिर एक त्रुटि को सामान्य रूप से संकेत देगा - एक त्रुटि-ध्वज प्रसारित करके (धारा 3.1.3 देखें), जैसा कि औपचारिक रूप से वर्णित है। धारा 6.2 में।

अनौपचारिक रूप से, यदि वह नोड त्रुटि-सक्रिय है (जो सामान्य मामला होना चाहिए) यह 6 प्रमुख बिट्स के एक त्रुटि ध्वज को संचारित करेगा, जिसे अन्य सभी नोड्स भी पता लगाएंगे (एक सामान त्रुटि के रूप में)। इससे उस संदेश को पूरी तरह से नष्ट करने का प्रभाव पड़ता है:

  • कोई भी इसे प्राप्त नहीं करेगा
  • ट्रांसमीटरों में से कोई भी यह नहीं सोचेगा कि उन्होंने कुछ भी सफलतापूर्वक प्रसारित किया है।

इसके बाद प्रत्येक ट्रांसमीटर रिट्रांसमिट करने का प्रयास करेगा - रिट्रांसमिशन के सटीक समय के आधार पर, कोई भी बस के दूसरे लाभ नियंत्रण से पहले पर्याप्त रूप से शुरू हो सकता है। अन्यथा, फिर से वही क्रम हो सकता है। (या एक और उच्च प्राथमिकता वाला संदेश उन दोनों को थोड़ी देर के लिए बंद कर सकता है!)


नीचे @ clabbacchio के उत्तर से प्रेरित विस्तारित उत्तर।

आप "नॉटी नोड्स" का उल्लेख करते हैं, और क्लैबाकैचियो वैध बिंदु बनाता है कि यदि दो नोड्स अलग-अलग समय पर प्रसारित होते हैं, तो प्रत्येक रिसीवर को यह तय करने की आवश्यकता है कि इसके कई रिसेप्शन के साथ क्या करना है।

यह पिछले साल एक हैक द्वारा प्रदर्शित किया गया था । पेपर चर्चा करता है, "पीएससीएम बारीकियों" अनुभाग में, कैसे एक हमलावर बस पर नियमित संदेशों को सिंक्रनाइज़ कर सकता है और अपने बुरे संदेश को एक के ठीक पहले खेल सकता है जो "अच्छा" ईसीयू भेजने वाला है। ECU प्राप्त करने वाला पहले वाला संदेश स्वीकार करता है, अपने संदेश काउंटर को अपडेट करता है और फिर "अच्छे" संदेशों को गलत बताता है, क्योंकि इसके संदेश काउंटर में वृद्धि नहीं हुई है।


1

अपने प्रश्न में, आप इस परिकल्पना को बनाते हैं:

जिनके पास प्रमुख बिट्स हैं वे केवल संचारित होंगे।

जो मानता है कि दोनों संदेश एक ही समय में प्रसारित होते हैं, जो कि अधिक सामान्य समस्या का एक विशिष्ट मामला है। मार्टिन का वैध उत्तर इस विशिष्ट मुद्दे को शामिल करता है, लेकिन (अधिक सामान्य) मामले को अनदेखा करता है जिसमें दो नोड्स अलग-अलग समय पर संचारित होते हैं।

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

उदाहरण के लिए, एक संदेश में तापमान संवेदक का वाचन होता है, दूसरे में एक बाइट पर एक एक्ट्यूएटर की लक्षित स्थिति सम्‍मिलित होती है (SHOULD NEVER HAPPEN IN REAL LIFE), आपको एक्ट्यूएटर को इसके लक्ष्य के रूप में भी पता चल सकता है।


हां, दो संदेशों के बीच अंतर करने के लिए एक तर्क लागू किया जाना चाहिए। लेकिन मेरा सवाल यह था कि अगर आईडी के आधार पर मध्यस्थता की जाती है, तो क्या होगा यदि संदेश आईडी समान है और डेटा अलग है।
स्वानंद

@ स्वानंद केवल एक साथ प्रसारण की परिकल्पना पर फिर? बस नोटिस कि यह एक कोने बात है, विपरीत अधिक होने की संभावना है
clabacchio

0

यदि संदेश डेटा फ़ील्ड अलग है, तो आप (उम्मीद है!) गलत CRC के कारण बस में एक त्रुटि फ़्रेम प्राप्त करेंगे।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.