עד שנת 2000, תעשיית הרכב נשלטה בעיקר על ידי יצרני הרכב המסורתיים. החלק העיקרי של מכוניות היה בעיקר פח ומנוע. ה"מוח" של המכונית היה מורכב מ-20-50 ECUs. ,ECU Electronic Control Unit, זהו בעצם מחשב עצמאי עם מערכת הפעלה, קלט/ פלט ועיבודים. אוסף ה- ECUs מנהלים את המכונית ואביזרי העזר באמצעות תקשורת בין ה-ECUs השונים, ובין הנהג באמצעות תצוגת מידע או קבלת הוראות ידניות.
החל משנת 2000 המכוניות הפכו בהדרגה להיות מערכת ממוחשבת על גלגלים, המורכבת מ-100 ECUs לפחות. המכוניות המודרניות מכילות אוסף רב של טכנולוגיות; הקישוריות לאינטרנט מאפשרת מחד פיתוח אלפי אפליקציות לנוחות הנהג, אך מאידך פותחת פתח לבעיות בטיחות ואבטחה. כל ECU מסוגל להפריע לנהג ואף לכבות את מנוע המכונית. התקלות האלקטרוניות יכולות להיות משהו פשוט כמו נעילת דלת המכונית, דרך דברים חמורים כתוצאה מתקלת אפליקציה שמרוקנת את הבטרייה ועד להשתלטות עוינת של האקרים על מכוניות תמורת כופר. כשמדובר במערכות המשולבות ברכב – תקלות יכולות להרוג, את הנהג או מישהו בסביבתו. בהתאם לכך המכונית המודרנית מכילה תוכנה המשדרגת את תכונות המכונית בצד תוכנה שמטרתה להבטיח את בטיחות הנהג ואבטחת המכונית.
המכוניות המודרניות כיום מכילות כמאה מיליון שורות קוד! תוך מספר שנים קטן, צפוי מספר שורות הקוד במכונית להגיע ל-200 מיליון עד 300 מיליון שורות קוד. זהו מספר בלתי נתפס. לשם השוואה, מטוס קרב F22 מכיל פחות מ-2 מיליון שורות קוד ומטוס בואינג 787 מכיל 14 מיליון שורות קוד.
מקור: מאמר שפורסם ב-IEEE
במאמר שפורסם בלינקדאין, על ידי Andrea Busnelli מופיעה טבלה הממחישה את מספר שורות הקוד במכונית יחסית למטוס, ספינת חלל או מכשירים מרובי שורות קוד אחרים. טבלה זו עובדה מתוך אותו מאמר שפורסם ב-IEEE.
תודו שהדבר מדהים, נכון?
היום רכב הוא מכלול נע, הכולל הרבה מחשבים, הרבה סוגי רשתות, מולטימדיה, וכולם יחד מהווים מערכת של מערכות (System of Systems). חלק יגידו שהדבר מהפכני, ויש שיגידו שזאת מהפכה שהופכת את המצב למורכב יותר. נוצר מצב חדש שצריך להתמודד איתו: מתקינים גוגל במכונית ומאבדים שליטה על מה שקורה, לעומת המצב הקודם שבו השליטה על מה שקורה ברכב הייתה בידי הנהג.
שוק הספקים לתעשיית הרכב משתנה במהירות. ספקים לתעשיית הרכב המסורתי מוצאים את עצמם לא מעודכנים. למשל, ספק של מנעולים לרכב; בעבר, ההתמודדות הייתה מכאנית-אלקטרונית; היום צריך להתמודד עם נושאים כמו הצפנה יותר מאשר מנעולים לרכב.
המודל העסקי משתנה, עד כדי כך שאפשר להרוויח מהתוכנה ברכב יותר מאשר מהרכב עצמו. העלות של התוכנות היום היא 60% מעלות הרכב; הרווחיות מהתוכנה ברכב היא 90% מהרווח הכולל במכונית. יצרני הרכב עוברים למודל עסקי של מתן שירותים באמצעות התוכנות. יש ספקים שמוכרים מוצרים שהם תוכנה בלבד, אותם אפשר להתקין בדשבורד והם לגמרי משולבים במכונית.
אליה וקוץ בה..
במקום שיש המון תוכנה, יש גם פוטנציאל לתקלות מרובות. האתגר הוא לא רק לפתח מוצר איכותי ללא תקלות אלא לוודא שהאינטגרציה של המוצר עם מוצרי תוכנה אחרים שמותקנים ברכב תעבוד בצורה חלקה.
איך מתמודדים עם האתגר?
ליצרני הרכב מאז ומתמיד היו דרישות מחמירות מהספקים שלהם. כיוון שאיכות התהליכים של פיתוח המוצר, משפיעה באופן ישיר על איכות המוצר הסופי, יצרני הרכב דורשים מהספקים שלהם הוכחה הן לאיכות המוצר והן לאיכות התהליכים שיצרו אותם.
איך בודקים את איכות התהליכים?
איגוד יצרני הרכב, VDA, יצר את מודל Automotive SPICE. המודל הוא מעין תקן בינלאומי למדידה של רמת היכולות של צוות הפרויקט המפתח מוצר לרכב. רמת היכולת נעה בטווח של 0-5 לכל נושא. המודל מדריך את צוות הפרויקט כיצד לשדרג את תהליכיו באמצעות הנחייה באילו פרקטיקות להשתמש בתהליכי פיתוח, ניהול פרויקט ואיכות. המודל מתווה דרך לעלייה מרמת יכולת נוכחית לרמת יכולת גבוהה יותר, וכך הוא מהווה אסטרטגיה לשיפור ביצועים על ידי מיסוד תהליכים יעילים ואפקטיביים.
חברות הרכב מודעות לכך, שלא תמיד לספקים שלהם יש את רמת הבשלות הנדרשת. לכן, חברות הרכב דורשות מספקיהן להראות להם תוכנית לשיפור תהליכים ולאורך זמן להגיע לרמת הבשלות הנדרשת. בדרך כלל רמה 2 או 3.
את מי זה מעניין?
את הספקים לתעשיית הרכב זה אמור מ-א-ד לעניין !
יצרני הרכב, בוחנים מספר ספקים כאשר נדרשת להם טכנולוגיה מסוימת. בהינתן שני ספקים בעלי יכולות טכנולוגיות זהות, אך לספק אחד יכולת מוכחת שהוא עומד בתקן ASPICE ולספק השני אין הוכחה שכזו, הספק שייבחר הוא ללא ספק הספק שהטמיע ASPICE.
מודל ה-ASPICE עצמו, ניתן להורדה בחינם מהאינטרנט; כל חברה יכולה ללמוד בעצמה את המודל. לחברות הזנק, בדרך כלל אין מנהל איכות, וגם כאשר יש מנהל איכות – נדרש זמן רב בלימוד המודל. ניתן לקצר את זמן הלימוד באמצעות הסתייעות ביועצים חיצוניים.
בארצנו, קיימת חברת ייעוץ אחת – OK יועצים לניהול המתמחה בליווי ארגונים במסעם להטמעת המודל. ניתן להסתייע גם בחברות ייעוץ בינלאומיות, בעלות גבוהה יותר, ובזמינות נמוכה יותר.
כדי להוכיח לעולם שאכן צוות הפרויקט עובד לפי ASPICE יש ליצור קשר עם אחת מחברות הייעוץ האירופאיות שמוסמכת לעשות מבדקים לפי המודל ולאשר את רמת הארגון.
בהצלחה !
לאחר שפרסמתי את המאמר קיבלתי מספר תגובות מעמיתים שהביאו את נקודת המבט הבאה:
במכוניות מודרניות, במיוחד במכוניות יוקרה, יש מספר אינסופי של אופציות ושילובים שונים של קונפיגורציות בתחומים שונים כגון: ניווט, נוחות, מערכות בידור מבוססות מידע (Infotainment) , מערכות בטיחות, התרעה ועוד מעט גם בנהיגה עצמאית בכלי הרכב. יצרני הרכב מנסים לחזות את צרכי הלקוחות העתידיים ולכן מעמיסים אופציות רבות ומגוונות שבחלק גדול מהמקרים הן לא בשימוש. התוצאה היא קוד עצום, שבמקרים מסוימים לא נבדק דיו כדי להבטיח שאכן הוא איכותי.
לעומת זאת, במטוס – התוכנה כולה היא פונקציונאלית ובטיחותית. דרישות האיכות ובטיחות של יצרני המטוסים הם כה גבוהות, שכל הקוד הכתוב נסקר בקפידה. תקני התעופה, בין היתר, אוסרים על קיום "קוד מת", דהיינו שורות קוד שמונחות סתם כך בלי שימוש;
תודה למגיבים, ואיזה כף שמדובר במאמר אינטרנטי שניתן לשינוי ולא במאמר מודפס.
תודה ושנה טובה !
