הבית > תערוכה > תוכן

ארכיטקטורות תוכנה משובצות

Mar 08, 2019

ישנם מספר סוגים שונים של ארכיטקטורת תוכנה בשימוש נפוץ.


לולאה שליטה פשוטה

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


מערכת מבוקרת

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


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


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


ריבוי משימות שיתופיות

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


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


ריבוי משימות מונע או ריבוי השחלות

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


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


בשל המורכבות הזו, מקובל על ארגונים להשתמש במערכת הפעלה בזמן אמת (RTOS), המאפשר למתכנתים ליישם את הפונקציונליות של המכשיר ולא את שירותי מערכת ההפעלה, לפחות עבור מערכות גדולות; מערכות קטנות יותר אינן יכולות להרשות לעצמן את התקורה הקשורה למערכת בזמן אמת, עקב מגבלות לגבי גודל הזיכרון, הביצועים או חיי הסוללה. הבחירה כי RTOS נדרש מביא את הבעיות שלה, עם זאת, כמו הבחירה צריכה להיעשות לפני תחילת תהליך הפיתוח של היישום. עיתוי זה מכריח את המפתחים לבחור את מערכת ההפעלה המשולבת עבור המכשיר שלהם על בסיס הדרישות הנוכחיות ולכן מגביל את האפשרויות בעתיד במידה רבה. המגבלה של אופציות עתידיות הופכת יותר לבעיה עם צמצום חיי המוצר. בנוסף, רמת המורכבות גדלה בהתמדה כאשר נדרשים מכשירים לניהול משתנים כגון טורי, USB, TCP / IP, Bluetooth, LAN אלחוטי, רדיו חד-ערוצי, ערוצים מרובים, נתונים וקול, גרפיקה משופרת, מספר מצבים, מצבי לחכות וכן הלאה. מגמות אלה מובילות לקליטה של תווכה משובצת בנוסף למערכת הפעלה בזמן אמת.


מיקרו - גרנולים ו - exokernels

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


באופן כללי, microkernels להצליח כאשר המשימה החלפת תקשורת intertask הוא מהיר להיכשל כאשר הם איטיים.


Exokernels לתקשר ביעילות על ידי שיגרת שגרה רגיל. החומרה וכל התוכנות במערכת זמינות ומתרחבות על-ידי מתכנתי יישומים.


גרעינים מונוליטיים

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


דוגמאות נפוצות של גרעין מונוליטי מוטבע מוטמעות Linux ו- Windows CE.


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


יציאות ערכות נפוץ שבב מוטבע זמינים.

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

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

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

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

רכיבי תוכנה נוספים

בנוסף למערכת ההפעלה הליבה, מערכות משובצות רבות כוללות רכיבי תוכנה נוספים. רכיבים אלה מורכבים מערימות פרוטוקולי רשת כגון CAN, TCP / IP, FTP, HTTP ו- HTTPS, וכוללים גם יכולות אחסון כמו מערכות FAT ו- Flash לניהול זיכרון. אם למכשיר המשובץ יש יכולות שמע ווידיאו, מנהלי ההתקן וה - Codec המתאימים יהיו קיימים במערכת. במקרה של גרעינים מונוליטי, רבים של שכבות תוכנה אלה כלולים. בקטגוריית ה- RTOS, זמינות רכיבי התוכנה הנוספים תלויה בהצעה המסחרית.


ארכיטקטורות ספציפיות לדומיין

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