אימות אוטומטי של דרישות TOR בתהליך של סימולציה דינמית

המשך הנושא "מה ההוכחה שלך?", בואו נסתכל על הבעיה של מודלים מתמטיים מהצד השני. לאחר שאנו משוכנעים שהמודל תואם את האמת הביתית של החיים, נוכל לענות על השאלה העיקרית: "מה בדיוק יש לנו כאן?" כשיוצרים דגם של אובייקט טכני, אנחנו בדרך כלל רוצים לוודא שאובייקט זה יענה על הציפיות שלנו. לשם כך מתבצעים חישובים דינמיים של תהליכים והתוצאה מושווה לדרישות. מדובר בתאום דיגיטלי, אב טיפוס וירטואלי וכו'. בחורים קטנים אופנתיים שבשלב העיצוב פותרים את הבעיה איך לוודא שנקבל את מה שתכננו.

איך נוכל לוודא במהירות שהמערכת שלנו היא בדיוק מה שאנחנו מעצבים, האם העיצוב שלנו יעוף או יצוף? ואם הוא עף, כמה גבוה? ואם הוא צף, כמה עמוק?

מאמר זה דן באוטומציה של אימות עמידה בדרישות של בניין טכני בעת יצירת מודלים דינמיים של מערכות טכניות. כדוגמה, בואו נסתכל על אלמנט של המפרט הטכני עבור מערכת קירור אוויר למטוס.

אנו רואים את הדרישות הניתנות לביטוי מספרי ולאימות מתמטית בהתבסס על מודל חישוב ספציפי. ברור שזה רק חלק מהדרישות הכלליות לכל מערכת טכנית, אבל בבדיקתן אנחנו מבזבזים זמן, עצבים וכסף על יצירת מודלים דינמיים של האובייקט.

כאשר מתארים דרישות טכניות בצורה של מסמך, ניתן להבחין במספר סוגים של דרישות שונות, שכל אחת מהן דורשת גישות שונות להיווצרות אימות אוטומטי של מילוי הדרישות.

לדוגמה, שקול את מערכת הדרישות הקטנה אך המציאותית הזו:

1. טמפרטורת אוויר אטמוספרי בכניסה למערכת טיפול במים:
   במגרש החניה - ממינוס 35 עד 35 מעלות צלזיוס,
   בטיסה - ממינוס 35 עד 39 ºС.
2. הלחץ הסטטי של אוויר אטמוספרי בטיסה הוא בין 700 ל-1013 GPa (מ-526 ל-760 מ"מ כספית).
3. לחץ האוויר הכולל בכניסה לכניסת האוויר של SVO בטיסה הוא מ-754 עד 1200 GPa (מ-566 עד 1050 מ"מ כספית).
4. טמפרטורת אוויר קירור:
   בחניון - לא יותר מ-27 ºС, עבור בלוקים טכניים - לא יותר מ-29 ºС,
   בטיסה - לא יותר מ-25 ºС, עבור בלוקים טכניים - לא יותר מ-27 ºС.
5. זרימת אוויר לקירור:
   בחנייה - לפחות 708 ק"ג לשעה,
   בטיסה - לא פחות מ-660 ק"ג לשעה.
6. טמפרטורת האוויר בתאי המכשיר אינה עולה על 60 מעלות צלזיוס.
7. כמות הלחות החופשית העדינה באוויר הקירור היא לא יותר מ-2 גרם/ק"ג אוויר יבש.

אפילו בתוך מערכת הדרישות המצומצמת הזו, יש לפחות שתי קטגוריות שצריך לטפל בהן אחרת במערכת:

• דרישות לתנאי ההפעלה של המערכת (סעיפים 1-3);
• דרישות פרמטריות למערכת (סעיפים 3-7).

דרישות תנאי ההפעלה של המערכת
ניתן לציין תנאים חיצוניים למערכת המפותחת במהלך המידול כתנאי גבול או כתוצאה מהפעלת המערכת הכללית.
בסימולציה דינמית, יש צורך לוודא שתנאי ההפעלה שצוינו מכוסים על ידי תהליך הסימולציה.

דרישות מערכת פרמטריות
דרישות אלו הן פרמטרים שמספקת המערכת עצמה. במהלך תהליך המידול נוכל לקבל את הפרמטרים הללו כתוצאות חישוב ולוודא שהדרישות מתקיימות בכל חישוב ספציפי.

זיהוי דרישות וקידוד

כדי להקל על העבודה עם הדרישות, תקנים קיימים ממליצים להקצות מזהה לכל דרישה. בעת הקצאת מזהים, רצוי מאוד להשתמש במערכת קידוד מאוחדת.

קוד דרישה יכול להיות פשוט מספר המייצג את מספר ההזמנה של הדרישה, או שהוא יכול להכיל קוד לסוג הדרישה, קוד למערכת או ליחידה שעליה הוא חל, קוד פרמטר, קוד מיקום, ו כל דבר אחר שמהנדס יכול לדמיין. (ראה את המאמר לשימוש בקידוד)

טבלה 1 מספקת דוגמה פשוטה של ​​קידוד דרישות.

1. קוד מקור הדרישות R-requirements TK;
2. סוג קוד של דרישות E - דרישות - פרמטרים סביבתיים, או תנאי הפעלה
   S - דרישות המסופקות על ידי המערכת;
3. קוד מצב מטוס 0 - כל, G - חונה, F - בטיסה;
4. קוד סוג פרמטר פיזי T - טמפרטורה, P - לחץ, G - קצב זרימה, לחות H;
5. המספר הסידורי של הדרישה.

ID דרישות	תיאור	פרמטר
REGT01	טמפרטורת האוויר בסביבה בכניסה למערכת קירור המים: בחניון - ממינוס 35ºС. עד 35 מעלות צלזיוס.
REFT01	טמפרטורת אוויר אטמוספרי בכניסה למערכת ההגנה האווירית: בטיסה - ממינוס 35 ºС עד 39 ºС.
REFP01	לחץ אוויר אטמוספרי סטטי בטיסה הוא מ-700 עד 1013 hPa (מ-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.

איור 1. דוגמה לתכנון של פרויקט אימות.

בדיוק כמו עבור אלגוריתמי בקרה, ניתן לערוך דרישות כסט של גיליונות. לנוחיות העבודה עם אלגוריתמים בסביבות דוגמנות מבניות כגון SimInTech, Simulink, AmeSim, נעשה שימוש ביכולת ליצור מבנים רב רמות בצורה של תת-מודלים. ארגון זה מאפשר לקבץ דרישות שונות לקבוצות כדי לפשט את העבודה עם מערך דרישות, כפי שנעשה עבור אלגוריתמי בקרה (ראה איור 2).

איור 2. מבנה היררכי של מודל אימות הדרישות.

לדוגמה, במקרה הנדון מבחינים בשתי קבוצות: דרישות לאיכות הסביבה ודרישות ישירות למערכת. לכן, נעשה שימוש במבנה נתונים דו-מפלסי: שתי קבוצות, שכל אחת מהן היא עלה של האלגוריתם.

כדי לחבר נתונים למודל, נעשה שימוש בסכימה סטנדרטית להפקת מסד נתונים של אותות, המאחסנת נתונים להחלפה בין חלקי הפרויקט.

בעת יצירה ובדיקה של תוכנה, הקריאות של חיישנים (אנלוגים של חיישני מערכת אמיתיים) המשמשים את מערכת הבקרה ממוקמות במסד נתונים זה.
עבור פרויקט בדיקה, ניתן לאחסן את כל הפרמטרים המחושבים במודל הדינמי באותו מסד נתונים ובכך לבדוק האם עומדים בדרישות.

במקרה זה, המודל הדינמי עצמו יכול להתבצע בכל מערכת מידול מתמטית או אפילו בצורה של תוכנית ניתנת להפעלה. הדרישה היחידה היא נוכחות של ממשקי תוכנה להנפקת נתוני מידול לסביבה החיצונית.

איור 3. חיבור פרויקט האימות למודל המורכב.

דוגמה לגיליון אימות דרישות בסיסי מוצגת באיור 4. מנקודת מבטו של המפתח, מדובר בתרשים חישוב קונבנציונלי שעליו מוצג בצורה גרפית אלגוריתם אימות הדרישות.

איור 4. גיליון בדיקת דרישות.

החלקים העיקריים של דף הבדיקות מתוארים באיור 5. אלגוריתם הבדיקה נוצר בדומה לדיאגרמות התכנון של אלגוריתמי בקרה. בצד ימין יש בלוק לקריאת אותות ממסד הנתונים. בלוק זה ניגש למסד הנתונים של האותות במהלך סימולציה.

האותות המתקבלים מנותחים כדי לחשב את תנאי אימות הדרישות. במקרה זה, ניתוח גובה מתבצע כדי לקבוע את מיקום המטוס (בין אם הוא חונה או בטיסה). למטרה זו, אתה יכול להשתמש באותות אחרים ופרמטרים מחושבים של המודל.

תנאי האימות והפרמטרים הנבדקים מועברים לקוביות אימות סטנדרטיות, בהן מנותחים פרמטרים אלו לעמידה בדרישות שצוינו. התוצאות נרשמות במסד הנתונים של האותות באופן שניתן להשתמש בהן ליצירת רשימת בדיקה אוטומטית.

איור 5. מבנה גיליון חישוב אימות הדרישות.

הפרמטרים שייבדקו אינם משתמשים בהכרח באותות הכלולים במסד הנתונים, אשר נשלטים על ידי פרמטרים המחושבים במהלך תהליך הסימולציה. דבר לא מונע מאיתנו לבצע חישובים נוספים במסגרת דרישות הטיוטה, כפי שאנו מחשבים את תנאי האימות.

לדוגמה, דרישה זו:

מספר ההפעלות של מערכת התיקון במהלך הטיסה למטרה לא יעלה על 5, וזמן ההפעלה הכולל של מערכת התיקון לא יעלה על 30 שניות.

במקרה זה, אלגוריתם למניעת מספר ההתחלות וזמן ההפעלה הכולל מתווסף לתרשים התכנון של הדרישות.

בלוק אימות דרישות טיפוסיות.

כל תיבת סימון דרישה סטנדרטית נועדה לחשב את מילוי דרישה מסוג מסוים. לדוגמה, הדרישות הסביבתיות כוללות מגוון של טמפרטורות הפעלה סביבתיות בעת חניה ובטיסה. בלוק זה חייב לקבל את טמפרטורת האוויר בדגם כפרמטר ולקבוע אם פרמטר זה מכסה את טווח הטמפרטורות שצוין./p>

הבלוק מכיל שתי יציאות קלט, param ו-condition.

הראשון מוזן עם הפרמטר הנבדק. במקרה זה, "טמפרטורה חיצונית".

משתנה בוליאני מסופק ליציאה השנייה - התנאי לביצוע הבדיקה.

אם TRUE (1) מתקבל בקלט השני, אז הבלוק מבצע חישוב אימות דרישה.

אם הקלט השני מקבל FALSE (0), אז תנאי הבדיקה לא מתקיימים. זה הכרחי כדי שניתן יהיה לקחת בחשבון את תנאי החישוב. במקרה שלנו, קלט זה משמש להפעלה או השבתה של הסימון בהתאם למצב הדגם. אם המטוס נמצא על הקרקע במהלך הסימולציה, אזי הדרישות הקשורות לטיסה אינן נבדקות, ולהיפך - אם המטוס בטיסה, אזי הדרישות הקשורות לתפעול בעמידה אינן נבדקות.

ניתן להשתמש בקלט זה גם בעת הגדרת המודל, למשל בשלב הראשוני של החישוב. כאשר הדגם מובא למצב הנדרש, בלוקי הסימון מושבתים, אך ברגע שהמערכת מגיעה למצב ההפעלה הנדרש, בלוקי הסימון מופעלים.

הפרמטרים של בלוק זה הם:

• תנאי גבול: גבולות טווח עליונים (UpLimit) ותחתונים (DownLimit) שיש לבדוק;
• זמן החשיפה הנדרש למערכת בטווחי הגבול (TimeInterval) בשניות;
• זיהוי בקשה ReqName;
• רשות לחרוג מהטווח Out_range הוא משתנה בוליאני שקובע אם ערך החורג מהטווח המסומן מהווה הפרה של הדרישה.

במקרים מסוימים, פלט ערך הבדיקה מצביע על כך שלמערכת יש מרווח מסוים וייתכן שהיא פועלת מחוץ לטווח הפעולה שלה. במקרים אחרים, פלט אומר שהמערכת אינה מסוגלת לשמור את נקודות ההגדרה בטווח.

איור 6. בלוק בדיקת מאפיינים טיפוסי בתרשים והפרמטרים שלו.

כתוצאה מהחישוב של בלוק זה, המשתנה Result נוצר בפלט, אשר לוקח את הערכים הבאים:

• 0 - rNone, ערך לא מוגדר;
• 1 - rDone, הדרישה מתקיימת;
• 2 – rFault, הדרישה לא מתקיימת.

תמונת הבלוק מכילה:

• טקסט מזהה;
• צגים דיגיטליים של פרמטרים של מגבלות מדידה;
• מזהה צבע של סטטוס הפרמטר.

בתוך הבלוק עשוי להיות מעגל מסקנות לוגי מורכב למדי.

לדוגמה, כדי לבדוק את טווח טמפרטורת הפעולה של היחידה המוצגת באיור 6, המעגל הפנימי מוצג באיור 7.

איור 7. תרשים פנימי של יחידת קביעת טווח הטמפרטורה.

בתוך בלוק המעגל, נעשה שימוש במאפיינים המצוינים בפרמטרי הבלוק.
בנוסף לניתוח עמידה בדרישות, התרשים הפנימי של הבלוק מכיל גרף הדרוש להצגת תוצאות הסימולציה. גרף זה יכול לשמש הן לצפייה במהלך החישוב והן לניתוח התוצאות לאחר החישוב.

תוצאות החישוב מועברות לפלט של הבלוק ונרשמות בו זמנית בקובץ דוחות כללי, שנוצר על סמך התוצאות של הפרויקט כולו. (ראה איור 8)

דוגמה לדוח שנוצר על סמך תוצאות הסימולציה היא קובץ HTML שנוצר לפי פורמט נתון. ניתן להגדיר את הפורמט באופן שרירותי לפורמט המקובל על ידי ארגון מסוים.

בתוך בלוק המעגל, נעשה שימוש במאפיינים המצוינים בפרמטרי הבלוק.
בנוסף לניתוח עמידה בדרישות, התרשים הפנימי של הבלוק מכיל גרף הדרוש להצגת תוצאות הסימולציה. גרף זה יכול לשמש הן לצפייה במהלך החישוב והן לניתוח התוצאות לאחר החישוב.

תוצאות החישוב מועברות לפלט של הבלוק ונרשמות בו זמנית בקובץ דוחות כללי, שנוצר על סמך התוצאות של הפרויקט כולו. (ראה איור 8)

דוגמה לדוח שנוצר על סמך תוצאות הסימולציה היא קובץ HTML שנוצר לפי פורמט נתון. ניתן להגדיר את הפורמט באופן שרירותי לפורמט המקובל על ידי ארגון מסוים.

איור 8. דוגמה לקובץ דוח המבוסס על תוצאות סימולציה.

בדוגמה זו, טופס הדוח מוגדר ישירות במאפייני הפרויקט, והפורמט בטבלה מוגדר כאותות פרויקט גלובליים. במקרה זה, SimInTech בעצמה פותרת את בעיית הגדרת הדוח, והחסימה לכתיבת תוצאות לקובץ משתמשת בשורות אלו כדי לכתוב לקובץ הדוח.

איור 9. הגדרת פורמט הדוח באותות פרויקטים גלובליים

שימוש במסד נתונים לדרישות.

כדי להפוך עבודה לאוטומטית עם הגדרות מאפיינים, נוצר מבנה סטנדרטי במסד הנתונים של האותות עבור כל בלוק טיפוסי. (ראה איור 10)

איור 10. דוגמה למבנה של בלוק בדיקת דרישות במסד נתונים של אותות.

מסד הנתונים של אותות מספק:

• אחסון כל פרמטרי דרישות המערכת הדרושים.
• צפייה נוחה של דרישות הפרויקט הקיימות מפרמטרים שצוינו ותוצאות דוגמנות עדכניות.
• הגדרת בלוק אחד או קבוצת בלוקים באמצעות שפת תכנות סקריפטים. שינויים במסד הנתונים של האותות מובילים לשינויים בערכי מאפייני הבלוק בתרשים.
• אחסון תיאורי טקסט, קישורים לפריטי מפרטים טכניים או מזהים במערכת ניהול הדרישות.

ניתן להגדיר בקלות מבני מסד נתונים של אותות לדרישות כך שיעבדו עם מערכת ניהול דרישות של צד שלישי. תרשים כללי של אינטראקציה עם מערכות ניהול דרישות מוצג באיור 11.

איור 11. תרשים של אינטראקציה עם מערכת ניהול הדרישות.

רצף האינטראקציה בין פרויקט הבדיקה של SimInTech לבין מערכת בקרת הדרישות הוא כדלקמן:

1. תנאי ההתייחסות מחולקים לדרישות.
2. הדרישות של המפרט הטכני מזוהות הניתנות לאימות על ידי מידול מתמטי של תהליכים טכניים.
3. תכונות של הדרישות שנבחרו מועברות למסד הנתונים של אותות SimInTech במבנה של בלוקים סטנדרטיים (לדוגמה, טמפרטורה מקסימלית ומינימלית).
4. במהלך תהליך החישוב, נתוני המבנה מועברים לדיאגרמות תכנון בלוקים, מתבצע ניתוח והתוצאות נשמרות במסד נתונים של אותות.
5. לאחר השלמת החישוב, תוצאות הניתוח מועברות למערכת ניהול הדרישות.

ניתן לחזור על שלבי דרישות 3 עד 5 במהלך תהליך התכנון כאשר מתרחשים שינויים בתכנון ו/או בדרישות ויש לבדוק מחדש את השפעת השינויים.

מסקנות.

• אב הטיפוס שנוצר של המערכת מספק הפחתה משמעותית בזמן הניתוח של מודלים קיימים לעמידה בדרישות המפרט הטכני.
• טכנולוגיית הבדיקה המוצעת משתמשת במודלים דינמיים שכבר קיימים וניתן להשתמש בה אפילו עבור כל מודל דינמי, כולל אלה שלא בוצעו בסביבת SimInTech.
• שימוש בארגון נתונים אצווה מאפשר ליצור חבילות אימות דרישות במקביל לפיתוח מודל, או אפילו להשתמש בחבילות אלו כמפרט טכני לפיתוח מודל.
• ניתן לשלב את הטכנולוגיה עם מערכות ניהול דרישות קיימות ללא עלויות משמעותיות.

למי שקרא עד הסוף, קישור לסרטון המראה כיצד עובד אב הטיפוס.

מקור: www.habr.com