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

סקירת המקרה

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

תסמינים

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

אילוצים

• התדירות נמוכה, וקשה לזהות את תנאי השחזור מהיומנים בלבד.
• מקור הבעיה יכול היה להיראות ב-SDK של המצלמה, ב-NIC, במתג הרשת או במימוש היישום.
• היה צורך לבודד את הבעיה מבלי להתרחק מתנאי תצורת הייצור.

מה בחנו

• כדי לשלול תחילה גורמי עצירה בתוך היישום, בדקנו עיכובי עיבוד וחריגות.
• צפינו ב-Retransmission ובהפרשי הזמנים באמצעות לכידת מנות (packet capture).
• בדקנו האם אפשרויות ה-TCP וצורת זמן ההמתנה לשידור חוזר תואמות את התסמינים.

כיצד בודדנו את הבעיה

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

כיצד שיפרנו

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

שירותים הקשורים למקרה זה

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

מאמרים קשורים

צרו איתנו קשר

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