תקשורת זמן אמת בשדה הקרב
בשדה הקרב המודרני, קצב העברת הנתונים הופך למגבלה, ושם המשחק הוא יישומי זמן אמת. ד"ר חררדו פרדו, ה-CTO של חברת rti, מסביר בראיון למגזין ישראל טק מדוע צבא שלא יפתח תשתית מתאימה – יפסיד את המלחמה
עמי רוחקס דומבה
| 19/05/2011
(shutterstock.com)
בחברת rti, המיוצגת בארץ על ידי מטריקס, הבינו מזמן שעתיד תקשורת הנתונים בין מכונות (M2M) ובין אנשים ומכונות, טמון בפתרון שיאפשר עבודה בסביבת זמן אמת. שלא כמו בעולם העסקי, כאשר מדובר על מלחמה, כל שניה באמת קובעת. "בסביבה רגילה (None RT) של יישומים, אין בעיית זמנים בשיתוף המידע. למשל באתר של בנק ,אם פעולה לוקחת זמן, הלקוח אולי מתעצבן, אבל לא נגרם נזק בפועל. הוא יכול לשתות קפה בינתיים. בסביבות של זמן אמת או קרוב לזמן אמת, המגבלות נקבעות על ידי הגבלות הפיזיקליות של המערכת החיצונית", מסביר ד"ר פרדו. "למשל בכטב”מ, הוא טס והפיזיקה שלו דורשת תגובה מסויימת. אם הוא רוצה לצלם מקום מסויים, כל איחור בזמנים של העברת המידע יגרום לכך שהוא לא יצלם את המקום הנכון. זה ההבדל".
מה הבעיות בסביבת לא זמן אמת?
"עוד הבדל הוא ביישומי M2M כאשר מדובר בקשר אדם-מכונה - האדם יכול לחכות. אבל כאשר מדובר על שתי מכונות שמתקשרות ביניהן, הם מנסות לעשות משהו בעולם האמיתי והזמנים קריטיים להצלחה. אם למשל מכונה אחת רוצה לפתוח פתח והמכונה השניה תלויה בכך, אם יהיה עיכוב בזמנים, הקומפוזיציה של הפעולה לא תהיה מושלמת ולא תעבוד כמו שצריך.
"בתקשורת M2M מסורתית, אם רצית לתקשר עם מכונה היית צריך לתקשר איתה בצורה חד ערכית, לוודא שהיא מחוברת ומגיבה ואז לשלוח את הבקשה. תחשוב על מדפסת. המחשב אומר לה להדפיס והיא מדפיסה. זו תקשורת נקודה לנקודה (P2P) וזו דוגמא קלאסית. אבל בסביבת זמן אמת זה לא עובד. המדפסת לפעמים לא מגיבה או המידע לא עובר ועבור יישומי זמן אמת זה אסון.
"בארכיטקטורה שלנו לסביבת זמן אמת זה עובד בצורה שונה. כלומר, אני אומר ל'עולם' שאני רוצה להדפיס, והשרתים השונים באותו עולם שמחוברים לאפיק נתונים מרכזי (data bus ) מקבלים את הבקשה ומיישמים אותה. אני לא צריך לחכות למדפסת המסויימת ולא לדעת שהיא עכשיו זמינה. אפיק הנתונים דואג לכך. המוצר שלנו שנקרא RTI Connext והוא מורכב ממגוון מרכיבים. אחד מהם הוא מרכיב ה-Connext DDS שמטפל בהודעות שרצות על אפיק הנתונים.
"אפיק הנתונים הוא מודל אבסטרקטי שבו עוברים הנתונים . זה לא אפיק פיזי ואין שרת מרכזי שהכל עובר דרכו. זו ארכיטקטורה מתאימה מאד לשדה הקרב, שם אין שרתים קבועים שהם המרכז של הרשת. כאן מדובר על רשת Peer2Peer. זה פרוטוקול תקשורת שמתנהג כמו רשת IP , כאשר לכל יישות יש מספר וכל היישויות מדברות ביניהן. זה מבוסס על שיטה שבה כל יישות נרשמת לאפיק הנתונים. והיא מחזיקה חלק מהמידע, כמו למשל איפה נמצאות שאר היישויות.
איך מתמודדים עם ניתוק וחיבור יישויות האופייני לשדה הקרב?
"זה אחד המאפיינים של ארכיטקטורה ממוקדת המידע שלנו (data centric). הישומים לא מתקשרים אחד עם השני ישירות, אלא הם מדברים עם אפיק הנתונים המרכזי. אם אתה מתנתק, יש לך קשר עם היישות המקומית שלך שהיא בעצם רכיב תוכנה שאוסף את הנתונים השונים. ברגע שאתה מתחבר מחדש לרשת, אותו רכיב יכול לשדר לאפיק הנתונים המרכזי את הנתונים שהוא מבקש.
"הראיון של אגירת נתונים בצורה מקומית (caching) הוא לא חדש, אבל אנחנו יודעים לעשות זאת בצורה חכמה. כלומר, אם היית מנותק ואתה מתחבר, נוצר מצב שבו רכיב התקשורת המקומי יכול 'לשפוך' את כל ההודעות שלו לאפיק המרכזי. אבל אנחנו מדברים על סביבת זמן אמת, ולכן ההודעות שצברת, לאו דווקא רלוונטיות לעכשיו. המפתח לתקשורת חכמה ויעילה בזמן אמת הוא ההקשר של המידע. לדעת מה חשוב ומה לא.
"באריטקטורה ממוקדת המידע אתה כל הזמן מעדכן את המצב (State) של המידע עצמו. זו יכולה להיות העמדה של הטנק , המיקום של האויב, המטרה שלך או כמות הדלק בכלי. אפיק הנתונים יודע מה המצב של כל חלק במידע והוא יכול לזכור את השינויים האחרונים (נתון לבחירת משתמש), ואז כאשר המערכות השונות חוזרות להיות בקשר עם האפיק, הוא יודע מה לבקש מהן. בצורה כזו המידע עובר בצורה יעילה ואין העמסה מיותרת של נתונים על האפיק.
"אסור לשכוח כי למרות הטכולוגייה המתקדמת, זה עדיין אתגר ליישם תצורת System Of Systems ולחבר בין המערכות השונות. זה לא פשוט. אמנם ברגע שהחלטת מה אתה רוצה ואיזה מודולציה לעשות לנתונים, זה יותר פשוט. לכל מערכת יש את מודל הנתונים שלה, וכאשר אתה מדבר על מגוון רחב של מערכות שצריכות לדבר יחד, זה נהיה מורכב. צריך לצור מכנה משותף, שפה משותפת, בין כל המערכות. יש לנו כלים שיודעים לעשות זאת על ידי תרגום בין מודולים שונים של מערכות. למשל יש מודל נתונים שמתאים לטנק כמערכת, יש מודל אחר שהוא מתאים למערכת של קואליציה ויש רכיבי תוכנה שמאפשרים תרגום שקוף של הנתונים ממערכת של הטנק לזו של הקואליציה".
מה האתגרים בתקשורת בין מכונות?
"המוצר שלנו התפתח מתוך תחום הרובוטיקה. מדובר על ארכיטקטורה שמתאימה לתקשורת בין מכונות , גם ללהקות. ברובוטים, אתה לא יכול לחקות את הצורה בה בני אדם מתקשרים. בין מכונות יכולה להיות רק אמת אחת. עוד היבט הוא הסטנרטיזציה. יש לך כל כך הרבה מערכות הפעלה לנייד, למחשב, לשרת. בגלל שאין הומוגניות בין סוגי החומרה והמערכות אתה צריך שכבה מקשרת שתדע לשלב את כולם יחד. אמנם בתחום הכלים הלא מאוישים יש את תקן JAUS, אבל הוא לא פותר את כל האתגרים של התקשורת בזמן אמת. השכבה המקשרת שלנו מספקת מסגור לנתונים בצורה כזו שאתה לא צריך להתעסק עם תווך התקשורת, אלא עם יישויות המידע.
"בנוסף לסטנדרטים, יש גם הרבה שפות תכנות. אבל בעתיד השפות יתבססו על מספר character set עיקריים כמו XML או DDS. אם אתה מסתכל על ארה"ב למשל, ה- UAS Control Segment (UCS) הולכת להיות הארכיטקטורה המרכזית של הצבא האמריקאי. אותו דבר קורה בצבא הבריטי עם Generic Vehicle Architecture (GVA) . , זה תהליך שקורה בכל הצבאות בעולם.
"גם ביישומים תעשייתים ומסחריים רוצים להרחיב את יכולות ה-IT לזמן אמת. הרבה יישומים צבאיים יעברו למוצרי מדף בעולם האזרחי. אחת הדוגמאות ליישום זמן אמת בתעשייה הוא תחום שנקרא "אחזקה חזויה" (predictive maintenance) המאפשר לחזות באמצעות מגוון טכנולוגיות בעיות לפני שהם מתרחשות ופוגעות בלקוחות החברה. במקרה של טורבינות רוח, אחת התקלות הנפוצות היא תקלה בגיר, אם ניתן יהיה לנטר את נתוני הטורבינה בזמן אמת, יהיה אפשר לתקן את הגיר לפני שהוא נשבר.
מה השינויים הטכנולוגיים הצפויים בעתיד?
"אחת המגמות היא שמערכות משובצות יחליפו את המחשבים האישיים. נראה יותר מחשוב ממוקד מטרה שיהיה מוטמע בחיי היום יום. מגמה נוספת תהיה מכונות שאפשר לתקשר אתן ולפנות אליהן. זה יאפשר את 'האינטרנט של הדברים' שהכל מחובר להכל. המחשב יתקשר עם הרכב , עם הסלולארי ועם כל התקן שתשתמש בו.
עוד מגמה תהיה דרישה ליעילות אנרגטית מהתוכנה. כלומר, ככל שהתוכנה יעילה יותר, כך היא צורכת פחות משאבי עיבוד ופחות אנרגיה. שאלות כמו כמה מחזורי מעבד?, כמה ליבות?, כמה מעבדים אתה משתמש?, כל אלו מצביעות על יעילות ברמת התוכנה. היה לנו ניסיון כזה עם מערכת ה-Blue Force Tracking של הצבא האמריקאי. הם רצו לשדרג גרסה, ובעזרת הארכיטקטורה שלנו הם הצליחו להוריד את כמות השרתים של המערכת בצורה משמעותית. כמות השרתים היא עוד פרמטר שקובע את צריכת האנרגיה הכללית של המערכת. היעילות של הפתרון שלנו בהעברת נתונים מתאים לתפישה זו. כיוון נוסף בהקשר זה הוא עולם הניידות, אם אתה עובד עם מכשיר סלולארי, צריך לוודא שהוא משתמש בכמה שפחות משאבים.
בחברת rti, המיוצגת בארץ על ידי מטריקס, הבינו מזמן שעתיד תקשורת הנתונים בין מכונות (M2M) ובין אנשים ומכונות, טמון בפתרון שיאפשר עבודה בסביבת זמן אמת. שלא כמו בעולם העסקי, כאשר מדובר על מלחמה, כל שניה באמת קובעת. "בסביבה רגילה (None RT) של יישומים, אין בעיית זמנים בשיתוף המידע. למשל באתר של בנק ,אם פעולה לוקחת זמן, הלקוח אולי מתעצבן, אבל לא נגרם נזק בפועל. הוא יכול לשתות קפה בינתיים. בסביבות של זמן אמת או קרוב לזמן אמת, המגבלות נקבעות על ידי הגבלות הפיזיקליות של המערכת החיצונית", מסביר ד"ר פרדו. "למשל בכטב”מ, הוא טס והפיזיקה שלו דורשת תגובה מסויימת. אם הוא רוצה לצלם מקום מסויים, כל איחור בזמנים של העברת המידע יגרום לכך שהוא לא יצלם את המקום הנכון. זה ההבדל".
מה הבעיות בסביבת לא זמן אמת?
"עוד הבדל הוא ביישומי M2M כאשר מדובר בקשר אדם-מכונה - האדם יכול לחכות. אבל כאשר מדובר על שתי מכונות שמתקשרות ביניהן, הם מנסות לעשות משהו בעולם האמיתי והזמנים קריטיים להצלחה. אם למשל מכונה אחת רוצה לפתוח פתח והמכונה השניה תלויה בכך, אם יהיה עיכוב בזמנים, הקומפוזיציה של הפעולה לא תהיה מושלמת ולא תעבוד כמו שצריך.
"בתקשורת M2M מסורתית, אם רצית לתקשר עם מכונה היית צריך לתקשר איתה בצורה חד ערכית, לוודא שהיא מחוברת ומגיבה ואז לשלוח את הבקשה. תחשוב על מדפסת. המחשב אומר לה להדפיס והיא מדפיסה. זו תקשורת נקודה לנקודה (P2P) וזו דוגמא קלאסית. אבל בסביבת זמן אמת זה לא עובד. המדפסת לפעמים לא מגיבה או המידע לא עובר ועבור יישומי זמן אמת זה אסון.
"בארכיטקטורה שלנו לסביבת זמן אמת זה עובד בצורה שונה. כלומר, אני אומר ל'עולם' שאני רוצה להדפיס, והשרתים השונים באותו עולם שמחוברים לאפיק נתונים מרכזי (data bus ) מקבלים את הבקשה ומיישמים אותה. אני לא צריך לחכות למדפסת המסויימת ולא לדעת שהיא עכשיו זמינה. אפיק הנתונים דואג לכך. המוצר שלנו שנקרא RTI Connext והוא מורכב ממגוון מרכיבים. אחד מהם הוא מרכיב ה-Connext DDS שמטפל בהודעות שרצות על אפיק הנתונים.
"אפיק הנתונים הוא מודל אבסטרקטי שבו עוברים הנתונים . זה לא אפיק פיזי ואין שרת מרכזי שהכל עובר דרכו. זו ארכיטקטורה מתאימה מאד לשדה הקרב, שם אין שרתים קבועים שהם המרכז של הרשת. כאן מדובר על רשת Peer2Peer. זה פרוטוקול תקשורת שמתנהג כמו רשת IP , כאשר לכל יישות יש מספר וכל היישויות מדברות ביניהן. זה מבוסס על שיטה שבה כל יישות נרשמת לאפיק הנתונים. והיא מחזיקה חלק מהמידע, כמו למשל איפה נמצאות שאר היישויות.
איך מתמודדים עם ניתוק וחיבור יישויות האופייני לשדה הקרב?
"זה אחד המאפיינים של ארכיטקטורה ממוקדת המידע שלנו (data centric). הישומים לא מתקשרים אחד עם השני ישירות, אלא הם מדברים עם אפיק הנתונים המרכזי. אם אתה מתנתק, יש לך קשר עם היישות המקומית שלך שהיא בעצם רכיב תוכנה שאוסף את הנתונים השונים. ברגע שאתה מתחבר מחדש לרשת, אותו רכיב יכול לשדר לאפיק הנתונים המרכזי את הנתונים שהוא מבקש.
"הראיון של אגירת נתונים בצורה מקומית (caching) הוא לא חדש, אבל אנחנו יודעים לעשות זאת בצורה חכמה. כלומר, אם היית מנותק ואתה מתחבר, נוצר מצב שבו רכיב התקשורת המקומי יכול 'לשפוך' את כל ההודעות שלו לאפיק המרכזי. אבל אנחנו מדברים על סביבת זמן אמת, ולכן ההודעות שצברת, לאו דווקא רלוונטיות לעכשיו. המפתח לתקשורת חכמה ויעילה בזמן אמת הוא ההקשר של המידע. לדעת מה חשוב ומה לא.
"באריטקטורה ממוקדת המידע אתה כל הזמן מעדכן את המצב (State) של המידע עצמו. זו יכולה להיות העמדה של הטנק , המיקום של האויב, המטרה שלך או כמות הדלק בכלי. אפיק הנתונים יודע מה המצב של כל חלק במידע והוא יכול לזכור את השינויים האחרונים (נתון לבחירת משתמש), ואז כאשר המערכות השונות חוזרות להיות בקשר עם האפיק, הוא יודע מה לבקש מהן. בצורה כזו המידע עובר בצורה יעילה ואין העמסה מיותרת של נתונים על האפיק.
"אסור לשכוח כי למרות הטכולוגייה המתקדמת, זה עדיין אתגר ליישם תצורת System Of Systems ולחבר בין המערכות השונות. זה לא פשוט. אמנם ברגע שהחלטת מה אתה רוצה ואיזה מודולציה לעשות לנתונים, זה יותר פשוט. לכל מערכת יש את מודל הנתונים שלה, וכאשר אתה מדבר על מגוון רחב של מערכות שצריכות לדבר יחד, זה נהיה מורכב. צריך לצור מכנה משותף, שפה משותפת, בין כל המערכות. יש לנו כלים שיודעים לעשות זאת על ידי תרגום בין מודולים שונים של מערכות. למשל יש מודל נתונים שמתאים לטנק כמערכת, יש מודל אחר שהוא מתאים למערכת של קואליציה ויש רכיבי תוכנה שמאפשרים תרגום שקוף של הנתונים ממערכת של הטנק לזו של הקואליציה".
מה האתגרים בתקשורת בין מכונות?
"המוצר שלנו התפתח מתוך תחום הרובוטיקה. מדובר על ארכיטקטורה שמתאימה לתקשורת בין מכונות , גם ללהקות. ברובוטים, אתה לא יכול לחקות את הצורה בה בני אדם מתקשרים. בין מכונות יכולה להיות רק אמת אחת. עוד היבט הוא הסטנרטיזציה. יש לך כל כך הרבה מערכות הפעלה לנייד, למחשב, לשרת. בגלל שאין הומוגניות בין סוגי החומרה והמערכות אתה צריך שכבה מקשרת שתדע לשלב את כולם יחד. אמנם בתחום הכלים הלא מאוישים יש את תקן JAUS, אבל הוא לא פותר את כל האתגרים של התקשורת בזמן אמת. השכבה המקשרת שלנו מספקת מסגור לנתונים בצורה כזו שאתה לא צריך להתעסק עם תווך התקשורת, אלא עם יישויות המידע.
"בנוסף לסטנדרטים, יש גם הרבה שפות תכנות. אבל בעתיד השפות יתבססו על מספר character set עיקריים כמו XML או DDS. אם אתה מסתכל על ארה"ב למשל, ה- UAS Control Segment (UCS) הולכת להיות הארכיטקטורה המרכזית של הצבא האמריקאי. אותו דבר קורה בצבא הבריטי עם Generic Vehicle Architecture (GVA) . , זה תהליך שקורה בכל הצבאות בעולם.
"גם ביישומים תעשייתים ומסחריים רוצים להרחיב את יכולות ה-IT לזמן אמת. הרבה יישומים צבאיים יעברו למוצרי מדף בעולם האזרחי. אחת הדוגמאות ליישום זמן אמת בתעשייה הוא תחום שנקרא "אחזקה חזויה" (predictive maintenance) המאפשר לחזות באמצעות מגוון טכנולוגיות בעיות לפני שהם מתרחשות ופוגעות בלקוחות החברה. במקרה של טורבינות רוח, אחת התקלות הנפוצות היא תקלה בגיר, אם ניתן יהיה לנטר את נתוני הטורבינה בזמן אמת, יהיה אפשר לתקן את הגיר לפני שהוא נשבר.
מה השינויים הטכנולוגיים הצפויים בעתיד?
"אחת המגמות היא שמערכות משובצות יחליפו את המחשבים האישיים. נראה יותר מחשוב ממוקד מטרה שיהיה מוטמע בחיי היום יום. מגמה נוספת תהיה מכונות שאפשר לתקשר אתן ולפנות אליהן. זה יאפשר את 'האינטרנט של הדברים' שהכל מחובר להכל. המחשב יתקשר עם הרכב , עם הסלולארי ועם כל התקן שתשתמש בו.
עוד מגמה תהיה דרישה ליעילות אנרגטית מהתוכנה. כלומר, ככל שהתוכנה יעילה יותר, כך היא צורכת פחות משאבי עיבוד ופחות אנרגיה. שאלות כמו כמה מחזורי מעבד?, כמה ליבות?, כמה מעבדים אתה משתמש?, כל אלו מצביעות על יעילות ברמת התוכנה. היה לנו ניסיון כזה עם מערכת ה-Blue Force Tracking של הצבא האמריקאי. הם רצו לשדרג גרסה, ובעזרת הארכיטקטורה שלנו הם הצליחו להוריד את כמות השרתים של המערכת בצורה משמעותית. כמות השרתים היא עוד פרמטר שקובע את צריכת האנרגיה הכללית של המערכת. היעילות של הפתרון שלנו בהעברת נתונים מתאים לתפישה זו. כיוון נוסף בהקשר זה הוא עולם הניידות, אם אתה עובד עם מכשיר סלולארי, צריך לוודא שהוא משתמש בכמה שפחות משאבים.
