वीकेंड के दौरान software update से कुछ Jeep 4xe hybrid गाड़ियां brick हो गईं

 (arstechnica.com)
1 पॉइंट द्वारा GN⁺ 2025-10-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कुछ Jeep Wrangler 4xe hybrid मालिकों ने वीकेंड के दौरान किए गए OTA software update के बाद वाहन के रुक जाने की समस्या का अनुभव किया
  • यह update Uconnect infotainment system की telematics के लिए था, लेकिन इसे पूरी तैयारी के बिना जारी कर दिया गया
  • समस्या update के तुरंत बाद नहीं, बल्कि चलते समय powertrain error के रूप में सामने आई, जिससे वाहन रुक गए
  • Jeep ने समस्या की रिपोर्ट मिलने के बाद update rollout रोक दिया, लेकिन तब तक यह कई वाहनों में डाउनलोड हो चुका था
  • बाद में Jeep ने fix patch जारी किया और जिन मालिकों ने अभी update install नहीं किया था, उन्हें इसे ignore करने की सलाह दी

Jeep 4xe hybrid वाहनों में OTA software update issue

issue overview

  • कुछ Jeep Wrangler 4xe hybrid मालिकों ने वीकेंड के दौरान OTA software update install करने के बाद अचानक चलते समय वाहन रुक जाने की समस्या झेली
  • यह समस्या Uconnect infotainment system के telematics update को पर्याप्त तैयारी के बिना जारी करने से हुई

समस्या कैसे हुई

  • समस्या तुरंत दिखाई नहीं दी, बल्कि update के बाद ड्राइविंग के दौरान power loss और वाहन रुकने की स्थिति बनी
  • कुछ मालिकों ने इसे रिहायशी इलाकों या कम गति वाले माहौल में अनुभव किया, लेकिन हाइवे पर चलते समय powertrain failure के मामले भी दर्ज किए गए

प्रतिक्रिया और कदम

  • Jeep ने समस्या की रिपोर्ट मिलने के बाद इस update का rollout रोक दिया, लेकिन तब तक कई वाहन update डाउनलोड कर चुके थे
  • Stellantis social team ने Jeep forum के जरिए उन मालिकों को update popup को ignore करने की सलाह दी, जिन्होंने इसे अभी install नहीं किया था

अस्थायी सलाह

  • जिन मालिकों ने update install कर लिया है लेकिन अभी तक समस्या नहीं आई, उन्हें hybrid mode या electric mode के इस्तेमाल से बचने की सलाह दी गई
  • बाद में Jeep ने समाधान के तौर पर fix patch (corrective update) को आपात रूप से जारी किया

पृष्ठभूमि और सबक

  • पिछले साल के Crowdstrike मामले की तरह, यह घटना भी दिखाती है कि शुक्रवार दोपहर के software update बड़े पैमाने पर समस्या पैदा कर सकते हैं
  • इस घटना से Stellantis को भी update timing और pre-release testing की अहमियत का सबक मिला
  • फिलहाल Stellantis की ओर से कोई आधिकारिक प्रतिक्रिया नहीं आई है, आगे की जानकारी बाद में update की जाएगी

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-14
Hacker News राय
  • मेरी 4xe गाड़ी शनिवार के software update के बाद घर के सामने ही बंद हो गई, और मैं 4xe मालिक के नज़रिए से बताना चाहता हूँ कि Jeep/Stellantis की प्रतिक्रिया कितनी खराब थी
    • सोमवार सुबह 8 बजे तक Jeep के किसी official account या कंपनी की तरफ से कोई संचार या स्वीकारोक्ति नहीं थी
    • मुझे भी समस्या का पता Facebook के Jeep groups में यह खोजते हुए चला कि क्या किसी और को भी यही लक्षण आ रहे हैं
    • सबसे "official" जानकारी भी Jeep द्वारा चलाए जाने वाले 'JeepCares' account की off-road forum post भर थी, और उस account से आई गाइडेंस भी आपस में मेल नहीं खा रही थी। पहले कहा गया कि Uconnect update और telematics update अलग हैं, फिर बाद में Uconnect update टालने की सलाह दी गई, मानो दोनों updates जुड़े हुए हों
    • Jeep की तरफ से जानकारी न होने के कारण लोग हर तरह की अफवाहों पर निर्भर थे, जैसे "किसी भी mode में Uconnect reboot करो तो check engine light बंद हो जाती है"। वास्तव में शिकायत कुछ समय के लिए शांत हो जाती थी, लेकिन मूल समस्या हल नहीं होती थी
    • यह जानने का कोई तरीका नहीं है कि खराब update मिला भी है या नहीं
    • यह जानने का भी कोई तरीका नहीं है कि patch मिला या नहीं
    • dealers को भी स्थिति के बारे में बिल्कुल जानकारी नहीं है
    • और मैं यह लिखते समय भी इस जोखिम में हूँ कि highway के बीच अचानक power loss हो और गाड़ी रुक जाए
    • यह सचमुच चौंकाने वाली बात है कि highway पर गाड़ी चलते समय power system, यानी engine, बंद हो सकता है। लेख के मुताबिक यह वास्तव में हुआ, और कुछ मामलों में यह घर के पास कम रफ्तार पर हुआ, लेकिन कुछ लोगों का कहना है कि highway पर चलते समय drivetrain fail हुआ। यह बेहद गंभीर समस्या है
    • ऐसा असल दुनिया में हो रहा है, यह पागलपन जैसा है। कुछ साल पहले auto industry की investment due diligence करते समय मैंने कहा था कि update से पहले यह सुनिश्चित करना ज़रूरी है कि गाड़ी पूरी तरह रुकी हो और motor बंद हो। मुझे याद है कि सब लोगों को मेरा यह इशारा अजीब लगा था, जबकि साफ था कि ऐसी स्थिति बड़ी समस्या बन सकती है
    • यह बिल्कुल वैसा लगता है जैसे कोई team original deadline नहीं पकड़ पाई, काम बार-बार टालती रही, और फिर सबके छुट्टी plans के कारण किसी के पास जिम्मेदारी लेने की गुंजाइश न होने पर code को जल्दबाज़ी में release कर दिया गया। समय के दबाव और confirmation bias में उन्होंने ऐसे code को push कर दिया जिसमें समस्या के संकेत थे, और अब मुख्य लोग या तो flight में हैं, संपर्क से बाहर हैं, या laptop के बिना छुट्टी पर हैं, इसलिए response नहीं दे पा रहे
    • मुझे यह जानने की जिज्ञासा है कि उन्होंने कैसे validate किया कि driving के दौरान software update चल सकता है और इससे power loss हो सकता है। मैं पहले automotive supplier में काम करता था, वहाँ update corruption risk से बचाने के लिए कई safeguards थे, और सबसे बुनियादी safeguard यह था कि UDS programming session में जाने से पहले vehicle speed या drive mode पर आधारित checks होते थे
  • मैंने हाल ही में एक बड़ी home lighting company में काम करते हुए bulbs और internet/user connectivity संभालने वाले router OS पर development किया है। हमारी OTAU architecture dual boot slot वाले A/B system update model पर आधारित है (संदर्भ लिंक)। इस तरीके में update fail होने पर अपने-आप पिछला version rollback हो जाता है, इसलिए कभी brick नहीं हुआ। ध्यान रहे, यह $100 से कम कीमत का consumer appliance है। ऐसे में यह देखकर संदेह होता है कि $50k-$60k SUV में ऐसा safety mechanism नहीं है, शायद cost cutting की वजह से। इस स्तर की गाड़ी में NAND capacity दोगुनी करने पर भी कुल cost का 0.5% नहीं बनेगा। अगर सच में boot slot corruption है तो बात अलग है, लेकिन carmakers अपने distribute किए जाने वाले code को लेकर इतने लापरवाह हैं, यह निराशाजनक है
    • IoT lights और automotive दोनों में काम करने के अनुभव से मैं दोनों industries की तुलना कर सकता हूँ। मेरा बचाव करने का इरादा नहीं है। बड़ी automakers भी cost optimization को लेकर बेहद संवेदनशील होती हैं, और मुझे नहीं लगता कि यह boot slot issue है। ज़्यादातर automotive software इस तरह design किया जाता है कि vehicle चलते समय update न हो सके। यह घटना शायद नए firmware में गंभीर bug की वजह से हुई। यह भी सही है कि automotive industry कुल मिलाकर बहुत नीचे जा चुकी है, लेकिन Stellantis खास तौर पर top-tier salary देने वाली company नहीं है
    • Android devices में भी (और कई vehicles में भी) brick risk घटाने के लिए ऐसे ही A/B partitions इस्तेमाल होते हैं। लेकिन यह तरीका भी जोखिम पूरी तरह खत्म नहीं करता। अगर logic जटिल हो और कई child devices को एक साथ update करना पड़े, तो 2*N partitions के मेल की ज़रूरत पड़ती है और हर checkpoint पर failure की संभावना रहती है। आम तौर पर अगर "सब कुछ ठीक है" checkpoint बहुत जल्दी mark कर दिया जाए, तो critical service fail होने पर भी system ऐसे state में जा सकता है जहाँ recovery संभव नहीं रहती
    • Automotive जैसे $50k-$60k device में 0.5% cost का असर भी बड़ा होता है। उदाहरण के लिए Ford का operating margin 2% है, तो vehicle per 0.5% cost increase profit margin को 25% तक घटा सकता है। गाड़ियों की annual shipment volume तुलनात्मक रूप से कम होती है, और chips की requirements भी सख्त होती हैं, इसलिए component cost ऊँची हो सकती है। A/B update भी पूर्ण समाधान नहीं है; गलत configuration होने पर infinite loop में फँस सकता है
    • मैंने सुना है कि automotive industry में device per $5 से कम लागत पर भी बहुत तीखी संवेदनशीलता होती है। हो सकता है A/B update शुरू से ही spec में शामिल न रहा हो, या OTA size बढ़ने से storage limit आ गई हो। और सुरक्षित बनाना हो तो A/B/A (जहाँ B lightweight OS हो) भी किया जाता है, लेकिन development time की कमी के कारण यह व्यावहारिक रूप से मुश्किल होता है
    • $100 के device में भी A/B model इस्तेमाल होता है, इसलिए ऐसी समस्या cost cutting से ज़्यादा priorities और capability की समस्या लगती है। हो सकता है update safety mechanism spec से ही गायब रहा हो और schedule pressure व जिम्मेदारी टालने की संस्कृति के बीच यह दुर्घटना हुई हो। असल में इस घटना में brick नहीं, बल्कि driving के दौरान fatal bug हुआ था
  • मैंने Jeep Wagoneer किराए पर ली थी, और उसकी electronics इतनी खराब थीं कि ऐसी घटना पर हैरानी नहीं होती। दूसरे ही दिन liftgate बंद नहीं हुई और dashboard पर error message आने लगा, electronic lock बिल्कुल काम नहीं कर रहा था। खोजने पर बहुत से लोग उसी समस्या की बात कर रहे थे और उन्हें software update की सलाह दी गई थी, जबकि कोई manual release तरीका भी नहीं था। rental company का outlet पास में था इसलिए गाड़ी बदल ली, लेकिन उसके बाद भी कई समस्याएँ देखीं
    • पीछे की सीट से Steam Deck charger लगाते ही infotainment system सहित पूरा instrument cluster बार-बार बंद होकर फिर चालू हो जाता था
    • driver seat नीचे झुक जाती थी ताकि बाहर निकलना आसान हो, लेकिन अपनी जगह अपने-आप वापस नहीं आती थी, इसलिए हर बार और पीछे खिसकती जाती थी
    • पीछे की सीट latch error warning लगातार आती थी जिसे बंद नहीं किया जा सकता था, जबकि latch बिल्कुल ठीक था
    • TPMS warning light बार-बार जलती और बुझती थी (खराब signal)
    • cruise control से जुड़ी error random तरीके से आती थी
    • electronic parking brake parking lot में थोड़ी देर रुकने पर अपने-आप लग जाती थी
    • cooling system अजीब तरह से काम करता था, केबिन गरम रहता था या AC ही काम नहीं करता था
    • online ऐसे बहुत लोग हैं जिन्हें इसी तरह की या इससे भी गंभीर समस्याएँ हुई हैं। $80k की नई गाड़ी में ऐसे issues होना भरोसे से बाहर है
    • हाल की family trip में हमने Grand Wagoneer की 4 अलग-अलग गाड़ियाँ बदलीं, और हर एक में कोई न कोई critical समस्या थी
    • Jeep और Stellantis/Dodge की quality control और electrical/electronic design बेहद खराब हैं। इनके fandom communities बहुत हैं, लेकिन वहाँ बार-बार आने वाले defects को भी सामान्य या स्वीकार्य बताने की प्रवृत्ति है। ऐसी गाड़ी खरीदना अपने ही खिलाफ फैसला है
  • OTA से ECU जैसे critical components update करना सचमुच अस्वीकार्य जोखिम लगता है। अगर किसी कारण यह बिल्कुल ज़रूरी हो, तो मेरी राय में यह dealer पर expert की मौजूदगी में rollback की तैयारी के साथ होना चाहिए। manufacturers हर चीज़ automate करके subscription services से कमाई करना चाहते हैं, और इस चक्कर में consumer safety को नुकसान पहुँचा रहे हैं। इसी वजह से मेरे जैसे car enthusiasts पुरानी गाड़ियाँ ज़्यादा पसंद करते हैं
  • Stellantis ने हाल ही में 'vibe coding' engineering workflow लागू किया था, और उसके दो हफ्ते भी नहीं बीते कि यह घटना हो गई (संबंधित समाचार)
    • लेकिन अगर code OTA के ज़रिए real vehicle fleet तक push हुआ, तो कम-से-कम वह code दो हफ्ते से पहले लिखा गया होगा
  • मैं कुछ महीनों से Jeep चला रहा हूँ, और community पूरी तरह mods पर केंद्रित रहती है, लेकिन OS के SiriusXM द्वारा विकसित बंद source होने को लेकर असंतोष है। Jeep Wrangler तो open source के लिए सबसे उपयुक्त vehicles में से एक होना चाहिए
    • ऐसा नहीं है कि Wrangler mods में software hacking सक्रिय नहीं है। संबंधित forum में बताई गई चीज़ों के आधार पर commercial product तक निकाला गया है। लेकिन head unit firmware के पूरी तरह crack होने का उदाहरण मैंने अभी तक नहीं देखा
    • क्या Jeep वही company नहीं है जिसने traffic signal पर रुकते समय popup ads दिखाने वाला infotainment ad system डाला था? manufacturer भला open source OS क्यों चाहेगा, अगर उससे ऐसे ads bypass हो सकते हों
  • मुझे समझ नहीं आता कि OTA update से पूरी गाड़ी brick कैसे हो सकती है। मेरा तो मानना है कि infotainment system और driving system पूरी तरह अलग होने चाहिए
    • यह निष्कर्ष इस धारणा से निकला कि यह सिर्फ infotainment OTA था। असल में यह full vehicle OTA है। यह infotainment, ECU, ECM, TCM, BCM सबको छू सकता है, और बड़े recalls भी OTA से ठीक किए जाते हैं, इसलिए critical systems के updates को रोकना व्यावहारिक नहीं है। 2025 तक ज़्यादातर manufacturers के पास ऐसी OTA capability है
    • ऐसी समस्याओं की जड़ cost cutting है। instrument cluster और infotainment सब analog के बजाय monitors से बदले जा रहे हैं क्योंकि इससे उत्पादन सस्ता पड़ता है। software भी "rewrite नहीं, सिर्फ reuse" वाली सोच के साथ जगह-जगह जोड़ा जाता है, इसलिए integration testing कमजोर होना तय है। EV era में हर motor controller का अपना software है, और OTA उससे भी ऊपर लिख सकता है। शायद सिर्फ Toyota ही अपने लंबे अनुभव के कारण अपेक्षाकृत कम समस्या झेल रही है
    • रोज़मर्रा की जानकारी भी, जैसे parking sensors चलते समय music mute करना, fuel या battery level दिखाना, driving system और infotainment के बीच interaction माँगती है, इसलिए पूरी तरह isolation संभव नहीं है
    • पहले मेरे Tahoe में OTA update से infotainment brick हो गया था। उसके बाद backup camera भी बिल्कुल बंद हो गया, और turn signal की आवाज़ तक नहीं आती थी, जिससे towing और repair पर लगभग $2,000 खर्च हो गए, लेकिन warranty भी लागू नहीं हुई। इसलिए मैंने तय किया कि आगे से सभी updates बंद रखूँगा
    • Tesla ने इस तरह के integrated OTA की मिसाल बनाई, और उसके बाद अधिकतर manufacturers उसी रास्ते पर चल रहे हैं। Volvo को भी ऐसी ही समस्याएँ हुई हैं
  • मुझे समझ नहीं आता कि infotainment systems इतने engineers के लिए बार-बार समस्या क्यों बनते हैं। Mazda 3 (2018) के मामले में तो class-action lawsuit तक हुआ। कई साल सामान्य रूप से चलने के बाद अचानक menus random तरीके से react करने लगते हैं, buttons अपने-आप दबने लगते हैं, फिर यह समस्या दिनों या महीनों तक गायब रहती है और फिर लौट आती है। आख़िर में मुझे सारे device connections हटाकर सिर्फ radio सुनते हुए गाड़ी चलानी पड़ी
    • जड़ समस्या यह है कि शुरू से vertical integration नहीं है, features के हिसाब से 20,000 से ज़्यादा ECU अलग-अलग बँटे हैं, और subcontractors पर दबाव डालकर हर हिस्से में चरम cost cutting की जाती है। साथ ही 'traditional' manufacturers और tier-1 suppliers software innovation अपनाने में लगभग कोई रुचि नहीं दिखाते
    • मैंने हाल ही में एक Android phone को Bluetooth से Mercedes vehicle से जोड़ा, और "luxury" brand होने के बावजूद setup process में ही पाँच GUI bugs मिल गए। गाड़ी का कुल fit and finish ठीक था, लेकिन software quality साफ तौर पर इरादे की बात है। (वैसे set-top box UIs भी hardware specs की तुलना में अनावश्यक रूप से धीमे होते हैं)
    • यह समस्या बस outsourcing और cost cutting की है। Vertical integration नहीं है, और काम सबसे सस्ते बाहरी vendor को दे दिया जाता है
    • मैं पहले infotainment software vendor में काम कर चुका हूँ, और वे systems cost cutting की पराकाष्ठा थे। न्यूनतम RAM, न्यूनतम CPU, घटिया display — यहाँ तक कि premium vehicles में भी। car radios लंबे समय से cost cutting का प्रतीक रहे हैं
    • phones की तरह हर साल नया product launch करने की बात ही छोड़िए, vehicles में एक device को दस साल से भी ज़्यादा टिकना पड़ता है और वह भी न्यूनतम staff के साथ लगातार भरोसेमंद तरीके से काम करना चाहिए
  • Tesla OTA updates से पूरी गाड़ी brick होने के मामले (यानी सचमुच बिल्कुल न चलने वाली brick स्थिति) बड़े पैमाने पर सुनाई नहीं देते। मेरी जानकारी में Tesla dual BIOS जैसी architecture पर बना है, motherboard के dual BIOS की तरह
    • मैं 10 साल से ज़्यादा समय से Tesla communities को follow कर रहा हूँ, लेकिन OTA से brick होने का मामला नहीं देखा। आम तौर पर लोगों की शिकायत बस इतनी होती है कि update लग गया और उन्हें अचानक जल्दी कहीं निकलना था, तो असुविधा हुई
    • Tesla बहुत ज़्यादा HIL testing करता है, और उसका overall testing approach पारंपरिक manufacturer से ज़्यादा software company जैसा है
    • हालाँकि Google करने पर Tesla OTA brick के मामले बिल्कुल नहीं हैं, ऐसा भी नहीं है। संबंधित उदाहरण
  • सप्ताहांत की चर्चा का संदर्भ लिंक