מקינזי: חשיבה מחדש של תוכנה וארכיטקטורת אלקטרוניקה ברכב

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

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

עם זאת, ככל שהאלקטרוניקה והתוכנה הופכות חשובות יותר, גם רמת המורכבות שלהן עולה. קחו כדוגמה את המספר ההולך וגדל של שורות קוד (SLOC) הכלולות במכוניות מודרניות. בשנת 2010, לכמה כלי רכב היו כעשרה מיליון SLOCs; עד 2016, נתון זה גדל פי 15 לכ-150 מיליון שורות קוד. מורכבות דמוית מפולת גורמת לבעיות חמורות באיכות התוכנה, כפי שמעידים ביקורות רבות על מכוניות חדשות.

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

פתרון בעיה דחופה בתעשייה

ככל שתעשיית הרכב עוברת ממכשירים מונעי חומרה למכשירים מונעי תוכנה, הכמות הממוצעת של תוכנה ואלקטרוניקה ברכב עולה במהירות. כיום, התוכנה מהווה 10% מסך התכולה של מכוניות עבור סגמנט D או מכונית גדולה יותר (כ-1220 דולר). נתח התוכנה הממוצע צפוי לגדול ב-11%. ההערכה היא שעד 2030 התוכנה תהווה 30% מכלל תכולת הרכב (כ-5200 דולר). אין זה מפתיע שאנשים המעורבים בשלב כלשהו של פיתוח מכוניות מנסים להפיק תועלת מחידושים המאפשרים תוכנה ואלקטרוניקה.

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

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

מכוניות העתיד יעברו לפלטפורמה של יתרונות תחרותיים ממותגים חדשים.

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

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

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

בחינת עשר השערות לגבי ארכיטקטורה חשמלית או אלקטרונית עתידית

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

איחוד של יחידות בקרה אלקטרוניות (ECU) יהפוך לנפוץ יותר ויותר

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

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

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

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

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

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

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

• מחסנית מונעת זמן. בתחום זה, הבקר מחובר ישירות לחיישן או למפעיל, בעוד שהמערכות חייבות לתמוך בדרישות זמן אמת מחמירות תוך שמירה על זמן אחזור נמוך; תזמון משאבים מבוסס על זמן. מחסנית זו כוללת מערכות המשיגות את הרמה הגבוהה ביותר של בטיחות רכב. דוגמה לכך היא התחום הקלאסי של ארכיטקטורת מערכות פתוחות לרכב (AUTOSAR).
• מחסנית מונעת זמן ואירועים. מחסנית היברידית זו משלבת יישומי אבטחה בעלי ביצועים גבוהים עם תמיכה ב-ADAS וב-HAD, למשל. יישומים וציוד היקפי מופרדים על ידי מערכת ההפעלה, בעוד שיישומים מתוכננים בזמן. בתוך אפליקציה, תזמון משאבים יכול להתבסס על זמן או עדיפות. סביבת ההפעלה מבטיחה שיישומים קריטיים למשימה פועלים במיכלים מבודדים, ומפרידה בבירור יישומים אלו מיישומים אחרים ברכב. דוגמה טובה היא AUTOSAR אדפטיבית.
• מחסנית מונעת על ידי אירועים. ערימה זו מתמקדת במערכת המידע והבידור, שאינה קריטית לבטיחות. יישומים מנותקים בבירור מציוד היקפי, ומשאבים מתוזמנים באמצעות תזמון אופטימלי או מבוסס אירועים. הערימה מכילה פונקציות גלויות ונפוצות בשימוש: אנדרואיד, Linux Grade Automotive, GENIVI ו-QNX. תכונות אלו מאפשרות למשתמש ליצור אינטראקציה עם הרכב.
• ערימת ענן. הערימה הסופית מכסה את הגישה לנתונים ומתאמת אותה ואת תפקודי הרכב חיצונית. מחסנית זו אחראית על תקשורת, כמו גם אימות אבטחת יישומים (אימות) ומקימה ממשק רכב ספציפי, כולל אבחון מרחוק.

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

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

Middleware תפשט יישומים מחומרה

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

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

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

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

בטווח הארוך, תעשיית הרכב תפתח פתרונות חיישנים ייעודיים להפחתת מספרם ועלותם. אנו מאמינים ששילוב מכ"ם ומצלמה עשוי להיות הפתרון הפופולרי ביותר בחמש עד שמונה השנים הקרובות. ככל שיכולות הנהיגה האוטונומיות ימשיכו לצמוח, יהיה צורך בהחדרה של לידרים. הם יספקו יתירות הן בתחום ניתוח האובייקטים והן בתחום הלוקליזציה. לדוגמה, תצורת נהיגה אוטונומית של SAE International L4 (אוטומציה גבוהה) תדרוש בתחילה 360-XNUMX חיישני לידאר, כולל אלו שמותקנים מאחור לניווט בעיר ולראות של כמעט XNUMX מעלות.

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

חיישנים יהפכו לחכמים יותר

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

יידרש כוח מלא ורשתות נתונים מיותרות

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

"אתרנט לרכב" יעלה ויהפוך לעמוד השדרה של המכונית

רשתות הרכב של היום אינן מספיקות כדי לענות על צורכי התחבורה העתידית. קצבי נתונים מוגברים, דרישות יתירות עבור HADs, הצורך באבטחה והגנה בסביבות מחוברות והצורך בפרוטוקולים סטנדרטיים חוצי תעשיות יובילו ככל הנראה להופעתו של Ethernet לרכב. זה יהפוך למאפשר מפתח, במיוחד עבור אפיק נתונים מרכזי מיותר. פתרונות Ethernet יידרשו לספק תקשורת אמינה בין תחומים ולעמוד בדרישות בזמן אמת. זה יתאפשר הודות להוספת הרחבות Ethernet כגון Audio Video Bridging (AVB) ורשתות רגישות לזמן (TSN). נציגי התעשייה ו-OPEN Alliance תומכים באימוץ טכנולוגיית Ethernet. יצרניות רכב רבות כבר עשו את הצעד הגדול הזה.

רשתות מסורתיות כגון רשתות חיבור מקומיות ורשתות בקרים ימשיכו לשמש ברכב, אך רק עבור רשתות סגורות ברמה נמוכה יותר כגון חיישנים. טכנולוגיות כמו FlexRay ו-MOST, ככל הנראה, יוחלפו ב-Ethernet לרכב וההרחבות שלו AVB ו-TSN.

בעתיד, אנו מצפים שתעשיית הרכב תשתמש גם בטכנולוגיות אתרנט אחרות - HDBP (מוצרי רוחב פס עם עיכוב גבוה) וטכנולוגיות 10 ג'יגה-ביט.

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

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

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

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

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

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

רכיבים הניתנים לשדרוג יופיעו במכוניות שיתמכו בתקשורת דו-כיוונית

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

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

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

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

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

הערכת ההשפעה העתידית של תוכנת רכב וארכיטקטורה אלקטרונית

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

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

אנו רואים מספר צעדים אסטרטגיים עיקריים:

• הפרד מחזורי פיתוח רכב ופונקציות רכב. יצרני OEM וספקים ברמה XNUMX חייבים להחליט כיצד הם יפתחו, יציעו ויפרוס תכונות. הם חייבים להיות בלתי תלויים במחזורי פיתוח רכב, הן מנקודת מבט טכנית והן מבחינה ארגונית. בהתחשב במחזורי פיתוח הרכב הנוכחיים, חברות צריכות למצוא דרך לנהל חדשנות תוכנה. בנוסף, עליהם לשקול אפשרויות לשדרוגים ושדרוגים (כגון יחידות מחשוב) עבור ציים קיימים.
• הגדר ערך מוסף יעד לפיתוח תוכנה ואלקטרוניקה. יצרני ציוד מקורי חייבים לזהות תכונות מבדילות עבורן הם יכולים לקבוע אמות מידה. בנוסף, חיוני להגדיר בבירור את הערך המוסף היעד לפיתוחי התוכנה והאלקטרוניקה שלהם. כדאי גם לזהות אזורים שבהם יהיה צורך במוצרים ונושאים שיש לדון בהם רק עם הספק או השותף.
• קבע מחיר מפורש לתוכנה. כדי לנתק את התוכנה מהחומרה, יצרני OEM צריכים לחשוב מחדש על תהליכים ומנגנונים פנימיים כדי לקנות תוכנה ישירות. בנוסף להתאמה אישית מסורתית, חשוב גם לנתח כיצד ניתן לקשור גישה זריזה לפיתוח תוכנה לתהליך הרכש. זה המקום שבו הספקים (שכבה א', שכבה שניה ושכבה שלישית) ממלאים גם הם תפקיד קריטי מכיוון שהם צריכים לספק ערך עסקי ברור להצעות התוכנה והמערכות שלהם כדי שיוכלו לתפוס נתח גדול יותר מההכנסות.
• פתח דיאגרמת ארגון ספציפית עבור ארכיטקטורת האלקטרוניקה החדשה (כולל backends). תעשיית הרכב צריכה לשנות תהליכים פנימיים כדי לספק ולמכור מוצרי אלקטרוניקה ותוכנה מתקדמות. הם גם צריכים לשקול הגדרות ארגוניות שונות לנושאים אלקטרוניים הקשורים לרכב. בעיקרון, הארכיטקטורה "השכבתית" החדשה דורשת את השיבוש הפוטנציאלי של ההגדרה ה"אנכית" הנוכחית והכנסת יחידות ארגוניות "אופקיות" חדשות. בנוסף, יש צורך להרחיב את היכולות והכישורים של מפתחי תוכנה ואלקטרוניקה בצוותים.
• פיתוח מודל עסקי לרכיבי רכב בודדים כמוצר (במיוחד לספקים). זה קריטי לנתח אילו תכונות מוסיפות ערך אמיתי לארכיטקטורה העתידית ולכן ניתן להפיק רווחים. זה יעזור לך להישאר תחרותי ולתפוס נתח משמעותי מהערך בתעשיית האלקטרוניקה לרכב. לאחר מכן, יהיה צורך למצוא מודלים עסקיים חדשים למכירת תוכנות ומערכות אלקטרוניות, בין אם זה מוצר, שירות או משהו חדש לגמרי.

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

מאמר זה פותח בשיתוף פעולה עם Global Semiconductor Alliance.

מקור: www.habr.com