חברה לפיתוח מערכת ניהול צי מכשירים מרחוק: מה המערכת צריכה לכלול ואיך בוחרים

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

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

מה מערכת ניהול צי מכשירים עושה

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

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

למה ניהול צי מכשירים מתחיל בתוכנה שבמכשיר

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

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

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

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

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

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

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

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

מדדי בריאות: מה כל מכשיר צריך לדווח

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

התראות: מה שווה להתריע עליו ומה לא

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

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

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

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

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

עדכוני תוכנה כחלק מניהול צי המכשירים

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

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

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

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

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

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

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

ניהול תצורה ופקודות מרחוק

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

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

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

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

פלטפורמה מוכנה, פיתוח עצמי או שילוב

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

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

שירותי הפלטפורמה משתנים, ולפעמים נסגרים. Google הפסיקה את שירות Cloud IoT Core באוגוסט 2023. לפי Microsoft, מאז 23 בספטמבר 2026 לא ניתן ליצור אפליקציות חדשות ב-Azure IoT Central, ואפליקציות קיימות לא יהיו זמינות אחרי 20 בספטמבר 2029. AWS הפסיקה את התמיכה ב-IoT Analytics בדצמבר 2025 וב-IoT Events במאי 2026. אלה אינן סיבות להימנע משירותי ענן, אלא סיבה לתכנן כך שהלוגיקה העסקית ומודל הנתונים לא יהיו קשורים לשירות אחד, ושמעבר בין שירותים יהיה אפשרי.

איך נראה פרויקט פיתוח של מערכת ניהול צי מכשירים

איך המערכת גדלה: ממאות מכשירים לעשרות אלפים

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

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

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

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

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

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

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

טעויות נפוצות בפיתוח מערכת ניהול צי מכשירים

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

שאלות נפוצות

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

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

למה מערכת ניהול צי מכשירים צריכה פיתוח גם בתוכנה של המכשיר?

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

האם עדיף להשתמש בפלטפורמה מוכנה או לפתח מערכת עצמית?

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

אילו מדדים כל מכשיר צריך לדווח?

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

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

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

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

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

האם אפשר להוסיף מערכת ניהול צי מכשירים למוצר שכבר בשטח?

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

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

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

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

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

היתרון של TandemG

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

הניסיון שלנו כולל מכשירים מבוססי Linux ומיקרו-בקרים עם קוד Real-Time Embedded, תקשורת סלולרית, Wi-Fi ו-BLE, ואפליקציות מובייל ו-Web שמתחברות לאותה מערכת. כשנמצאת תקלה בשטח, הנתונים שהמערכת אוספת הם נקודת הפתיחה, ומהנדסי החומרה והתוכנה שלנו ממשיכים משם אל הסיבה.

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

למי מתאים

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

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

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

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

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