מערכות אלקטרוניות בזמן אמת: יסודות, תכנון ויישומים

אינפורמטק דיגיטל » Recursos » מערכות אלקטרוניות בזמן אמת: יסודות, תכנון ויישומים

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

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

מהי מערכת בזמן אמת וכיצד היא שונה ממערכת מהירה?

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

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

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

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

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

דוגמה מעשית: בקרת רמזור בצומת

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

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

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

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

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

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

היסטוריה ואבולוציה של מערכות זמן אמת

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

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

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

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

מקרים מרכזיים: אפולו 11 ומאדים פאת'פיינדר

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

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

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

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

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

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

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

רכיבים בסיסיים של מערכת בזמן אמת

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

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

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

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

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

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

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

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

מאפיינים עיקריים: זמן, מקביליות, אבטחה ויעילות

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

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

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

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

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

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

סוגי מערכות זמן אמת: קשות, רכות ויציבות

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

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

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

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

ארכיטקטורות: פתוחות/סגורות ומרכזיות/מבוזרות

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

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

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

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

דטרמיניזם, השהיית הפרעות ותגובתיות

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

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

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

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

בקרת מערכת לפי תהליכים ואמינות

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

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

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

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

שפות ותכנות בזמן אמת

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

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

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

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

מערכות הפעלה בזמן אמת (RTOS)

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

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

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

מבחינה היסטורית, פיתוח מערכות RTOS החל בשנות ה-60 וה-70 עבור יישומים צבאיים, תעופה וחלל ותעשייה. בעשורים שלאחר מכן, צצו מוצרים מסחריים, המכונים גרסאות VxWorks, QNX, או Solaris בזמן אמת, בשימוש נרחב בתקשורת, רכב ומערכות משובצות.

עם עליית האינטרנט של הדברים בשנות ה-2000 וה-2010, מערכות RTOS קלות משקל כמו FreeRTOS הם הפכו פופולריים מאוד במכשירים מחוברים בעלי צריכת אנרגיה נמוכה. במקביל, הוצעו הרחבות POSIX בזמן אמת כדי לאחד ממשקים ולהקל על ניידות תוכנה.

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

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

דרישות ש-RTOS טוב חייב לעמוד בהן

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

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

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

אלגוריתמי תזמון: EDF ומודלים אחרים

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

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

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

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

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

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

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

יישומים אופייניים של מערכות בזמן אמת

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

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

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

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

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

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

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

בכל הסביבות הללו, נדרשים הדברים הבאים: פרוטוקולי תקשורת ספציפיים בזמן אמת, כגון CAN, Token Bus, TDMA-TTP, CSMA/CD מותאמים, או תוכניות אישור חיובי או שידור חוזר (PAR), אשר מפחיתות את זמני השידור ומספקות ערבויות לגבי מועד הגעת הנתונים.

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

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