क्या अब वाहन सॉफ़्टवेयर से परिभाषित होता है? डोमेन आर्किटेक्चर और SDV रूपांतरण

इस पेज को साझा करें
हाँ: आधुनिक ऑटोमोबाइल का व्यवहार, विशेषताएं और प्रदर्शन की प्रकृति अब प्राथमिक रूप से सॉफ्टवेयर द्वारा परिभाषित होती है। सॉफ्टवेयर-डिफाइंड व्हीकल (SDV) कहलाने वाला यह बदलाव वाहन के इलेक्ट्रॉनिक आर्किटेक्चर को ECU ढेरों से डोमेन और ज़ोनल कंट्रोलर्स की ओर ले जाकर हार्डवेयर और सॉफ्टवेयर को एक-दूसरे से अलग करता है और वायरिंग के वजन से लेकर OTA अपडेट तक सब कुछ नए सिरे से आकार देता है।
मुख्य बातें
- आज के वाहन 100 या उससे अधिक कंट्रोल यूनिट रख सकते हैं; नए आर्किटेक्चर इस संख्या को 20% तक घटाने का लक्ष्य रखते हैं।
- डोमेन आर्किटेक्चर फ़ंक्शन के अनुसार, ज़ोनल आर्किटेक्चर भौतिक स्थान के अनुसार व्यवस्थित करता है।
- ज़ोनल टोपोलॉजी में CAN XL (20 Mbps तक) और गीगाबिट ईथरनेट जैसे उच्च बैंडविड्थ वाले बैकबोन का उपयोग किया जाता है।
- OTA अपडेट, हार्डवेयर-सॉफ्टवेयर पृथक्करण के कारण संभव होने वाली एक मूलभूत SDV क्षमता है।
- संक्रमण चरणबद्ध है: पहला क्षेत्र बॉडी डोमेन है; ADAS, पावरट्रेन और शसी लंबे समय तक मौजूदा संरचना में रह सकते हैं।
सॉफ्टवेयर डिफाइंड व्हीकल वास्तव में क्या है?
परिभाषा स्पष्ट है: सॉफ्टवेयर डिफाइंड व्हीकल वह वाहन है जिसकी कार्यक्षमता और व्यवहार प्राथमिक रूप से हार्डवेयर के बजाय सॉफ्टवेयर द्वारा निर्धारित होता है। पारंपरिक कार में कोई विशेषता उस फ़ंक्शन के लिए विशेष रूप से निर्मित हार्डवेयर भाग से परिभाषित होती थी; SDV में वही हार्डवेयर, उस पर चलने वाले सॉफ्टवेयर से अलग-अलग कार्यों का रूप ले सकता है। वाहन के बिक जाने के बाद भी नई विशेषताएं जोड़ी जा सकती हैं, व्यवहार को कैलिब्रेट किया जा सकता है, त्रुटियों को दूरस्थ रूप से ठीक किया जा सकता है।
आज के E/E आर्किटेक्चर 100 या उससे अधिक कंट्रोल यूनिट से मिलकर बने होते हैं; नई पीढ़ी की संरचनाएं कंट्रोल यूनिट की संख्या में 20% तक और सामग्री व हार्डवेयर में 10% तक बचत प्रदान करती हैं।
इस वाक्य में निहित आंकड़े इस बदलाव के पैमाने का सारांश देते हैं। समस्या केवल कंट्रोल यूनिट की संख्या नहीं है: प्रत्येक ECU अपनी वायरिंग, अपना सॉफ्टवेयर स्टैक और अपना सत्यापन बोझ साथ लाता है। SDV की दृष्टि इस बिखरी हुई संरचना को एक ऐसी प्रणाली में बदलना है जहां सॉफ्टवेयर एक ही सुसंगत परत में प्रबंधन कर सके। इसके लिए इलेक्ट्रॉनिक आर्किटेक्चर को शुरू से नए सिरे से डिज़ाइन करना आवश्यक है।
ECU से डोमेन आर्किटेक्चर तक: फ़ंक्शन के अनुसार समूहन
किसी ऑटोमोबाइल में प्रत्येक छोटे फ़ंक्शन का अलग इलेक्ट्रॉनिक कंट्रोल यूनिट (ECU) होने का दौर वायरिंग हार्नेस को अप्रबंधनीय बना गया। डोमेन आर्किटेक्चर इसका पहला व्यवस्थित उत्तर बना: यह वाहन के इलेक्ट्रॉनिक्स को ADAS, इन्फोटेनमेंट, पावरट्रेन, बॉडी इलेक्ट्रॉनिक्स, शसी और सुरक्षा जैसे बड़े कार्यात्मक क्षेत्रों के अनुसार व्यवस्थित करता है। प्रत्येक डोमेन में सामान्यतः अपना प्रोसेसर, सॉफ्टवेयर स्टैक, संचार इंटरफ़ेस, सेंसर और एक्चुएटर होते हैं और इसे एक डोमेन कंट्रोलर द्वारा प्रबंधित किया जाता है।
इस संरचना ने ECU अराजकता की तुलना में गंभीर सरलीकरण प्रदान किया। लेकिन जैसे-जैसे SDV का लक्ष्य बढ़ा, डोमेन आर्किटेक्चर की सीमाएं सामने आईं। विशेष रूप से स्वायत्त कार्यों द्वारा उत्पन्न सेंसर डेटा ने क्लासिक CAN नेटवर्क की बैंडविड्थ को अपनी सीमाओं तक धकेल दिया। साथ ही प्रत्येक डोमेन का अपनी प्रोसेसिंग क्षमता रखना वायरिंग हार्नेस को जटिल बनाए रखा और सॉफ्टवेयर के पूरे वाहन में स्केल होना कठिन बना दिया।
ज़ोनल आर्किटेक्चर: संगठन कार्य से स्थान की ओर बढ़ रहा है
ज़ोनल आर्किटेक्चर का तर्क उलट देता है: इलेक्ट्रॉनिक्स को कार्य के अनुसार नहीं, बल्कि वाहन में भौतिक स्थान के अनुसार समूहित करता है। वाहन को आगे बाएं, आगे दाएं, पीछे बाएं, पीछे दाएं और केबिन जैसे क्षेत्रों में विभाजित किया जाता है; प्रत्येक क्षेत्र में एक ज़ोनल कंट्रोलर उस क्षेत्र के सेंसर, एक्चुएटर और बिजली वितरण को एकत्र करता है और केंद्रीय उच्च-प्रदर्शन प्रोसेसिंग प्लेटफॉर्म के साथ संवाद करता है।
| विशेषता | डोमेन आर्किटेक्चर | ज़ोनल आर्किटेक्चर |
|---|---|---|
| संगठन का सिद्धांत | कार्य के अनुसार (पावरट्रेन, ADAS, बॉडी...) | भौतिक स्थान के अनुसार (आगे बाएं, पीछे दाएं...) |
| प्रोसेसिंग संसाधन | डोमेन-विशिष्ट प्रोसेसिंग | एकीकृत केंद्रीय/वितरित प्रोसेसिंग |
| वायरिंग | जटिल, लंबी वायर हार्नेस | कम वायरिंग और वजन |
| ECU संख्या | बड़ी संख्या में ECU | कम संख्या में ज़ोनल कंट्रोलर + केंद्रीय कंप्यूटर |
| सॉफ्टवेयर लचीलापन | SDV के लिए स्केल करना कठिन | उच्च सॉफ्टवेयर लचीलापन |
लाभ ठोस और मापने योग्य है: वायर हार्नेस का वजन कम हो जाता है, पॉइंट-टू-पॉइंट कनेक्शन कम हो जाते हैं, वाहन आर्किटेक्चर और सिस्टम सत्यापन का प्रयास सरल हो जाता है। इससे भी महत्वपूर्ण बात यह है कि सेंसर और एक्चुएटर डिज़ाइन केंद्रीय प्रोसेसिंग नोड से स्वतंत्र हो जाते हैं; इस प्रकार हार्डवेयर और सॉफ्टवेयर अपडेट चक्र अलग हो जाते हैं और एक सेंसर डिज़ाइन को कई वाहन पीढ़ियों तक उपयोग किया जा सकता है।
ज़ोनल कंट्रोलर क्या काम करता है? कार्य विभाजन और हार्डवेयर से संबंध

ज़ोनल आर्किटेक्चर की कुंजी ज़ोनल कंट्रोलर है, जो बड़ी संख्या में एक्चुएटर और सेंसर को केंद्रीय प्रोसेसिंग ECU से जोड़ने का जिम्मेदार है। यह कंट्रोलर केवल डेटा संग्रह बॉक्स नहीं है; यह रियल-टाइम नियंत्रण लूप को अपने ऊपर चला सकता है, अपने क्षेत्र के उपकरणों का प्रबंधन कर सकता है और बैकबोन को फ़िल्टर किया हुआ, प्राथमिकता वाला ट्रैफ़िक भेजता है। Ti से प्राप्त इंजीनियरिंग मूल्यांकन के अनुसार, ज़ोनल मॉड्यूल के MCU में उच्च रियल-टाइम प्रदर्शन, बड़ी मेमोरी, विभिन्न ASIL स्तरों के लिए वर्चुअलाइज़ेशन समर्थन, बैकबोन से उच्च-गति संचार और CAN FD, LIN जैसे कम लागत वाले कई एंड इंटरफेस होने चाहिए।
बिजली वितरण कैसे विकेंद्रीकृत हो रहा है?
डोमेन आर्किटेक्चर में बिजली केंद्रीय पावर डिस्ट्रिब्यूशन बॉक्स से वितरित होती है जिसमें फ्यूज़ और रिले होते हैं। ज़ोनल संरचना में वितरण विकेंद्रीकृत हो जाता है: बैटरी से एकल पावर हार्नेस क्षेत्र तक खींचा जाता है, ज़ोन मॉड्यूल उस क्षेत्र के मॉड्यूल में बिजली बांटता है। छोटे पावर केबल सीधे वजन और लागत की बचत हैं। इसके अलावा, फ्यूज़ों की जगह अर्धचालक-आधारित स्मार्ट फ्यूज़ ले लेते हैं; I²t विशेषता वाले हाई-साइड स्विच कम फ्यूज़ विविधता और अधिक अनुकूलित केबल क्रॉस-सेक्शन प्रदान करते हैं। MCU, हाई-साइड स्विच और ट्रांसीवर से बना स्मार्ट पावर डिस्ट्रिब्यूशन बॉक्स एक ऐसी इकाई बन जाता है जिसकी कॉन्फ़िगरेशन सॉफ्टवेयर से की जाती है: वही बॉक्स प्रत्येक क्षेत्र में, भार के अनुसार अनुकूलित करके उपयोग किया जा सकता है।
भौतिक और तार्किक I/O का अलग होना
ज़ोनल मॉड्यूल, कई ECU के लॉजिकल इनपुट/आउटपुट फंक्शनों को एक ही जगह पर समेकित करके वायरिंग की जटिलता को कम करता है; जबकि सेंसर और एक्चुएटर के भौतिक स्थान सुरक्षित रहते हैं। एक कदम आगे, एंड डिवाइस "स्मार्ट" बन जाते हैं: स्थानीय सर्किट स्थिति की जानकारी बनाए रखता है और दोष निदान (फॉल्ट डायग्नोसिस) चलाता है। CAN FD Light जैसे सरलीकृत प्रोटोकॉल कुछ एंड नोड्स में अलग MCU की आवश्यकता को भी समाप्त कर सकते हैं। यह विभाजन, जिसमें हार्डवेयर स्थिर रहता है और कार्य को सॉफ्टवेयर से परिभाषित किया जाता है, SDV की इंजीनियरिंग रीढ़ है।
ज़ोनल वाहन में डेटा बस: बैंडविड्थ, टाइमिंग और साइबर सुरक्षा
सेंसर फ्यूजन और AI वर्कलोड, ज़ोनल टोपोलॉजी को उच्च-बैंडविड्थ बैकबोन पर आधारित करना अनिवार्य बना देते हैं: PCIe, 20 Mbps तक डेटा गति तक पहुँचने और मौजूदा CAN अनुकूलता बनाए रखने वाले CAN XL और गीगाबिट ईथरनेट। असली चुनौती बैंडविड्थ से परे टाइमिंग की है; छोटे नियंत्रण संदेश, ADAS सेंसर डेटा और इंफोटेनमेंट ट्रैफिक की विलंबता (लेटेंसी), जिटर और सिंक्रनाइज़ेशन की आवश्यकताएँ एक-दूसरे से बहुत अलग होती हैं। मोटे अनुमान ये हैं: ऑडियो के लिए मिलीसेकंड स्तर, और पावरट्रेन तथा शेसी नियंत्रण के लिए माइक्रोसेकंड स्तर की लेटेंसी लक्ष्य मान्य हैं।
इन विभिन्न ट्रैफिक वर्गों को एक ही नेटवर्क पर ले जाने के लिए ईथरनेट आधारित Time-Sensitive Networking (TSN) समाधान के रूप में सामने आता है। टाइम सिंक्रनाइज़ेशन (IEEE 802.1AS), टाइम-सेंसिटिव ट्रैफिक शेपिंग (802.1Qbv), एक्सप्रेस ट्रैफिक (802.3br), फ्रेम प्री-एम्प्शन (802.1Qbu) और रिडंडेंसी (802.1CB) जैसे मानक महत्वपूर्ण डेटा को नियतात्मक (डिटरमिनिस्टिक) लेटेंसी की गारंटी देते हैं। सुरक्षा के मोर्चे पर ISO 26262 समर्थन, रिडंडेंट संचार पथ, सुरक्षा पार्टीशनिंग और दोष पहचान निर्णायक हैं; साइबर सुरक्षा के मोर्चे पर ISO/SAE 21434 मानक, UNECE विनियम और MACsec जैसे निम्न-स्तरीय एन्क्रिप्शन-प्रमाणीकरण तंत्र निर्धारक हैं। चूँकि ज़ोनल आर्किटेक्चर नेटवर्क को केंद्रीकृत करता है, ईथरनेट आधारित हमले के तरीके भी संभव हो जाते हैं; सुरक्षा उल्लंघन की स्थिति में I/O-प्रोसेसिंग विभाजन अवधारणा का ध्वस्त होना एक ऐसा जोखिम है जिसका अलग-अलग मूल्यांकन किया जाना चाहिए।
हार्डवेयर-सॉफ्टवेयर विभाजन OTA अपडेट को कैसे संभव बनाता है?
OTA अपडेट अधिकांश SDV चर्चाओं में सबसे पहले सोचा जाने वाला फीचर है, लेकिन यह अकेले कोई क्षमता नहीं, बल्कि एक आर्किटेक्चरल परिणाम है। सॉफ्टवेयर को हार्डवेयर एब्स्ट्रैक्शन लेयर (HAL) के माध्यम से विशिष्ट चिप्स से अलग किए बिना और वाहन कार्यों को स्वतंत्र, पुन: प्रयोज्य, ढीले रूप से जुड़ी सेवाओं में विभाजित किए बिना (सर्विस-ओरिएंटेड आर्किटेक्चर, SOA) निरंतर अपडेट प्रदान नहीं किया जा सकता। यह विभाजन विभिन्न सुरक्षा स्तरों वाले सॉफ्टवेयर के एक-दूसरे से पृथक्करण को भी शामिल करता है।
इसका ठोस अर्थ यह है: zone आर्किटेक्चर, OTA/FOTA अपडेट और निरंतर क्लाउड कनेक्शन के साथ उच्च-स्तरीय सॉफ़्टवेयर रखरखाव का नियंत्रण निर्माता को देते हुए, वास्तविक समय के नियंत्रण लूपों को zone मॉड्यूल में स्थानांतरित किया जा सकता है। इलेक्ट्रिक वाहनों में उपयोग में न आने वाले मॉड्यूल की पावर डाउन जैसी बारीक सेटिंग्स भी इस संरचना में आसान हो जाती हैं। अंततः इलेक्ट्रिक वाहन का सॉफ़्टवेयर, केवल एक अपडेट चैनल होने से कहीं आगे, वाहन की विशेषताओं, सुरक्षा प्रणालियों और प्रदर्शन चरित्र को निर्धारित करने वाली एक परिभाषा परत है। वाहन, पहियों पर वितरित एक डेटा सेंटर जैसा दिखने लगता है; मूल्य श्रृंखला सॉफ़्टवेयर, प्रोसेसिंग पावर और सिस्टम आर्किटेक्चर पर टिकी होती है।
संक्रमण कितना तेज़ होगा और केवल ज़ोनल आर्किटेक्चर पर्याप्त होगा?
संक्रमण क्रमिक होगा। बॉडी (body) डोमेन, कई वितरित एक्चुएटर और सेंसर ECU शामिल होने के कारण zone आर्किटेक्चर में जाने वाला पहला क्षेत्र होगा; ADAS, पावरट्रेन और शेसी नियंत्रण का संक्रमण सुरक्षा-महत्वपूर्ण स्वभाव के कारण अधिक समय ले सकता है। 2017 से MCAL, BSW और एप्लिकेशन परतों में हुआ विकास दिखाता है कि यह कोई तकनीकी परियोजना नहीं बल्कि पूरे उद्योग-स्तरीय मानसिकता परिवर्तन है।
संतुलित पढ़ाई भी ज़रूरी है। ज़ोनल आर्किटेक्चर वाहन को भौतिक रूप से पुनर्गठित करता है; तार्किक और सॉफ़्टवेयर पक्ष (SOA, HAL, साइबर सुरक्षा) को अलग से हल करना होगा - केवल तारों को पुनर्व्यवस्थित करना वाहन को सॉफ़्टवेयर-डिफ़ाइंड नहीं बनाता। बाज़ार आकार के अनुमान भी क्षेत्र की परिभाषाओं के अनुसार गंभीर रूप से बदलते हैं; E/E आर्किटेक्चर बाज़ार से संबंधित अलग-अलग आंकड़े, इस बात पर निर्भर करते हैं कि बाज़ार की गणना कैसे की जा रही है (केवल प्रोसेसिंग प्लेटफ़ॉर्म, या सम्पूर्ण वितरित इलेक्ट्रॉनिक्स)। साथ ही यह नहीं भूलना चाहिए कि संक्रमण के पक्षकार सेमीकंडक्टर और समाधान प्रदाता स्वाभाविक रूप से इस परिवर्तन के पक्ष में हैं।
निष्कर्ष एक स्पष्ट इंजीनियरिंग संतुलन है: वाहन का सॉफ़्टवेयर द्वारा परिभाषित होना केवल एक सॉफ़्टवेयर परियोजना नहीं, बल्कि डोमेन और ज़ोनल नियंत्रकों पर आधारित नए हार्डवेयर संगठन, अलग की गई सॉफ़्टवेयर परतों और नियतात्मक, सुरक्षित डेटा रीढ़ के एक साथ अस्तित्व से संभव है। OTA अपडेट इस एकीकृत संरचना का सबसे दृश्यमान फल है; असली क्रांति, वाहन के हार्डवेयर के अपने कार्य का परिभाषा सॉफ़्टवेयर को सौंपने में है।
स्रोत
- पूर्ण सॉफ्टवेयर-परिभाषित वाहन के मार्ग के रूप में ज़ोन आर्किटेक्चर कैसे काम करता है (TI SPRY345)
- डोमेन बनाम ज़ोनल आर्किटेक्चर: एक संपूर्ण गाइड
- सॉफ्टवेयर परिभाषित वाहनों (SDVs) के लिए ज़ोनल E/E आर्किटेक्चर
- ऑटोमोटिव ज़ोनल आर्किटेक्चर
- ऑटोमोटिव ज़ोन कंट्रोलर
- ज़ोन कंट्रोल यूनिट (ZCU)
- सॉफ्टवेयर-परिभाषित वाहन क्या है
- सॉफ्टवेयर-परिभाषित वाहनों (SDVs) को समझना
- सॉफ्टवेयर-परिभाषित वाहन (SDV) की व्याख्या
- सुरक्षा फ़ंक्शन डिकपलिंग क्यों आवश्यक है
- SDVs के लिए सर्विस-ओरिएंटेड आर्किटेक्चर
- सर्विस-ओरिएंटेड आर्किटेक्चर (SOA) क्या है?
- सॉफ्टवेयर-परिभाषित वाहन का उदय: आर्किटेक्चर और चुनौतियां
- भविष्य का E/E आर्किटेक्चर
- वाहन इलेक्ट्रॉनिक्स आर्किटेक्चर
- SDVs में आर्किटेक्चर को फिर से परिभाषित करना