هندسة الوثوقية

برنامج الوثوقية هو نظام معقد قائم على المعرفة والمعرفة يتفرد به منتجات وعملياته. تدعمها القيادة، مبنية على المهارات التي يطورها المرء داخل فريق، ومدمجة في العمليات التجارية ويتم تنفيذها من خلال اتباع ممارسات العمل القياسية المثبتة.

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

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

كما يمكن استخدام خطة برنامج الوثوقية لتقييم وتحسين توافر النظام من خلال إستراتيجية التركيز على زيادة قابلية الاختبار والصيانة وليس على الوثوقية. تحسين الصيانة هو أسهل عموما من تحسين الوثوقية.

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

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

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

وعلاوة على ذلك، ينبغي أن تؤدي متطلبات تصميم الوثوقية إلى تصميم لدمج ميزات تمنع حدوث الفشل، أو الحد من عواقب الفشل في المقام الأول. يجب أن يكون أي نوع من متطلبات الوثوقية مفصلاً ويمكن الحصول عليه من تحليل الفشل أو أي نوع من اختبارات الوثوقية.

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

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

من الناحية العملية، يمكن إرجاع معظم حالات الفشل إلى نوع من الخطأ البشري، على سبيل المثال في:

قرارات الإدارة (على سبيل المثال في الموازنة، والتوقيت، والمهام المطلوبة)

هندسة النظم: استخدام الدراسات (حالات التحميل)

هندسة الأنظمة: تحليل المتطلبات / الإعداد

هندسة الأنظمة: التحكم في التهيئة

الافتراضات

الحسابات / المحاكاة

التصميم

تصميم الرسومات

الاختبار (على سبيل المثال، إعدادات التحميل غير الصحيحة أو قياس الفشل)

تحليل احصائي

تصنيع

رقابة جودة

أعمال صيانة

كتيبات الصيانة

تدريب

تصنيف وترتيب المعلومات

تعليقات المعلومات الميدانية (على سبيل المثال، غير صحيحة أو غامضة للغاية)

إلخ

ومع ذلك، فإن البشر أيضًا جيدون جدًا في اكتشاف حالات الفشل هذه، وتصحيحها، والارتجال عند حدوث حالات غير طبيعية. لذلك، السياسات التي تستبعد تمامًا الإجراءات البشرية في عمليات التصميم والإنتاج لتحسين الوثوقية قد لا تكون فعالة. يتم تنفيذ بعض المهام بشكل أفضل من قبل البشر، ويتم تنفيذ بعضها بشكل أفضل بواسطة الآلات.[4]

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

تنبؤ هندسة الوثوقية تشمل:

خلق نموذج الوثوقية المناسب

تقدير (وتصليح) المعلومات المدخلة إلى هذا النموذج (على سبيل المثال معدلات الفشل في وضع فشل معين أو الحدث والوقت يعني لإصلاح النظام لفشل معين)

تقدير معلمات وثوقية المخرجات على مستوى النظام أو المستوى (أي توفر النظام أو تواتر عطل وظيفي معين) قد ينطوي على وجود حد للوثوقية القابلة للتحقيق، ومع ذلك، لا يوجد حد ملازم وتطوير وثوقية أعلى لا تحتاج إلى أن تكون أكثر تكلفة. بالإضافة إلى ذلك، فإنهم يجادلون بأن التنبؤ بالاعتمادية من البيانات التاريخية يمكن أن يكون مضللاً للغاية، مع المقارنات صالحة فقط للتصاميم متطابقة، والمنتجات، وعمليات التصنيع، والصيانة مع متطابقة تحميل الاحمال وبيئات الاستخدام. حتى التغييرات الطفيفة في أي من هذه يمكن أن يكون لها صلاحيات رئيسية على الوثوقية. وعلاوة على ذلك، فإن أكثر البنود التي لا يمكن الاعتماد عليها والأكثر أهمية (أي المرشحات الأكثر إثارة للاهتمام لإجراء تحقيقات بشأن الوثوقية) من الأرجح أن يتم تعديلها وإعادة تصميمها منذ جمع البيانات التاريخية، مما يجعل الطرق الإحصائية القياسية (إعادة النشاط أو الاستباقية) والعمليات المستخدمة مثلا الصناعات الطبية أو التأمين أقل فعالية.[5]

بالنسبة للأنظمة الحالية، يمكن القول إن أي محاولة من قبل برنامج مسؤول لتصحيح السبب الجذري للفشل المكتشف يمكن يجعل تقدير متوسط الوقت بين الفشل الأولي باطلاً، حيث يجب إجراء افتراضات جديدة (تخضع لمستويات خطأ عالية) لتأثير هذا التصحيح.

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

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

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

بالنسبة للتنبؤات على مستوى الجزء، هناك مجالان منفصلان للتحقيق شائعان:

يستخدم فيزياء نهج الفشل فهم لآليات الفشل المادية المعنية، مثل انتشار الشقوق الميكانيكية أو تدهور أو فشل التآكل الكيميائي

يُعد نهج نمذجة ضغط األجزاء طريقة تجريبية للتنبؤ تستند إلى حساب عدد ونوع مكونات النظام والضغط الذي يتعرض له أثناء التشغيل.

تعتبر وثوقية البرامج مجالًا أكثر تحديًا ويجب أخذها في الاعتبار عندما يوفر رمز الكمبيوتر مكونًا كبيرًا من وظائف النظام.

الغرض من اختبار الوثوقية هو اكتشاف المشاكل المحتملة في التصميم في أقرب وقت ممكن، وفي نهاية المطاف، توفير الثقة بأن النظام يلبي متطلبات الوثوقية الخاصة به.

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

مع كل اختبار يمكن إجراء كل من النوع الإحصائي 1 والخطأ 2 ويعتمد على حجم العينة ووقت الاختبار والافتراضات ونسبة التمييز المطلوبة. هناك خطر من قبول تصميم غير صحيح بشكل خاطئ (خطأ من النوع 1) وخطر رفض التصميم الجيد بشكل خاطئ (خطأ من النوع2)

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

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

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

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

اختبار الوثوقية أمر شائع في صناعة الضوئيات. أمثلة على اختبارات الوثوقية من أشعة الليزر هي اختبار الحياة والحرق. تتكون هذه الاختبارات من الشيخوخة المتسارعة للغاية، تحت ظروف خاضعة للرقابة، لمجموعة من الليزر. يتم استخدام البيانات التي تم جمعها من اختبارات الحياة هذه للتنبؤ بالعمر المتوقع للليزر تحت خصائص التشغيل المقصودة.[8]

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

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

على الرغم من هذا الاختلاف في مصدر الفشل بين البرامج والأجهزة، فقد تم اقتراح العديد من نماذج الاعتمادية للبرامج المستندة إلى الإحصائيات لقياس ما نعاني منه مع البرامج: حيث يتم تشغيل البرنامج الأطول، كلما زادت احتمالية استخدامه في نهاية الأمر في نظام غير مجرب. بطريقة ما وتعرض عيب كامن ينتج عنه فشل.(Shooman 1987), (Musa 2005), (Denney 2005).

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

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

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

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

يمكن أن تتحول مخاطر الاعتمادية إلى حوادث تؤدي إلى خسارة في الإيرادات للشركة أو العميل، على سبيل المثال بسبب التكاليف المباشرة وغير المباشرة المرتبطة بفقدان الإنتاج بسبب عدم توفر النظام ؛ مطالب عالية أو منخفضة غير متوقعة لقطع الغيار. تكاليف الإصلاح؛ ساعات العمل؛ إعادة التصاميم؛ الانقطاعات في الإنتاج الطبيعي إلخ.[9]

غالبًا ما تكون هندسة الأمان محددة للغاية، وتتعلق فقط بصناعات أو تطبيقات أو مناطق معينة محكمة التنظيم. ويركز في المقام الأول على مخاطر سلامة النظام التي يمكن أن تؤدي إلى حوادث خطيرة بما في ذلك: فقدان الحياة؛ تدمير المعدات أو أضرار بيئية؛ على هذا النحو، غالباً ما تكون متطلبات الوثوقية الوظيفية للنظام ذات الصلة عالية للغاية. على الرغم من أنها تتعامل مع حالات الفشل غير المرغوب فيها بنفس المعنى مثل هندسة الوثوقية، إلا أنها، مع ذلك، لديها تركيز أقل على التكاليف المباشرة، ولا تهتم بإجراءات الإصلاح بعد الفشل. وهناك فرق آخر هو مستوى تأثير الفشل على المجتمع، مما يؤدي إلى ميل للسيطرة الصارمة من قبل الحكومات أو الهيئات التنظيمية (مثل صناعات الطاقة النووية والفضائية والدفاع والسكك الحديدية والنفط).[9]

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

هندسة الوثوقية هي جزء هندسي متخصص في هندسة الأنظمة. عملية هندسة الأنظمة هي عملية اكتشاف تختلف تمامًا عن عملية التصنيع. تركز عملية التصنيع على الأنشطة المتكررة التي تحقق مخرجات عالية الجودة بأقل تكلفة ووقت. يجب أن تبدأ عملية هندسة الأنظمة باكتشاف مشكلة حقيقية (محتملة) تحتاج إلى حل. أكبر فشل يمكن تحقيقه في هندسة الأنظمة هو إيجاد حل أنيق للمشكلة الخاطئة (أو من حيث الوثوقية: «توفير حلول أنيقة للأسباب الجذرية الخطأ لفشل النظام»).

مصطلح الاستخدام اليومي «جودة المنتج» يُعتبَر على أنه يعني درجة امتيازه المتأصلة. في الصناعة، يتم استخدام تعريف أكثر دقة للجودة «المطابقة للمتطلبات أو المواصفات في بداية الاستخدام». بافتراض أن مواصفات المنتج النهائي تلتقط بشكل كاف المتطلبات الأصلية واحتياجات العميل / النظام، يمكن قياس مستوى الجودة على أنه جزء من وحدات المنتج التي يتم شحنها والتي تلبي المواصفات.[10]

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

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

الجودة هي لقطة في بداية الحياة وترتبط بشكل أساسي بالتحكم في مواصفات المنتج الأقل مستوى. ويشمل ذلك العيوب الزمنية-صفر حيث أفلتت أخطاء التصنيع من مراقبة الجودة النهائية. نظريًا، يمكن وصف مستوى الجودة بجزء واحد من المنتجات المعيبة. تعد الوثوقية (كجزء من هندسة الأنظمة) أكثر من حساب مستمر للقدرات التشغيلية، في كثير من الأحيان على مدى سنوات عديدة. من الناحية النظرية، سوف تفشل جميع البنود على مدى فترة لا حصر لها من الزمن.[11] ويشار إلى العيوب التي تظهر بمرور الوقت بأنها تداعيات الوثوقية. لوصف الاعتمادية تداعيات هناك حاجة إلى نموذج الاحتمال الذي يصف جزء الكسر مع مرور الوقت. هذا هو المعروف باسم نموذج توزيع الحياة.[10] قد تكون بعض مشكلات الوثوقية هذه ناتجة عن مشكلات التصميم المتأصلة، والتي قد تكون موجودة على الرغم من توافق المنتج مع المواصفات. حتى العناصر التي يتم إنتاجها بشكل مثالي قد تفشل بمرور الوقت بسبب وجود آلية فشل واحدة أو أكثر (على سبيل المثال، بسبب خطأ بشري أو عوامل ميكانيكية وكهربائية وكيميائية). يمكن أيضًا أن تتأثر مشكلات الوثوقية هذه بمستويات مقبولة من التباين أثناء الإنتاج الأولي.

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

وعلى النقيض من حلول Six Sigma، يتم العثور على حلول هندسية موثوقة بشكل عام من خلال التركيز على تصميم (نظام) وليس على عملية التصنيع. توجد الحلول بطرق مختلفة، مثل تبسيط نظام يسمح بفهم المزيد من آليات الفشل. إجراء حسابات مفصلة لمستويات الإجهاد المادية مما يسمح بتحديد عوامل السلامة المناسبة ؛ العثور على ظروف تحميل النظام غير طبيعية ممكنة واستخدام ذلك لزيادة متانة التصميم لتصنيع آليات الإخفاق ذات الصلة بالفرق. علاوة على ذلك، تستخدم هندسة الاعتمادية حلول على مستوى النظام، مثل تصميم أنظمة متكررة ومقاومة للخطأ في المواقف ذات احتياجات التوفر العالية (انظر هندسة الوثوقية مقابل هندسة السلامة أعلاه).

Six Sigma هي أيضا أكثر كميا (على أساس القياس). تم بناء جوهر Six-Sigma على الأبحاث التجريبية والتحليل الإحصائي (على سبيل المثال لإيجاد وظائف النقل) من المعلمات القابلة للقياس مباشرة. هذا لا يمكن ترجمته عمليًا لمعظم مشكلات الوثوقية، حيث لا يمكن الوثوقية (الموثوقة) نظرًا لكونها دالة للوقت (قد تكون أوقات العمل كبيرة)، خاصةً أثناء متطلبات المواصفات وعبارات التصميم، حيث تكون هندسة الوثوقية الأكثر كفاءة. إن التحديد الكامل للاعتمادية في هذه المرحلة بالغ الصعوبة أو التكلفة (بسبب كمية الاختبار المطلوبة). كما أنه قد يعزز إدارة إعادة النشاط (في انتظار إخفاق فشل النظام قبل اتخاذ القرار). علاوة على ذلك، كما هو موضح في هذه الصفحة، من المرجح أن تأتي مشكلات الوثوقية من عدة أسباب مختلفة (على سبيل المثال، الفشل المتأصل، الخطأ البشري، الفشل النظامي) بما في ذلك العيوب الناجمة عن التصنيع.

ملاحظة: «العيب» في المؤلفات الستة سيغما / الجودة ليس هو نفسه مثل «الفشل» (فشل المجال | الخ كسر العنصر) في الوثوقية. يشير عيب Six Sigma / جودة بشكل عام إلى عدم المطابقة مع المتطلب (مثل الوظيفة الأساسية أو البعد الرئيسي). ومع ذلك، يمكن أن تفشل العناصر بمرور الوقت، حتى لو تم الوفاء بهذه المتطلبات. لا تهتم الجودة عمومًا بطرح السؤال المهم «هل المتطلبات فعلية صحيحة؟»، في حين أن الوثوقية هي.

داخل الكيان، يجب على الإدارات ذات الصلة بالجودة (أي الاهتمام بالصناعة)، و Six Sigma (أي مراقبة العمليات ذات الصلة)، والوثوقية (تصميم المنتج) أن تقدم مدخلات لبعضها البعض لتغطية المخاطر الكاملة بشكل أكثر كفاءة.[12]

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

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

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

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

• هندسة التكهنات
• معدل الإخفاق
• التوافرية
• هندسة النظم
• أعطال منظومة القوى

• بوابة إحصاء
• بوابة إدارة أعمال
• بوابة تصميم
• بوابة تقانة
• بوابة صناعة
• بوابة هندسة