حالة الضمان: قضية سلامة مسببة



المصدر



ما هي أفضل طريقة لتقييم الأمن وعدم تفويت أي شيء؟ هل من الممكن جمع مجموعة متنوعة من عناصر الأمان في مستند واحد (أو رسم تخطيطي) وتنظيمها بطريقة يمكن تصور أي جانب بمستوى مفهومة من التفاصيل؟



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



المقدمة



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



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



خرائط الحجج وأصولها الفلسفية



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



ما الذي يمكن فعله لتبرير أو تقييم السلامة بطريقة منطقية ومعقولة؟ يعتمد هذا النهج على نظرية الجدل. تم إعطاء دفعة جديدة للتطور الحديث للجدل في عمل الفيلسوف البريطاني ستيفن تولمين بعنوان "استخدامات الحجة" ، الذي نُشر عام 1958. وسعت تولمين الاستدلال المنطقي الضمني بمعلمات إضافية واقترح تمثيل هذه العملية في شكل رسومي. يعمل تدوين تولمين مع الكيانات التالية: البيانات (D) - البيانات الأولية للتحليل ، المطالبة (C) - الهدف من التضمين المنطقي (إذا كان D So C) ، ضمان (W) - وسيطة إضافية ، مؤهل (Q) - درجة الثقة في نتائج المنطقي الاستدلال ، القابل للدحض (R) هو حجة مضادة إضافية (الشكل 1).





الشكل 1. تدوين من قبل ستيفن تولمين



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





الشكل 2. تم تطوير خريطة الحجة مع الخدمةعقلاني



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



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



تاريخ حالة الضمان ومفهومها



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



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



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



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



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



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



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



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



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





الشكل 3. واجهة برنامج Adelard ASCE



الآن دعونا نلقي نظرة على اثنين من الرموز الأساسية المستخدمة لتطوير حالة ضمان (CAE و GSN).



تدوين CAE (المطالبة والحجة والإثبات)



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



الشكل 4. ترميز المطالبة والحجة والأدلة (CAE): المكونات الرئيسية



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



GSN (تدوين بنية الهدف)



تعمل GSN بمكونات مثل الهدف (هدف ، يُشار إليه بمستطيل وهو نظير لمطالبة في CAE) ، واستراتيجية حجة (استراتيجية ، يُشار إليها بواسطة متوازي الأضلاع ، وهي تماثلية للحجة) ، وحل (يُشار إليه بدائرة ويماثل الدليل) (الشكل 5). يستخدم السياق للمعلومات لدعم الأهداف. يمكن استخدام الافتراضات والمبررات لدعم الحجة. هيكل الأهداف هرمي.





الشكل 5. ترميز هيكل الهدف (GSN): المكونات الرئيسية



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



لقد حدث أن GSN اليوم أكثر شيوعًا. تنسيق GSN ثابت في المعيارمعيار مجتمع تدوين بنية الهدف (GSN) ، بالإضافة إلى نموذج بيانات نموذج بيانات حالة الضمان المهيكل (SACM) من مجموعة إدارة الكائنات (OMG).



قاعدة المعرفة: الصناعات ، المعايير ، البحث ، الأدوات ، الرموز البديلة



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



بالنظر إلى متطلبات تطبيق حالة ضمان خارج المملكة المتحدة ، تجدر الإشارة إلى:

  • معيار السيارات ISO 26262: 2011 ، مركبات الطرق - السلامة الوظيفية ، جزء من عائلة معايير السلامة الوظيفية التي توضح متطلبات IEC 61508 ؛
  • European Organisation for the Safety of Air Navigation (EUROCONTROL): “Safety Case Development Manual, 2006”, “EAD (European Aeronautical Information System Database) Safety Case, 2009”, “EAD (European Aeronautical Information System Database) Safety Case Guidance, 2010”;
  • “Licensing of safety critical software for nuclear reactors – Common position of international nuclear regulators and authorised technical support organisations, 2018”, (, , , , , , , , );
  • معايير سلسلة ISO / IEC 15026 ، هندسة النظم والبرمجيات - ضمان الأنظمة والبرمجيات ، والتي تشمل أربعة أجزاء: الجزء 1: المفاهيم والمفردات (2019) ؛ الجزء الثاني: قضية ضمان (2011) ؛ الجزء 3: مستويات تكامل النظام (2015) ؛ الجزء الرابع: الضمان في دورة الحياة (2012).



وتجدر الإشارة أيضًا إلى عدد من المنظمات (إلى جانب Adelard المذكورة بالفعل ومجموعة هندسة النظم عالية النزاهة من جامعة يورك) التي تعمل بنشاط في مجال قضايا الضمان. وتشمل هذه:

  • US-CERT (فريق الاستعداد للطوارئ الحاسوبية بالولايات المتحدة) ، يسمون حالات ضمان أمن المنهجية الخاصة بهم ؛
  • SEI/CMU (Sofrware Engineering Institute – Carnegie Mellon University), , CERT Division, SEI, Assurance Case US-CERT;
  • NASA (National Aeronautics and Space Administration) Scientific and Technical Information (STI) Assurance Case ;
  • , , John Rushby, SRI International ( Stanford Research Institute), , “The Interpretation and Evaluation of Assurance Cases”, .


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



تتضمن الأساليب البديلة لتطوير حالة الضمان الأداة البرمجية NOR-STA... سيتم تطويره من قبل الشركة البولندية Argevide (التابعة لجامعة غدانسك للتكنولوجيا). تدعم NOR-STA تدوين TRUST-IT الخاص بها. الفرق هو أنه بدلاً من التمثيل الرسومي ، تستخدم NOR-STA قائمة هرمية منظمة (الشكل 6).







الشكل 6. ترميز Trust-IT: المكونات الأساسية



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



بالإضافة إلى ذلك ، يتم استخدام حالة الضمان لحل التطبيقات التالية:

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


حالة ضمان لأمن المعلومات



تُعرف الحالة الأمنية (الجدارة بالثقة) بأنها أحد أنواع حالة الضمان. إذا لزم الأمر ، يمكن استكمال حقيبة الأمان بمكونات علبة الأمان. في الواقع ، الفكرة وراء حالة الضمان هي الجمع بين سمات السلامة والأمن. في مجال الاعتماد ، هناك تطورات لمعيار ISO / IEC 15408 (المعايير العامة) ، والتي تم تحويل المتطلبات الخاصة بها إلى هيكل متوافق مع هيكل حالة الضمان. يمكن إجراء هذا التحويل للمعايير الأخرى ذات الصلة ، مثل ISO 27000 أو IEC 62443 أو أي إطار عمل آخر.



مثال على ذلك هو مقتطف حالات ضمان الأمنالمنشورة على موقع US-CERT. يراجع هذا المقتطف دليل تنفيذ دورة حياة تطوير البرامج (SDLC). ينصب التركيز على القضاء على عيوب الترميز (على وجه الخصوص ، Buffer Overflow) ، والتي يتم فيها استخدام طرق مثل مبرمجي التدريب ، ومراجعات الكود ، والتحليل الثابت والاختبار. يمكن للمرء ، بالطبع ، أن يجادل في اكتمال هذه القطعة ، لكنها مقدمة فقط كتوضيح (الشكل 7).





الشكل 7. تجزئة حالات ضمان الأمن



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



حالة ضمان دراسة الحالة



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



الحجج المنظمة



لنتخيل عملية تطوير الحجج في خطوتين متتاليتين (الشكل 8). الخطوة الأولى ، التي تسمى خطوة الاستدلال (RS) ، هي تحليل الأهداف الفرعية (SC) ، والتي تهدف إلى تحقيق الهدف الرئيسي (C). في هذه الخطوة ، يتطور هيكل الجدل. في الخطوة الثانية ، التي تسمى الخطوة الإثباتية (ES) ، تتم صياغة التأكيدات (Evidece، E) لدعم الأهداف الفرعية (SC) التي تم إنشاؤها في الخطوة السابقة. لإضفاء الطابع الرسمي على خطوات RS و ES ، يتم استخدام قوالب النص المهيكل النموذجية (ST).





الشكل 8. خطوات ومكونات الحجج المنظمة



التسلسل الهرمي للمتطلبات



تخيل تسلسلاً هرميًا أو هرمًا للمتطلبات يشكل هيكلًا يتوافق مع عمود حالة الضمان. تحتوي معظم المتطلبات التنظيمية لأنظمة أو برامج الكمبيوتر على 3 أو 4 مستويات من هيكل المتطلبات (الشكل 9).





الشكل 9. التسلسل الهرمي للمتطلبات وعلاقته بخطوات الجدل



المستوى صفر هو هدف فوقي ، وبموجبه يجب أن يفي النظام قيد التقييم بجميع متطلبات الأمان. في المستوى الأول ، تتحقق أهداف السلامة العالمية ، على سبيل المثال ، تتبع الأهداف التالية من متطلبات IEC 61508 للسلامة الوظيفية:

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


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



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



حالة الضمان لمجموعة من متطلبات الموارد البشرية (IEC 61508)



كتوضيح ، ضع في اعتبارك مقتطف حالة الضمان فيما يتعلق بمتطلبات IEC 61508 HR ( IEC 61508-1 الفقرة 6 ).



نص منظم يصف ويجمع خطوات التفكير (RS) لجميع المتطلبات ذات الصلة
Reasoning Step (Human Resource Management)

Context

Connection between the group of Human Resource Management requirements of the Assurance Case Level 2 and composite and separate requirements of Level 3

Docs

Human Resource Management Plan

Claim

Human Resource Management complies with IEC 61508 requirements

Subclaim SC1 (IEC 61508-1, 6.2.1), SEPARATE

Persons responsible for specific activities shall be appointed

Subclaim SC2 (IEC 61508-1, 6.2.3), SEPARATE

Project participants shall understand their roles and responsibilities

Subclaim SC3 (IEC 61508-1, 6.2.4), SEPARATE

Communications of the project participants shall be defined

Subclaim SC4 (IEC 61508-1, 6.2.13), SEPARATE

Evaluation and assurance of the project participants’ competencies shall be performed

Subclaim SC5 (IEC 61508-1, 6.2.14a,…,k), COMPOSITE

Competencies shall be considered in relation to the particular application, taking into account all relevant factors

Subclaim SC6 (IEC 61508-1, 6.2.15), SEPARATE

Competencies of all responsible persons shall be documented

Subclaim SC7 (IEC 61508-1, 6.2.16), SEPARATE

Human resource management activities shall be implemented and monitored

Justification

Structure and content of the Human Resource Management Plan

END Reasoning Step



تم استخراج ما مجموعه سبعة متطلبات إدارة شؤون الموظفين من IEC 61508. من وجهة نظر الجدل المنظم ، هذه المتطلبات هي أهداف فرعية (SC1 ، ... ، SC7). واحد فقط من الأهداف الفرعية (SC5) مركب ، وكل الأهداف الأخرى ذرية. من أجل الانتقال من هدف فرعي مركب (SC5) إلى هدف ذري (SC5.1، ...، SC5.11) ، يتم تنفيذ خطوة أخرى من التفكير (RS). من المفهوم أنه وفقًا لمتطلبات IEC 61508 ، تم تطوير خطة إدارة الموارد البشرية لمشروع يتعلق بإنشاء منتج مجرد. تفسر هذه الخطة متطلبات المعيار في سياق المشروع.



نص منظم لخطوات التأكيد (ES)
Evidential Step ES1,…,ES6

Context

Connection with the subclaims of the Levels 3 and the Level 4

Docs

Human Resource Management Plan; Communications Plan; Training Plans; Training Reports

Claim

SC1,…, SC7

Evidence E1

Organizational Chart

Evidence E2

Project Roles Description

Evidence E3

Participants and Signature List

Evidence E4

Participants Communications Plan

Evidence E5

Competency Matrix

Evidence E6

Training Plans and Reports

Claim -> Evidence

SC1 -> E1&E2; SC2 -> E3; SC3 -> E4; SC4 -> E5&E6; SC5 -> E5&E6; SC6 -> E5&E6; SC7 -> E1&E2

Justification

Structure and content of E1,…,E6

END Evidential Step



بالنسبة لجميع خطوات التأكيد (ES) ، يُقترح استخدام نص منظم مشترك يشير إلى الروابط بين الأهداف الفرعية (SG) للتأكيدات (E). سنستخدم العلاقة SG -> E للإشارة إلى العلاقة بين الهدف الفرعي المقابل (SG) والتأكيدات (E) التي تدعمه.



SC5 تحليل المتطلبات المركبة
S5 . , (ES). , (RS) (ES). .







«» (RS), , , (ES).



يمكن تحويل جميع العلاقات التي تم الحصول عليها SG -> E إلى عمود حالة ضمان ، وفقًا لتدوين GSN ، المعدل للمناقشة المنظمة (الشكل 10). يعكس هذا الرسم البياني المجموعة الكاملة من المتطلبات المتعلقة بإدارة شؤون الموظفين وفقًا للمعيار IEC 61508. يمكن أيضًا استخدام هذا الرسم البياني كنموذج لتقييم الامتثال لمتطلبات IEC 61508.





الشكل 10. رسم بياني لحالة الضمان مستمد من الحجج المنظمة لمجموعة من متطلبات الموارد البشرية (IEC 61508)



للوهلة الأولى ، كل هذا طويل وصعب ، ولكن مع ذلك ، فإن حالة الضمان لها تطبيقاتها العملية. هذا هو النهج الذي استخدمناه عند التصديق على RdICS PLC للامتثال مع IEC 61508 .



خاتمة



تم استخدام طريقة حالة الضمان (حالة السلامة) لأكثر من 20 عامًا لتحليل سلامة مرافق معهد التأمين القانوني. تُستخدم هذه الطريقة على نطاق واسع في المملكة المتحدة وعدد من دول الكومنولث البريطانية في صناعات مثل الرعاية الصحية والطيران والطاقة النووية والسيارات والدفاع والبتروكيماويات وصناعات السكك الحديدية.



تشمل مزايا حالة الضمان جميع المزايا التي يتم تحقيقها من خلال تصور العلاقات في مجال موضوع معقد ، من خلال تحسين إدراكنا وفهمنا. تعود العيوب إلى ذاتية الطريقة من حيث اعتمادها على خبرة الأشخاص الذين يقومون بالتقييم. يتم هنا وصف أشهر "فشل ملحمي" في تطبيق Assurance Case... باختصار: في 2 سبتمبر 2006 ، اندلع حريق في أفغانستان على متن طائرة تابعة لسلاح الجو البريطاني نمرود. نشأت المشكلة من تسرب الوقود. قُتل كل من كانوا على متنها وعددهم 14 شخصًا. وأكد تقرير سابق لـ Safety Case سلامة الطائرة. أظهر التحقيق أن تعديل نظام الوقود لم يكن صحيحًا تمامًا على طائرات الإنتاج ، وظهرت مشكلات مماثلة من قبل ، لكن لسبب ما لم ينتبه إليها أحد على أنه خطأ في النظام. وفي تقرير مؤلف من 600 صفحة صدر ، لم يُطلق على هذه الحادثة سوى لقب "فشل القيادة والثقافة والأولويات".



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



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

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



All Articles