গাড়ি কি এখন সফ্টওয়্যার দিয়েই সংজ্ঞায়িত হচ্ছে? ডোমেইন আর্কিটেকচার এবং SDV রূপান্তর

এই পেজটি শেয়ার করুন
হ্যাঁ: আধুনিক অটোমোবাইলের আচরণ, বৈশিষ্ট্য এবং পারফরম্যান্স ক্যারেক্টার এখন প্রাথমিকভাবে সফটওয়্যার দ্বারা নির্ধারিত হয়। সফটওয়্যার-ডিফাইন্ড ভেহিকল (SDV) নামে পরিচিত এই রূপান্তর, যানবাহনের ইলেকট্রনিক আর্কিটেকচারকে ECU-র স্তূপ থেকে ডোমেইন এবং জোনাল কন্ট্রোলারে নিয়ে গিয়ে হার্ডওয়্যার ও সফটওয়্যারকে পরস্পর থেকে আলাদা করে এবং কেবলিং ওজন থেকে OTA আপডেট পর্যন্ত সবকিছুকে নতুন রূপ দেয়।
উল্লেখযোগ্য বিষয়সমূহ
- আধুনিক গাড়িতে ১০০ বা তার বেশি কন্ট্রোল ইউনিট থাকতে পারে; নতুন আর্কিটেকচার এই সংখ্যা ২০% পর্যন্ত কমানোর লক্ষ্য রাখে।
- ডোমেইন আর্কিটেকচার ফাংশন অনুযায়ী, জোনাল আর্কিটেকচার ভৌত অবস্থান অনুযায়ী সংগঠিত করে।
- জোনাল টপোলজিতে CAN XL (২০ Mbps পর্যন্ত) এবং গিগাবিট ইথারনেটের মতো উচ্চ ব্যান্ডউইথের ব্যাকবোন ব্যবহৃত হয়।
- OTA আপডেট হল হার্ডওয়্যার-সফটওয়্যার বিচ্ছেদের কারণে সম্ভব হওয়া একটি মৌলিক SDV সক্ষমতা।
- রূপান্তরটি ধাপে ধাপে হয়: প্রথম ক্ষেত্র হল বডি ডোমেইন; ADAS, পাওয়ারট্রেইন এবং চ্যাসিস আরও দীর্ঘ সময় বর্তমান কাঠামোতে থাকতে পারে।
সফটওয়্যার-ডিফাইন্ড ভেহিকল আসলে কী?
সংজ্ঞা স্পষ্ট: সফটওয়্যার-ডিফাইন্ড ভেহিকল হল এমন একটি যানবাহন যার কার্যকারিতা ও আচরণ প্রাথমিকভাবে হার্ডওয়্যারের পরিবর্তে সফটওয়্যার দ্বারা নির্ধারিত হয়। ঐতিহ্যবাহী অটোমোবাইলে একটি বৈশিষ্ট্য সেই ফাংশনের জন্য বিশেষভাবে তৈরি একটি হার্ডওয়্যার অংশ দিয়ে সংজ্ঞায়িত হতো; SDV-তে একই হার্ডওয়্যার তার উপর চলমান সফটওয়্যারের মাধ্যমে ভিন্ন ফাংশন ধারণ করতে পারে। যানবাহন বিক্রি হওয়ার পরেও নতুন বৈশিষ্ট্য যোগ করা যায়, আচরণ ক্যালিব্রেট করা যায়, ত্রুটিগুলো দূর থেকে সংশোধন করা যায়।
আধুনিক E/E আর্কিটেকচার ১০০ বা তার বেশি কন্ট্রোল ইউনিট নিয়ে গঠিত; নতুন প্রজন্মের কাঠামো কন্ট্রোল ইউনিটের সংখ্যায় ২০% পর্যন্ত এবং উপকরণ ও হার্ডওয়্যারে ১০% পর্যন্ত সাশ্রয় করে।
এই বাক্যের বহন করা সংখ্যাগুলো রূপান্তরের পরিধি সংক্ষেপে তুলে ধরে। সমস্যাটি শুধু কন্ট্রোল ইউনিটের সংখ্যা নয়: প্রতিটি ECU নিজস্ব কেবলিং, নিজস্ব সফটওয়্যার স্ট্যাক এবং নিজস্ব যাচাইকরণের বোঝা নিয়ে আসে। SDV-এর লক্ষ্য হল এই বিক্ষিপ্ত কাঠামোকে এমন একটি সিস্টেমে রূপান্তর করা যেখানে সফটওয়্যার একটি একক সামঞ্জস্যপূর্ণ স্তরে এটি পরিচালনা করতে পারে। এর জন্য ইলেকট্রনিক আর্কিটেকচারের শুরু থেকে নতুন করে পরিকল্পনা করা প্রয়োজন।
ECU থেকে ডোমেইন আর্কিটেকচার: ফাংশন অনুযায়ী গ্রুপিং
একটি অটোমোবাইলের প্রতিটি ছোট ফাংশনের আলাদা ইলেকট্রনিক কন্ট্রোল ইউনিট (ECU) থাকার যুগটি কেবলিং হার্নেসগুলোকে অপরিচালনযোগ্য করে তুলেছিল। ডোমেইন আর্কিটেকচার এর প্রথম ব্যবস্থাপনাগত উত্তর ছিল: যানবাহনের ইলেকট্রনিক্সকে ADAS, ইনফোটেইনমেন্ট, পাওয়ারট্রেইন, বডি ইলেকট্রনিক্স, চ্যাসিস এবং সেফটির মতো বড় কার্যকরী ক্ষেত্র অনুযায়ী সংগঠিত করে। প্রতিটি ডোমেইনে সাধারণত নিজস্ব প্রসেসর, সফটওয়্যার স্ট্যাক, যোগাযোগ ইন্টারফেস, সেন্সর এবং অ্যাকচুয়েটর থাকে এবং একটি ডোমেইন কন্ট্রোলার দ্বারা পরিচালিত হয়।
এই কাঠামো ECU-র বিশৃঙ্খলার তুলনায় উল্লেখযোগ্য সরলীকরণ এনে দিয়েছিল। তবে SDV-এর লক্ষ্য বাড়ার সাথে সাথে ডোমেইন আর্কিটেকচারের সীমাবদ্ধতা প্রকাশ পেতে থাকে। বিশেষত স্বায়ত্তশাসিত ফাংশনগুলোর উৎপন্ন সেন্সর ডেটা ঐতিহ্যবাহী CAN নেটওয়ার্কের ব্যান্ডউইথকে তার সীমায় ঠেলে দিয়েছিল। এছাড়াও প্রতিটি ডোমেইনের নিজস্ব প্রসেসিং রিসোর্স বহন করা ওয়্যারিং হার্নেসকে জটিল রেখেছিল এবং সফ্টওয়্যারের গাড়িজুড়ে স্কেল করা কঠিন করে তুলেছিল।
জোনাল আর্কিটেকচার: সংগঠন ফাংশন থেকে অবস্থানের দিকে এগোচ্ছে
জোনাল আর্কিটেকচার যুক্তিটি উল্টে দেয়: ইলেকট্রনিক্সগুলোকে ফাংশন অনুযায়ী নয়, বরং গাড়ির মধ্যে ভৌত অবস্থান অনুযায়ী গোষ্ঠীভুক্ত করে। গাড়িটি সামনে-বাম, সামনে-ডান, পিছনে-বাম, পিছনে-ডান এবং কেবিনের মতো অঞ্চলে বিভক্ত হয়; প্রতিটি অঞ্চলে একটি জোনাল কন্ট্রোলার সেই অঞ্চলের সেন্সর, অ্যাকচুয়েটর এবং পাওয়ার ডিস্ট্রিবিউশনকে একত্রিত করে এবং কেন্দ্রীয় উচ্চ-পারফরম্যান্স প্রসেসিং প্ল্যাটফর্মের সাথে যোগাযোগ করে।
| বৈশিষ্ট্য | ডোমেইন আর্কিটেকচার | জোনাল আর্কিটেকচার |
|---|---|---|
| সংগঠনের নীতি | ফাংশন অনুযায়ী (powertrain, 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) নিরবচ্ছিন্ন আপডেট দেওয়া সম্ভব নয়। বিচ্ছেদ একই সঙ্গে ভিন্ন নিরাপত্তা স্তরের সফটওয়্যারের একে অপর থেকে বিচ্ছিন্ন থাকাও অন্তর্ভুক্ত করে।
এর বাস্তব অর্থ এই: জোন আর্কিটেকচার OTA/FOTA আপডেট ও অবিরাম ক্লাউড সংযোগের মাধ্যমে উচ্চস্তরের সফটওয়্যার রক্ষণাবেক্ষণের নিয়ন্ত্রণ প্রস্তুতকারকের হাতে তুলে দেয়, আর রিয়েল-টাইম কন্ট্রোল লুপগুলো জোন মডিউলে স্থানান্তর করতে পারে। ব্যবহারে না থাকা মডিউলের পাওয়ার ডাউনের মতো সূক্ষ্ম সমন্বয়ও এই কাঠামোয় সহজ হয়ে যায়। শেষ পর্যন্ত বিশ্লেষণ করলে দেখা যায়, ইলেকট্রিক যানবাহনের সফটওয়্যার কেবল একটি আপডেট চ্যানেল হওয়ার পাশাপাশি যানবাহনের বৈশিষ্ট্য, নিরাপত্তা ব্যবস্থা এবং পারফরম্যান্সের চরিত্র নির্ধারণকারী সংজ্ঞা স্তর। যানবাহন ধীরে ধীরে চাকার উপর ছড়িয়ে থাকা একটি ডেটা কেন্দ্রের মতো হয়ে উঠছে; মূল্য শৃঙ্খল সফটওয়্যার, প্রসেসিং ক্ষমতা এবং সিস্টেম আর্কিটেকচারের উপর নির্ভরশীল।
রূপান্তর কত দ্রুত হবে এবং শুধু জোনাল আর্কিটেকচারই কি যথেষ্ট?
রূপান্তরটি ধাপে ধাপে হবে। বডি (body) ডোমেইন, অসংখ্য বিতরণকৃত অ্যাকচুয়েটর ও সেন্সর ECU ধারণ করার কারণে জোন আর্কিটেকচারে রূপান্তরিত হওয়া প্রথম ক্ষেত্র; ADAS, পাওয়ারট্রেন এবং শেসি নিয়ন্ত্রণের রূপান্তর অবশ্য নিরাপত্তা-সংকটাপন্ন প্রকৃতির কারণে আরও বেশি সময় নিতে পারে। 2017 সাল থেকে MCAL, BSW এবং অ্যাপ্লিকেশন স্তরে ঘটে যাওয়া বিবর্তন দেখাচ্ছে যে এটি কেবল একটি কারিগরি প্রকল্প নয়, বরং সেক্টরব্যাপী একটি মানসিকতার পরিবর্তন।
ভারসাম্যপূর্ণ দৃষ্টিভঙ্গিও প্রয়োজন। জোনাল আর্কিটেকচার যানবাহনকে শারীরিকভাবে পুনর্গঠন করে; যৌক্তিক ও সফটওয়্যার দিকের (SOA, HAL, সাইবার নিরাপত্তা) সমাধান আলাদাভাবে করতে হবে - কেবল তারগুলো পুনর্বিন্যাস করলে একটি যানবাহন সফটওয়্যার-নির্ধারিত হয়ে ওঠে না। বাজারের আকার সংক্রান্ত পূর্বাভাসও পরিসরের সংজ্ঞা অনুযায়ী উল্লেখযোগ্যভাবে পরিবর্তিত হয়; E/E আর্কিটেকচার বাজার সম্পর্কিত বিভিন্ন সংখ্যা কাস্টমারের কী গণনা করা হচ্ছে (শুধু প্রসেসিং প্ল্যাটফর্ম, নাকি সম্পূর্ণ বিতরণকৃত ইলেকট্রনিক্স) তার উপর ভিন্নভাবে পরিমাপের ফল। এছাড়াও রূপান্তরের পক্ষগুলোর মধ্যে সেমিকন্ডাক্টর ও সমাধান প্রদানকারীরা এই রূপান্তরে স্বাভাবিকভাবেই পক্ষ রাখে - তা ভুলে যাওয়া উচিত নয়।
ফলাফল হল একটি স্পষ্ট প্রকৌশলগত ভারসাম্য: যানবাহনের সফটওয়্যার দ্বারা সংজ্ঞায়ন কেবল একটি সফটওয়্যার প্রকল্প নয়, বরং ডোমেইন ও জোনাল কন্ট্রোলার ভিত্তিক নতুন একটি হার্ডওয়্যার সংগঠন, বিভক্ত সফটওয়্যার স্তর এবং ডিটারমিনিস্টিক, নিরাপদ একটি ডেটা ব্যাকবোনের একযোগে অস্তিত্বের মাধ্যমেই সম্ভব। OTA আপডেট এই সমন্বিত কাঠামোর সবচেয়ে দৃশ্যমান ফল; প্রকৃত বিপ্লব হল যানবাহনের হার্ডওয়্যারের দায়িত্ব সফটওয়্যারের কাছে হস্তান্তরে।
সূত্রসমূহ
- How a Zone Architecture Paves the Way to a Fully Software-Defined Vehicle (TI SPRY345)
- Domain vs zonal architecture: a complete guide
- Zonal E/E Architecture for Software Defined Vehicles (SDVs)
- Automotive zonal architecture
- Automotive Zone Controller
- Zone Control Unit (ZCU)
- What is a Software-Defined Vehicle
- Understanding Software-Defined Vehicles (SDVs)
- Software-Defined Vehicle (SDV) Explained
- Why Safety Function Decoupling is Essential
- Service-Oriented Architecture for SDVs
- What Is Service-Oriented Architecture (SOA)?
- The Rise of the Software-Defined Vehicle: Architectures and Challenges
- The E/E architecture of the future
- Vehicle Electronics Architecture
- Redefining Architecture in SDVs