מה זה בעצם תוכנה embedded
תוכנה embedded – או בשמה העברי, תוכנה משובצת – היא הקוד שרץ בתוך המוצר עצמו, ולא במחשב או בטלפון. היא שוכנת על מיקרו-בקר קטן בתוך המכשיר, מפעילה מנועים, קוראת חיישנים, מנהלת סוללה ומדברת עם העולם. במרבית המוצרים החכמים היא הרכיב שקובע אם המוצר מרגיש אמין או מרגיש כמו צעצוע.
ההבדל מפיתוח תוכנה רגיל אינו בשפה אלא בסביבה: זיכרון של קילובייטים במקום גיגה-בייטים, ללא מערכת הפעלה או עם מערכת מינימלית, בלי מסך לדבג עליו, וקוד שצריך לרוץ שנים בלי אתחול. מהנדס תוכנה מעולה מהעולם המשרדי אינו בהכרח מפתח embedded, וזו הבחנה שחוסכת ליזמים גיוס שגוי.
הכלל הראשון: התוכנה נכתבת יחד עם החומרה
הטעות היקרה ביותר בפרויקטים כאלה היא לסיים את החומרה ואז להתחיל לכתוב קוד. בפועל, הקושחה היא זו שחושפת את בעיות החומרה: פין שלא ניתן לשליטה, ערוץ מדידה רועש, זמן התעוררות ארוך מדי, רכיב שלא עונה בזמן. כשהתגליות האלה מגיעות אחרי שהלוח נסגר, כל תיקון עולה מהדורת לוח שלמה.
לכן אנחנו כותבים קושחה בסיסית על המהדורה הראשונה של הלוח, גם אם היא רק מדליקה נורה ומודדת ערך אחד. הרחבנו על סדר העבודה הזה בפיתוח חומרה ובתהליך הפיתוח של מוצר אלקטרוניקה.
מה תוכנת embedded מנהלת במוצר
- קריאת חיישנים ועיבוד אות: המדידה הגולמית אינה שמישה כמעט לעולם – נדרש סינון, כיול ופיצוי על טמפרטורה. כאן נקבעת איכות המדידה של המוצר, לא רק ברכיב.
- שליטה במנועים ובמפעילים: תזמון מדויק, האצה והאטה, וזיהוי תקיעה או עומס חריג.
- ניהול הספק: מצבי שינה, התעוררות לפי אירוע וכיבוי רכיבים שאינם בשימוש. זה מה שקובע אם המוצר עובד יום או חודש על סוללה.
- תקשורת: בלוטות', רשת אלחוטית או סלולר – כולל התמודדות עם ניתוקים, שהם המצב הרגיל ולא החריג.
- אמינות ושרידות: שעון שמירה שמאתחל את המוצר אם הקוד נתקע, שמירת מצב בזיכרון קבוע, והתאוששות שקטה מתקלה. משתמש לא צריך לדעת שהייתה תקלה.
- עדכון גרסה בשטח: היכולת לתקן באג אחרי שהמוצר נמכר – ההבדל בין קמפיין החזרה יקר לבין עדכון שקוף.
עדכון קושחה – פונקציה שחייבת להיות מהיום הראשון
כל מוצר חומרה יוצא לשוק עם באגים; ההנחה ההפוכה אינה מקצועית. לכן מנגנון עדכון אינו תכונה מתקדמת אלא דרישת בסיס, ויש לתכנן אותו לפני שהמוצר נסגר. שני עקרונות מחייבים: העדכון חייב לשרוד ניתוק באמצע – מוצר שנהרס כי הטלפון נעל את המסך הוא כשל תכן; והמוצר חייב לדעת לחזור לגרסה הקודמת אם החדשה נכשלת.
כשהעדכון מגיע דרך אפליקציה, מדובר בפרויקט מערכת ולא בשני פרויקטים נפרדים – ראו פיתוח אפליקציה עבור המוצר שלי.
חלוקת האחריות: מה במוצר ומה מחוצה לו
שאלה שיש להכריע בה מוקדם, כי היא משפיעה על עלות ועל אמינות. שלושה כללים מנוסים:
- כל מה שקריטי לבטיחות – בקושחה, תמיד. אם עצירת חירום דורשת טלפון מחובר, המוצר אינו בטוח.
- חישוב כבד – מחוץ למוצר. מיקרו-בקר קטן אינו מקום לעיבוד מסובך; אפליקציה או שרת יעשו זאת טוב יותר.
- לוגיקה שתשתנה תכופות – לא בקושחה. עדכון קוד בשטח מסובך יותר מעדכון אפליקציה.
בחירת המעבד – החלטה שקשה לחזור ממנה
בחירת המיקרו-בקר קובעת את גבולות המוצר לשנים, ולכן אינה החלטה "טכנית קטנה". לא הכי חזק – הכי מתאים: מעבד עוצמתי מדי מייקר, מחמם ומקצר את חיי הסוללה, ומעבד חלש מדי יאלץ החלפת ארכיטקטורה באמצע הדרך. שיקול שנשכח: זמינות ושרשרת אספקה – רכיב עם ספק בודד וזמן אספקה ארוך הוא סיכון פרויקטלי, ולכן אנו מעדיפים רכיבים עם חלופה מוכרזת.
כשהמוצר רפואי או בטיחותי
אם המוצר מיועד לשימוש רפואי, לתעשייה או לכל הקשר שבו כשל מסוכן, התוכנה המשובצת נכתבת בשיטת עבודה מתועדת: דרישות מנוסחות כך שניתן למדוד אותן, בדיקות שמקושרות לכל דרישה, וניהול גרסאות מלא. זו אינה ביורוקרטיה אלא מה שמאפשר להוכיח שהמוצר בטוח. הרחבנו על הגישה בהנדסת מוצרי רפואה.
מי כותב את הקוד
פיתוח embedded יושב בתפר שבין חומרה לתוכנה, ולכן הוא מצליח בעיקר כשהמפתח יושב ליד מהנדס האלקטרוניקה ולא מרחוק. פרויקטים שבהם החומרה, הקושחה והמכניקה מנוהלות בנפרד נתקעים בדיוק בממשקים – ראו שיתוף פעולה בין תחומי הנדסה. בפרוג'קטס האוס בע"מ שני התחומים יושבים תחת קורת גג אחת, וזו הסיבה שהתפר הזה אינו הופך לצוואר בקבוק.
לסיכום
תוכנה embedded היא הקוד שרץ בתוך המוצר, והיא זו שקובעת את האמינות, את חיי הסוללה ואת התחושה שהמוצר "עובד כמו שצריך". שלושת הכללים המרכזיים: לכתוב אותה במקביל לחומרה ולא אחריה, לתכנן מנגנון עדכון מהיום הראשון, ולהחליט במודע מה יושב בקושחה ומה מחוצה לה. בפרוג'קטס האוס בע"מ אנו מפתחים חומרה וקושחה כמערכת אחת – מבחירת המעבד ועד ההעברה לייצור.
רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.
מאמרים נוספים בנושא פיתוח תוכנה embedded
- Bootloader במיקרו-בקר - למה כל מוצר צריך אחד
- FreeRTOS מול Zephyr — איזו מערכת הפעלה למוצר משובץ
- I2C, SPI או UART — מה ההבדל בין פרוטוקולי התקשורת
- MicroPython במוצר מסחרי — קיצור דרך או מלכודת
- RTOS או Bare Metal — איך בוחרים ארכיטקטורת קושחה
- Secure Boot והצפנת קושחה - הגנה על הקניין הרוחני שלכם
- TinyML — הרצת מודלים של בינה מלאכותית על מיקרו-בקר
- Watchdog ומנגנוני התאוששות — קושחה שלא נתקעת בשטח
- איך מתכננים מוצר שמחזיק שנים על סוללה אחת
- בדיקות HIL: בדיקות אוטומטיות לקושחה מול חומרה אמיתית
- בדיקות יחידה בקוד משובץ — האם זה בכלל אפשרי
- בחירת סביבת פיתוח ו-Toolchain לפרויקט embedded
- חיבור מוצר משובץ לענן — מה נדרש בצד הקושחה
- טעויות נפוצות בפיתוח קושחה ראשונה למוצר
- כלי דיבוג לפיתוח embedded: JTAG, SWD ולוגיק אנלייזר
- כמה זיכרון Flash ו-RAM המיקרו-בקר צריך באמת
- כמה עולה פיתוח firmware למוצר חדש
- לוגים ואבחון תקלות מרחוק במוצר משובץ
- לינוקס משובץ — מתי המוצר שלכם צריך Embedded Linux
- מה זו קושחה (Firmware) — מדריך ליזמים בלי רקע טכני
- מיקרו-בקר או מעבד עם לינוקס — איך מקבלים את ההחלטה
- מכונת מצבים בקושחה — כך מתכננים את לוגיקת המוצר
- מערכות זמן אמת — מתי המוצר דורש Real-Time קשיח
- מצבי שינה במיקרו-בקר: הסוד לצריכת חשמל נמוכה
- ניהול גרסאות קושחה בייצור ובשטח — בלי לאבד שליטה
- עיבוד אותות DSP במערכת משובצת — פילטרים ודגימה
- פיתוח BLE בקושחה — שירותי GATT, פרסום וצריכת חשמל
- פיתוח embedded ב-C או ב-Rust — מה נכון לפרויקט
- פיתוח קושחה לתקן Matter — הדור החדש של הבית החכם
- פסיקות (Interrupts) בקושחה — עקרונות לתכנון נכון