חברה לפיתוח Yocto בישראל: מה היא עושה, מי מספק את השירות ואיך בוחרים

חברה לפיתוח Yocto בישראל היא חברה שבונה עבור מוצר מערכת Embedded Linux מבוססת Yocto. העבודה כוללת העלאה של ה-BSP על הלוח, כתיבת שכבת מוצר, התאמת ה-Kernel וה-Device Tree, קיצור זמן העלייה, מנגנון עדכון בשטח ותחזוקה לאורך שנים. בישראל אפשר למצוא בתחום בעיקר שני סוגים של גורמים. הראשון הוא חברות שירותי הנדסה שעובדות על הלוח של הלקוח. השני הוא יצרני מודולי מעבד (SoM) שמספקים BSP ב-Yocto למודולים שלהם. TandemG היא חברה ישראלית מהסוג הראשון. היא משלבת פיתוח Embedded Linux עם פיתוח חומרה, Embedded בזמן אמת וענן, וקיימת מאז 2010. בהמשך המאמר מופיעה סקירה של חברות ישראליות נוספות שמציגות שירותים בתחום, לפי מה שהן מפרסמות.

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

מה חברה לפיתוח Yocto עושה בפועל

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

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

Yocto, Buildroot או הפצה מוכנה: ההחלטה שקודמת לבחירת החברה

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

ברוב המוצרים המסחריים עם מעבדי Cortex-A, Yocto הוא הבחירה הטבעית, בעיקר כי יצרני המעבדים והמודולים מספקים את ה-BSP שלהם על בסיסו. אבל יש מוצרים שבהם Buildroot מספיק בהחלט, ולכן כדאי לבחור חברה שממליצה על הכלי לפי המוצר.

שני סוגי ספקים: חברות שירותים ויצרני מודולים

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

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

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

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

מי מספק שירותי Yocto בישראל

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

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

מתי צריך חברה חיצונית ל-Yocto ומתי הצוות יכול לבד

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

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

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

איך נראה פרויקט Yocto עם חברה חיצונית

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

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

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

מה קובע את היקף פרויקט Yocto

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

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

תרחיש לדוגמה: ממערכת פיתוח למוצר על מודול מעבד

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

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

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

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

הכנה לייצור כוללת תמונת ייצור, חבילת צריבה לפס הייצור ודוח רישיונות.

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

מה מקבלים בסוף: רשימת תוצרים

פרויקט Yocto טוב מסתיים בתוצרים שמאפשרים ללקוח להמשיך בלי תלות בספק:

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

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

מודלי עבודה

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

שאלות שכדאי לשאול חברה לפיתוח Yocto

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

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

טעויות נפוצות בבחירת חברה ל-Yocto

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

שאלות נפוצות

מה עושה חברה לפיתוח Yocto?

היא בונה מערכת Embedded Linux מבוססת Yocto למוצר: מעלה את ה-BSP על הלוח, כותבת שכבת מוצר, מתאימה את ה-Kernel וה-Device Tree, כותבת דרייברים, מקצרת את זמן העלייה, מגדירה מנגנון עדכון ומתחזקת את המערכת לאורך שנים.

מה ההבדל בין חברת שירותים ליצרן מודולים בתחום Yocto?

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

אילו חברות בישראל מציגות שירותי Yocto?

בין החברות שמציגות שירותים בתחום באתרים שלהן: TandemG, TkOS, iGATES ו-EMBEDOX כחברות שירותים, ו-Variscite, CompuLab ו-SolidRun כיצרניות מודולים עם BSP מבוסס Yocto. כדאי לאמת את ההיקף והניסיון מול כל חברה.

האם צריך חברה חיצונית אם עובדים עם מודול מעבד מוכן?

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

כמה זמן לוקח פרויקט Yocto?

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

האם חברה לפיתוח Yocto יכולה לתחזק מערכת שבנה מישהו אחר?

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

מה צריך לקבל בסוף פרויקט Yocto?

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

האם אפשר להתחיל עם חברה חיצונית ולהעביר את התחזוקה לצוות הפנימי?

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

האם חברה לפיתוח Yocto עובדת גם עם Buildroot?

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

היתרון של TandemG

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

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

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

למי מתאים

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

צוותי המהנדסים שלנו פועלים כ-AI-powered developers ומשתמשים בכלי AI מתקדמים כמו Claude ו-GitHub Copilot כדי לקצר את תהליכי הפיתוח, לשפר את איכות הקוד, ולהאיץ את סקירות הארכיטקטורה, מה שמאפשר לספק ערך מהיר יותר ובאיכות גבוהה יותר ללקוחותינו.

הפרויקט הבא שלכם מתחיל בשיחה

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

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