ملخص
- في 25 فبراير 1991، فشلت بطارية باتريوت في الظهران في تعقب واعتراض صاروخ سكود عراقي وارِد. خلص مكتب المحاسبة العام الأمريكي (GAO) إلى أن مشكلة برمجية في كمبيوتر التحكم في الأسلحة أنتجت حساب تتبع غير دقيق تفاقم مع وقت التشغيل المستمر. أصاب الصاروخ ثكنة عسكرية، وأفاد GAO أن 28 أمريكيًا لقوا حتفهم.
- الآلية التقنية كانت تحويل الوقت بدقة محدودة. كان النظام يحتفظ بالوقت بأعشار الثانية ويحول قيمة ساعة صحيحة متزايدة لحسابات نطاق المدى. حددت سجلاته ذات الـ 24 بت دقة هذا التحويل. بعد أن عملت بطارية الظهران لأكثر من 100 ساعة متواصلة، بلغ خطأ الوقت المتراكم حوالي 0.3433 ثانية، وتم إزاحة نطاق المدى المتوقع بحوالي 687 مترًا.
- كان الخطأ قد أصبح مرئيًا مؤسسيًا بالفعل. أظهرت بيانات إسرائيلية وردت في 11 فبراير إزاحة كبيرة في نطاق المدى بعد ثماني ساعات. تم إصدار تعديل برمجي تعويضي في 16 فبراير، وحذرت رسالة بتاريخ 21 فبراير المستخدمين من أن فترات التشغيل الطويلة جدًا قد تُزيح نطاق المدى. لكن التحذير لم يحدد معنى "طويلة جدًا"، وافترض المسؤولون أن البطاريات لن تبقى قيد التشغيل لمدة كافية للفشل، ووصل البرنامج المعدل إلى الظهران في 26 فبراير، أي بعد يوم واحد من الهجوم.
- لذا تمتد المساءلة إلى ما هو أبعد من الحساب. فهي تتبع السيطرة على تمثيل الأرقام، وافتراضات التحمل، وتحليل الشذوذ، والحدود التشغيلية، ومحتوى التحذير، وسلطة إعادة التشغيل، وتوزيع البرامج، وتكوين الوحدة، وإثبات أن الإجراء التصحيحي وصل إلى البطارية قبل الحاجة إليه. تحول خطأ حسابي صغير إلى كارثة لأن نظام التحكم التقني والتشغيلي لم يحده في ظروف الانتشار.
الظهران حوّلت وقت التشغيل إلى حالة حرجة للسلامة
غالبًا ما يُعتبر وقت تشغيل البرامج دليلاً على الموثوقية. قد يبدو النظام الذي ظل متاحًا لأيام أكثر جدارة بالثقة من النظام الذي أعيد تشغيله مؤخرًا. يكشف فشل باتريوت في الظهران عن الاحتمال المعاكس: الوقت المنقضي نفسه يمكن أن يكون خطرًا متزايدًا. إذا فقد حساب داخلي دقته مع زيادة قيمة الساعة، فإن الاستمرار في التشغيل ليس محايدًا. إنه يغير حالة النظام حتى عندما لا يتعطل أي مكون بشكل مرئي ولا يرى أي مشغل إنذارًا.
تقرير GAO الصادر في فبراير 1992 حدد الحدث المركزي. في 25 فبراير 1991، فشل نظام باتريوت للدفاع الصاروخي الذي يعمل في الظهران بالمملكة العربية السعودية في تعقب واعتراض صاروخ سكود وارِد. أصاب الصاروخ ثكنة عسكرية أمريكية. أفاد GAO أن 28 أمريكيًا قُتلوا. طُلب مراجعته لتحديد ما إذا كانت مشكلة برمجية متورطة، وما هي المشكلة وما تم فعله لتصحيحها.
كان جواب التقرير مباشرًا. مشكلة برمجية في كمبيوتر التحكم في الأسلحة أدت إلى حساب تتبع غير دقيق أصبح أسوأ كلما طالت مدة تشغيل النظام. في وقت الحادث، كانت البطارية تعمل بشكل مستمر لأكثر من 100 ساعة. تسبب عدم الدقة المتراكم في أن يبحث النظام في المكان الخطأ عن الهدف الوارد.
هذا الوصف مهم لأنه يميز الحالة عن فقدان الطاقة الكلي أو شاشة متجمدة أو تعطل تقليدي. بقيت بطارية باتريوت نظامًا قيد التشغيل. كان التدهور الخطير موجودًا داخل حساب يُستخدم لتحديد أين يجب أن تبحث معالجة الرادار بعد ذلك. لذلك يمكن للنظام أن يكون عاملاً بالمعنى الإداري - مزود بالطاقة، ومُوظف، ومتاح - بينما يصبح غير صالح وظيفيًا لوظيفة سلامة محددة.
سؤال المساءلة ليس ببساطة لماذا مثل الكمبيوتر كسرًا بشكل غير كامل. الآلات الثنائية تُقرّب الكميات التي لا يمكن التعبير عنها بالضبط ضمن عدد ثابت من البتات بشكل روتيني. السؤال الأصعب هو لماذا سُمح للتقريب بالتراكم إلى ما يتجاوز الحد الآمن في مهمة دفاعية حية، ولماذا لم تحول المنظمات التي تتحكم في البرمجيات والعمليات والدعم الميداني الحد المعروف إلى حماية للوحدة المنتشرة.
ما يثبته السجل الرسمي
يجب أن يظل تقرير GAO السلطة الأساسية لاستنتاج برمجيات الظهران. لم تكن حكاية صفية بأثر رجعي مجمعة من الفولكلور. أجرى GAO مقابلات مع المسؤولين المسؤولين عن صيانة برمجيات باتريوت، وراجع تحليلات الجيش، وفحص بنية النظام ومواد لغة التجميع، وحلل تعليمات الآلة المرتبطة بعدم الدقة، وتحقق من الحساب التصحيحي، وشارك في محاكاة في منشأة اختبار برمجيات باتريوت. يقول التقرير إن المسؤولين وافقوا عمومًا على الحقائق كما عُرضت.
هذا لا يعني أن التقرير يحسم كل جدل حول أداء باتريوت خلال حرب الخليج. أصبح سجل الاعتراض الأوسع للنظام موضوع نزاع سياسي وتقني وأدلي. الادعاءات حول ما إذا كانت اشتباكات أخرى دمرت رؤوسًا حربية واردة تنطوي على أدلة وتعريفات وأسئلة سببية مختلفة. لا ينبغي استيراد هذه النقاشات إلى حالة برمجيات الظهران كما لو كانت قابلة للتبادل.
في هذه الحادثة، وصف GAO سلسلة أضيق ومدعومة جيدًا. استخدم كمبيوتر التحكم في الأسلحة معلومات الهدف من الرادار. قامت خوارزمية نطاق المدى بحساب منطقة حيث يجب أن يبحث النظام بعد ذلك عن صاروخ سكود مشتبه به. تم تصفية البيانات خارج تلك المنطقة المحسوبة، بينما دعمت المعلومات داخلها التتبع والاستهداف والاعتراض. اعتمد التنبؤ على سرعة الهدف ووقت آخر اكتشاف راداري.
كانت ساعة النظام تحتفظ بالوقت بأعشار الثانية كعدد صحيح. تطلبت حسابات التعبير عن الوقت والسرعة كأرقام حقيقية. نظرًا لأن سجلات الكمبيوتر كانت بطول 24 بتًا، أدى تحويل قيمة الوقت إلى فقدان في الدقة. نما التأثير مع كل من مدة التشغيل وسرعة الهدف. أدى التشغيل الممتد إلى إزاحة نطاق المدى المحسوب بعيدًا عن الموقع الفعلي للهدف.
ثم ربط GAO الحساب بالنتيجة الميدانية. كانت بطارية ألفا قد عملت بشكل مستمر لأكثر من 100 ساعة. انزاح نطاق المدى كثيرًا لدرجة أن البطارية لم تتعقب صاروخ سكود الوارد وبالتالي لم تشتبك معه. هذا هو السببية الرسمية للفشل البرمجي. يمكن للتحليل استخلاص دروس الحوكمة منها، لكن لا ينبغي أن يخترع أوامر ميدانية إضافية أو دوافع فردية أو قرارات غير موثقة.
الخطأ العددي كان صغيرًا لكل عملية حسابية وكبيرًا في السياق
غالبًا ما يتم ضغط الحساب في عبارة "خطأ تقريب". هذه العبارة صحيحة اتجاهيًا ولكنها غير مكتملة مؤسسيًا. إنها توحي بتباين عشري غير ضار أو خطأ منعزل من مبرمج. الخطر الفعلي جاء من تفاعل التمثيل والتراكم وسرعة الهدف والاستخدام المستمر.
كان النظام يحسب الوقت بوحدات عُشر الثانية. العُشر ليس له تمثيل دقيق محدود في النظام الثنائي، تمامًا كما أن الثلث ليس له تمثيل دقيق محدود في النظام العشري. يجب على الكمبيوتر تخزين تقريب. قيدت بنية كمبيوتر باتريوت الدقة المتاحة للتحويل المستخدم في حساب التتبع. كان كل تحويل قريبًا من القيمة المقصودة، ولكن ليس مطابقًا لها.
كان الوقت المنقضي ممثلاً بعدد صحيح يزداد مع بقاء النظام قيد التشغيل. عندما تم تحويل عدد الساعات الأكبر هذا باستخدام تقريب محدود الدقة، زاد الفرق المطلق بين الوقت المحسوب والفعلي أيضًا. لم تكن البرمجيات بحاجة إلى أن تصبح أقل حذرًا من لحظة إلى أخرى. نفس طريقة التمثيل ولدت خطأ تشغيليًا أكبر لأنه طُبق على قيمة وقت منقضي أكبر.
حدد ملحق GAO التقدم. بعد ساعة واحدة، كان الوقت المحسوب أقل بحوالي 0.0034 ثانية، وهو ما يتوافق مع إزاحة نطاق مدى تقريبًا سبعة أمتار. بعد ثماني ساعات، أدرج التقرير عدم دقة وقت بحوالي 0.0275 ثانية وإزاحة بحوالي 55 مترًا. بعد 20 ساعة، كان عدم الدقة حوالي 0.0687 ثانية والإزاحة حوالي 137 مترًا. عند 100 ساعة، كان الحساب أقل بحوالي 0.3433 ثانية والإزاحة التقريبية 687 مترًا.
تظهر هذه الأرقام لماذا "مجرد جزء من الثانية" هو إطار المخاطرة الخاطئ. جزء من الثانية يجب تقييمه مقابل سرعة الهدف والمنطق الذي يستهلك قيمة الوقت. وصف GAO صواريخ سكود بأنها تسير بسرعة تقارب ماخ 5 في هذا السياق التشغيلي. الهدف سريع الحركة يقطع مسافة كبيرة خلال فترة زمنية قصيرة. كانت وظيفة نطاق المدى هي تقييد أين تبحث معالجة الرادار بعد ذلك. بمجرد أن أزاح خطأ التنبؤ هذا النطاق بعيدًا بما فيه الكفاية، يمكن أن يقع الهدف الحقيقي خارج المنطقة التي يتم التعامل معها على أنها ذات صلة.
لم تكن النتيجة مجرد تقدير أقل أناقة. لقد غيرت ما يمكن للنظام التعرف عليه كهدف. ساعد الحساب في تحديد ما إذا كان جسم ما قد تم تحديده وتتبعه واعتباره ضمن نطاق إطلاق النار. لذلك كان تقريب رقمي داخل حدود قرار ذات عواقب مباشرة على الاشتباك.
هذا مبدأ سلامة متكرر. لا يمكن تقييم حجم الخطأ بمعزل عن وظيفة النقل بين الحساب والفعل. قد يكون خطأ زمني صغير غير مهم في معالجة رواتب وكارثيًا في تجنب الاصطدام أو الجرعات الطبية أو التحكم الصناعي أو تتبع الصواريخ. يجب أن يترجم ضمان الهندسة الخطأ العددي إلى تأثير في المجال في أسوأ حالة تشغيل معقولة.
افتراض تصميمي أصبح حدًا تشغيليًا غير مُعلن
أفاد GAO أن باتريوت صُمم أصلاً كنظام دفاع جوي متنقل. تصور مفهوم التشغيل السابق الحركة وساعات قليلة فقط من التشغيل في موقع واحد. خلال حرب الخليج، وُضعت البطاريات في مواقع دائمة نسبيًا لحماية الأصول والأفراد والمدنيين من هجمات سكود. كان النظام يُستخدم أيضًا ضد فئة هدف ومسار طيران لم يحددا مهمته الأصلية.
هذا ليس دليلاً على أن التكيف كان غير مسؤول بطبيعته. غالبًا ما يُطلب من الأنظمة المنتشرة مواجهة تهديدات متغيرة. إنه دليل على أن الضمان القائم على غلاف التشغيل الأصلي لا يمكن أن يتبع النظام بصمت إلى غلاف مختلف. قد يحتوي النظام المتنقل الذي من المتوقع إعادة تشغيله أو نقله كل بضع ساعات على متغيرات حالة لم يُعتبر سلوكها طويل الأمد أبدًا بالغ الأهمية للسلامة. البطارية التي تُبقى متاحة بشكل مستمر لأيام تخلق متطلب تحمل مختلفًا.
لذا كان انحراف الساعة أيضًا فشل واجهة بين افتراضات التصميم وعقيدة الميدان. جسدت البرمجيات افتراضًا حول حجم الوقت المنقضي. خلقت الممارسة الحربية قيمة أكبر بكثير. لا يحدد أي من الجانبين السلامة بمفرده. النظام آمن فقط إذا كان نمط التشغيل المنتشر يبقى ضمن الغلاف المُصدق أو إذا تم تغيير البرمجيات والإجراءات قبل أن يتوسع الغلاف.
حد وقت التشغيل الموجود ضمنيًا فقط في الحساب ليس حدًا فعالاً. لا يمكن للمشغلين الامتثال لعتبة لم تُعط لهم أبدًا. لا يمكن للقادة التخطيط للإغاثة أو فترات إعادة التشغيل أو التغطية المتداخلة حول رقم لم يُترجم إلى عقيدة. لا يمكن لفرق اللوجستيات تحديد أولوية تعديل برمجي إذا لم يتم إخبارهم بالوحدات التي تقترب من حالة خطرة.
لذلك تطرح حالة الظهران سؤالاً: من كان يملك غلاف التشغيل؟ سيطر القائمون على صيانة البرمجيات على معرفة الحساب. يمكن لمكتب المشروع تحليل بيانات الشذوذ وتغيير الكود. عرفت القيادات التشغيلية كيف كانت البطاريات تُدار فعليًا. سيطرت الوحدات المنتشرة على التكوين الفوري وإجراءات إعادة التشغيل ضمن السلطة وظروف التهديد التي مُنحت لهم. سيطرت القيادة العليا للجيش على نظام توزيع التحذيرات والتحديثات. اعتمدت السلامة على التوفيق بين هذه الرؤى.
لم يكن المتطلب ذو الصلة مجرد "تتبع صواريخ سكود". كان أقرب إلى "الحفاظ على دقة التتبع المطلوبة لأطول فترة تشغيل مستمر قد يتطلبها الانتشار الحربي". لو كان شرط التحمل صريحًا، لكان يمكن تقييم تحليل الخطأ العددي، والاختبار طويل المدى، والتعليمات الميدانية، وتقارير التكوين مقابل نفس الحد القابل للقياس.
البيانات الإسرائيلية جعلت الخطر مرئيًا قبل الهجوم
لم يصبح الخلل معروفًا فقط بعد الظهران. وصف GAO أدلة ميدانية وردت قبل الحادث. في 11 فبراير 1991، تلقى مكتب مشروع باتريوت بيانات إسرائيلية تحدد إزاحة بنسبة 20% في نطاق مدى الرادار بعد ثماني ساعات متتالية من التشغيل. استخدمت الأنظمة الخاضعة للسيطرة الإسرائيلية مسجلات بيانات خارجية، مما وفر معلومات مفيدة لتحليل الجيش.
قال مسؤولو مكتب المشروع إن النظام لن يتتبع صاروخ سكود عندما تصل إزاحة نطاق المدى إلى 50% أو أكثر. نظرًا لأن الإزاحة كانت متناسبة مع وقت التشغيل، يمكن استقراء نتيجة الثماني ساعات. أفاد GAO أنه بعد حوالي 20 ساعة من الاستخدام المستمر، أصبح حساب الوقت غير الدقيق كبيرًا بما يكفي ليجعل الرادار يبحث في المكان الخطأ.
هذا التسلسل هو اختبار تصعيد الشذوذ الكلاسيكي. كانت الأدلة موجودة، لكن الأدلة لا تحمي النظام حتى يتم تحويلها إلى قرار متحكم فيه. يمكن وصف الإزاحة الأولية بنسبة 20% على أنها هامش متدهور بدلاً من فشل فوري. لكن أهميتها تعتمد على مسار الخطأ. الخطأ المتنامي مع عتبة فشل معروفة يتطلب إسقاطًا، وليس مجرد ملاحظة.
أفاد GAO أن مسؤولي الجيش اعتقدوا في البداية أن التجربة الإسرائيلية كانت غير نمطية. افترضوا أن المستخدمين الآخرين لم يكونوا يديرون الأنظمة لمدة ثماني ساعات أو أكثر في المرة الواحدة. كان هذا الاعتقاد افتراضًا تشغيليًا، وكان خاطئًا بالنسبة لبطارية ألفا في الظهران. بقيت الوحدة في النهاية في التشغيل المستمر لأكثر من 100 ساعة.
لم يكن فشل الحوكمة أن المسؤولين تجاهلوا كل الأدلة. لقد حللوا البيانات، وأكدوا فقدان الدقة، وأجروا تغييرًا برمجيًا. كانت الفجوة أن الشذوذ لم ينتج استجابة سلامة كاملة وقابلة للتنفيذ ميدانيًا قبل أن يصل الإصلاح إلى كل وحدة معرضة للخطر. قال GAO إن المسؤولين لم يستخدموا البيانات الإسرائيلية لتحديد المدة التي يمكن أن يعمل فيها باتريوت قبل أن يجعل الحساب غير الدقيق النظام غير فعال.
هذا التمييز مهم. التطوير التصحيحي والتحكم المؤقت في المخاطر التزامان منفصلان. بمجرد إعداد التصحيح، قد تتصرف المنظمات كما لو أن المشكلة في طريقها إلى الحل. تظل الوحدة المنتشرة معرضة للخطر حتى يتم تثبيت التكوين المصحح أو تفعيل تخفيف فعال. الوقت بين تأكيد الخلل والتركيب على مستوى الأسطول هو في حد ذاته فترة خطر مُدارة.
التحذير لم يذكر العتبة التي يحتاجها المشغلون
في 21 فبراير، أرسل مكتب مشروع باتريوت رسالة إلى المستخدمين تفيد بأن فترات التشغيل الطويلة جدًا يمكن أن تُزيح نطاق المدى وتزيح الهدف. ذكرت الرسالة أيضًا أنه سيتم إرسال تغيير برمجي لتحسين الاستهداف. حدد GAO ضعفًا حاسمًا: الرسالة لم تحدد ما يعتبر "طويلة جدًا".
اللغة النوعية يمكن أن تنقل القلق دون تمكين العمل. قد تعني "طويلة جدًا" ثماني ساعات لمحلل برمجيات، أو يومًا لقائد، أو عدة أيام لطاقم يعمل تحت تهديد مستمر. يجب أن يربط التحذير التشغيلي الخطر بحالة قابلة للقياس واستجابة مطلوبة. يجب أن يذكر متى يصبح الخطر غير مقبول، وماذا يجب على الوحدة فعله، ومن يمكنه التصريح بالعمل، وكيف يتم تسجيل الامتثال.
أخبر مسؤولو الجيش GAO أنهم افترضوا أن المستخدمين لن يديروا البطاريات بشكل مستمر لفترات طويلة بما يكفي للفشل، لذلك لم يعتقدوا أن هناك حاجة إلى توجيه أكثر تفصيلاً. هذا الافتراض يوضح لماذا لا يمكن لتصميم التحذير الاعتماد على نفس الافتراض المتورط في الخطر. إذا كانت الممارسة الميدانية غير مؤكدة، يجب على عملية التحذير التحقق منها. يجب أن يشمل الإقرار وقت التشغيل الحالي للوحدة، وإصدار البرمجيات، والتخفيف المخطط، وليس مجرد تأكيد استلام الرسالة.
الحالة الفعلية لبطارية الظهران - أكثر من 100 ساعة من التشغيل المستمر - لم تكن حافة دقيقة حول نقطة فقدان التتبع المتوقعة البالغة 20 ساعة. كانت بعيدة جدًا عنها. نظام تحكم قادر على مطابقة التحذيرات مع حالة الوحدة كان يجب أن يحدد بطارية ألفا كحالة عاجلة.
هنا تصبح المساءلة قائمة على الأدلة. لا يكفي إظهار أن المقر الرئيسي أرسل رسالة عامة. الدليل ذو الصلة هو ما إذا كانت الوحدة المعرضة تلقت حدًا مفهومًا في الوقت، وفهمت عواقبه، وكان لديها السلطة والفرصة للتحرك، وأبلغت عن الإنجاز. سجلات الإرسال تثبت فقط بداية تلك السلسلة.
يجب أن تكون التحذيرات للبرمجيات الحرجة للسلامة توجيهات تشغيلية مُرقمة. يجب أن تحتوي على معرف الخلل، والتكوينات المتأثرة، والمشغل القابل للملاحظة، والحد الأقصى الآمن، والتخفيف، والدور المسؤول، والموعد النهائي، وتأكيد الاستلام، ودليل الإغلاق. عندما تكون العتبة معتمدة على الوقت، يجب أن يتطلب التحذير أيضًا الإبلاغ عن وقت التشغيل الحالي. وإلا يبقى متغير الخطر المركزي غير مرئي للمنظمة التي تحاول السيطرة عليه.
إعادة التشغيل كانت تخفيفًا، لكن ليس نظام تحكم كامل
أفاد GAO أن إعادة تشغيل نظام باتريوت كل بضع ساعات يمكن أن يزيل إزاحات نطاق المدى الكبيرة عن طريق إعادة تهيئة ساعة الكمبيوتر إلى الصفر. وصف إعادة التشغيل بأنها تستغرق حوالي 60 إلى 90 ثانية. من الناحية التقنية البحتة، كان ذلك تخفيفًا بسيطًا لخطأ الوقت المتراكم.
من الناحية التشغيلية، "فقط أعد التشغيل" ليس تلقائي التنفيذ. توجد بطارية الدفاع الجوي لتوفير حماية مستمرة. حتى الانقطاع القصير قد يحتاج إلى التنسيق مع التنبيهات الحالية، والتغطية من البطاريات الأخرى، وسلطة القيادة، وعبء عمل الطاقم. لاحظ نفس التقرير أن تثبيت تعديلات البرمجيات يتطلب إيقاف تشغيل الأنظمة لمدة ساعة إلى ساعتين على الأقل، وهو انقطاع أطول بكثير مع آثار تخطيط واضحة.
هذا لا يثبت أن إعادة التشغيل في لحظة معينة كان مستحيلاً أو أن المشغلين رفضوا أمرًا متاحًا. الأدلة العامة في مجموعة المصادر لا تدعم هذا الادعاء. إنها تظهر لماذا يجب ترجمة التخفيف إلى عقيدة قبل أن يُعتبر عنصر تحكم.
عنصر تحكم إعادة التشغيل الموثوق سيحدد أقصى وقت تشغيل أقل من العتبة الخطرة، ويحذر مع اقتراب هذا الحد، ويحدد من يأمر بإعادة التشغيل، وينسق التغطية المؤقتة، ويتحقق من إعادة تعيين الساعة، ويسجل وقت البدء الجديد. إذا كانت الحماية المستمرة تجعل إعادة التشغيل غير مقبولة، يجب على المنظمة توفير قدرة متداخلة أو تسريع تثبيت البرمجيات المصححة. لا يمكن إدارة الخطر بأمل أن تستنتج الفرق الميدانية إجراءً من تحذير غير دقيق.
وجود تخفيف سهل تقنيًا يمكن أن يضعف الاستجابة المؤسسية أحيانًا. قد يفترض صانعو القرار أن شخصًا قريبًا من النظام يمكنه حل المشكلة بشكل غير رسمي. هذا الافتراض ينقل المسؤولية دون نقل التعليمات أو السلطة أو الأدلة. في حالة السلامة، لا يُحتسب التخفيف إلا عندما يكون ممكنًا في ظل الظروف التشغيلية ومنفذًا بشكل واضح.
الإصلاح البرمجي كان موجودًا قبل الهجوم لكنه وصل بعده
بعد تحليل البيانات الإسرائيلية، طور مكتب مشروع باتريوت تغييرًا برمجيًا للتعويض عن حساب الوقت غير الدقيق والسماح بفترات تشغيل ممتدة. أفاد GAO أن النسخة المعدلة صدرت في 16 فبراير 1991. وصلت إلى الظهران في 26 فبراير - اليوم التالي للهجوم المميت.
أرجع مسؤولو الجيش تأخير التوزيع إلى الوقت المطلوب لترتيب النقل الجوي والبري إلى جميع مواقع باتريوت في بيئة حربية. هذا السياق ذو صلة. توصيل وسائط برمجية مادية أو دعم فني أو تغييرات تكوين خاضعة للرقابة عبر مسرح عمليات ليس مكافئًا لتوزيع تحديث استهلاكي روتيني. لكن الصعوبة التشغيلية لا تمحو التعرض. إنها تحدد متطلبات اللوجستيات التي يجب على عملية السلامة إدارتها.
يجب معالجة الفاصل الزمني البالغ تسعة أيام بين الإصدار وحادثة الظهران كنافذة مخاطر تكوين. خلال هذه النافذة، بقيت بعض الوحدات على برمجيات معروف أن بها مشكلة تتبع تعتمد على المدة. عملية ناضجة ستحتفظ بقائمة جرد حية للبطاريات المتأثرة وإصدارات برمجياتها ووقت تشغيلها الحالي وأهمية المهمة وحالة شحن التحديث والتخفيف المؤقت.
يجب أن تتبع الأولوية المخاطر، وليس مجرد تسلسل توزيع قياسي. الوحدة التي تجاوزت بالفعل مدة التشغيل الآمنة المتوقعة ستستحق اهتمامًا فوريًا. إذا لم يتمكن الإصدار المصحح من الوصول بسرعة، فسيحتاج نظام القيادة إلى فرض جدول إعادة تشغيل أو إجراء معتمد آخر. يجب أن تنتقل كل وحدة عبر حالات صريحة: متأثرة، محذرة، مخففة، تم إرسال التحديث، تم استلامه، تم تثبيته، تم الفحص وظيفيًا، ومغلقة.
حالة الظهران تسبق عمليات البرمجيات المقدمة عبر الشبكة كما تُفهم الآن بشكل شائع، لكن مشكلة المساءلة تبقى حالية. البائع أو مكتب المشروع قد يصدر إصلاحًا بينما تظل القاعدة المثبتة ضعيفة. "التصحيح متاح" ليس مثل "المخاطر مُزالة". المنظمات المسؤولة عن الأنظمة عالية العواقب تحتاج إلى أدلة على الميل الأخير.
ينطبق نفس المنطق على المستشفيات والمصانع وشبكات السلامة العامة والبنية التحتية الحيوية. الكود التصحيحي الجالس في المقر الرئيسي لا يحمي نظامًا بعيدًا. تعتمد السلامة على وقت التوزيع والسلطة المحلية وفرصة التثبيت واختبار التوافق وإثبات التكوين الناتج.
التسجيل المحدود للأداء أضعف التعلم
وصف GAO أيضًا قيدًا في الأدلة. لم يكن لدى باتريوت مسجل بيانات داخلي مدمج يحتفظ بمعلومات أداء تفصيلية. كانت المسجلات الخارجية المحمولة متاحة، لكن القادة الأمريكيين قرروا عدم استخدامها بسبب القلق من أن المسجلات قد تسبب إيقاف تشغيل غير متوقع للنظام. استخدم القادة الإسرائيليون المسجلات وقدموا بيانات ساعدت في كشف شذوذ نطاق المدى.
يمثل القرار مفاضلة سلامة حقيقية. إضافة أدوات إلى نظام أسلحة حي يمكن أن يخلق مخاطره الخاصة. المسجل الذي قد يعطل التشغيل لا يمكن معاملته على أنه غير ضار. لكن رفض جمع البيانات له أيضًا تكلفة: قد يبقى التدهور غير مرئي، ويصبح تحليل الشذوذ أبطأ، ويصبح إعادة بناء ما بعد الحادث أقل يقينًا.
تتطلب الهندسة المسؤولة أن تكون هذه المفاضلة صريحة. إذا كان المسجل المفضل شديد الخطورة للاستخدام الروتيني، فإن مسار أدلة بديل مطلوب. يمكن أن يشمل ذلك أدوات سلبية مُصدقة بشكل مستقل، أو جمع تشخيصي مجدول، أو إعادة مخبرية باستخدام حالات طويلة الأمد ممثلة، أو تسجيل زائد على بطاريات مختارة، أو خطة رسمية لالتقاط بيانات الشذوذ دون التدخل في الاشتباك.
النقطة المهمة ليست أن القادة يجب أن يختاروا دائمًا المزيد من القياس عن بعد. إنما أن نظامًا عالي العواقب يتكيف مع هدف جديد ونمط تشغيل جديد يحتاج إلى نظام تعلم محدد. خلال عاصفة الصحراء، تم تعديل البرمجيات بشكل متكرر مع تراكم الخبرة التشغيلية. أفاد GAO بستة تعديلات برمجية بين أغسطس 1990 وفبراير 1991. التكيف السريع يزيد من أهمية أداء الأدلة الموثوقة وإمكانية تتبع التكوين.
بدون سجلات جيدة، تعتمد المنظمات بشكل أكبر على تقارير المستخدمين والافتراضات والملاحظات المعزولة. وهذا يجعل من السهل رفض الشذوذ باعتباره غير نمطي ويصعب تحديد ما إذا كان التغيير فعالاً عبر الأسطول. جمع الأدلة هو بالتالي جزء من نظام الحماية، وليس مجرد مورد للمؤرخين بعد الفشل.
المساءلة تتبع السيطرة العملية
لم يتحكم دور واحد في كل رابط في سلسلة الظهران. هذا هو بالضبط لماذا نموذج مساءلة الأنظمة ضروري. المسؤولية الموزعة لا ينبغي أن تصبح مسؤولية مخففة.
سيطرت هندسة البرمجيات والأجهزة على خيارات التمثيل، ومعرفة قيود 24 بت، والخوارزمية التصحيحية، والتحقق من الحساب المعدل. لم يكن التزامهم ضمان الكمال الرياضي. كان تحديد حد الخطأ عبر نطاق التشغيل المعقول وإظهار أن التتبع بقي ضمن التسامح المطلوب.
سيطر مكتب مشروع باتريوت على تحليل الشذوذ وصيانة البرمجيات وأجزاء مهمة من التحذير والتوزيع. بمجرد أن أظهرت البيانات الإسرائيلية تدهورًا، كان المكتب في وضع يسمح له بتحويل الملاحظة إلى حد تشغيل وإصدار تصحيحي وإجراء ميداني ذو أولوية. يظهر حساب GAO أنه طور إصلاحًا وأرسل تحذيرًا. يسأل تحليل المساءلة لماذا لم تؤد تلك الإجراءات إلى حماية في الوقت المناسب في الظهران.
سيطرت القيادة التشغيلية على العقيدة ومعرفة كيفية استخدام البطاريات فعليًا. إذا كانت الأنظمة تبقى نشطة بشكل مستمر لأيام، كانت تلك الحقيقة بحاجة إلى الوصول إلى الأشخاص الذين يقيمون افتراضات التحمل. كما سيطرت القيادات على ما إذا كان يمكن التخطيط لإعادة التشغيل ووقت تعطل التحديث والحماية المتداخلة.
سيطرت سلسلة توزيع البرمجيات والدعم المسرحي على حركة الإصدار المعدل إلى المواقع المنتشرة. في بيئة حربية، قد يكون تأخير النقل مفهومًا، لكنه يظل جزءًا من مخاطر النظام. يجب قياس أداء اللوجستيات مقابل إلحاح الخطر.
سيطرت قيادة الوحدة والمشغلون على الإجراءات المحلية ضمن الأوامر والمعلومات والسلطة المتاحة لهم. لا ينبغي إلقاء اللوم الوحيد عليهم لفشلهم في استنتاج عتبة غير معلنة. على العكس من ذلك، يجب أن تحدد عملية السلامة الأدلة المطلوبة على مستوى الوحدة: سجلات وقت التشغيل، إقرار التحذير، سجل إعادة التشغيل، الإصدار المثبت، والفحص الوظيفي.
سيطرت قيادة الجيش والدفاع على نظام الحوكمة الأكبر: معايير الجاهزية، قنوات الإبلاغ، سلطة النشر، المراجعة المستقلة، والتوازن بين التوفر ووقت التعطل التصحيحي. تقع المساءلة المؤسسية على هذا المستوى لأن الفرق المحلية لا يمكنها إنشاء رؤية تكوين على مستوى الأسطول أو إعادة كتابة سياسة التحذير بنفسها.
يجب أيضًا تحديد دور الشركة المصنعة بالأدلة. السجل المصدر يدعم مناقشة صيانة البرمجيات والتصحيح التقني، لكنه لا يبرر معاملة مبرمج واحد أو شركة واحدة كسبب كامل. الفشل التشغيلي نشأ من خلل تقني يتفاعل مع بنية النظام، ظروف المهمة المتغيرة، افتراضات حول وقت التشغيل، محتوى تحذير غير كامل، وتأخير نشر التصحيح.
هذا التوزيع الطبقي أكثر تطلبًا من تسمية الجاني. يتطلب من كل مالك تقديم أدلة على السيطرة التي كان يمتلكها. تنتج الهندسة تحليل الأخطاء ونتائج الاختبارات. ينتج مكتب المشروع قرارات المخاطر وسجلات الإصدار. تنتج القيادة عقيدة التشغيل ورؤية حالة الوحدة. تنتج اللوجستيات أدلة التسليم. تنتج الوحدات تأكيد التكوين والتخفيف. يتحقق الإشراف من إغلاق السلسلة قبل استمرار التعرض.
القضية ليست حكمًا على كل اشتباك باتريوت
كانت فعالية باتريوت الأوسع في حرب الخليج محل جدل. شككت شهادة GAO وتحليل السياسات التقنية والتقارير العامة اللاحقة في ادعاءات النجاح الرسمية وفحصت صعوبة تحديد عمليات قتل الرؤوس الحربية. دافع أطراف آخرون عن أداء النظام. تلك النقاشات هي سياق ذو صلة لجودة الأدلة، لكنها ليست ضرورية لتضخيم استنتاج انحراف ساعة الظهران.
الحالة المحددة لها سجلها الرسمي الخاص: فشلت بطارية واحدة في تعقب واعتراض صاروخ سكود وارٍد لأن حساب توقيت غير دقيق نما خلال التشغيل الممتد. الحفاظ على الحدود ضيقة يحسن المساءلة. يمنع فشل برمجي موثق من أن يصبح وكيلاً بلاغيًا لكل ادعاء حول نظام السلاح.
ينطبق نفس الانضباط على الإبلاغ عن الضحايا. يذكر تقرير GAO للظهران أن صاروخ سكود أصاب ثكنة عسكرية وقتل 28 أمريكيًا. يمكن أن يُنسب هذا الرقم إلى GAO. لا ينبغي للمقال إضافة عدد دقيق للإصابات أو تسلسل مفصل داخل الثكنة أو ادعاءات حول إجراءات استجابة فردية ما لم تكن هناك أدلة موثوقة بنفس القدر تدعمها.
كما أن السجل لا يثبت سوء نية متعمد. الأدلة تدعم استنتاجات حول الافتراضات وحدود الحساب وخصوصية التحذير وتوقيت التحديث. لا تدعم ادعاءات التخريب أو السلوك الإجرامي أو قرار متعمد بتعريض الوحدة لنتيجة مميتة معروفة.
من المهم أيضًا عدم وصف كل حساب دقة محدودة على أنه خلل. التقريب متأصل في الحوسبة. الخلل يكمن في استخدام تقريب يتجاوز خطأه المتراكم تسامح النظام في ظل ظروف تشغيل معقولة دون اكتشاف أو تحكم فعال.
أخيرًا، لا ينبغي اختزال القضية إلى خطأ مشغل. أفاد GAO أن المسؤولين افترضوا أن المستخدمين لن يديروا البطاريات لفترات طويلة جدًا، بينما كانت الحقيقة الميدانية في الظهران أكثر من 100 ساعة من التشغيل المستمر. هذا التباين هو مشكلة واجهة مؤسسية. المشغلون جزء من النظام، لكن لا يمكنهم فرض حد لم تجعله الهندسة والقيادة صريحًا وقابل للتنفيذ.
ما يتطلبه نظام تحكم أقوى
الدروس الأكثر فائدة من الظهران هي ملموسة. "استخدم دقة أكبر" هو إصلاح واحد، لكنه ليس برنامج حوكمة كامل.
تحديد التسامح العددي من حيث التشغيلي
يجب أن تنص المتطلبات على الحد الأقصى المسموح به لخطأ التنبؤ عند أطول وقت تشغيل معقول وأعلى سرعة هدف ذات صلة. يجب أن تحدد النقطة التي لم يعد عندها نطاق المدى يوفر احتمال التتبع المطلوب. يصبح قرار عرض البت قابلاً للمراجعة فقط عندما يُترجم إلى تأثير فيزيائي.
يجب على المهندسين حساب الخطأ المتراكم في أسوأ الأحوال، وليس فقط الخطأ لكل تحويل. يجب أن تختبر الاختبارات الساعات بالقرب من حدود التحمل وما بعدها. إذا كانت البرمجيات تستخدم الوقت المنقضي في وظائف متعددة، يحتاج كل مسار إلى ميزانية خطأ.
جعل غلاف التشغيل صريحًا
يجب أن يشمل الغلاف المُصدق مدة التشغيل المستمر، وخصائص الهدف، وافتراضات إعادة التشغيل، وإصدار البرمجيات، والظروف البيئية. عندما يتغير الانتشار من استخدام متنقل وقصير المدة إلى ثابت وجاهزية مستمرة، يجب أن يؤدي التغيير إلى إعادة تقييم رسمية.
يجب أن يكون حد وقت التشغيل في الأوامر الفنية وشاشات المشغل ولوحات معلومات الجاهزية وتخطيط القيادة. لا ينبغي أن يظل قابلاً للاكتشاف فقط من خلال التحليل اللاحق لتعليمات التجميع.
قياس وقت التشغيل والهامش
يجب أن يكشف النظام عن الحالة ذات الصلة بالسلامة. يحتاج المشغلون وقيادات الدعم إلى قياس دقيق لوقت التشغيل المستمر ومؤشر واضح لهامش التتبع المتبقي. يجب أن تتصاعد التحذيرات قبل الحد، وليس بعد أن يصبح الحساب غير فعال.
يجب اختبار الأجهزة نفسها لعدم التداخل. إذا كان التسجيل يخلق خطرًا غير مقبول، يحتاج البرنامج إلى آلية أدلة أخرى مُصدقة. اختيار عدم التسجيل لا يمكن أن يعني اختيار عدم التعلم.
فصل التطوير التصحيحي عن التخفيف المؤقت
عندما يكون تغيير برمجي دائم قيد التنفيذ، لا يزال التحكم المؤقت في الخطر بحاجة إلى مالك. قد يكون التخفيف إعادة تشغيل مجدولة، أو تقليل الحد الأقصى لوقت التشغيل، أو تغطية متداخلة، أو وضع مهمة مقيد، أو إجراء هندسي آخر. يحتاج إلى جدوى موثقة وأدلة إنجاز.
يظل الخطر مفتوحًا حتى يتم حماية كل وحدة متأثرة، وليس فقط حتى يتم إصدار الكود.
استخدام تحذيرات كمية
يجب أن تستبدل رسائل السلامة عبارات مثل "طويلة جدًا" بعتبات. يجب أن تحدد الإصدارات المتأثرة، وتذكر العواقب، وتتطلب إجراءً محددًا، وتسمي السلطة المسؤولة عن ذلك الإجراء. إذا كانت العتبة تعتمد على الحالة الحالية، يجب أن تبلغ الوحدات عن تلك الحالة مع إقرارها.
الرسالة لا تُغلق عندما تغادر المقر الرئيسي. الإغلاق يتطلب الاستلام والفهم والعمل والتحقق.
الحفاظ على رؤية تكوين الأسطول
يجب أن يعرف القادة البرمجيون والتشغيليون أي إصدار برمجي تعمل به كل بطارية، ومتى أعيد تشغيلها آخر مرة، وأي تحذيرات أقرتها، وما إذا كان التغيير التصحيحي قد اجتاز فحصًا وظيفيًا محليًا. يجب أن يكون هذا المخزون حديثًا بما يكفي لتحديد أولويات المخاطر أثناء العمليات سريعة الحركة.
سجلات التكوين تمنع أيضًا نمط فشل شائع حيث تفترض المنظمات أن الإصلاح المنشور قد أزال التعرض في كل مكان.
التخطيط لنوافذ الصيانة الآمنة
إعادة التشغيل أو تثبيت البرمجيات قد يقطع الحماية. هذا يخلق مشكلة تشغيلية مشروعة، وليس عذرًا لترك الخطر غير مُدار. يجب أن تخطط القيادات لتغطية متداخلة أو صيانة مرحلية أو إجراء استمرارية آخر. يجب أن تكون سلطة قبول مخاطر الصيانة القصيرة مقابل مخاطر الحساب المتزايد صريحة.
اختبار المهمة التي يتم أداؤها فعليًا
يجب أن يعكس اختبار التحمل التشغيل الحربي المستمر، وليس فقط الجلسات الأقصر المتخيلة في المفهوم الأصلي. يجب أن تعكس نماذج الهدف سرعة وسلوك التهديدات التي تم تخصيص النظام لمواجهتها. يجب أن يغطي الاختبار تفاعل وقت التشغيل والتمثيل العددي ومنطق نطاق المدى.
أفاد GAO أنه تم إجراء اختبار تحمل لاحقًا لضمان أن فترات التشغيل الممتدة لا تخلق صعوبات نظام أخرى. التحكم الدائم هو جعل هذا النوع من الاختبار روتينيًا قبل أن تظهر ظروف الانتشار الحد.
الحفاظ على التحقق المستقل
يجب فحص التصحيحات الحرجة للسلامة بشكل مستقل مقابل حد الخطأ المذكور والسيناريو التشغيلي. أعاد GAO نفسه حساب التصحيح كجزء من مراجعته. لا ينبغي أن تحتاج البرامج إلى تدقيق بعد الفشل لاكتشاف ما إذا كان الحساب طويل المدى قد تم تقييمه.
يجب أن تقيم المراجعة المستقلة أيضًا كفاية التحذير والتوزيع الميداني وإغلاق التكوين. التحقق من البرمجيات وحده لا يمكن أن يظهر أن الإصدار المصحح وصل إلى النظام المعرض.
الاحتمالات المضادة توضح الضوابط لكن لا تعيد كتابة التاريخ
العديد من الاحتمالات المضادة تساعد في تحديد الضوابط المفقودة. إذا كان تحويل التوقيت قد حافظ على دقة كافية عند 100 ساعة، لما تطورت إزاحة نطاق المدى المحددة التي وصفها GAO بنفس الطريقة. إذا كانت البطارية قد أعيد تشغيلها ضمن فاصل آمن مفروض، لكانت الساعة الداخلية قد عادت إلى الصفر ولانخفض الخطأ المتراكم. إذا كانت البرمجيات المعدلة قد وصلت وتُثبت قبل 25 فبراير، لربما كان الحساب التعويضي قد عالج المشكلة المعروفة.
هذه مقترحات موجهة نحو التحكم، وليست ادعاءات بأن أي تغيير واحد كان سيمنع بالتأكيد كل نتيجة من الهجوم. الاعتراض عملية فيزيائية وتشغيلية معقدة. الأدلة العامة تثبت لماذا لم تتعقب بطارية ألفا هذا الصاروخ سكود وتشتبك معه؛ لا تضمن نتيجة لاشتباك افتراضي.
احتمال مضاد آخر يتعلق بمحتوى التحذير. توجيه كمي صدر في 21 فبراير، مطابق لوقت التشغيل الحالي لكل وحدة متأثرة ومدعوم بسلطة إعادة التشغيل، كان سيجعل الخطر أكثر قابلية للتنفيذ. ما إذا كان سيتم تنفيذه في الظهران يعتمد على حقائق غير مثبتة بالكامل هنا. الدرس هو أن التحذير النوعي الفعلي لم يوفر العتبة التي يحتاجها المشغلون.
الغرض من تحليل الاحتمالات المضادة هو ربط كل نقطة فشل بضابط قابل للاختبار. لا ينبغي استخدامه لخلق يقين بعد وقوع الحدث أو لمحو قيود العمليات الحربية.
الأنظمة الحديثة لا تزال تتراكم مخاطر الوقت غير المرئية
تعكس البنية في تقرير GAO عصرها، لكن نمط الخطر معاصر. الأنظمة طويلة التشغيل تتراكم حالة: تنمو العدادات، وتتدحرج الساعات، وتنتهي صلاحية التراخيص، وتتقادم الشهادات، وتنحرف التعويضات، وتتعمق قوائم الانتظار، وتتضاعف التقريبات العددية. يمكن للخدمة اجتياز اختبارات قصيرة وتفشل بعد أيام أو أشهر من التشغيل.
الأجهزة الحديثة تقدم سجلات أوسع ودقة أكبر، لكن العرض وحده لا يضمن السلامة. لا تزال البرمجيات تحول بين وحدات الوقت ومجالات الساعة والأنواع العددية. تجمع الأنظمة الموزعة بين ساعات الحائط والساعات الرتيبة والطوابع الزمنية البعيدة. الأجهزة المضمنة قد تحافظ على الذاكرة أو قوة المعالجة. تعتمد السلامة على تحليل التمثيل الفعلي ومدة المهمة.
الافتراضات التشغيلية تستمر أيضًا في التغير أسرع من الأنظمة. منصة مصممة للاستخدام المتقطع قد تصبح بنية تحتية متاحة باستمرار. أداة احتياطية قد تصبح خدمة أساسية. انتشار إقليمي قد يصبح عالميًا. نظام مبني لعبء عمل واحد قد يتعرض لبيئة أسرع أو أكثر تقلبًا. كل تغيير يمكن أن يبطل حدًا ضمنيًا.
مشكلة سلسلة التحذير حالية بنفس القدر. فرق الأمن والسلامة تنشر بانتظام تنبيهات بينما يبقى مشغلون عن بعد على إصدارات ضعيفة. قد تظهر لوحات المعلومات أن تصحيحًا موجود دون إثبات التثبيت. قد تصف الرسائل المخاطر بشكل نوعي دون ذكر موعد نهائي أو حالة متأثرة. تظهر الظهران لماذا أهمية أدلة الميل الأخير.
أعمق درس هو أن الوقت يجب أن يُحكم كبيانات. وحدته ودقته وعصره وقيمته القصوى وسلوك إعادة التعيين ومسار تحويله هي متطلبات واجهة. وقت التشغيل هو مدخل لحالة السلامة. إذا نما الخطأ مع الوقت، كل ساعة تشغيل تستهلك هامشًا.
أسئلة للإشراف والقيادة
يجب أن يكون القادة المسؤولون عن البرمجيات عالية العواقب قادرين على الإجابة عن مجموعة محددة من الأسئلة.
ما هي أطول مدة تشغيل مستمر معقولة، وهل تم اختبار النظام بما يتجاوزها؟ أي حسابات تتراكم الخطأ مع الوقت المنقضي؟ ما التأثير الفيزيائي أو الخدمي الذي يتبع من خطأ أسوأ الحالات؟ أين تم توثيق أقصى مدة آمنة؟
من يتلقى بيانات الشذوذ من الميدان، ومن يقرر ما إذا كانت تغير غلاف التشغيل؟ عندما يتم تأكيد خطر، من يملك التخفيف المؤقت أثناء تطوير الإصلاح الدائم؟ هل يمكن لذلك الشخص أن يأمر بإعادة تشغيل أو انقطاع خدمة؟
هل يحتوي التحذير على عتبة قابلة للقياس وإصدارات متأثرة وإجراء مطلوب؟ هل يبلغ الإقرار عن الحالة الفعلية للوحدة؟ هل هناك دليل على أن الإجراء حدث؟
هل يمكن للقيادة تحديد كل تكوين منشور ووقت التشغيل الحالي وحالة التحديث؟ كم من الوقت يستغرق وصول البرمجيات التصحيحية إلى الموقع الأكثر بعدًا؟ هل أولوية التوزيع مرتبطة بالتعرض؟
ما الأدلة التي يتم جمعها أثناء التشغيل؟ هل تم اختبار الأجهزة لعدم التداخل؟ إذا كان التسجيل المباشر غير آمن، ما البديل الذي يدعم اكتشاف الشذوذ وإعادة البناء المستقل؟
من يتحقق بشكل مستقل ليس فقط من تغيير الكود ولكن أيضًا من الإغلاق الميداني؟ ما الحالة التي تغير الوضع من "تم إصدار الإصلاح" إلى "تمت إزالة الخطر"؟
هذه الأسئلة تحول قصة برمجية مشهورة إلى نموذج تشغيل مساءلة. إنها تطلب أدوات وأصحاب وعتبات بدلاً من عبارات الثقة.
الاستنتاج
فشل باتريوت في الظهران كان بسبب مشكلة توقيت برمجية، لكن "خطأ تقريب" هو وصف صغير جدًا للفشل المؤسسي. الدقة المحدودة خلقت خطأً نما مع وقت التشغيل. ظروف الانتشار المتغيرة دفعت النظام إلى ما هو أبعد بكثير من مدة التشغيل التي افترضها المسؤولون. كشفت البيانات الميدانية عن التدهور. تم إصدار تصحيح برمجي، وتم إرسال تحذير، لكن التحذير افتقر إلى عتبة زمنية قابلة للاستخدام ووصل الإصدار المصحح إلى الظهران بعد الهجوم.
سجل GAO يدعم توزيعًا منضبطًا للمسؤولية. امتلكت الهندسة السلوك العددي والتحقق منه. امتلك مكتب المشروع تحويل الشذوذ والتحذير والتصحيح. امتلكت القيادة التشغيلية العقيدة والرؤية في الاستخدام المستمر. امتلكت اللوجستيات تسليم التكوين المتغير. احتاجت الوحدات المنتشرة إلى سلطة وتعليمات صريحة للتخفيف. امتلكت القيادة العليا نظام الأدلة الذي يربط تلك الضوابط.
الدرس الدائم ليس أن أجهزة الكمبيوتر يجب أن تتجنب التقريب. بل أن المنظمات يجب أن تحدد التقريب في ظل الظروف المهمة. الوقت المنقضي وإصدار البرمجيات واستلام التحذير والإجراء التصحيحي يجب أن تصبح كائنات تحكم مرئية. في نظام يحمي حياة الإنسان، لا يمكن أن يظل حد السلامة مخفيًا في التوسع الثنائي لكسر.
المصادر
- https://www.gao.gov/products/imtec-92-26
- https://www.gao.gov/assets/imtec-92-26.pdf
- https://cs.nyu.edu/~exact/resource/mirror/patriot.htm
- https://www.cs.unc.edu/~smp/COMP205/LECTURES/ERROR/lec23/node4.html
- https://gao.justia.com/department-of-defense/1992/2/patriot-missile-defense-imtec-92-26/
- https://ntrl.ntis.gov/NTRL/dashboard/searchResults/titleDetail/ADA344865.xhtml
- https://www.gao.gov/assets/t-nsiad-92-27.pdf
- https://scienceandglobalsecurity.org/archive/sgs08sullivan.pdf
- https://babel.hathitrust.org/cgi/pt?id=pur1.32754076883812
- https://onlinebooks.library.upenn.edu/webbin/book/lookupid?key=ha011339545
- https://ocwitic.epsem.upc.edu/assignatures/se/recursos/patriot-dharan-skeel-siam.pdf
- https://www-users.cse.umn.edu/~arnold/disasters/Patriot-dharan-skeel-siam.pdf
- https://publikationen.bibliothek.kit.edu/1000181916
- https://publikationen.bibliothek.kit.edu/1000181916/160370039
- https://barrgroup.com/sites/default/files/case-study-patriot-missile-defects.pdf
- https://www.pbs.org/wgbh/pages/frontline/gulf/weapons/patriot.html
- https://gulflink.health.mil/scud_info/scud_info_refs/n41en182/patriot.htm