💻 computer science

JTA: Joint Testability Architecture for Scenario-Based Validation of Safety-Critical Software

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

المؤلفون الأصليون: Wenyao Xue, Jiandi Wang, Yichen Wang

نُشر 2026-08-07

📖 5 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: Wenyao Xue, Jiandi Wang, Yichen Wang

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

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

في عالم البرمجيات الحساسة للسلامة — مثل العقول التي تدير الطائرات، والقطارات، والمركبات ذاتية القيادة — غالباً ما يخرج هذا الفريق عن التزامن. قد تكون السيارة جاهزة، لكن المختبرين لا يستطيعون إنشاء العاصفة المطرية المطلوبة بدقة. أو قد يتمكن المختبرون من إنشاء العاصفة، لكن السيارة لا "تتحدث" بوضوح كافٍ لتخبرهم لماذا توقفت. هذه الورقة البحثية، التي كتبها باحثون من جامعة بهيانغ (Beihang University)، تعالج سؤالاً كبيراً: كيف نتأكد من أن السيارة، والمختبرين، وسيناريوهات الاختبار جميعهم على نفس الصفحة؟ لقد قدموا طريقة جديدة للتفكير تسمى بنية الاختبار المشترك (Joint Testability Architecture - JTA). فبدلاً من النظر إلى كود البرمجيات بمعزل عن غيره، تعامل JTA مع هذا الثلاثي كمنظومة واحدة متصلة. وهي تطرح ثلاثة أسئلة بسيطة ولكنها قوية لكل اختبار: هل يمكننا التحكم في الموقف؟ هل يمكننا رؤية ما يحدث؟ وإذا حدث خطأ ما، هل يمكننا تحديد المسؤول بدقة؟

المشكلة: سلسلة ثقة مكسورة

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

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

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

الحل: "الجسور الثلاثة"

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

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

السلاح السري: "عقد السيناريو"

تقدم الورقة أداة ذكية تسمى عقد السيناريو (Scenario Contract). فكر في هذا كقائمة مراجعة صارمة أو كتاب قواعد لكل اختبار على حدة. قبل أن تبدأ في إجراء أي اختبار، تكتب بالضبط ما تحتاجه:

ماذا نختبر؟ (الهدف)
كيف نفعّل ذلك؟ (التحكم)
ما هو الدليل الذي نحتاج لرؤيته؟ (الأدلة)
من المسؤول في حال الفشل؟ (الإسناد)

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

دراسة الحالة: طائرة ArduPilot بدون طيار

للتأكد من نجاح هذه الفكرة، اختبر المؤلفون هذا النهج على ArduPilot، وهو نظام تحكم طيران مفتوح المصدر مشهور يُستخدم في الطائرات بدون طيار والروبوتات. لقد نظروا في ثلاثة سيناريوهات "كارثية" محددة:

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

ما وجدوه:

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

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

الخلاصة

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

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

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

ملخص تقني: بنية اختبار القدرة المشتركة (JTA) للبرمجيات الحرجة من حيث السلامة

1. بيان المشكلة

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

2. المنهجية: بنية اختبار القدرة المشتركة (JTA)

تعيد JTA صياغة قابلية الاختبار كقدرة مشروطة بالسيناريو لنظام مشترك. وهي تقترح بنية رسمية وسير عمل للتحليل يتكون من خمس خطوات لتحديد وفجوات القدرة وسدها.

2.1 النموذج الرسمي

تُعرف البنية كـ $JTA = \langle D_\Sigma, D_T, D_S, BC, BO, BI, L \rangle$ ، وتتكون من:

ثلاثة مجالات:
- مجال السيناريو ( $D_\Sigma$ ): ينظم أهداف التحقق، والقيود، والدرجة الحرجة.
- مجال نظام الاختبار ( $D_T$ ): يشمل قدرات التحفيز، وجمع الأدلة، وتوليد الأحكام.
- مجال النظام تحت الاختبار ( $D_S$ ): يتضمن السلوك الوظيفي ونقاط التحقق المكشوفة (نقاط التحكم، نقاط الأدلة، وحدود المسؤولية).
ثلاثة جسور: أنماط معمارية تربط المجالات ببعضها لحل عدم التوافق في القدرات:
- جسر التحكم ( $BC$ ): يترجم الشروط المسبقة للسيناريو إلى إعدادات بارامترية قابلة لإعادة الإنتاج وحقن للأخطاء.
- جسر الأدلة ( $BO$ ): ينظم السجلات والحالات الخام إلى أدلة مهيكلة ومتوافقة زمنيًا لإصدار أحكام مؤتمتة.
- جسر العزو ( $BI$ ): يربط النتما غير الطبيعية بمصادر المحفزات المحددة وحدود المسؤولية لتمكين المعالجة.
الحلقة المغلقة ( $L$ ): عملية تكرارية من التحليل، والتصميم، والتقييم، والتحسين.

2.2 المفاهيم الجوهرية

نظام اختبار القدرة المشتركة ( $JTS_\sigma$ ): وحدة التحليل ليست البرمجيات وحدها، بل الثلاثي $\langle \sigma, T_\sigma, S_\sigma \rangle$ الذي يمثل سيناريو محدد، وقدرات الاختبار المشاركة، وحدود النظام تحت الاختبار ذات الصلة.
عقود السيناريو ( $SC(\sigma)$ ): مواصفات مكونة من ثماني عناصر $\langle g, p, u, e, o, r, \kappa, \Theta \rangle$ تحدد صراحةً هدف التحقق، والشروط المسبقة، ونمط التحفيز، والحد الأدنى من الأدلة، وقواعد الحكم، ومجموعة من مصادر الخطأ القابلة للتمييز ( $r$ )، والدرجة الحرجة، والحدود الدنيا للقدرة على التحكم، والقدرة على الملاحظة، والقدرة على العزل.
تقييم القدرة المشتركة:
- القدرة على التحكم ( $C$ )، والقدرة على الملاحظة ( $O$ )، والقدرة على العزل ( $I$ ): تُقاس لكل من النظام تحت الاختبار ( $CS, OS, IS$ ) ونظام الاختبار ( $CT, OT, IT$ ).
- **القدرة المشتركة ($JTCap $):** تُعرف بأنها الحد الأدنى من قدرات النظام تحت الاختبار ونظام الاختبار لكل بُعد (على سبيل المثال،$ JC = \min(CS, CT)$)، مما يعكس مبدأ "أضعف حلقة".
- الكفاية ($Adeq$): يكون السيناريو ملائمًا فقط إذا استوفت جميع الأبعاد المشتركة الثلاثة الحدود الدنيا المحددة في العقد.
- النقاط العمياء: السيناريوهات التي تكون فيها $Adeq(\sigma) = 0$ .

2.3 سير العمل المكون من خمس خطوات

تحديد السيناريوهات الحرجة: تحديد المجموعة $\Sigma$ وتعيين أوزان الدرجة الحرجة.
إنشاء عقود السيناريو: تعريف الأهداف، ومتطلبات الأدلة، ومجموعة مصادر الخطأ المراد تمييزها بشكل صريح.
تقييم القدرات الثنائية: تقييم $Cap_S$ و $Cap_T$ مقابل متطلبات العقد.
حساب الفجوات وتحديد النقاط العمياء: حساب متجه فجوة القدرة $Gap(\sigma)$ وتحديد السيناريوهات التي تفشل في تحقيق الكفاية.
تصميم الجسور وإعادة التقييم: ربط الفجوات بإجراءات تصميمية محددة على جسور التحكم، أو الأدلة، أو العزو، ثم إعادة التقييم.

3. المساهمات الرئيسية

نموذج نظام اختبار القدرة المشتركة ( $JTS_\sigma$ ): يوسع موضوع التحقق من منتج معزول إلى كيان مشترك مُنشأ بالسيناريو يضم السيناريو، ونظام الاختبار، والنظام تحت الاختبار.
عقود السيناريو مع مجموعات مصادر الخطأ: يقدم عقدًا رسميًا يتضمن مجموعة من مصادر الخطأ القابلة للتمييز ( $r$ )، مما يحول العزل من مفهوم عام إلى قيد تصميمي ملموس لعملية العزو.
منهج التصميم الموجه نحو الجسور: يقترح إطار عمل "ثلاثة مجالات، ثلاثة جسور، وحلقة مغلقة" يربط فجوات القدرة مباشرة بإجراءات تصميم معمارية قابلة للتنفيذ (مثل إضافة متحكم توقيت إلى جسر التحكم أو توسيعات أكواد الأسباب إلى جسر العزو).
التحليل التوضيحي لـ ArduPilot: يوضح تطبيق JTA على التحقق من آليات الأمان (failsafe) في ArduPilot، وتحديد نقاط عمياء محددة في سيناريوهات فقدان الاتصال واضطرابات تقدير الحالة.

4. النتائج: دراسة حالة ArduPilot

طبق المؤلفون JTA على ثلاثة سيناريوهات للأمان في مشروع ArduPilot مفتوح المصدر: فقدان اتصال جهاز التحكم عن بعد (S1)، وانقطاع نبضات القلب من المحطة الأرضية (S2)، واضطرابات تقدير الحالة في EKF (S3).

S1 (فقدان اتصال RC): صُنفت على أنها ملائمة (1). يدعم نظام الاختبار والنظام تحت الاختبار السيناريو بشكل مشترك، رغم وجود بعض الاختناقات في هيكلة الأدلة.
S2 (انقطاع نبضات القلب من GCS): صُنفت على أنها غير ملائمة (0). بينما يمكن تحفيز السيناريو، فإن جسر العزو ضعيف؛ إذ لا تستطيع السجلات الحالية التمييز بين الانقطاعات الحقيقية وأخطاء أدوات الاختبار.
S3 (اضطرابات EKF): صُنفت على أنها غير ملائمة (0). يكشف هذا السيناريو عن اختناقات في كل من القدرة على التحكم (صعوبة فصل قوة الاضطراب والتوقيت) والقدرة على العزل (الغموض في التمييز بين فشل صحة EKF وتدهور نظام GPS المتزامن).

المقياس على مستوى النظام: تم حساب التغطية الملائمة المرجحة بالدرجة الحرجة ( $JT(JTS)$ ) للسيناريوهات التي تم تحليلها عند 28.6%، مما يسلط الضوء على أن السيناريوهات عالية الخطورة (مثل اضطرابات EKF) تظل نقاطًا عمياء كبيرة في التحقق رغم وجود بنية تحتية ناضجة للسيناريوهات الأبسط.

توصيات التصميم: أسفر التحليل عن إجراءات محددة على مستوى الجسور، مثل:

إضافة "عرض عزو ثلاثي" (حدث انقطاع – كود السبب – حالة الاتصال) لـ S2.
تنفيذ قوالب اضطراب معلمية (parameterized) ومهايئات إعادة تشغيل تدعم الحقن لتحسين القدرة على التحكم في S3.

5. الأهمية والادعاءات

يزعم البحث أن JTA توفر أساسًا معماريًا لنمذجة وتصميم وتقييم التحقق القائم على السيناريو، بدلاً من استبدال تقنيات الاختبار أو تحليل السلامة الموجودة.

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

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