מהפכה בהנדסת מערכות מבוססות מודל באמצעות System Composer
פתרון אחוד המגשר בין דרישות, תכנון, מימוש ואימות מערכתי באמצעות פתרונות מבית MathWorks
למה אנחנו צריכים Model-Based System Engineering (MBSE) ?
דמיינו שאתם מנהלים פרויקט פיתוח של מערכת מורכבת, רכב אוטונומי, לוויין, או מכשור רפואי מציל חיים. כל שינוי קטן בתכנון יכול לגרור שרשרת של טעויות יקרות, עיכובים בלוחות זמנים, ותיאומים אינסופיים בין צוותי חומרה, תוכנה ומכניקה. בעולם שבו מורכבות המערכות הולכת וגדלה, והזמן לשוק מתקצר, כל טעות בתהליך הפיתוח עלולה לעלות מיליוני דולרים ולאבד יתרון תחרותי.
כאן נכנסת לתמונה הנדסת מערכות מבוססת-מודל (MBSE). מעבר ליתרונות הטכניים – עקביות, שקיפות, ויכולת ניתוח מוקדמת – MBSE מביאה גם יתרונות עסקיים ברורים כמו: קיצור זמני פיתוח, הורדת עלויות אינטגרציה ותיקונים, הגדלת הוודאות בתכנון, ושיפור שיתוף הפעולה בין צוותים ושותפים. בסביבה עסקית תחרותית, השימוש ב-MBSE אינו רק יתרון הנדסי, אלא מהלך אסטרטגי שמבטיח חדשנות מהירה יותר ועמידה בלוחות זמנים ובתקציבים.
מה נלמד במאמר זה ?
במאמר זה נציג את עקרונות תהליך העבודה עם פתרון ה- System Composer כחלק מתהליך MBSE. נסקור יכולות המאפשרות בניית ארכיטקטורת מערכת היררכית, הגדרת ממשקים ודרישות, יצירת דיאגרמות, קישור של מידול ואלגוריתמיקה לארכיטקטורה עבור סימולציה מערכתית אחודה, וביצוע תהליכי אימות ותיקוף עבור בדיקות מערכתיות.
הפוסט מתאים למהנדסי מערכת, ראשי צוותים, אינטגרטורים ומקבלי החלטות המעוניינים ליישם גישה מודרנית ומבוססת‑מודל בתהליך הפיתוח.
להדגמה מלאה של תהליך ה-MBSE עם System Composer, הרשמו לוובינר ייעודי בנושא
שיתקיים ב-20.11 לפרטים והרשמה
בניית ארכיטקטורה היררכית (Architecture)
תהליך העבודה בהתייחס ל- MBSE הינו גמיש ואנו יכולים להתחיל מיצירת ארכיטקטורה היררכית של המערכת. באמצעות System Composer, סביבת עריכה גרפית המאפשרת תצוגה נוחה וברורה של הארכיטקטורה, ניתן ליצור רכיבים (Components) המהווים ייצוגים פיזיים או לוגיים של תתי מערכות, להגדיר פורטים (Ports) המייצגים קלטים ופלטים, ואת הקשרים ביניהם בעזרת מקשרים (Connectors) המהווים את התווך בין הרכיבים במערכת. כל הרכיבים ניתנים לפירוק לרמות עומק נוספות ומאפשרים גמישות גבוהה בעריכה והכנסת שינויים לאורך חיי הפרויקט.
תמונה 1: ארכיטקטורת המערכת
הגדרת וקישור דרישות (Requirements)
מערכות מורכבות צריכות דרישות רבות ומסוגים שונים, פונקציונליות, פיזיות, רגולטוריות, תחזוקתיות, בדיקות ועוד. את הדרישות הללו ניתן לשלב כחלק בלתי נפרד מתהליך תכנון המערכת. אפשר לקשר כל דרישה לאלמנט ספציפי הקיים בארכיטקטורה (כולל בדיקות), לבדוק כיסוי של הדרישות במערכת וליצור עקיבות (traceability) מהדרישה ועד למימוש בפועל וכמובן, ולהודיע במקרה וחלים שינויים בדרישות.
כמו כן, ניתן לייבא דרישות ממקורות חיצוניים כגון Word, Excel, DOORS NG או בפורמט ReqIF, ולבצע סנכרון דו‑כיווני עם מסמכי הדרישות המקוריים. הגדרת וניהול הדרישות מתבצעת בצורה אינטגרטיבית עם פתרון ה‑ Requirements Toolbox אשר מוסיף תצוגות ניהול, קישורים דינמיים, כלי ניתוח ותיעוד.
תמונה 2: הגדרת וקישור דרישות לארכיטקטורה
הגדרת וקישור ממשקים (Interfaces)
באמצעות ה- System Composer ניתן להגדיר ממשקים המכילים הגדרות מדויקות של מבני נתונים הטרוגניים (סוגי המשתנים, גודלם וכו'). ממשקים אלו ניתנים לשיוך לכניסות ויציאות (קלט / פלט) של רכיבים בארכיטקטורה, בצורה מודולרית, באופן שהקישוריות בין תת-מערכות נעשית עקבית. ניתן לבצע בדיקות תקינות על ממשקים כבר בשלב הפיתוח, דבר אשר מפחית תקלות ואי התאמות בשלב האינטגרציה. בצורה זאת אנו שומרים על אחדות ההגדרה של ממשקים בכל הרמות בארכיטקטורה ואל מול כלל צוותי הפיתוח הפרויקט.
תמונה 3: הגדרת ממשקים
נושא זה, לצד דוגמאות נוספות מתהליכי MBSE יוצג גם בסמינר למהנדסי מערכת – Innovative Systems Engineering in Action שיתקיים ב־10.12 — למידע נוסף והרשמה
מאפייני המערכת – פרופילים וסטריאוטיפים (Profiles & Stereotypes)
אנו יכולים להגדיר פרופילים (Profiles) אשר מהווים חבילות מטא-דאטה. כל פרופיל יכול להכיל סטריאוטיפים (Stereotypes) המכילים מטא-דאטה אשר מתייחסים לאלמנטים בארכיטקטורה (רכיבי חומרה, תוכנה, כניסות/יציאות וכו'). כל סטריאוטיפ מכיל מאפיינים (Properties) עבור האלמנטים בארכיטקטורה (עלות, משקל, הספק, קצב עבודה, זיכרון וכו'). לאחר הגדרת כלל המאפיינים ההנדסיים באופן זה, ניתן לקשרם אל האלמנטים השונים בארכיטקטורה ולהקצות להם ערכים (למשל, קצב עבודה: 10KHz) עפ"י מפרטים ו/או דרישות המערכת.
לאחר שיש ברשותנו את המאפיינים של המערכת אנו יכולים ליצור:
- מבטים (Views) – התמקדות ברכיב בודד בארכיטקטורה ובחינה עם מי הוא מתקשר ובאיזו רמה ו/או הצגת כלל הרכיבים העונים לקריטריונים מוגדרים (למשל, רק רכיבי חומרה אלקטרומכנית).
- ניתוח סטטי (Static Analysis) – ניתוח מאפייני המערכת ע"י חישובים פשוטים / מורכבים, בחינת שינויים וחלופות ברכיבי המערכת (למשל, FPGA Vs. GPU) והבנת השפעתם על המערכת והפרויקט.
תמונה 4: מבטים וניתוח סטטי
דיאגרמות (Diagrams)
לצד הארכיטקטורה, אשר לעת עתה הינה הסטטית, ניתן ליצר דיאגרמות המתארות התנהגות דינמית של המערכת שאנו מפתחים. באמצעות Sequence Diagrams ו- Activity Diagrams ניתן לתאר תרחישי פעולה במערכת, סדרי פעולה לוגיים בין רכיבים, זרימת הפעולות והנתונים, ותנאי מעבר בין מצבים שונים.
הדיאגרמות משולבות ישירות עם הארכיטקטורה, כך שכל שינוי ברכיבים או בממשקים משתקף מיד גם בדיאגרמות. בנוסף, ניתן לקשר תרחישים לדיאגרמות על מנת לאפשר ניתוח ומעקב מבוקר יותר של תפקוד המערכת, בשלבים מוקדמים של תהליך הפיתוח.
- Sequence Diagrams – מתארות סדר כרונולוגי של פעולות, הודעות או אינטראקציות בין רכיבים שונים במערכת. דיאגרמות מסוג זה עוזרות להמחיש תרחישים ופעולות קריטיות בזמן ריצה.
- Activity Diagrams – מתארות בצורה ויזואלית זרימת תהליכים ונתונים, קבלת החלטות מערכתיות, ומעברים בין פעולות שונות.
תמונה 5: דיאגרמות Sequence & Activity
סימולציה מערכתית (System-Level Simulation)
פתרון ה- System Composer משמש כפלטפורמה אינטגרטיבית לסימולציה של מערכות רב‑תחומים, בכך שהוא מחבר בין התכנון ההנדסי ברמת הארכיטקטורה לבין ההתנהגות הדינמית של המערכת. כל רכיב בארכיטקטורה יכול להכיל התנהגות המוגדרת במודלים של Simulink, קוד MATLAB, לוגיקת מצבים ב‑ Stateflow, מידול פיזיקלי, רכיבי FMU וחיבורים לכלים חיצוניים (Co-Simulation).
הסימולציה במבנה זה מאפשרת למהנדסי המערכת לבחון את התנהגות המערכת בשלבים מוקדמים של הפיתוח, לבצע ניתוחים כמו בדיקות ביצועים, יציבות, תזמון, תגובות לתרחישי קצה וניתוחים סטטיסטים, כל זאת עוד לפני פיתוח ממשי של קוד או אבטיפוס של המערכת עצמה.
ככל שהפרויקט מתקדם וקורם עור וגידים, ניתן ליצור סביבת בדיקות אוטומטית בכדי להריץ סימולציות היברידיות שבהן משולבים יחד תתי‑מערכות מכניות, חשמליות, אלקטרוניות תוכנה, בקרה ועוד, ולבצע בדיקות של הסימולציה אל מול חומרות נבחרות
תמונה 6: סימולציה מערכתית
אימות ותיקוף (Verification & Validation)
תהליך האימות והתיקוף נעשה בשלבים שונים – החל מבדיקות היחידות השונות (Unit Tests), דרך סימולציה של המערכת הכוללת (System-Level Testing), ועד בדיקות קצה לקצה (כולל עבודה עם חומרות). ניתן להגדיר תרחישים לבדיקות בהתאם לדרישות שהוגדרו, להריץ את התרחישים, לאסוף את תוצאות ולנתחן, ואף להפיק דוחות של תוצאות הבדיקות בצורה אוטומטית. בנוסף, ניתן לשלב גם ניתוח קוד סטטי באמצעות פתרונות ממשפחת Polyspace, זאת לצורך עמידה בתקני תעשייה (כגון ISO 26262, DO-178C).
תמונה 7: בדיקות מערכתיות
סיכום
המעבר ל- Model-Based System Engineering מאפשר לנהל דרישות, ארכיטקטורה, ממשקים, התנהגות וסימולציות תחת מעטפת אחת. System Composer מספק את הכלים לתכנון וניתוח מודולרי, חיבור ישיר לדרישות, שילוב סימולציות רב-תחומיות, ואימות ותיקוף מלא לאורך מחזור חיי המערכת.
באמצעותו, מהנדסי מערכת יכולים לקבל החלטות מושכלות מוקדם יותר, לצמצם סיכונים ועלויות, ולהבטיח שהמערכת הסופית תעמוד הן בציפיות ההנדסיות והן בדרישות העסקיות.
למידע נוסף:
Model-Based Systems Engineering
Systems Engineering Documentation
Model-Based Systems Engineering for Space-Based Applications
Validating Requirements with Simulation and Formal Methods
Gulfstream Develops a New System Architecture Modeling Approach Using System Composer
