কেস স্টাডি: Boeing 737 MAX MCAS
এই পাঠে যা শিখবেন
- MCAS কী করার কথা ছিল এবং এর মূল ডিজাইন-সিদ্ধান্ত (একক সেন্সর, কোনো রিডানডেন্সি চেক ছাড়া)
- দুটি দুর্ঘটনা ও বিশ্বব্যাপী গ্রাউন্ডিং সম্পর্কে নথিভুক্ত তথ্য
- তদন্তে উঠে আসা প্রশিক্ষণ-ঘাটতি ও সার্টিফিকেশন-প্রক্রিয়া সংক্রান্ত উদ্বেগ
- কেন এটি "প্রবলেম অফ মেনি হ্যান্ডস"-এর একটি প্রামাণ্য উদাহরণ -- কোনো একক সরল ভিলেন নেই
- Python দিয়ে সেন্সর রিডানডেন্সি/ভোটিং-লজিক নামক প্রকৌশল-নীতির একটি ইলাস্ট্রেটিভ তুলনা
১ · MCAS কী করার কথা ছিল
MCASManeuvering Characteristics Augmentation SystemBoeing 737 MAX-এর একটি ফ্লাইট-কন্ট্রোল সফটওয়্যার ফিচার যা নির্দিষ্ট পরিস্থিতিতে স্বয়ংক্রিয়ভাবে বিমানের নাক নিচু করতে পারতো। ছিল Boeing 737 MAX বিমানের একটি ফ্লাইট-কন্ট্রোল সফটওয়্যার ফিচার। এর উদ্দেশ্য ছিল নির্দিষ্ট ফ্লাইট পরিস্থিতিতে বিমানের ম্যানুভারিং বৈশিষ্ট্য সামঞ্জস্যপূর্ণ রাখতে স্বয়ংক্রিয়ভাবে বিমানের নাক নিচু করা। মূল ডিজাইনে এই সিস্টেমটি একটি মাত্র অ্যাঙ্গেল-অফ-অ্যাটাক (angle-of-attack) সেন্সরের ইনপুটের উপর নির্ভর করতো -- দ্বিতীয় সেন্সরের সাথে তুলনা করে যাচাই করার কোনো রিডানডেন্সি-ব্যবস্থা ছিল না।
২ · দুটি দুর্ঘটনা ও বিশ্বব্যাপী গ্রাউন্ডিং
প্রায় পাঁচ মাসের ব্যবধানে দুটি মারাত্মক দুর্ঘটনা ঘটে: Lion Air Flight 610 (ইন্দোনেশিয়া, অক্টোবর ২০১৮, আনুমানিক ১৮৯ জন নিহত) এবং Ethiopian Airlines Flight 302 (ইথিওপিয়া, মার্চ ২০১৯, আনুমানিক ১৫৭ জন নিহত) -- একত্রে ৩০০-রও বেশি মানুষ প্রাণ হারান। এই দুর্ঘটনাগুলোর পর, সম্পূর্ণ 737 MAX বহর ২০১৯ সালের মার্চ মাস থেকে দীর্ঘ সময়ের জন্য বিশ্বব্যাপী গ্রাউন্ড করা হয়।
৩ · তদন্তে যা উঠে এসেছিল
পরবর্তী তদন্তে বেশ কয়েকটি সমস্যা চিহ্নিত হয়। প্রথমত, পাইলটদের প্রশিক্ষণ উপকরণে MCAS-এর অস্তিত্ব ও আচরণ সম্পর্কে পর্যাপ্তভাবে জানানো হয়নি -- ফলে কিছু পাইলট অপ্রত্যাশিত নাক-নিচু আচরণের সম্মুখীন হয়ে তা কী ও কেন ঘটছে তা দ্রুত বুঝতে পারেননি। দ্বিতীয়ত, একক-সেন্সর ডিজাইনে রিডানডেন্সির অভাব ছিল -- একটি সেন্সর ত্রুটিপূর্ণ তথ্য দিলে তা যাচাই করার কোনো স্বতন্ত্র ব্যবস্থা ছিল না। তৃতীয়ত, সার্টিফিকেশন প্রক্রিয়া নিয়ে উদ্বেগ উঠে আসে -- নিয়ন্ত্রক সংস্থার পক্ষ থেকে কতটা স্ব-সার্টিফিকেশনের অনুমতি দেওয়া হয়েছিল তা নিয়ে প্রশ্ন, এবং প্রতিযোগিতামূলক/খরচ সংক্রান্ত কারণে অতিরিক্ত পাইলট প্রশিক্ষণের প্রয়োজনীয়তা কমিয়ে রাখার প্রাতিষ্ঠানিক চাপ নিয়েও উদ্বেগ প্রকাশ করা হয়েছিল।
৪ · "প্রবলেম অফ মেনি হ্যান্ডস" -- কোনো একক ভিলেন নেই
এই কেসটিকে অ্যাকাউন্টেবিলিটি (accountability) নিয়ে আলোচনার একটি প্রামাণিক উদাহরণ হিসেবে বিবেচনা করা হয় -- কারণ কোনো একক ব্যক্তি বা সিদ্ধান্ত এককভাবে এই বিপর্যয়ের জন্য দায়ী নয়। যে ইঞ্জিনিয়াররা একক-সেন্সর ডিজাইন বেছে নিয়েছিলেন, যে ম্যানেজমেন্ট প্রশিক্ষণ-প্রয়োজনীয়তা সীমিত রাখতে চেয়েছিল, এবং যে নিয়ন্ত্রক সংস্থা সার্টিফিকেশন প্রক্রিয়া তদারকি করেছিল -- প্রত্যেকেই নিজ নিজ প্রেক্ষাপটে হয়তো তুলনামূলকভাবে যুক্তিসঙ্গত মনে হওয়া সিদ্ধান্ত নিয়েছিলেন, অথচ সেই সিদ্ধান্তগুলো একত্রে একটি মারাত্মক ব্যর্থতায় পরিণত হয়েছিল। পরবর্তী পাঠ (L27) এই "প্রবলেম অফ মেনি হ্যান্ডস" ধারণাটি আরও গভীরভাবে অন্বেষণ করবে।
৫ · সেন্সর রিডানডেন্সি -- একটি ইলাস্ট্রেটিভ ইঞ্জিনিয়ারিং তুলনা
নিচের কোড MCAS-এর প্রকৃত ইমপ্লিমেন্টেশন নয় -- বরং এটি সাধারণভাবে সেন্সর রিডানডেন্সিSensor Redundancyএকাধিক স্বতন্ত্র সেন্সরের রিডিং তুলনা করে সিদ্ধান্ত নেওয়ার প্রকৌশল-নীতি, যাতে একটি একক সেন্সরের ত্রুটি সরাসরি ভুল সিদ্ধান্তে রূপান্তরিত না হয়। নামক প্রকৌশল-নীতিটি একটি ছোট, জেনুইন উদাহরণে দেখানোর জন্য তৈরি একটি সরলীকৃত মডেল -- একক-সেন্সর পদ্ধতি বনাম বহু-সেন্সর ভোটিং/তুলনা পদ্ধতির মধ্যে পার্থক্য।
# শিক্ষামূলক ইলাস্ট্রেশন -- MCAS-এর প্রকৃত ইমপ্লিমেন্টেশন নয়, বরং "সেন্সর রিডানডেন্সি"
# নামক সাধারণ ইঞ্জিনিয়ারিং নীতিটি সংখ্যা দিয়ে দেখানোর একটি সরলীকৃত মডেল।
def single_sensor_decision(sensor_reading, threshold):
"""একটি মাত্র সেন্সরের উপর সরাসরি নির্ভর করে সিদ্ধান্ত নেয় -- সেন্সরটি ত্রুটিপূর্ণ হলেও"""
return sensor_reading > threshold
def voting_sensor_decision(sensor_readings, threshold, disagreement_limit):
"""একাধিক সেন্সরের রিডিং তুলনা করে -- মতবিরোধ সীমার বেশি হলে "ফল্ট" হিসেবে চিহ্নিত করে,
কোনো একটি রিডিংকে অন্ধভাবে বিশ্বাস না করে"""
spread = max(sensor_readings) - min(sensor_readings)
if spread > disagreement_limit:
return "fault_detected", None
average_reading = sum(sensor_readings) / len(sensor_readings)
return "ok", average_reading > threshold
threshold = 20.0 # ইলাস্ট্রেটিভ একক
# দৃশ্যকল্প ১: একটি সেন্সর ত্রুটিপূর্ণভাবে অস্বাভাবিক উচ্চ রিডিং দিচ্ছে, অন্য দুটি স্বাভাবিক
faulty_readings = [35.0, 8.0, 9.0]
single_result = single_sensor_decision(faulty_readings[0], threshold)
voting_status, voting_result = voting_sensor_decision(faulty_readings, threshold, disagreement_limit=10.0)
print("দৃশ্যকল্প ১: একটি সেন্সর ত্রুটিপূর্ণ")
print(f" একক-সেন্সর পদ্ধতি (শুধু প্রথম রিডিং {faulty_readings[0]} ব্যবহার করে): অ্যাকশন ট্রিগার? {single_result}")
print(f" ভোটিং পদ্ধতি (৩টি সেন্সর তুলনা করে) : অবস্থা={voting_status}, অ্যাকশন ট্রিগার? {voting_result}")
# দৃশ্যকল্প ২ (তুলনার জন্য): সবগুলো সেন্সর একমত, কোনো ত্রুটি নেই
agreeing_readings = [25.0, 24.0, 26.0]
single_result_2 = single_sensor_decision(agreeing_readings[0], threshold)
voting_status_2, voting_result_2 = voting_sensor_decision(agreeing_readings, threshold, disagreement_limit=10.0)
print("\nদৃশ্যকল্প ২: সবগুলো সেন্সর একমত (কোনো ত্রুটি নেই)")
print(f" একক-সেন্সর পদ্ধতি: অ্যাকশন ট্রিগার? {single_result_2}")
print(f" ভোটিং পদ্ধতি : অবস্থা={voting_status_2}, অ্যাকশন ট্রিগার? {voting_result_2}")
Boeing 737 MAX/MCAS কেসটি দেখায় কীভাবে একটি ডিজাইন সিদ্ধান্ত (একক সেন্সরের উপর নির্ভরতা), একটি প্রশিক্ষণ/ডকুমেন্টেশন ঘাটতি, এবং একটি সার্টিফিকেশন প্রক্রিয়া সংক্রান্ত উদ্বেগ -- এই সবগুলো একত্রে একটি মারাত্মক ব্যর্থতায় পরিণত হতে পারে, প্রতিটি এককভাবে হয়তো "ব্যবস্থাপনাযোগ্য" মনে হলেও। কোনো একক প্রকৌশলী, ম্যানেজার, বা নিয়ন্ত্রক এই বিপর্যয়ের একমাত্র কারণ নন -- দায় বিতরিত।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন -- তারপর "→ উত্তর" চাপুন।
প্র ০১ MCAS-এর একক-সেন্সর ডিজাইন কেন এতটা ঝুঁকিপূর্ণ ছিল?
কারণ সিস্টেমটি একটি মাত্র সেন্সরের রিডিং সত্য বলে ধরে নিয়ে সরাসরি স্বয়ংক্রিয় অ্যাকশন নিতো, সেই রিডিং যাচাই করার কোনো স্বতন্ত্র উপায় ছাড়াই। যদি সেই একটি সেন্সর ত্রুটিপূর্ণ তথ্য দেয় (যেকোনো কারণে), সিস্টেমের কাছে সেই ত্রুটি শনাক্ত করার কোনো উপায় ছিল না -- এটি ঠিক Therac-25 (L25)-এর মতোই "একক নির্ভরতার বিন্দু" (single point of failure) সমস্যার একটি ভিন্ন রূপ।
প্র ০২ "প্রবলেম অফ মেনি হ্যান্ডস" বলতে কী বোঝানো হচ্ছে, এবং কেন এটি অ্যাকাউন্টেবিলিটিকে জটিল করে তোলে?
এর মানে হলো একটি খারাপ ফলাফল একাধিক ব্যক্তির/দলের ছোট ছোট, প্রত্যেকের কাছে এককভাবে যুক্তিসঙ্গত মনে হওয়া সিদ্ধান্তের সম্মিলিত ফল -- কোনো একক ব্যক্তি "এই বিপর্যয় ঘটাবো" এমন সিদ্ধান্ত নেননি। এটি অ্যাকাউন্টেবিলিটিকে জটিল করে কারণ ঐতিহ্যগত জবাবদিহিতার ধারণা প্রায়ই একজন স্পষ্ট দায়ী ব্যক্তি খোঁজে, কিন্তু বাস্তবে দায় প্রায়ই একাধিক পক্ষের মধ্যে বিতরিত থাকে (L27-এ বিস্তারিত)।
প্র ০৩
উপরের কোড সেলে disagreement_limit যদি 10.0 থেকে 30.0-তে বাড়ানো হতো, তাহলে দৃশ্যকল্প ১-এর ফলাফল কী হতো?
দৃশ্যকল্প ১-এ spread = 35.0 - 8.0 = 27.0, যা 30.0-এর চেয়ে কম -- তাই ভোটিং
পদ্ধতি আর "fault_detected" বলবে না, বরং গড় (৩৫+৮+৯)/৩ ≈ ১৭.৩ হিসাব করে 17.3 > 20.0 যা
False -- অর্থাৎ কাকতালীয়ভাবে সঠিক সিদ্ধান্তে পৌঁছাতো, কিন্তু এটি নিরাপদ ডিজাইন নয়:
disagreement_limit খুব বেশি বড় রাখলে সিস্টেম প্রকৃত সেন্সর-ত্রুটি শনাক্ত করার ক্ষমতাই
হারিয়ে ফেলে -- থ্রেশহোল্ড সঠিকভাবে ঠিক করা রিডানডেন্সি ডিজাইনের একটি গুরুত্বপূর্ণ অংশ।
অনুশীলন
-
চিন্তা করুন: এই কেসে অন্তত তিনটি ভিন্ন পক্ষ (ইঞ্জিনিয়ারিং, ম্যানেজমেন্ট, নিয়ন্ত্রক
সংস্থা) জড়িত ছিল বলে তদন্তে উঠে এসেছে। প্রত্যেকের সিদ্ধান্ত তাদের নিজ নিজ প্রেক্ষাপটে কেন তুলনামূলকভাবে
"যুক্তিসঙ্গত" মনে হয়ে থাকতে পারে?
একজন ইঞ্জিনিয়ার হয়তো একটি নির্দিষ্ট প্রযুক্তিগত সমস্যার সীমার মধ্যে কাজ করছিলেন এবং তার দৃষ্টিতে সমাধানটি যথেষ্ট মনে হয়েছিল; ম্যানেজমেন্ট প্রতিযোগিতামূলক বাজারে খরচ ও সময়সীমা নিয়ে বাস্তব চাপে ছিল; নিয়ন্ত্রক সংস্থা সীমিত সম্পদ দিয়ে একটি জটিল সিস্টেম পর্যালোচনা করছিল। কোনোটিই এককভাবে "দুর্বৃত্ত" সিদ্ধান্ত নয়, কিন্তু একত্রে সেগুলো একটি বিপজ্জনক ফাঁক তৈরি করেছিল -- এটিই L27-এর মূল বিষয়।
-
পরীক্ষা করুন: উপরের কোড সেলে
faulty_readings-এ একটি তৃতীয় সেন্সরও ত্রুটিপূর্ণ করে দিন (যেমন[35.0, 33.0, 9.0]) এবং Run চেপে দেখুন ভোটিং পদ্ধতি এখন কী ফলাফল দেয়।[35.0, 33.0, 9.0]-এর জন্যspread = 35.0 - 9.0 = 26.0, যা এখনো10.0-এর চেয়ে বেশি -- তাই ভোটিং পদ্ধতি আবারও "fault_detected" বলবে। এটি দেখায় যে ভোটিং/রিডানডেন্সি পদ্ধতি এই সরল মডেলে নির্ভর করে সেন্সরগুলোর মধ্যে মতবিরোধ শনাক্ত করার উপর, কোনটি সেন্সর "সঠিক" তা নিশ্চিতভাবে না জেনেও -- বাস্তব বিমান-প্রকৌশলে এই ধরনের পরিস্থিতিতে সাধারণত একাধিক, আরও জটিল ফল্ট-হ্যান্ডলিং কৌশল ব্যবহৃত হয়, যা এই সরলীকৃত মডেলের সুযোগের বাইরে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- অ্যাকাউন্টেবিলিটি ও "প্রবলেম অফ মেনি হ্যান্ডস" পরের পাঠ এই কেসের "কোনো একক ভিলেন নেই" ধারণাটি একটি সিন্থেটিক কন্ট্রিবিউশন-ম্যাট্রিক্স দিয়ে গভীরভাবে অন্বেষণ।
- কেস স্টাডি: Therac-25 আগের পাঠ সেফটি-ক্রিটিক্যাল সফটওয়্যারে একক নির্ভরতার বিন্দু (single point of failure) সংক্রান্ত আরেকটি বাস্তব কেস স্টাডি।
- সেফটি-ক্রিটিক্যাল সিস্টেম ও বাগের প্রকৃত মূল্য M6 সেফটি-ক্রিটিক্যাল সিস্টেমের সংজ্ঞা ও প্রেক্ষাপট -- এই কেস স্টাডিগুলোর ভিত্তি।
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ ক্লাসিক্যাল এথিক্যাল ফ্রেমওয়ার্ক, প্রাইভেসি, অ্যালগরিদমিক বায়াস, প্রফেশনাল এথিক্স, সফটওয়্যার সেফটি, সাইবারসিকিউরিটি এথিক্স, AI অ্যালাইনমেন্ট ও রেগুলেশন।