תארו לעצמכם את הסצנה הבאה, שקורית בהרבה פרויקטים. המכשיר מתאפס פעם ביום בשטח. צוות התוכנה בודק את הקוד ואומר: "הקוד תקין, זו בעיה בחומרה". צוות החומרה מודד את הכרטיס ואומר: "הכרטיס תקין, זה באג בתוכנה". מנהל הפרויקט קובע פגישה. אחרי שבועיים מתברר שהבעיה היא שניהם: נפילת מתח קצרה בזמן שידור, שהקוד לא מטפל בה.
אף אחד לא עשה עבודה גרועה. הבעיה היא שהבאג ישב בדיוק על הקו שמפריד בין שני הצוותים, ואף אחד מהם לא ראה את התמונה המלאה.
איפה באמת יושבים הבאגים הקשים
באגים שנמצאים כולם בתוך הקוד, או כולם בתוך המעגל, נמצאים מהר יחסית. הבאגים שלוקחים שבועות הם כמעט תמיד באגים של התפר:
- רעש שנראה כמו באג. קריאות חיישן קופצות. האם זה הקוד, או מסלול חשמלי שעובר ליד מקור מיתוג?
- באג שנראה כמו רכיב תקול. תקשורת נופלת. האם הרכיב פגום, או שהגדרת ה-SPI בקוד לא מתאימה לרכיב?
- תזמון שעובד על השולחן ונשבר בשטח. כבל ארוך יותר, טמפרטורה אחרת, ופתאום הודעות הולכות לאיבוד.
- צריכת חשמל. הסוללה מחזיקה יומיים במקום חודש. החומרה? ה-Firmware (קושחה) שלא מכניס את המעבד לשינה?
כדי לפתור באג כזה צריך לדעת בו-זמנית מה קורה בפין, בטיימר, בערוץ ה-DMA ובאוסצילוסקופ. כשהידע הזה מפוצל בין שני אנשים, כל צעד באבחון דורש תיאום.
שתי דוגמאות מהשטח
יחידת חיישן IMU לתעשייה הביטחונית. בשלב הרמת הכרטיס החיישן לא הגיב בכלל. מצד הקוד, היו שתי בעיות שנראו זהות לגמרי: אין תשובה מהחיישן. בפועל, אחת הייתה הגדרת SPI שגויה כברירת מחדל, בקוד. השנייה הייתה מחבר שחווט הפוך, בחומרה, בגלל שרטוט בדאטה-שיט שמציג את הרכיב במבט מלמטה. מהנדס תוכנה לבד היה מחפש בקוד. מהנדס חומרה לבד היה מודד את המחבר. מי שעשה את שניהם מצא את שתי הבעיות. לפרויקט המלא.
כרטיס בקרה עם שלושה ערוצי RS422 מהירים. התקשורת השתבשה, והחשד הראשון היה הקוד. הבעיה הייתה בכבילה: קו שידור שפוצל לשני מחברים בלי סיום (termination). מי שמכיר גם את הפרוטוקול וגם את הפיזיקה של הקו מזהה את זה מהר. לפרויקט המלא.
מה עוד מרוויחים כשמהנדס אחד אחראי על הכול
- החלטות תכן טובות יותר. כשמי שמתכנן את הכרטיס יודע מה הקוד יצטרך, הוא בוחר את הפין הנכון לטיימר, משאיר ערוץ DMA פנוי ומוסיף נקודות בדיקה במקומות הנכונים. חלק גדול מהבעיות לא נוצר מלכתחילה.
- אין מסמך ממשק שמתיישן. בין שני צוותים צריך מסמך שמתאר כל פין וכל רגיסטר, ומישהו צריך לעדכן אותו בכל שינוי. כשאותו אדם עושה את שניהם, הממשק פשוט עובד.
- אחריות אחת. כשמשהו לא עובד, יש כתובת אחת. אין "זו בעיה של הצוות השני".
- פחות פגישות, יותר עבודה. הזמן שהיה הולך על תיאום הולך על פיתוח, ואתם לא משלמים עליו.
מתי זה פחות מתאים
כדי שהתמונה תהיה הוגנת: כשמערכת גדולה מאוד, עם עשרות כרטיסים ומאות אלפי שורות קוד, היא צריכה צוות, ואי אפשר שאדם אחד יעשה הכול. גם אז, כדאי שבכל תת-מערכת יהיה מהנדס אחד שמבין גם את החומרה וגם את הקוד שלה, ושיהיה מישהו שרואה את התמונה המלאה.
לרוב המוצרים האלקטרוניים, כמו בקרים, מכשירים רפואיים ניידים, יחידות IoT, כרטיסי בקרה ומערכות בדיקה, מהנדס אחד שאחראי על החומרה ועל ה-Firmware הוא הדרך המהירה והזולה ביותר להגיע למוצר שעובד.
מה לשאול חברת פיתוח לפני שמתחילים
- מי יתכנן את הכרטיס, ומי יכתוב את הקוד? האם זה אותו אדם?
- כשתהיה בעיה בשילוב בין החומרה לתוכנה, מי אחראי לפתור אותה?
- האם אדבר ישירות עם המהנדס, או דרך מנהל פרויקט?
ב-ProtoMakers התשובה לשלוש השאלות היא אותו מהנדס. כך אנחנו עובדים.
נכתב על ידי רומן אלפרוביץ', מייסד ומהנדס ראשי ב-ProtoMakers.