חיבור אפליקציית VR למערכות ארגוניות: החלטות לפני קוד

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

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

מפת נתונים לפני חיבור VR למערכות ארגוניות

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

המפה הזו חושפת מוקדם את השאלות הקשות: לאיזו מערכת יש בעלים שיאשר גישה, איזה נתון רגיש, ואיפה שני מקורות סותרים זה את זה. בסימולציית הדרכה, למשל, התוצאה עשויה להיכנס למערכת לניהול למידה, דרך תקן כמו xAPI או cmi5 או דרך ייבוא בשכבת הביניים, תלוי במה שהמערכת תומכת בו; או למערכת משאבי אנוש. אם בוחנים תקן, בדקו אם המערכת כוללת מאגר רשומות למידה (LRS) ואיך מפעילים ממנה אפליקציה שרצה במשקפיים. באפליקציית תחזוקה ב-AR, הנתונים מגיעים בדרך כלל ממערכת ניהול האחזקה או מה-ERP.

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

לקרוא קודם, לכתוב אחר כך

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

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

מי המשתמש כשהמשקפיים משותפים

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

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

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

עבודה ללא רשת וסנכרון

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

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

שכבת ביניים במקום חיבור ישיר

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

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

בדיקת קבלה לחיבור לפני שמרחיבים

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

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

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