פיתוח אפליקציית AR לנייד לתעשייה

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

פיתוח ותמיכה בכל סוגי היישומים הניידים:

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

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

השירותים שאנו מציעים
מציג 1 מתוך 1כל 1734 השירותים
פיתוח אפליקציית AR לנייד לתעשייה
מורכב
מ- 2 שבועות עד 3 חודשים

הכישורים שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית מובייל עבור FEEDME
    פיתוח אפליקציית מובייל עבור FEEDME
    971
  • פיתוח אפליקציית מובייל עבור XOOMER
    פיתוח אפליקציית מובייל עבור XOOMER
    869
  • פיתוח אפליקציית מובייל עבור RHL
    פיתוח אפליקציית מובייל עבור RHL
    1289
  • פיתוח אפליקציית מובייל עבור ZIPPY
    פיתוח אפליקציית מובייל עבור ZIPPY
    1143
  • פיתוח אפליקציית מובייל עבור Affhome
    פיתוח אפליקציית מובייל עבור Affhome
    1076
  • פיתוח אפליקציית מובייל עבור חברת FLAVORS
    פיתוח אפליקציית מובייל עבור חברת FLAVORS
    677

אפליקציית AR לתעשייה: היכן נעצר הפיילוט

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

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

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

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

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

מה משתנה באתר לאחר הטמעת שכבת AR

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

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

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

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

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

שלושה מצבי עבודה: ניווט, רמז שלב-אחר-שלב, בקרה

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

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

מצבים והמגבלות שלהם

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

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

שלבי הטמעה: מסקר האתר ועד למסירה

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

  1. סקר האתר. מהנדסים יוצאים לייצור, מצלמים את מסלול המפעיל, מתעדים סוגי ציוד, תאורה לפי אזורים, זמינות רשת ומגבלות אמצעי הגנה. התוצאה — מפת אזורים שבהם AR עובד יציב, ורשימת אזורים שבהם נדרשת הפעלה ידנית.
  2. תרשים תרחיש הפעולה. מפרקים את העבודה לשלבים, לכל אחד מגדירים סוג רמז: הארת מכלול, חץ סדר, הנחיה טקסטואלית, בדיקת תוצאה. מתאמים את התרשים עם טכנולוגים — הוא הופך לחוזה לכל ההיקף בהמשך.
  3. הרכבת תוכן AR. מכינים מודלים, קישורים ורמזים לזיהוי אובייקטים אמיתיים, כולל וריאנטים של ציוד שחוק ומזוהם. מנהלים גרסאות של התוכן בנפרד מקוד האפליקציה.
  4. הגדרת ציוד ומצב לא מקוון. בוחרים מכשירים, חיבורים ומצב עבודה לפי אורך המשמרת, שומרים את התרחיש במטמון במכשיר כדי שהרמזים לא יהיו תלויים בכיסוי הרשת בבית המלאכה.
  5. בדיקה בפעולות אמיתיות. משמרת עוברת את התרחיש במצב עבודה, אנו מחשבים שיעור שלבים שזוהו, זמן לפעולה ומספר הפניות להוראה. תיקונים מבוצעים לפני הקבלה, לא אחרי ההפעלה.
  6. מסירת הפתרון והדרכת המשמרת. מוסרים תצורות, תרשים תרחיש, תקנון עדכון תוכן ונוהל החזרה לאחור. מדריכים מפעילים ושירות הנדסי — אפשר לעדכן רמזים בלעדינו.

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

ערכת מסירה: תצורות, תרשימים, תקנונים והרשאות

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

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

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

מקרה בוחן: הרכבת מכלול בקו — מדדים לפני ואחרי

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

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

מה נמדד בפיילוט

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

התוצאה: חציון המחזור ירד מ-9 ל-5.5 דקות, הפער בין מפעיל מנוסה למתחיל הצטמצם כמעט פי שניים. סוג הטעות 'מחבר לא לפי מפרט' בקו הפיילוט נעלם לחלוטין, עבודות מחדש — מ-4% לעשיריות האחוז. מתחיל הגיע להרכבה עצמאית במשמרת הראשונה, ולא אחרי שבוע עם חונך.

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

במה שונה רמז שלב-אחר-שלב מעזרה מרחוק של מהנדס?

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

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

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

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

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

ספקות הנדסיים לפני פיילוט: מפרקים לפי סעיפים

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

איך האפליקציה עובדת ברשת סגורה של הייצור?

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

מה קורה בבית מלאכה שבו אין חיבור יציב?

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

איך מתבצעת האינטגרציה עם מערכת הרישום?

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

מה כלול בתמיכה לאחר המסירה?

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

איך לשכפל את הפתרון לאזורים אחרים?

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

נדון במשימה: מה לשלוח להערכה ולתוכנית

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

מה לשלוח לניתוח המשימה:

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

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