עיצוב לצורך בדיקה

פרסומת
X-ray_Promo1


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

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

פרסומת

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

היתרונות של עיצוב לצורך בדיקה

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

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

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

בנוסף לסיוע ישיר לצוות הפיתוח, Design for Testability הוא גם מאוד מועיל עבור צוות QC Validation and Verification. אספקת כלי הפקודה והרישום של תוכנת ה-QC מאפשרת להם לבדוק במהירות רבה יותר את המכשיר ולנתח את הנתונים כדי לאשר אם המכשיר עובר אימות.

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

עיצוב לבדיקה יכול להזניח כי הוא לא "מבריק" כמו משימות אחרות. ישנן סיבות מוחשיות יותר לכך שצוות עשוי לבחור שלא להשתמש ב-Design for Testability.

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

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

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

סיכום

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

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

ייתכן שהתוכנית אינה עיצוב לבדיקת כושר, אבל התכנון צריך תמיד לשקול עיצוב לבדיקת יכולת.

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





קישור לכתבת המקור – 2024-04-06 00:27:06

Facebook
Twitter
LinkedIn
Telegram
WhatsApp
Email
פרסומת
X-ray_Promo1

עוד מתחומי האתר