מטוס מדגם B738, של חברת OneClick, המריא מבוקרשט לכיוון נתב"ג. הצוות עצר טיפוס בגובה 8,000 רגל, הודיעו על תקלת מד מהירות בצד של הקברניט וחזרו לנחיתה, לאחר כ-35 דקות מההמראה. נחתו בשלום. המטוס הוחזר לשירות בתוך יממה.

תקלת מד מהירות היא נדירה ומפתיעה. אם פועלים על פי הספרות והבד"ח אפשר להסתדר איתה. יש לה פעולות מידיות הנעשות מהזיכרון. ל-NNC של תקלה זו במטוסי 737 יש מטרה (Objective) והיא לנסות לזהות מד מהירות אמין או להשתמש בטבלאות של טיסה עם מד מהירות לא אמין הנמצאות ב-QRH. יש מצבים בהם תקלת מד המהירות היא ברורה, לדוגמה מצב בו לפתע מד מהירות מסוים חורג משמעותית מהערכים הסבירים לאותו שלב של הטיסה. לעיתים מדי המהירות מתחילים לפתוח מרווח ביניהם ויש נטייה ל-PF לטוס על פי מד המהירות שלו, עד ש"יורד האסימון" שמשהו לא כשורה. באירוע המדובר, ככל הנראה הצוות זיהה די מידית שמד המהירות של הקברניט תקול. במקרה כזה ההנחיה היא לטוס על פי מד המהירות האמין, של הק"ר (עם גיבוי של מד המהירות על מכשיר החירום). אלא מה, במצב של מד מהירות לא תקין, גם אם זוהה, לא ניתן לנטרל אותו ולמנוע ממנו לתת אינדיקציות שגויות למכשירי מטוס אליהם הוא מחובר. לא תמיד הצוות יודע לנתח את כל המשמעויות, הן לא רשומות ב-NNC ולעיתים עלול להיות מופתע. לדוגמה- לעיתים (אני לא אומר שזה המצב בתקלה זו) יש מד מהירות אחד שעל פיו נקבעות מגבלות המדפים. אם מד המהירות הזה נותן קריאה גבוהה מהאמיתית, יש מצב שהמדפים לא ירדו למצב הרצוי, עקב תכונת הקלת העומס (Load Relief). יכולות להתקבל התראות של מעבר מגבלת מהירות ועוד. צוות חייב להיות מוכן להתמודד עם הפתעות ולנטרל אותן. גם כאשר אנחנו מתאמנים בסימולטור על תקלת מד מהירות והצוות אמור להיות מוכן אליה, לעיתים נתקל בהפתעות.