השג הצלחה עסקית על ידי גישור על הפער בין תוכנה לחומרה במערכות משובצות
שלבי התכנון והאב טיפוס של פתרונות טכנולוגיים הם בדרך כלל ארוכים וקריטיים להצלחת העסק. השקעות הון ראשוניות יכולות להיות גבוהות בפרויקטים אלה. כתוצאה מכך, ההימור והציפיות גבוהות! מכיוון שאנו עדיין סובלים מהשלכות המגיפה מבחינת עיכובים במשלוח ומחסור ברכיבים אלקטרוניים, במקרים רבים חברות חוות לחץ עצום להגיע לשוק ולשלוח מלאי מחויב בזמן.
ישנו גם מאבק מתמיד על משאבי חומרה, משום שלעתים קרובות יישומים דורשים יכולות עיבוד הולכות וגדלות. משמעות הדבר היא שחומרה כנראה תהיה גדולה מדי בהתחלה ומיושנת עם הזמן. לכן, תצטרכו לשנות את התכנון שלכם כדי להוסיף כל הזמן יכולות חומרה נוספות למוצרים הטכנולוגיים שלכם ולהגדיל את העלויות וההשקעות שלא לצורך.
לבסוף, מציאת צוות מנוסה ובעל ידע בו זמנית במערכות משובצות, חומרה ותוכנה אינה תמיד קלה. בחברות מסוימות, מהנדסים ללא ניסיון במערכות משובצות מובילים ומפתחים פרויקטים טכנולוגיים. כתוצאה מכך, הם עשויים לבחור בערכות פיתוח (Jetson Nano, Arduino, Raspberry PI) בשל ההיכרות שלהם עם מערכות אלו והתכונות הסטנדרטיות המאפשרות אינטגרציה עם מערכות אחרות. ללוחות פיתוח יש יישומים תעשייתיים ייחודיים, ותוכלו לקרוא עוד עליהם בפוסט בבלוג זה. אבל זה לא תמיד המקרה בייצור המוני.
כל הגורמים הללו יכולים להשפיע לרעה על ההחלטה לגבי תכנות שפות, ארכיטקטורת אלגוריתמים ופיתוח תוכנת יישומים בכללותו. לעיתים ההחלטה מסתכמת בשימוש במערכת הפעלה סטנדרטית במקום במערכת הפעלה מותאמת אישית או מיוחדת עם קוד Stack Overflow במקום באלגוריתם קנייני. זה מוביל למשאבים בלתי מנוצלים, רכיבי חומרה גדולים מדי, עיכובים מיותרים, עלויות נוספות של עיצוב מחדש או הסמכה מחדש. לכן, בהתחלה, זה אולי נראה כפתרון חסכוני, אך ייתכן שתגלו שזה לא היה הפתרון החסכוני ביותר בהמשך הדרך. גרוע מכך, במהלך פעולה רגילה, חומרה שעובדת במלוא יכולתה עלולה להוביל לחימום, קיצור הזמן הממוצע בין כשלים ועלויות תיקון גבוהות יותר.
ארכיטקטורת אלגוריתמים
בואו ננתח את המסלול הנפוץ שחברות נוקטות בו לקראת ארכיטקטורת אלגוריתמים. למרבה הצער, חלק מהמהנדסים שעובדים עם מערכות משובצות יושבים לתכנת ללא כל תוכנית או עיצוב. הבעיה היא שתגלו רק לאחר מעשה אם האלגוריתם שלכם יעיל או לא יעיל.
אנו הולכים לתאר שתי דוגמאות לאלגוריתמים אידיאליים: לינאריים ולוגריתמיים. נניח שכל פעולה בסיסית אורכת שנייה. במקרה של אלגוריתמים לינאריים, ככל שהקלטים גדלים, זמן הביצוע עולה גם כן, כפי שניתן לראות בטבלה 1. אם אלגוריתם זה התנהג בצורה לוגריתמית, ככל שהיו לנו יותר קלטים, זמן הביצוע שלהם יישאר יציב (טבלה 2). לדוגמה, אלגוריתמי חיפוש בינארי מציגים התנהגות לוגריתמית.
טבלה 1. הקשר בין קלטים לזמן ביצוע של אלגוריתם לינארי.
| קֶלֶט | זמן ביצוע |
| 10 | 0.00000001 |
| 100 | 0.0000001 |
| 1,000 | 0.000001 |
| 1,000,000,000 | 1 |
טבלה 2. הקשר בין קלטים לזמן ביצוע של אלגוריתם לוגריתמי.
| קֶלֶט | זמן ביצוע |
| 10 | 3.3E-09 |
| 100 | 6.6E-09 |
| 1,000 | 1.0E-08 |
| 1,000,000,000 | 3.0E-08 |
שתי דוגמאות אלו אינן נמצאות בדרך כלל בחיים האמיתיים מכיוון שאלגוריתמים כמעט ולא מתנהגים באופן ליניארי או לוגריתמי. אלגוריתם ה"מיון טיפשי" יכול לשמש כדוגמה לתוצאות כאשר לא בוצעו תכנון או עיצוב לפני שמתחילים לתכנת. זהו אלגוריתם מבנה המבוסס על בדיקה אקראית בקבוצת כרטיסים עם התנהגות פקטוריאלית (טבלה 3). אם יש לנו 100 קלטים, יש לנו 3.2E+183 שנים לפתור אותו. על פי נאס"א, גיל היקום הוא 13.7E9 שנים, מה שמרמז שאם היינו מבצעים את האלגוריתם בתאריך שבו היקום נוצר, הוא עדיין היה פועל ללא פתרון. כדאי להימנע מאלגוריתמים פקטוריאלית, כמו אלגוריתם ה"מיון טיפשי", כדי להימנע מבזבוז משאבי חומרה.
טבלה 3. הקשר בין קלטים לזמן ביצוע של אלגוריתם פקטוריאלי.
| קֶלֶט | זמן ביצוע | משך זמן בשנים |
| 10 | 10 | 3.171E-7 |
| 100 | 1.0E+191 | 3.2E+183 |
| 1,000 | ? | ? |
| 1,000,000,000 | ? | ? |
למעשה, לחומרה יש מגבלות. באופן כללי, קשה לבני אדם לתפוס את קנה המידה של זמן במערכות משובצות. מסיבה זו, נגדיר סקאלה קלה יותר להבנה עבור ניתוח זה. עבור מעבד 3.9 גיגה-הרץ הטיפוסי הכלול במחשבים רגילים משנת 2014, ניתן לומר שמחזור מעבד אחד אורך שנייה אחת, כפי שמוצג בטבלה 4. במקרים אלה, קריאת קובץ בכונן הקשיח עשויה להימשך בתרחיש הגרוע ביותר 1.5 שנים, או קריאת קובץ בזיכרון ה-RAM עשויה להימשך 32 שניות. כפי שניתן לראות, אלגוריתם שתוכנן בצורה גרועה יבזבז משאבים. כתוצאה מכך, ייתכן שתחשבו שאתם זקוקים לחומרה חזקה יותר עם יכולות מוגברות כשאתם צריכים לבחון מחדש את אופן פיתוח התוכנה.
טבלה 4. זמני ביצוע של תהליכים רגילים במחשב בסולם שקל יותר להבין.
| פְּעִילוּת | זְמַן | קנה מידה אנושי |
| מחזור המעבד | 0.256 ננו-שניות | שנייה אחת |
| מטמון L1 | 1.026 ננו-שניות | 4 שניות |
| מטמון L2 | 3.077 ננו-שניות | 12 שניות |
| מטמון L3 | 6.154 ננו-שניות | 24 שניות |
| R.A.M. זֵכֶר | 8.4 ננו-שניות | 32 שניות |
| כונן קשיח - המקרה הטוב ביותר | 2.9 אלפיות השנייה | 132 ימים |
| כונן קשיח - המקרה הגרוע ביותר | 12 אלפיות השנייה | 1.5 שנים |
| SDD | 85 מיקרו-שניות | 3 ימים ו-20 שעות |
| שינוי הקשר | 10 מיקרו-שניות | 10.8 שעות |
| קוונטום | 100 אלפיות השנייה | 12.4 שנים |
כיצד משיגים הצלחה עסקית בעת פיתוח מוצרים טכנולוגיים?
עם ארכיטקטורת אלגוריתמים מדויקת. עליכם להרכיב צוות הכולל לפחות מהנדס מנוסה אחד במערכות משובצות. איש המקצוע הזה יהיה מצויד בצורה הטובה ביותר לאדריכלות אלגוריתמים שירצו בחומרה ספציפית. אדם זה ישפר בעצם את התוכנה כך שתתאים בצורה הטובה ביותר לחומרה (ולא להיפך), מה שבתורו יספק תשואה טובה יותר על ההשקעה ויחסוך לכם הרבה כאבי ראש תפעוליים וייצוריים.
מהנדס מערכות משובצות יגבש אסטרטגיה, יתכנן ויתכנת כדי להימנע מטעויות נפוצות בעת פיתוח תוכנה ויוכל לחזות את יכולות החומרה. משמעות הדבר היא שניתן להפחית את האתגרים ויהיה קל יותר להשיג הצלחה עסקית. מי יודע! אולי אפילו תהפכו לגיבורי תעשייה 4.0, האינטרנט של הדברים, הרובוטיקה או עיבוד התמונה בחברה שלכם.
אם אתם רוצים להמשיך לקרוא על הנושא הזה, אתם מוזמנים לבדוק הבלוג הזה. אתה יכול גם בדקו את הדף הזה למידע נוסף על מערכות משובצות.