تحمل الخطأ (منظومات-)

أ ب ت ث ج ح خ د ذ ر ز س ش ص ض ط ظ ع غ ف ق ك ل م ن هـ و ي

تحمل الخطأ (منظومات-)

تحمل خطا (منظومات)

Fault-tolerant systems -

تحمّل الخطأ

مفاهيم أساسية	التكرار المكاني
أساسيات الثقة	التكرار الزمني
أنواع الأخطاء	تطبيقات التسامح مع الأخطاء
تقنيات تحقيق التسامح مع الخطأ	آفاق مستقبلية

يُقصد بمنظومات تحمّل الخطأ fault-tolerant systems المفاهيم الرئيسية التي تتقبل بعض الخطأ أو الخلل، وأنواع تلك الأخطاء التي يمكن التغاضي عنها، والعلاقة بين هذا التسامح والتكرار الزائد redundancy، كما تدرس أنواع التكرار المختلفة؛ والتقنيات الأساسية لتصميم منظومات العتاد hardware والبرمجيات software المتسامحة مع الخطأ؛ والطرائق الشائعة لتقييم تلك المنظومات كالموثوقية reliability مثلاً؛ إضافة إلى المجالات التطبيقية الرئيسية للتسامح مع الخطأ (الخلل).

مفاهيم أساسية

المنظومة المتسامحة مع الخطأ هي منظومة قادرة على الاستمرار بأداء وظائفها المنشودة مع وجود أخطاء. يرتبط التسامح مع الخطأ بمعناه الواسع بالموثوقية والعمليات الناجحة وعدم وجود أعطال. وينبغي أن تكون المنظومة المتسامحة مع الخطأ قادرة على التعامل مع كل خلل في المكونات المفردة العتادية والبرمجية؛ ومع انقطاع التيار الكهربائي؛ وأنواع أخرى من مشاكل غير متوقعة، وتبقى مع كل ذلك فاعلة وتحقق المواصفات المطلوبة.

التسامح مع الخطأ ضروري؛ لأنه من المستحيل عملياً بناء منظومة مثالية. والمشكلة الأساسية هي تناقص موثوقيتها جداً كلما ازدادت المنظومة تعقيداً؛ ما لم تُتخذ تدابير تعويضية. فعلى سبيل المثال إذا كانت موثوقية العناصر المفردة 99.99% فإن موثوقية منظومة مؤلفة من 100 مكون غير مكرَّر هي 99.01% (حاصل ضرب الموثوقية المفردة بنفسها 100 مرة)؛ في حين أن موثوقية منظومة مؤلفة من 10000 مكون غير مكرَّر هي 36.79% فقط. ومثل هذه الموثوقية المنخفضة غير مقبولة في معظم التطبيقات. وإذا كانت الموثوقية
99 % مطلوبة لمنظومة ذات 10000 عنصر؛ فيجب أن تكون المكونات المفردة ذات موثوقية 99.999% على الأقل، وهذا يعني زيادة حادة في التكلفة.

ومع أن المصممين يبذلون قصارى جهدهم لتنظيف المنظومة من كل العيوب العتادية والعثرات bugs البرمجية قبل أن تذهب إلى السوق؛ فإن التاريخ يدل على أن مثل هذا الهدف لا يمكن تحقيقه، فلا مناص من أن بعض العوامل البيئية غير المتوقعة لم تؤخذ في الحسبان، أو أنه لم يُتنبأ بوقوع بعض أخطاء المستعملين المحتملة. ولذلك حتى في حالة احتمال أن تكون المنظومة مصممة ومنجزة على نحوٍ تام فسوف يكون هناك على الأرجح أخطاء ناجمة عن حالات خارج سيطرة المصممين.

يُقال عن منظومة ما إنها أخفقت failed إذا توقفت عن أداء وظائفها المنشودة، ويُقصد بالمنظومة في هذا البحث معناها الواسع؛ أي مجموعة من عناصرَ مفردة؛ لكنها مترابطة وتؤلف كياناً موحَّداً. ومن ثَم فالتقنيات المعروضة قابلة للتطبيق على مجموعة متنوعة من المنتجات والتجهيزات والمنظومات الفرعية. ويمكن أن يتجلى إخفاقها بالتوقف الكامل عن أداء وظيفة معينة؛ أو أداء بعض الوظائف بجودة أو كمية دون السوية؛ مثل تدهور العمليات أو عدم استقرارها. والهدف من التصميم المتسامح مع الأخطاء هو تقليل احتمال حدوث الأعطال سواء أكانت بسيطة كإزعاج للمستعملين، أم جسيمة تؤدي إلى خسران ثروات أو إصابات بشرية أو كوارث بيئية.

أساسيات الثقة

الهدف النهائي من التسامح مع الخطأ هو جعل المنظومة في حالة يمكن الاعتماد عليها. والثقة dependability عموماً هي قدرة المنظومة على تقديم المستوى المقصود من الخدمة لمستعمليها. وعندما تغدو الحوسبة في كل مكان، ومتغلغلة في الحياة اليومية على جميع المستويات تصبح الثقة مهمة؛ ليس فقط للتطبيقات التقليدية الحرجة من حيث الأمان أو المهام أو الأعمال business-, mission-, or safety-critical؛ ولكن أيضاً للمجتمع برمّته.

تتعرض الثقة لثلاث مسائل أساسية: الضعف، الوسائل، الصفات. يعبِّر ضعف الثقة عن علةِ توقُّف المنظومة عن أداء وظيفتها، أو بعبارة أخرى: التهديدات التي تتعرض لها تلك الثقة. أما وسائل الثقة فهي الأساليب والتقنيات التي تتيح تطوير منظومة يمكن الاعتماد عليها؛ مثل تفادي الخطأ؛ والتسامح مع الخطأ؛ وإزالة الخطأ، والتنبؤ بالخطأ. وتعبِّر صفات الثقة عن الخصائص التي تُتوقع من المنظومة.

الصفات الرئيسية للثقة ثلاث هي: الموثوقية، والمتاحية availability، والأمان. وثَمة صفات أخرى ممكنة منها: قابلية الصيانة maintainability، وقابلية الاختبار testability، وجودة الأداء performability، والأمن. واعتماداً على التطبيق يمكن أن يُحتاج إلى واحدة أو أكثر من هذه الصفات لتقييم سلوك المنظومة تقييماً صحيحاً. ففي آلة الصراف الآلي Automated Teller Machine (ATM) -مثلاً- تُعَدّ نسبة الوقت التي تكون فيه المنظومة قادرة على تقديم المستوى المقصود من الخدمة (متاحية المنظومة) مقياساً مهماً. وفي حالة مريض القلب المزوَّد بجهاز تنظيم ضربات القلب مثلاً يُعَدّ استمرار عمل الجهاز مسألة حياة أو موت. وهكذا فإن قدرة المنظومة على تقديم خدماتها من دون انقطاع (موثوقية المنظومة) هو أمر بالغ الأهمية. وفي منظومة التحكم في محطة للطاقة النووية تُعَدّ قدرة المنظومة على أداء وظائفها أداءً صحيحاً؛ أو وقف وظيفتها بطريقة آمنة (أمان المنظومة) أمراً ذا أهمية قصوى.

الموثوقية هي مقياس لاستمرار الخدمة الصحيحة. والموثوقية العالية مطلوبة في الحالات التي يتوقع أن تعمل المنظومة فيها من دون انقطاع؛ كما هي الحال مع جهاز تنظيم ضربات القلب، أو في الحالات التي لا يمكن فيها إجراء الصيانة لعدم إمكان الوصول إليها؛ كما هي الحال مع تطبيقات الفضاء السحيق deep space. وعلى سبيل المثال من المفروض أن توفر منظومة التحكم في مركبة فضائية الخدمة من دون انقطاع، ويمكن على الأرجح أن يسبب خللٌ ما في المنظومة تدميرَ المركبة الفضائية؛ كما حدث في حالة ساتل ناسا الفضائي «لويس Lewis» المصمم ليدور حول الأرض والذي أطلق في 23 آب /أغسطس عام 1997، فقد دخل الساتل في مدار مسطّح مما أدى إلى فقدان في الطاقة الشمسية وتفريغ البطارية تفريغاً قاتلاً، وفُقد الاتصال بالساتل ودُمِّر في 28 أيلول/سبتمبر1997؛ ووفقاً لما ورد في تقرير التحقيق حول إخفاقِ مهمة الساتل لويس أن العطل حدث لعيوب فنية في تصميم منظومة التحكم في مراقبة سلوكه، وكانت مراقبة الساتل غير مناسبة في المرحلة الأولى في عمله.

أنواع الأخطاء

يمكن عموماً تصنيف الأخطاء التي تصيب المنظومات في أخطاء مادية physical وأخطاء برمجية soft. فالأخطاء المادية هي أعطال تصيب المكونات المادية؛ كالخدوش التي تصيب الأقراص المدمجة CDs أو أقراص الفيديو الرقمية DVDs؛ أو تعطل الحاسوب في أثناء التنفيذ؛ أو انقطاع شبكة الاتصال. أما الأخطاء البرمجية فهي عموماً أخطاء في أثناء البرمجة؛ مثل توقف مخدم برمجي عن العمل نتيجة عطل برمجي أو هجوم أمني؛ أو توقف خدمة من خدمات نظام التشغيل بسبب إعدادات خاطئة.

تقنيات تحقيق التسامح مع الخطأ

ثَمة أساليب مختلفة لتحقيق التسامح مع الخطأ. وثمة تقاطعات بين جميع هذه الطرائق؛ هي قدْر معين من التكرار الزائد؛ أي توفير القدرات الوظيفية غير الضرورية في بيئة خالية من الخطأ fault-free، ويتجلى ذلك بتكرار مكوِّن عتادي hardware component أو إرفاق بت إضافي إلى متوالية معطيات رقمية string of digital data؛ أو زيادة بضعة أسطر من رماز البرنامج program code للتحقق من صحة نتائج البرنامج. كان راعي فكرة تضمين التكرار بغية تحسين موثوقية المنظومات جون فون نويمان John von Neumann في الخمسينيات من القرن العشرين، في عمله «المنطق الاحتمالي وتركيب كائناتٍ موثوقة من مكونات غير موثوقة».

ثمة نوعان من التكرار: التكرار المكاني space redundancy والتكرار الزمني redundancy time. يوفر التكرار المكاني مكوناتٍ أو وظائف أو بنود معطيات إضافية لا لزوم لها في العمليات الخالية من الخطأ fault-free operations. أما في التكرار الزمني فيجري إعادة حساب المعطيات أو نقلها؛ ومقارنة النتيجة بنسخة مخزَّنة من النتيجة السابقة.

1- التكرار المكاني

يصنَّف التكرار المكاني في تكرار عتادي؛ وتكرار برمجي؛ وتكرار المعلومات، وهذا يتوقف على نوع الموارد المكرَّرة المضافة إلى المنظومة.

التكرار العتادي

يتحقق التكرار العتادي بتوفير نسختين ماديتين أو أكثر من مكون العتاد. على سبيل المثال قد تحوي المنظومة عدة معالِجات processors، وذواكر ومساري buses ووحدات تغذية مكرَّرة. وعندما تُستنفد التقنيات الأخرى -مثل استعمال مكونات أكثر موثوقية، ومراقبة جودة التصنيع والاختبار وتبسيط التصميم وما إلى ذلك- يمكن أن يكون التكرار العتادي هو السبيل الوحيد لتحسين الثقة بالمنظومة. فعلى سبيل المثال في حالات عدم إجراء صيانة للمعدات -كسواتل الاتصالات- فإن المكونات المكرَّرة تسمح بإطالة وقت التشغيل من دون انقطاع.

وفي المقابل يمكن أن يسبب التكرار العتادي عدداً من المشاكل كزيادة في الوزن والحجم وفي استهلاك الطاقة والتكلفة، وكذلك في التصميم والتصنيع والاختبار. وهناك عدد من الخيارات للتحقق ولتحديد أفضل طريقة لمكاملة التكرار في منظومة معينة. فعلى سبيل المثال يمكن أن تخفَّض زيادة الوزن بتطبيق التكرار على مكونات من مستوى أعلى، كما يمكن التقليل من الزيادة في التكاليف إذا كان التحسن المتوقع في الثقة أقل من تكلفة الصيانة الوقائية للمنظومة.

هناك ثلاثة أنواع من التكرار العتادي: التكرار الخامل passive والتكرار النشط active والتكرار الهجين hybrid. يحقق التكرار الخامل التسامح مع الخطأ عن طريق إخفاء الأخطاء التي تَحدث من دون الحاجة إلى اتخاذ أي إجراء لتلافيها من المنظومة أو المشغّل. ويتطلب التكرار النشط أن يجري الكشف عن الخطأ قبل التسامح معه، فبعد الكشف عن الخطأ يجري تحديدُ موقعه واحتواؤه وتلافيه بإزالة المكون المحتوي على الخلل من المنظومة. وتتطلب تقنيات التكرار النشط إيقاف المنظومة عن العمل وإعادة تشكيلها للتسامح مع الأخطاء. أما التكرار الهجين فيجمع بين النهجين الخامل والنشط. ويجري تلافي الأخطاء لمنع توليد نتائج خاطئة، ويجري كشف الخطأ وتحديد موقعه وتلافيه وتبديل المكون المحتوي على الخلل بمكون احتياطي، ويمكّن التكرار الهجين من إعادة تكوين المنظومة من دون تعطيلها.

جرى في الأصل استعمال تقنيات التكرار للتعامل مع الموثوقية المنخفضة لمكونات العتاد الأساسية، فقد لجأ مصمّمو منظومات الحوسبة الأولى إلى التكرار الثلاثي triplicate للمكونات المنخفضة المستوى، مثل البوابات والقلابات، وطبّقوا التصويت بالأغلبية majority voting لتصحيح الأخطاء (الفكرة مماثلة لمبدأ العمل (الشكل3). وأطلق على تقنية التكرار الثلاثي أيضاً: Triple Modular Redundancy (TMR). ومع تحسن موثوقية المكونات الأساسية انتقل التكرار إلى مستويات أعلى؛ إذ جرى تكرار مكونات أكبر حجماً؛ مثل الذواكر ووحدات المعالجة، وبهذا انخفض حجم إخفاق الناخبين النسبي لتلك المكونات المكرَّرة واحتمالاته.

إنّ استعمال التكرار لا يضمن تحسناً فورياً في الثقة بالمنظومة، والزيادة الإجمالية في التعقيد الناجم عن التكرار يمكن أن تكون قاسية جداً، فقد تُقلِّل من الثقة ما لم يجرِ تحصيص الموارد المكرَّرة بطريقة صحيحة، ولا بد من إجراء تحليل دقيق للتحقق من إمكان الحصول على منظومة يمكن الاعتماد عليها أكثر في نهاية المطاف.

هناك عدد من الاحتمالات يمكن تفحصها لتحديد: المستوى الأفضل لتوفير التكرار، والمكونات التي ينبغي تكرارها.

تُستعمل أيضاً إلى جانب طريقة التكرار الثلاثي طريقة الاختبار الذاتي المضمن Built-In Self-Test (BIST). في هذه الطريقة تقوم المنظومة دورياً بفحص ذاتي لجميع مكوناتها، وفي حال العثور على عطل تعيد المنظومة تشكيل نفسها آلياً بإخراج المكون المحتوي على الخلل من الخدمة؛ وإدخال أحد المكونات المكرَّرة الجيدة.

التكرار البرمجي

يمكن تقسيم تقنيات التسامح مع الخطأ البرمجية إلى مجموعتين: الإصدار المفرد single version، والإصدارات المتعددة multi version. وتهدف تقنيات الإصدار المفرد إلى تحسين التسامح مع الخطأ لأحد المكونات البرمجية عن طريق تزويده بآلية لكشف الخطأ واحتوائه وتلافيه. أما تقنيات الإصدارات المتعددة فتستعمل مكونات برنامج مكررة يجري تطويرها باتباع قواعد التصميم.

وكما في حالة العتاد يجب تحرّي الخيارات المختلفة لتحديد المستوى الذي يجري عنده إدخال التكرار والمجتزآت البرمجية software modules التي يجب أن تُتخذ منها إصدارات مكرَّرة. يمكن تطبيق التكرار على مستوى إجراءٍ procedure؛ أو عملية process؛ أو منظومة برمجية كاملة. يطبق التكرار عادة على المكونات التي تُبدي أقل موثوقية. وعلى المرء أن يكون على عِلم بأن زيادة التعقيد الناجم عن التكرار يمكن أن تكون لها عواقب قاسية جداً وربما تُقلل من تحسين الثقة؛ ما لم يجرِ تحصيص الموارد المكرَّرة بطريقة مناسبة.

تشمل منهجياتُ التكرار البرمجي: تقنياتِ الإصدار المفرد العامة للكشف عن الخطأ في البرمجيات، واحتوائه، والتعافي منه، وتقنياتِ الإصدارات المتعددة الرئيسية: البرمجة بـ N إصداراً n-version programming، وكتل التعافي recovery blocks، ونقاط التدقيق والتعافي بالتراجع check-pointing and roll-back recovery. البرمجة بـ N إصداراً هي تقنية مقتبسة من تقنية التكرار الثلاثي العتادية TMR؛ إذ تنفَّذ المجتزآت البرمجية المكرَّرة على التساير (في آن معاً) concurrently، وتؤخذ النتائج المكرَّرة بالأكثرية. أما في تقنية كتل التعافي فتقوم المكونات المكرَّرة (وتسمى كتلاً) بحساب النتائج ذاتها لكن باستعمال خوارزمية مختلفة. في البرمجة
بـ N إصداراً تكون المجتزآت البرمجية عادةً من تطوير فِرَق برمجية مختلفة، أما في تقنية كتل التعافي فتُطبَّق خوارزميات مختلفة في الكتل المختلفة. وأخيراً في طريقة نقاط التدقيق والتعافي بالتراجع يجري قياس حالة المنظومة عند كل نقطة تدقيق؛ وفي حال كون الاختبار ناجحاً تتابع المنظومة تنفيذها، وفي الحالة المعاكسة تعود المنظومة إلى آخر نقطة تدقيق صالحة (الشكل 1).

الشكل (1) نقاط التدقيق والتعافي. بالتراجع.

البرمجيات مقابل العتاديات

ثَمة اختلافات بين المنظومات العتادية والبرمجية. وعموماً لا يكون التسامح مع الخطأ في مجال البرمجيات مفهوماً أو ناضجاً كما في حالة التسامح مع الخطأ في مجال العتاديات. ففي حالة العتاديات يمكن تبسيط تقييم الموثوقية بافتراض الإخفاقات في المكونات هي أحداث مستقلة، وعادةً ما يكون غير واقعي وضعُ مثل هذا الافتراض للبرمجيات، حيث تميل أعطال المجتزآت البرمجية إلى أن تكون عالية الترابط فيما بينها highly correlated. فالحساب الذي يُجرى في مجتزأ غالباً ما يرتبط ارتباطاً مباشراً أو غير مباشر بالحساب الذي تؤديه مجتزآت أخرى، ولذلك يكون الخطأ في نتائج مجتزأ معيّن ذا تأثير في نتائج مجتزآت أخرى.

ثمة آراء مثيرة للجدل بخصوص إمكان استعمال الموثوقية مقياساً للثقة بالبرمجيات، فالبرمجيات لا يتردى أداؤها مع مرور الوقت، وأعطالها على الأغلب تكون بسبب تفعيل أخطاء في المواصفات أو التصميم بوساطة تسلسل المدخلات. لذلك في حالة وجود خطأ في البرمجيات ينكشف الخطأ في المرة الأولى التي تَحدث فيها الشروط ذات الصلة، وهذا ما يجعل من موثوقية مجتزأ برمجي يعتمد على البيئة التي تولد مدخلات المجتزأ مع مرور الوقت. تعطي البيئات المختلفة قيم موثوقية مختلفة؛ فمثلاً يُعدّ حادث الصاروخ أريان 5 Ariane نموذجاً لسؤال: كيف يمكن لقطعة من البرمجيات -آمنة في حالة بيئة تشغيل الصاروخ أريان (4)- أن تسبب كارثة في بيئةٍ جديدة؟

كثير من التقنيات الحالية للتسامح مع الخطأ البرمجي شبيه بمخططات التكرار العتادي. فعلى سبيل المثال تماثل البرمجة بـ N إصداراً التكرار العتادي بـ N مجتزأ، ومع ذلك فالبرمجيات مختلفة بطبيعتها عن العتاديات. وقد جرى تطوير التقنيات التقليدية للتسامح مع الخطأ العتادي للتخفيف من أخطاء العناصر الدائمة في المقام الأول؛ وللتخفيف من الأخطاء العابرة الناجمة عن العوامل البيئية ثانوياً؛ فهي لا توفر حمايةً كافية من أخطاء التصميم المهيمنة في مجال البرمجيات. ومن الواضح أنه لا يمكن التسامح مع خطأ في مجتزأ برمجي بتكرارها ثلاثاً ومن ثمّ التصويت على النتائج؛ لأن جميع الإصدارات فيها أخطاء متطابقة، وبدلاً من ذلك لا بد من إعادة تنجيز كلّ من المجتزآت المكررة بطريقة مختلفة.

البرمجيات هي أكثر تعقيداً جداً من العتاديات. على سبيل المثال، تحوي منظومةُ تفادي الاصطدام المطلوبة لمعظم الطائرات التجارية في الولايات المتحدة 1,400 حالة، إنّ مثل هذه الحالات ليست مشكلة إذا أظهرت انتظاماً معيّناً، وهو أمر شائع في العتاديات. ولكن البرمجيات غير منتظمة إلى حدّ بعيد. ولذلك لا يمكن تخفيض عدد الحالات عن طريق تجميعها في صفوف تكافؤ. وهذا يعني أنه لا يوجد سوى جزء برمجي صغير جداً من المنظومة يمكن التحقق من صحته، حتى أفضل النظم البرمجية جودة تحوي 3.3 أخطاء في 1000 سطر رماز غير موثَّق. وطرائق الاختبار والتفلية debugging التقليدية بطيئة بطبيعتها وغير قابلة للتصعيد unscalable، وعادةً ما تكون غير قادرة على «تغطية» الحالات الوظيفية الرئيسية؛ أو إيجاد عثرات bugs يصعب العثور عليها، ولا يمكن أن تحدث إلا بعد مئات الآلاف من الدورات (مثل عثرة إنتل بنتيوم في حساب الفاصلة العائمة Floating DIVide (FDIV). ومع أن الطرق الرسمية تبشر بتغطية أعلى؛ لكنها بسبب تعقيدها الحسابي الكبير غير قابلة للتطبيق إلا في تطبيقات محددة. ومن عواقب التحقق غير المكتمل يبقى العديد من أخطاء التصميم في البرمجيات غير مكتشف، مما يولِّد احتمال وقوع حوادث خطرة؛ كما حدث في زيادة جرعات جهاز العلاج الإشعاعي Therac-25؛ وغرق المدمرة البريطانية شيفيلد Sheffield بصاروخ إكزوسيت Exocet الفرنسي الصنع بعدما أخطأه صاروخ مضاد عائد إلى المدمرة؛ وكذلك انفجار صاروخ أريان (5)؛ وتفكك مكوك الفضاء تشالنجر Challenger.

تكرار المعلومات

يمكن التسامح مع الخطأ عن طريق الترميز coding؛ فالترميز تقنية قوية تساعد على تجنب التغييرات غير المرغوب فيها في المعلومات في أثناء تخزين المعطيات أو نقلها.

توجِّهُ اختيار رماز تطبيق معيّن عادةً أنواع الأخطاء ومعدلها المطلوب التسامح معه (السكوت عنه)؛ والنتائج المترتبة عليها، والأعباء المرتبطة بتنجيز الترميز وفك الترميز. فعلى سبيل المثال تستعمل التطبيقات المعرضة للخدوش- مثل الأقراص المدمجة أو أقراص الفيديو الرقمية -رموز ريد- سولومون Reed-Solomon cods القوية المصمَّمة خاصة لأخطاء رشقية bursty faults. وفي الذواكر الرئيسية التي تخزن ملفات المنظومة الحرجة غير القابلة للاسترداد تُستعمل عادةً رموز هامينغ Hamming لتصحيح الأخطاء، في حين تُستعمل رموز ندّية parity codes لكشف أرخص الأخطاء ثمناً في الخوابي caches؛ والتي يمكن استرجاع محتوياتها إذا وُجدت فيها عيوب.

2- التكرار الزمني

يؤثر التكرار العتادي في حجم المنظومة ووزنها واستهلاكها للطاقة الكهربائية وتكلفتها، وفي بعض التطبيقات من الأفضل إضافة زمن بدلاً من إضافة عتاد لتحمّل الأخطاء.

ثمة تقنيات تكرار زمني لاكتشاف الأخطاء العابرة transient faults وتصحيحها، وتقنيات لدمج التكرار الزمني مع مخطط ترميز محدد لمعالجة الأخطاء الدائمة permanent faults.

أ-الأخطاء العابرة

يتمثل التكرار الزمني بتكرار حساب أو نقل معطيات مرتين أو أكثر، ومقارنة النتائج بالنسخ المخزنة سابقاً.

إذا كان الخطأ عابراً- كانت النتائج المخزّنة مختلفة عن النتائج التي أُعيد حسابها، فإذا حدث التكرار مرتين -كما هو مبين في الشكل (2)- يمكن كشف خطأ مفرد، وإذا حدث التكرار ثلاث مرات -كما هو مبين في الشكل (3)- يمكن تصحيح خطأ مفرد. كما يمكن استعمال تقنيات تصويت- مماثلة لتلك المستعملة في حالة تكرار العتاد- لاختيار النتيجة الصحيحة.

الشكل (2) التكرار الزمني لكشف الخطأ العابر.

الشكل (3) التكرار الزمني لتصحيح الخطأ العابر.

يمكن أن يكون التكرار مفيداً أيضاً للتمييز بين خطأ عابر وخطأ دائم، فإذا اختفى الخطأ بعد إعادة الحساب يمكن الافتراض أنه خطأ عابر. وفي هذه الحالة ليست هناك حاجة إلى إعادة تكوين المنظومة وإبدال وحدة العتاد المتضررة، ويمكن أن تظل في وضعية العمل فتُحفظ الموارد من الهدر.

المشكلة الرئيسية مع التكرار الزمني هو افتراض أن المعطيات المطلوبة لتكرار حساب ما متوفرة في المنظومة، ولمّا كان الخطأ العابر قادراً على التسبب في إخفاق المنظومة فقد يكون من الصعب- أو ليس من الممكن- تكرار الحساب.

ب-الأخطاء الدائمة

إذا اجتمع التكرار الزمني مع مخطط ترميز محدَّد فإنه يمكن أن يُستعمل لكشف الأخطاء الدائمة وتصحيحها. تتوفر أربع تقنيات للتكرار الزمني تستهدف الأخطاء الدائمة: المنطق المتناوب، وإعادة إجراء الحساب مع إزاحة المعاملات، وإعادة إجراء الحساب مع إبدال المعاملات، وإعادة إجراء حساب مع الازدواجية والمقارنة.

تطبيقات التسامح مع الأخطاء

جرى استعمال تقنيات التسامح مع الخطأ في الأصل للتعامل مع العيوب المادية في المكونات العتادية المفردة، ولذلك لجأ مصممو نظم الحوسبة الأولى إلى تكرار العناصر الأساسية ثلاثاً؛ واستعمال التصويت بالأغلبية لإخفاء أثر الأخطاء.

بعد الحرب العالمية الثانية زاد الاهتمام بالتسامح مع الخطأ إلى حدٍّ بعيد. وكان أحد أسباب هذا مشاكل موثوقية المعدات الإلكترونية التي حصلت خلال الحرب، وأصبح من الواضح أن التقانة العسكرية المستقبلية سوف تعتمد اعتماداً كبيراً على الأجهزة الإلكترونية المعقدة. وثمة عامل تحفيز آخر هو «سباق الفضاء» بين الولايات المتحدة والاتحاد السوفييتي (سابقاً) التي تلت إطلاق أول ساتل حول الأرض «سبوتنيغ» Sputnik في عام 1957. ونتيجة لذلك بدأت وزارات الدفاع ووكالات الفضاء في العديد من البلدان تدرس مشاريع التسامح مع الأخطاء.

ومن أمثلة التسامح مع الخطأ العتادي: الإبدال الساخن hot swapping ، ويتمثل بإبدال الأجزاء المتوقفة بقِطع جديدة مع بقاء المنظومة في حالة عمل. تمتاز المنظومات التي من هذا النوع والمنجزة باستعمال مكون احتياطي مفرد، بتسامحها مع خطأ مفرد single point tolerant.

حقق التسامح مع الخطأ نجاحاً ملحوظاً في مجال التطبيقات الحاسوبية، فالحواسيب المزدوجةtandem computers مثلاً تستعمل التسامح مع خطأ مفرد لتوفير منظومات لا تتوقف Nonstop في زمن عمل uptime يقاس بالسنوات. ومن متطلبات الحاسوب المزدوج: الكشف عن الخطأ تلقائياً، وإعادة تشكيل المنظومة وإصلاحها من دون توقف وظائف المكونات الخالية من العطل ضمن المنظومة.

آفاق مستقبلية

التسامح مع الخطأ مجال خصب للبحث والدراسة. دُرس تطبيق التقنيات العامة للتسامح مع الخطأ في نظم الزمن الحقيقي، ونظم قواعد المعطيات، ونظم الحوسبة المتنقلة، والنظم الموزَّعة، وغيرها. والغاية هي تحقيق استمرارية عمل تلك المنظومات في ظل وجود أعطال مادية مرتبطة بمكوناتها، لكن جميع محاولات تطوير التقنيات -مثل التسامح مع الخطأ الحيوي bio-inspired- لاقت تقاطعاً مشتركاً يتمثل بإضافة أجزاء مكرَّرة مدروسة بعناية في جميع الحالات.

وترى شركات الأعمال أن التسامح بالأعطال يعني متاحية عالية high-availability. تميل الشركات إلى تطلب موثوقية أعلى (99.999 متاحية) وزمن عمل أطول لتطبيقات خطوط الأعمال ذات المهمات الحرجة الخاصة بها. وتميل تلك الشركات إلى تحمّل نفقات طائلة الكلفة للعتاد hardware والعناقيدclusters ذات المتاحية العالية، وإلى خدمات التسامح مع الخطأ بغية ضمان زمن عمل أعظمي.

نزار الحافظ

مراجع للاستزادة:

- E. Dubrova, Fault-Tolerant Design, Springer, 2013.