ISO 26262: המדריך המלא

מהו ISO 26262? מדוע יש צורך ב-ISO 26262?

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

תקן ISO 26262 היה הנורמה הבינלאומית הראשונה שעסקה בבטיחות של מערכות חשמליות/אלקטרוניות/ניתנות לתכנות. הוא הוכרז בשנת 2011 על ידי הארגון הבינלאומי לתקינה (ISO), אך הוא מושרש בתקן IEC 61508, שיצא לאור בשנת 1998.

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

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

למידע נוסף אודות תקן זה, עיינו בהנחיות לתקן ISO 26262.

מה ההבדל בין IEC 61508 ל-ISO 26262?

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

האם ISO 26262 הוא חובה?

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

חלקים מ-ISO 26262

תקן ISO 26262 מורכב מ-שנים עשר חלקים, כל אחד מתייחס לרמה שונה של מחזור חיי המוצר:

Pחלק 1: אוצר מילים

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

Pחלק 2: ניהול בטיחות פונקציונלית

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

Pחלק 3: שלב הקונספט

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

Pחלק 4: פיתוח מוצר ברמת המערכת

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

Pחלק 5: פיתוח מוצר ברמת החומרה

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

Pחלק 6: פיתוח מוצר ברמת התוכנה

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

Pחלק 7: ייצור, תפעול, שירות, הוצאה משימוש

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

Pחלק 8: תהליכי תמיכה

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

חלק 9: ניתוחים מכווני ASIL (Automotive Safety Integrity Level) ומכווני בטיחות

חלק 9 מכסה פירוק ASIL, קריטריונים לדו-קיום של רכיבים, ניתוח כשלים תלויים וניתוחי בטיחות.

חלק 10: הנחיות בנושא ISO 26262

חלק 10 הוא סקירה של ISO 26262 המורחבת במידע נוסף. המטרה היא לשפר את ההבנה של חלקים אחרים ושל ISO 26262 בכלל.

Pסעיף 11: הנחיות ליישום התקן על מוליכים למחצה

חלק 11 מספק מידע מפורט לתמיכה ביצרני מוליכים למחצה ובקניין רוחני (IP) של סיליקון. מטרתו להתמודד עם האופן שבו ספקי IP ומשלבים צריכים לשתף פעולה.

חלק 12: התאמת ISO 26262 לאופנועים

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

ISO 26262 לעומת ISO PAS 21448 (SOTIF)

ISO 26262 אינו מכסה את כל תחומי הבטיחות התפקודית. חסרים בו סעיפים המוקדשים, למשל, לשימוש לרעה או לנהיגה אוטומטית. ISO PAS 21448 (SOTIF) הוצג כדי להשלים פערים אלה. הייתה תוכנית לכלול אותו ב-ISO 26262 כסעיף ארבעה עשר, אך בסופו של דבר הוא פורסם כמסמך נפרד.

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

מהו ASIL?

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

קיימות ארבע רמות סיכון ASIL: A, B, C ו-D. קיימת גם רמה חמישית – MQ, שהיא רמה שאינה מסוכנת. ASIL מ-A עד D משמעה שקיימת רמה כלשהי של סיכון בלתי קביל במערכת, ונדרשים מאמצי FUSA מסוימים כדי להגביר את השליטה במצבים לא רצויים.

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

בקצה השני של ספקטרום רמות הסיכון נמצא QM, ראשי תיבות של "Quality Management" (ניהול איכות). הוא מייצג את רמת הסיכון הנמוכה ביותר, כלומר אין סכנה automotive, או במילים אחרות, אין דרישות שיש להבטיח במסגרת ISO 26262.

כיצד לקבוע את רמת ASIL עבור תוכנה לרכב?

ה-ASIL נקבע באמצעות הערכת סיכונים וסכנות (HARA), הכוללת הערכה של חומרה, חשיפה ושליטה בתרחיש הפעלת הרכב.

האם כדאי לבצע פירוק ASIL?

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

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

Dסכמות פירוק בהתאם ל ISO26262

אסטרטגיית הפירוק מתוארת ב-ISO 2626-9:2018 סעיף 5. בהתאם ליעד הבטיחות הגבוה ביותר, הארכיטקט יכול ליישם אסטרטגיות פירוק ASIL שונות לתכנון המערכת, תוך התחשבות בטכנולוגיות הנדרשות ובשיטות העבודה המומלצות.

דוגמה:

פיתוח של רכיבים מפורקים צריך להיעשות, לכל הפחות, בהתאם לדרישות ASIL לאחר ביצוע הפירוק. עם זאת, קיים חריג אחד בנוגע לרמת החומרה. ערכי יעד להערכת המדדים הארכיטקטוניים של החומרה והערכת הפרות של יעדי בטיחות עקב כשלי חומרה אקראיים צריכים להילקח מ-ASIL גנרי (לפני פירוק (ISO26262-9:2018, 5.4.11))

הפירוק (Decomposition) חייב לקחת בחשבון את ההיתכנות הטכנית. לדוגמה, דרישת ASIL D שהוקצתה לפונקציונליות כלשהי המבוצעת על ידי ECU, אינה יכולה להתפרק כ-ASIL QM(D) עבור ה-ECU ו-ASIL D(D) שיוקצה ל-Watchdog פשוט (הפועל כמנגנון בטיחות), שכן ה-Watchdog עשוי להיות בלתי מספק כדי לכסות את כל מצבי הכשל הרלוונטיים של המיקרו-בקר.

איומי פירוק

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

שנית, פירוק לא יתבצע אם לא מובטחת עצמאות מספקת. כלומר, לא קיימים כשלים מסיבה משותפת ומובטחת חופש מהפרעות בין המרכיבים המפורקים. כדי להבטיח זאת, יש לבצע ניתוח של כשלים תלויים בהתאם ל-ISO 26262-9:2018, סעיף 5.

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

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

הזדמנויות הנובעות מפירוק ASIL

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

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

יתרה מכך, ניתן להשיג חיסכון משמעותי בעלויות בעת שימוש בפירוק. במיוחד כאשר פירוק ASIL מבוצע כך שרוב התוכנה מסווגת כ-QM (Quality Managed) או ASIL A/B במקום ASIL C או D. היתרון יגדל עוד יותר כאשר החלק בתוכנה הכפוף לשינויים תכופים יהיה בעל ASIL נמוך. ארכיטקטורת בטיחות טובה מאופיינת בכך שרק חלק קטן מהתוכנה, שאינו משתנה בתדירות גבוהה, מפותח בהתאם לרמות ASIL גבוהות.

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

כיצד להשיג עמידה בתקן ISO 26262?

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

למטרה זו, תקן ISO 26262 מציג את אמצעי האישור (Confirmation Measures), המחולקים לשלוש קטגוריות:

• סקירת אישור– נוגע ליעדי תוצר העבודה (קונספט בטיחות פונקציונלית, תכנון ארכיטקטורת תוכנה)
• ביקורת– מכסה את התהליך המיושם ביחס ליעדי התהליך (ISO 26262)
• הערכה– מתעמק בפריט או במאפיינים של רכיב ביחס ליעדי התהליך (Body Control Module)

כיצד לבצע סקירת אישור לפי ISO 26262?

בעת פיתוח מוצר בהתאם ל-ISO 26262, יש לקחת בחשבון פעילויות נוספות כדי לעמוד בדרישות התקן. אחת מהן היא תהליך אימות מוגדר היטב, שמאפייניו משתנים בהתאם ל-ASIL שהוקצה. התקן מציג צורה ספציפית של סקירה הידועה כסקירת אישור (confirmation review) כדי לצמצם את הסיכון. עם זאת, כיצד לעשות זאת, באיזה שלב ובאילו אמצעים, אינו כה ברור ותלוי בגורמים שונים כמו ה-ASIL של הפרויקט. צורה ספציפית של סקירה הידועה כסקירת אישור נדרשת גם בתעשיית הרכב, שבה מיושמת בטיחות תפקודית.

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

מדוע מבוצעת סקירת אישור?

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

מהו סקירת אישור?

ההגדרה הכלולה בתקן היא פשוטה:

“אישור שתוצר עבודה רלוונטי לבטיחות מספק ראיות מספקות ומשכנעות לתרומתם להשגת בטיחות פונקציונלית בהתחשב במטרות ובדרישות המתאימות של ISO 26262”

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

מה שמייחד את ה-CRs הוא העצמאות הנדרשת. תקן ISO 26262 מתאר ארבע רמות של עצמאות המתוארות להלן:

כיצד מתבצעת סקירת האישור?

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

זיהוי תוצרי עבודה הדורשים סקירת אישור

לתשובה, עליך לעיין ב-ISO 26262 חלק 2. יש להדגיש שוב, שהתשובה לשאלה זו תלויה ב-ASIL הגבוה ביותר בפרויקט הנתון, אך גם מוגבלת על ידי היקף הפרויקט. לדוגמה, קונספט הבטיחות הפונקציונלית (Functional Safety Concept) בדרך כלל מחוץ להיקף עבור פרויקטי תוכנה המפותחים כרכיב בטיחות מחוץ להקשר (SEooC).

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

זיהוי מי יהיה אחראי לסקירת האישור

יש למנות אדם או קבוצה האחראים לביצוע סקירת האישור (confirmation review). הארגון יוודא שלאדם זה יש את הסמכות, הכשירות וההסמכה לבצע CR. ניתן למנות עוזר אחד או יותר לתמיכה בביצוע סקירת האישור. אנשים אלה עשויים לחסר עצמאות ממפתחי הפריט, הרכיבים או תוצרי העבודה הרלוונטיים, אך העצמאות שלהם תהיה לפחות I1, כמוגדר בטבלה 1, והסוקר יעריך את תרומתם כדי להבטיח שתינתן חוות דעת בלתי משוחדת.

קביעת מה יהווה את הראיות לסקירת האישור

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

תכנון מתי לבצע את סקירת האישור

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

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

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

כיצד לבצע ביקורת בטיחות פונקציונלית (ISO 26262) לתוכנה?

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

הוא מתחיל בקביעה מי הוא האדם האחראי על ביקורת תהליכים, עם קביעת רמת עצמאות הנדרשת לאמצעי אישור מסוים שנקבעת על ידי רמת שלמות בטיחות רכב (ASIL) ספציפית.

העצמאות הארגונית הבאה נדרשת לצורך ביצוע ביקורת ISO 26262:

• עבור QM ו-ASIL A, אין דרישה לביצוע ביקורת בטיחות פונקציונלית.
• ASIL B דורש את רמת העצמאות הנמוכה ביותר (I0) של ביקורת, שתבוצע על ידי אדם שאינו מעורב ביצירת תוצר עבודה כלשהו מחוץ לפרויקט.
• ASIL C דורש שביקורת ברמת עצמאות 2 (I2) תבוצע על ידי אדם בלתי תלוי בצוות האחראי ליצירה, למשל, שאינו כפוף לאותו מנהל.
• ASIL D דורש ביקורת ברמת העצמאות הגבוהה ביותר (I3) שתבוצע על ידי אדם בלתי תלוי במחלקה האחראית על היצירה. באופן אידיאלי, גוף ביקורת נפרד מחברה אחרת.

לאחר קביעת רמת העצמאות, כל פריט ISO 26262 שנמצא בהיקף הביקורת מוערך מנקודות מבט שונות, כולל:

1. הערכה של התהליך המיושם מול הגדרותיו או מפרטיו בתוכנית בטיחות.
2. הערכה של הטיעונים שהוצגו ליישום התהליך.
3. הערכת תוצרי העבודה (בפרויקטים שונים).
4. המלצות לשיפור (במקרה של אי-עמידה בדרישות).

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

ומה לעשות עם תוצאות הביקורת?

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

• נקודות של אי-התאמה מהותית
• נקודות של אי-התאמה משנית
• פעולות שיש לנקוט כדי לשפר או לפתור פערים ואנומליות שזוהו.

יש להתייחס להמלצות לשיפור בשלב הבא ואפשר לפתור אותן על ידי הגורמים האחראים.

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

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

כדאי גם לציין כי ביקורת ISO 26262 והערכת Automotive SPICE יכולות להתבצע באופן מתואם כדי למנוע כפילות עבודה וחוסר עקביות. לשם כך, מוצג מודל הערכת תהליכים (PAM) מורחב.

כיצד לבצע הערכת ISO 26262?

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

ארגון ההערכה

אחת השאלות הנוגעות להערכה היא:מתי יש לבצע זאת?יש לנו כאן שני היבטים, הראשון הוא כאשר הדבר נדרש על ידי תקן ISO. הוא מומלץ החל מ-ASIL B וחובה עבור ASIL C ו-D. מכיוון שהערכת בטיחות פונקציונלית היא אחד מאמצעי האישור, קיימת גם רמת עצמאות נדרשת בהתאם ל-ASIL.

• עבור QM ו-ASIL A, אין המלצה בעד או נגד ביצוע ההערכה.
• ASIL B דורש עצמאות I0, ולכן ההערכה צריכה להתבצע על ידי אדם אחר שאינו מעורב בפרויקט וביצירת תוצר העבודה.
• ASIL C דורש עצמאות I2, ולאחר מכן ההערכה תבוצע על ידי אדם בלתי תלוי בצוות האחראי ליצירת תוצר העבודה.
• ASIL D דורש עצמאות I3, כלומר ההערכה תבוצע על ידי אדם שהוא בלתי תלוי מבחינת ניהול ומשאבים במחלקה האחראית על יצירת תוצר העבודה, אשר יכול להיות, למשל, חברה חיצונית.

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

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

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

היקף ההערכה

היקף הערכת הבטיחות הפונקציונלית יכלול:

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

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

דוגמה לאג'נדה של בטיחות פונקציונלית ניתן למצוא ב-ISO26262-8 נספח D.

תוצאת ההערכה

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

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

הסמכת כלים לפי ISO 26262

הסמכת כלים (Tool Qualification) חיונית להשגת עמידה בתקן ISO 26262. מטרתה להבטיח שכל הכלים המשמשים בפרויקט מהימנים, שכל תקלה מזוהה, ושכל בעיה שעולה ניתן לטפל בה. חשוב לקחת בחשבון את כל הכלים המעורבים בתהליך הפיתוח, כולל אלו המשמשים בעקיפין.

כיצד להסמיך כלי תוכנה בהתאם ל-ISO 26262?

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

זהו את הכלי

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

הערכת סיכונים

גורמי ה-TCL (Tool Confidence Level) מדורגים מ-TCL1 ועד TCL3. TCL1, שמשמעותו שבשלבים הבאים שיטות הסמכה אינן בהכרח ישימות, כך שההסמכה עצמה אינה נדרשת. TCL 2 ו-TCL 3, במקרים אלו מניחים שהתנהגות הכלי אינה צפויה במלואה, ויש ליישם שיטות הסמכה מסוימות. ה-Tool Confidence Level נובע משילוב של Tool Impact (TI) ו-Tool Error Detection (TD).

Tool Impact – הוא מקדם לקביעת השאלה האם הכלי יכול להציג שגיאות או להיכשל בזיהוין, שגיאות שעלולות להשפיע על התכונות הקשורות לבטיחות של המוצר הסופי. אם הפרה של דרישת בטיחות אינה אפשרית, יש לבחור ב-'TI 1'. אחרת, השפעת הכלי היא 'TI 2'.

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

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

הסמכת הכלי

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

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

׳הערכת תהליך הפיתוח׳ היא השיטה הדורשת ניתוח מפורט של תהליך פיתוח הכלי. לעיתים ספק הכלי מספק ראיות הסמכה מסוג זה יחד עם הכלי.

השיטה 'אימות כלי התוכנה' מומלצת לעמידה גבוהה ב-ASIL כמו ASIL C, או D. היא מבוססת בעיקרון על פיתוח בדיקות המכסות את כל מקרי השימוש הקשורים לבטיחות של כלי התוכנה. על פי ISO 26262-8, היא יכולה להיות מסופקת גם על ידי ספק הכלי.

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