التحقق التلقائي من متطلبات TOR في عملية المحاكاة الديناميكية

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

كيف يمكننا أن نتأكد سريعًا من أن نظامنا هو بالضبط ما نصممه، وهل تصميمنا سيطير أم يطفو؟ وإذا طار فكم يبلغ ارتفاعه؟ وإذا طفت، فما هو عمقها؟

التحقق التلقائي من متطلبات TOR في عملية المحاكاة الديناميكية

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

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

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

على سبيل المثال، خذ بعين الاعتبار مجموعة المتطلبات الصغيرة ولكن الواقعية:

  1. درجة حرارة الهواء الجوي عند مدخل نظام معالجة المياه:
    في موقف السيارات - من -35 إلى 35 درجة مئوية،
    أثناء الطيران - من 35 إلى 39 درجة مئوية تحت الصفر.
  2. يتراوح الضغط الثابت للهواء الجوي أثناء الطيران من 700 إلى 1013 جيجا باسكال (من 526 إلى 760 ملم زئبق).
  3. يتراوح إجمالي ضغط الهواء عند مدخل مدخل هواء SVO أثناء الطيران من 754 إلى 1200 جيجا باسكال (من 566 إلى 1050 ملم زئبق).
  4. درجة حرارة هواء التبريد:
    في موقف السيارات - لا تزيد عن 27 درجة مئوية، للكتل الفنية - لا تزيد عن 29 درجة مئوية،
    أثناء الطيران - لا تزيد عن 25 درجة مئوية، للكتل الفنية - لا تزيد عن 27 درجة مئوية.
  5. تدفق هواء التبريد:
    عند الوقوف - 708 كجم/ساعة على الأقل،
    أثناء الطيران - لا يقل عن 660 كجم/ساعة.
  6. لا تزيد درجة حرارة الهواء في حجرات الأجهزة عن 60 درجة مئوية.
  7. لا تزيد كمية الرطوبة الحرة الدقيقة في هواء التبريد عن 2 جم/كجم من الهواء الجاف.

حتى ضمن هذه المجموعة المحدودة من المتطلبات، هناك فئتان على الأقل يجب التعامل معهما بشكل مختلف في النظام:

  • متطلبات ظروف تشغيل النظام (البنود 1-3)؛
  • المتطلبات البارامترية للنظام (البنود 3-7).

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

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

تحديد المتطلبات والترميز

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

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

يقدم الجدول 1 مثالاً بسيطًا لترميز المتطلبات.

  1. رمز مصدر المتطلبات R-متطلبات TK؛
  2. نوع كود المتطلبات E - المتطلبات - المعلمات البيئية، أو ظروف التشغيل
    S - المتطلبات التي يوفرها النظام؛
  3. رمز حالة الطائرة 0 – أي، G – متوقفة، F – أثناء الطيران؛
  4. رمز نوع المعلمة الفيزيائية T - درجة الحرارة، P - الضغط، G - معدل التدفق، الرطوبة H؛
  5. الرقم التسلسلي للمتطلبات.

ID
متطلبات
وصف المعلمة
REGT01 درجة حرارة الهواء المحيط عند مدخل نظام تبريد المياه: في ساحة انتظار السيارات - من 35 درجة مئوية تحت الصفر. ما يصل إلى 35 درجة مئوية.
REFT01 درجة حرارة الهواء الجوي عند مدخل نظام الدفاع الجوي: أثناء الطيران - من 35 درجة مئوية تحت الصفر إلى 39 درجة مئوية.
REFP01 يتراوح ضغط الهواء الجوي الثابت أثناء الطيران من 700 إلى 1013 هبأ (من 526 إلى 760 ملم زئبق).
REFP02 يتراوح إجمالي ضغط الهواء عند مدخل مدخل هواء SVO أثناء الطيران من 754 إلى 1200 hPa (من 566 إلى 1050 ملم زئبق).
RSGT01 درجة حرارة هواء التبريد: عند الوقوف لا تزيد عن 27 درجة مئوية
RSGT02 درجة حرارة هواء التبريد: في موقف السيارات للوحدات الفنية لا تزيد عن 29 درجة مئوية
RSFT01 درجة حرارة هواء التبريد أثناء الطيران لا تزيد عن 25 درجة مئوية
RSFT02 درجة حرارة هواء التبريد: أثناء الطيران، للوحدات الفنية لا تزيد عن 27 درجة مئوية
RSGG01 تدفق هواء التبريد: عند الوقوف لا يقل عن 708 كجم/ساعة
RSFG01 تدفق هواء التبريد: أثناء الطيران لا يقل عن 660 كجم/ساعة
RS0T01 درجة حرارة الهواء في حجرات الأجهزة لا تزيد عن 60 درجة مئوية
RSH01 لا تزيد كمية الرطوبة الحرة الدقيقة في هواء التبريد عن 2 جم/كجم من الهواء الجاف

تصميم نظام التحقق من المتطلبات.

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

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

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

يظهر مثال محتمل لتصميم النظام في الشكل 1.

التحقق التلقائي من متطلبات TOR في عملية المحاكاة الديناميكية
الشكل 1. مثال لتصميم مشروع التحقق.

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

التحقق التلقائي من متطلبات TOR في عملية المحاكاة الديناميكية
الشكل 2. الهيكل الهرمي لنموذج التحقق من المتطلبات.

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

لربط البيانات بالنموذج، يتم استخدام مخطط قياسي لإنشاء قاعدة بيانات الإشارة، والتي تقوم بتخزين البيانات للتبادل بين أجزاء المشروع.

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

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

التحقق التلقائي من متطلبات TOR في عملية المحاكاة الديناميكية
الشكل 3. ربط مشروع التحقق بالنموذج المعقد.

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

التحقق التلقائي من متطلبات TOR في عملية المحاكاة الديناميكية
الشكل 4. ورقة فحص المتطلبات.

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

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

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

التحقق التلقائي من متطلبات TOR في عملية المحاكاة الديناميكية
الشكل 5. هيكل ورقة حساب التحقق من المتطلبات.

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

على سبيل المثال هذا الشرط:

يجب ألا يتجاوز عدد مرات تفعيل نظام التصحيح أثناء الرحلة إلى الهدف 5 مرات، ويجب ألا يتجاوز إجمالي وقت التشغيل لنظام التصحيح 30 ثانية.

في هذه الحالة، تتم إضافة خوارزمية لمواجهة عدد مرات البدء وإجمالي وقت التشغيل إلى مخطط تصميم المتطلبات.

كتلة التحقق من المتطلبات النموذجية.

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

تحتوي الكتلة على منفذي إدخال، المعلمة والحالة.

يتم تغذية الأول مع المعلمة التي يتم فحصها. في هذه الحالة، "درجة الحرارة الخارجية".

يتم توفير متغير منطقي للمنفذ الثاني - وهو شرط إجراء الفحص.

إذا تم استلام TRUE (1) عند الإدخال الثاني، فستقوم الكتلة بإجراء حساب التحقق من المتطلبات.

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

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

معلمات هذه الكتلة هي:

  • شروط الحدود: حدود النطاق العليا (UpLimit) والسفلى (DownLimit) التي يجب التحقق منها؛
  • وقت تعرض النظام المطلوب عند النطاقات الحدودية (TimeInterval) بالثواني؛
  • معرف الطلب ReqName؛
  • جواز تجاوز النطاق Out_range هو متغير منطقي يحدد ما إذا كانت القيمة التي تتجاوز النطاق المحدد تمثل انتهاكًا للمتطلبات.

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

التحقق التلقائي من متطلبات TOR في عملية المحاكاة الديناميكية
الشكل 6. كتلة فحص الخصائص النموذجية في الرسم التخطيطي ومعلماتها.

ونتيجة لحساب هذه الكتلة يتم تكوين متغير النتيجة عند المخرجات والذي يأخذ القيم التالية:

  • 0 - rNone، القيمة غير محددة؛
  • 1- تم استيفاء المطلب؛
  • 2- خطأ، لم يتم استيفاء الشرط.

تحتوي صورة الكتلة على:

  • نص المعرف؛
  • شاشات عرض رقمية لمعلمات حدود القياس؛
  • معرف اللون لحالة المعلمة.

قد تكون هناك دائرة استدلال منطقية معقدة إلى حد ما داخل الكتلة.

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

التحقق التلقائي من متطلبات TOR في عملية المحاكاة الديناميكية
الشكل 7. رسم تخطيطي داخلي لوحدة تحديد نطاق درجة الحرارة.

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

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

مثال على تقرير تم إنشاؤه بناءً على نتائج المحاكاة هو ملف html تم إنشاؤه وفقًا لتنسيق معين. يمكن تكوين التنسيق بشكل تعسفي للتنسيق المقبول من قبل مؤسسة معينة.

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

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

مثال على تقرير تم إنشاؤه بناءً على نتائج المحاكاة هو ملف html تم إنشاؤه وفقًا لتنسيق معين. يمكن تكوين التنسيق بشكل تعسفي للتنسيق المقبول من قبل مؤسسة معينة.

التحقق التلقائي من متطلبات TOR في عملية المحاكاة الديناميكية
الشكل 8. مثال لملف تقرير يعتمد على نتائج المحاكاة.

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

التحقق التلقائي من متطلبات TOR في عملية المحاكاة الديناميكية
الشكل 9. تحديد تنسيق التقرير في إشارات المشروع العالمية

استخدام قاعدة بيانات الإشارة للمتطلبات.

لأتمتة العمل مع إعدادات الخاصية، يتم إنشاء بنية قياسية في قاعدة بيانات الإشارة لكل كتلة نموذجية. (انظر الشكل 10)

التحقق التلقائي من متطلبات TOR في عملية المحاكاة الديناميكية
الشكل 10. مثال على هيكل كتلة فحص المتطلبات في قاعدة بيانات الإشارة.

توفر قاعدة بيانات Signal:

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

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

التحقق التلقائي من متطلبات TOR في عملية المحاكاة الديناميكية
الشكل 11. رسم تخطيطي للتفاعل مع نظام إدارة المتطلبات.

تسلسل التفاعل بين مشروع اختبار SimInTech ونظام التحكم في المتطلبات هو كما يلي:

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

يمكن تكرار خطوات المتطلبات من 3 إلى 5 أثناء عملية التصميم عند حدوث تغييرات في التصميم و/أو المتطلبات ويجب إعادة اختبار تأثير التغييرات.

الاستنتاجات.

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

لمن قرأ حتى النهاية رابط لمقطع فيديو يوضح كيفية عمل النموذج الأولي.

المصدر: www.habr.com

إضافة تعليق