بالنسبة إلى SDVs، تمثل البرمجيات التحدي الأكبر

تتضمن المركبات المعرفة بالبرمجيات (SDVs) ما هو أكثر بكثير من مجرد تطبيقات OTA التي تتيح ترقية البرامج عبر الهواء. من المتوقع أن تنمو البرامج التي ستدير المئات من وحدات التحكم الإلكترونية والوظائف الأخرى داخل السيارة لتتجاوز مئات الملايين من أسطر التعليمات البرمجية، مما قد يجعل تطوير برمجيات SDV هو التحدي الأول في تصميم السيارات.

إن فوائد SDVs، مثل التحديثات السهلة وفرص إيرادات ما بعد السوق، تدفع مصنعي المعدات الأصلية الرئيسيين للسيارات إلى الاستثمار في تكنولوجيا وأساليب المركبات المحددة بالبرمجيات. مثال على ذلك: أنشأت مجموعة فولكس فاجن قسمًا للبرمجيات يسمى CARIAD، والذي يوفر مجموعة قابلة للتطوير تتكون من منصة البرمجيات VW.os، وهي بنية إلكترونية موحدة تتصل بسحابة سيارات فولكس فاجن. وتتوقع الشركة أنه بحلول عام 2030، سيتم تشغيل ما يصل إلى 40 مليون سيارة من سيارات مجموعة فولكس فاجن على برنامج CARIAD.

لكن التطور من تصميم السيارات المعتمد على الأجهزة إلى تصميم المركبات المبني على البرمجيات والمحدد بالبرمجيات يعد عملية معقدة. على مر السنين، قدم تطوير البرمجيات القوية العديد من أنواع التحديات المختلفة. كلما زاد عدد أسطر الكود، زادت درجة الصعوبة.

عقبات SDV
تشمل المشكلات التي لم يتم حلها والتي تواجه SDVs تطوير البرمجيات والأمن السيبراني واستخدام الذكاء الاصطناعي وتكامل النظام، من بين أمور أخرى. من أجل بناء SDVs، سيحتاج مصنعو المعدات الأصلية للسيارات إلى تعلم كيفية تبني البرامج في عملية تطوير السيارات. في البداية، سيعتمد معظم مصنعي المعدات الأصلية على موردي المستوى الأول والمستوى الثاني لتوفير حل، ولكن في النهاية سيحتاج مصنعو المعدات الأصلية هؤلاء إلى فهم مفاهيم ومهارات البرامج وإتقانها لاتخاذ قرارات جيدة. والأهم من ذلك هو أن مصنعي المعدات الأصلية سيحتاجون إلى تحديد كيفية تأثير البرنامج على الجدول الزمني للتطوير والإنتاج. من الأسهل جدولة تجميع المحركات والهيكل والأجزاء الداخلية والإطارات بدلاً من إدارة البرنامج في مركبة محددة برمجيًا.

وقال روبرت داي، مدير شراكات السيارات لشركة "إن التعاون بين الصناعات أمر ضروري لتوفير البنية التحتية الكاملة التي تتطلبها SDV". ذراعخط أعمال السيارات. "يجب أن تتضمن منهجيات تطوير SDV الجديدة كلاً من السلامة والأمن لضمان موثوقية وظائف السيارة المحددة بواسطة البرامج. تعمل مبادرة البنية المفتوحة القابلة للتطوير للحافة المدمجة (SOAFEE) على تعزيز التعاون المهم بين أكثر من 100 عضو في صناعة السيارات. تقدم SOAFEE منهجيات ومعايير سحابية أصلية لتطوير برمجيات السيارات ونشرها. وفي الوقت نفسه، تضيف هذه المبادرة خصائص مثل السلامة والوقت الفعلي اللازمة لبرامج السيارات.

تمثل ميزانية الشركة المصنعة الأصلية مصدر قلق كبير في الانتقال إلى SDVs. قال ديفيد مسقط، كبير المهندسين في قطاع أعمال الهندسة المعمارية والشبكات: "لا يمكن نشر وظائف البرامج التي تعتمد على الأجهزة، مثل المستشعر أو ربما نوع معين من المعالج، عن طريق التنزيل إلا في حالة وجود الأجهزة على السيارة". في أمريكا الشمالية القارية. "أصبح تخطيط الأداء وتوافر الموارد للترقيات والميزات المستقبلية أكثر أهمية، لأن ذلك له تأثير مباشر على سعر السيارة. يؤدي الانتقال إلى بنية SDV مع الحفاظ على البنى السابقة أيضًا إلى إجهاد ميزانية الشركة المصنعة للمعدات الأصلية. إن الجمع بين العديد من البائعين الذين تم دمج برامجهم في وحدة إلكترونية واحدة ليس بالأمر الهين.

مع تطور الصناعة، لن ينجح نموذج تصميم السيارات التقليدي مع السيارات الكهربائية والمركبات ذاتية القيادة في المستقبل. وسيتطلب ذلك إعادة تصميم كاملة لبنية السيارة لتتوافق مع نهج يركز على البرمجيات.

وقال بيدرو لوبيز إستيبا، مدير قسم السيارات في شركة Real-Time Innovations (RTI): "أحد التحديات الرئيسية هو توضيح مفهوم ما تعنيه السيارة المعرفة بالبرمجيات، حيث أن هناك تفسيرات مختلفة بين مصنعي المعدات الأصلية". "يتمحور التحدي في المقام الأول حول إنشاء واجهات الأجهزة المتوافقة مع معايير الصناعة، وواجهات برمجة تطبيقات المركبات، ونماذج البيانات. إن تمكين التعاون مع نظام بيئي قوي يتضمن موردين جدد يقدمون إمكانات فريدة، بالإضافة إلى دمج البائعين التقليديين في سلسلة التوريد، يهدف إلى تخفيف المخاطر مع ضمان قابلية تطوير النظام وتأمينه للمستقبل.

تحديات تطوير البرمجيات
تواجه SDVs بعض التحديات بما في ذلك إدارة كمية هائلة من البرامج. هناك تحديات في إنتاج تعليمات برمجية خالية من الأخطاء، والاختبار، وتتبع التحديثات والتغييرات، والحفاظ على أمان البرنامج.

وقال سفين كوباتش، مدير قسم المركبات ذاتية القيادة في شركة "في السيارات المتميزة اليوم، يمكننا أن نمتلك ما يصل إلى 150+ وحدة تحكم إلكترونية مدمجة". كيسيت تكنولوجيز. "إن تحويل هذه إلى وحدات VECU سيستغرق ما لا يقل عن 100 مليون سطر من التعليمات البرمجية، مع توقع بعض التقديرات زيادة إلى أكثر من 300 مليون سطر من التعليمات البرمجية بحلول عام 2030. مع هذه الأسطر العديدة من التعليمات البرمجية، يمكننا بسهولة أن نتخيل ما يمكن أن يحدث من خطأ، أو ما ينبغي أن يحدث لا تسوء الأمور، ضمن وسائل النقل والمركبات من الجيل التالي لدينا.

الانطلاق	خطوط الكود
MS-DOS	~ 4,000
نوافذ 10	~10 - 80 مليون
ماك X	~ 84 مليون
أندرويد	~ 12 مليون
آيفون	~ 12 مليون

ومن الناحية الواقعية، لن يكون هناك أبدًا برنامج خالٍ من الأخطاء أو الثغرات. وقال فيتو جيالورينزو، نائب الرئيس الأول والمدير العام لشركة IVY ورئيس تطوير الشركات في "مع الابتكار والتطوير المستمر للأجهزة والبرامج والحلول السحابية المتكاملة، من المحتم أن نواجه حالات ركنية من شأنها أن تؤدي إلى أخطاء أو نقاط ضعف". بلاك بيري.

ومع ذلك، هناك الكثير الذي يمكن لشركات صناعة السيارات ومورديها القيام به للحد من نقاط الضعف هذه، سواء في اختبار ما قبل الإنتاج أو في مرحلة ما بعد الإنتاج من خلال التحديثات المتكررة والفعالة عبر الأثير.

وأوضح جيالورينزو: "يحتاج صانعو السيارات وموردوهم إلى المراجعة المستمرة وتحسين نهج الاختبار في التصميم والتطوير، بالإضافة إلى البحث عن أدوات جديدة تعمل على أتمتة وزيادة تغطية الاختبار لمنتجاتهم". "تعد المحاكاة السحابية ابتكارًا رئيسيًا يأتي إلى الصناعة لتسهيل التطوير والاختبار. تاريخيًا، تمت إعاقة اختبار حلول البرامج المضمنة بسبب نقص الشرائح والأجهزة المطلوبة لاختبار حلول الأجهزة والبرامج الكاملة بشكل صحيح. وكان هذا مؤلمًا بشكل خاص خلال أزمة سلسلة التوريد الأخيرة الناجمة عن فيروس كورونا.

تعمل BlackBerry وآخرون مع موفري الخدمات السحابية مثل Microsoft Azure وAmazon AWS وGoogle لتطوير توائم رقمية لهذه الأنظمة المدمجة في السيارات، حيث يمكن للتوائم الرقمية تمكين فرق البحث والتطوير الموزعة من بناء البرامج واختبارها بكفاءة في السحابة دون الحاجة إلى الشحن. وبناء أنظمة الأجهزة المادية في مختبراتهم. في الواقع، تصبح السحابة بمثابة مستودع الغراء للفرق الهندسية، بغض النظر عن مكان تواجدهم.

رمز أفضل
يعد دمج اختبار البرامج في سير عمل التطوير في أقرب وقت ممكن أفضل طريقة لإنتاج تعليمات برمجية خالية من الأخطاء.

وأشار ريكاردو كاماتشو، مدير السلامة التنظيمية والأمن: "بمجرد أن يبدأ مهندس البرمجيات في كتابة سطر من التعليمات البرمجية، فإن دمج تحليل التعليمات البرمجية الثابتة داخل IDE أو المحرر لتحديد انتهاكات معايير التشفير الخاصة بالسلامة والأمن يؤدي على الفور إلى زيادة جودة التعليمات البرمجية". الامتثال لحلول الاختبار المضمنة لشركة Parasoft. "من خلال القيام بذلك، تحدد الفرق هذه المشكلات في وقت مبكر، ولا يتم تركها لوقت لاحق في دورة حياة التطوير عندما يكون العثور عليها أكثر صعوبة ويكون إصلاحها أكثر تكلفة. أنها مجرد بداية. يجب اختبار كل وظيفة أو وحدة من التعليمات البرمجية للتأكد من أنها قوية بما يكفي للتعامل مع أي سيناريو محتمل لليوم الممطر أو المشمس. وعندما يبدأ المطورون في دمج برامجهم مع برامج بعضهم البعض، يزداد التعقيد، وتصبح الحاجة إلى اختبار التكامل أمرًا بالغ الأهمية.

تعتبر طرق الاختبار الأخرى، مثل اختبارات الأداء والضغط والحمل، بالإضافة إلى اختبار المتطلبات، حيوية أيضًا. وقال كاماتشو: "إن تلبية المتطلبات تضمن أنك تقوم ببناء المنتج المناسب - منتج آمن ومأمون وموثوق". "عندما يتم دمج مكونات البرامج في النظام، يجب إجراء اختبار النظام. على مستوى النظام، يقوم المختبرون باختبار الوظائف الشاملة، وقصفها بالبيانات، وحتى الضغط على الأزرار وتدوير المقابض إذا كانت موجودة. ثم يتم إجراء اختبار القبول للتأكد من أن أصحاب المصلحة سيحصلون على ما يدفعون مقابله. يختلف اختبار البرمجيات عند كل مستوى تجريدي من تطوير البرمجيات، ويهدف إلى إنتاج تعليمات برمجية خالية من الأخطاء.

علاوة على ذلك، تقدم مبادئ DevOps التكامل المستمر/الاختبار المستمر/التسليم والنشر المستمر (CI/CT/CD) - عمليات متكاملة ومؤتمتة وقوية تتيح التطوير السريع والاختبار والنشر المستمر للتعليمات البرمجية/الوظائف.

وقال كوباتش: "بينما يتم إجراء مرحلة الاختبار الوظيفي والنظام في العمليات التقليدية بشكل منفصل أو بعد تجميع السيارة باختبار قائم على الإنسان، فإن DevOps تدمج الاختبار المستمر في مرحلة المفهوم الأولى". "يعني تكامل DevOps أن الاختبار لا يقتصر فقط على الميزات الجديدة. يتطلب أي تغيير في البرنامج أن يتم اختبار كل شيء تم اختباره مسبقًا مرة أخرى للتأكد من أنه لا يزال يعمل. يُعرف هذا باسم اختبار الانحدار. حتى مع وجود فريق كبير من المختبرين، من المستحيل القيام بذلك يدويًا لأن مجموعة الاختبارات تستمر في النمو كل يوم. لذلك، يجب أن ينمو حجم الفريق أو أوقات الاختبار بشكل متناسب، وكلاهما غير مقبول.

وهذا يعني أيضًا أنه لا يمكن نقل السيارة إلى مسار الاختبار لاختبار الانحدار. وأوضح: "على المسار الصحيح، لا يمكننا أبدًا خلق ظروف الاختبار نفسها تمامًا، لذلك لا يمكننا أبدًا التأكد من أن كل شيء لا يزال يعمل كما هو مقصود". "ما نحتاجه هو طريقة لنقل الاختبار اليدوي على مسار الاختبار إلى اختبار مؤتمت بالكامل في المختبر وجعله جزءًا من دورة DevOps. من المهم أيضًا ملاحظة أنه مع كل تغيير في الكود، قد تظهر ثغرة أمنية محتملة. لذا، وكجزء آخر من الاختبار الآلي بالكامل، يتم تنفيذ اختبارات اختراق الأمن السيبراني على الكود الجديد مع كل تكرار، مما يؤدي إلى منهجية DevSecOps (التطوير/الأمن/العمليات)."

تتبع التغييرات والتحديثات
تعد القدرة على تحديث البرامج عبر الهواء أمرًا مريحًا، ولكنها تأتي بثمن. لا يمكن تجاهل متابعة جميع التغييرات. قد تحتوي المركبات الحديثة على مئات من وحدات التحكم الإلكترونية، وقد لا يأتي البرنامج الذي يتحكم فيها من نفس المورد. بالإضافة إلى ذلك، قد يؤثر تغيير جزء واحد من البرنامج داخل SDV على الجزء الآخر. لذلك، من المهم جدًا متابعة التغييرات. وإلا، فقد تنشأ مشكلات جديدة في البرامج نتيجة للتحديث.

قال براكاش مادفاباثي، مدير تسويق المنتجات في Tensilica لمزودي خدمات الصوت/الصوت في شركة Tensilica: "تأتي تحديثات البرامج في نسختين - تحديثات FOTA (البرامج الثابتة عبر الهواء) وتحديثات SOTA (برامج التطبيقات عبر الأثير)". إيقاع. "يؤثر FOTA على نظام التشغيل الأساسي وبرنامج النظام، بينما تقوم SOTA بتحديث برنامج التطبيق. يعد FOTA أكثر أهمية لأنه يؤثر على تطبيقات متعددة، بما في ذلك رمز إدارة وحدة التحكم الإلكترونية. وفي كلتا الحالتين، يجب أن تسمح آلية التحديث للعميل النهائي بالعودة إلى الإصدار السابق إذا واجه العميل مشكلات مع البرامج الثابتة أو البرامج الجديدة.

من المهم أيضًا جمع تعليقات العملاء لمعرفة سبب التراجع عن التحديث وإجراء التغييرات حسب الضرورة.

قال مادفاباثي: "قد تحتاج حملات تثقيف العملاء إلى أن تسبق كلاً من التحديثات الدعائية والتحديثات التي يبدأها العملاء لمساعدتهم على فهم قيمة التحديثات و/أو اكتساب ثقتهم". "إن تتبع العديد من النماذج، وسلوكيات العملاء، والتفضيلات، وإصدارات البرامج والسياقات على مدى عمر السيارة ليست مهمة سهلة، ويمكن أن تتفاقم بسبب تغيير ملكية السيارة أو الخروج من نطاق الخدمة أو الدخول إليه مرة أخرى. قد يتم أيضًا تنشيط الميزات وإلغاء تنشيطها مؤقتًا من قبل السائق، على سبيل المثال، في رحلة برية طويلة. يجب أن تتعامل البرامج وقواعد البيانات مع عمليات تنشيط الميزات المؤقتة والفوترة. قد تحتاج الأسئلة المتعلقة بنقل الميزات الممكّنة للبرامج مع تغيير الملكية والتداعيات على تصميم البرامج إلى النظر فيها."

حماية
دائمًا ما يكون اختراق الأمن السيبراني أمرًا خطيرًا بالنسبة للشركة أو المؤسسة أو الأفراد المتأثرين.

وقال أفيجيت سينها، كبير مسؤولي المنتجات في Wind River: "إن تفرد حماية نظام السيارات يكمن حقًا في تعقيد المناظر الطبيعية التي تحتاج إلى الحماية". "على الرغم من أن البنى الكهربائية للمركبة سوف يتم تبسيطها عندما تصبح SDVs حقيقة، إلا أن المركبات ستظل عبارة عن نظام من أنظمة الحوسبة الموحدة التي تعمل معًا لتشغيل السيارة. من المحتمل أن يكون التحدي في هذا هو ضمان تحقيق تقنيات وإجراءات وتطبيقات أمنية متسقة وقوية عبر هذه الأنظمة الفيدرالية، والتي من المحتمل أن يتم تسليم كل منها من مورد مختلف.

أين هو خط النهاية؟

الشكل 2: ستستمر تقنيات SDV في التطور إلى ما بعد عام 2035. المصدر: تقرير "إعادة كتابة قواعد المركبات المعرفة بالبرمجيات". مجموعة بوسطن الاستشارية (BCG) والمنتدى الاقتصادي العالمي

بعض التقنيات لها خط النهاية. على سبيل المثال، بمجرد إنشاء معيار USB3 الشهير، ستستخدم جميع الأجهزة المتوافقة مع USB3 نفس المعيار ولن تحيد عنه حتى المراجعة التالية. لكن بالنسبة لمركبات SDV، لا يوجد خط نهاية. وسوف تستمر في التطور. سيستغرق الانتقال من المركبات المعتمدة على الأجهزة إلى المركبات المعتمدة على البرمجيات وقتًا طويلاً. ثم سوف يستمر في التغيير مع الهندسة المعمارية الجديدة. سيحدد كل مصنع OEM مساره الخاص.

قد يتم اعتماد بعض معايير السيارات، مثل بنية النظام المفتوح للسيارات (AUTOSAR)، من قبل مصنعي المعدات الأصلية بطريقتهم الخاصة. وفقًا لتقرير صناعة البرمجيات AUTOSAR لعام 2020، يشمل "الشركاء الأساسيون" مجموعة BMW، وBosch، وContinental، وDaimler، وFord، وجنرال موتورز، ومجموعة PSA، وتويوتا، ومجموعة فولكس فاجن.

بينما اعتمدت مرسيدس-بنز AUTOSAR Classic وAUTOSAR Adaptiv، فقد قامت أيضًا بتضمين Linux وQNX في تصميمها. للتطوير المستقبلي، فهو يتمتع ببنية MB.OS من الشريحة إلى السحابة، والتي تتيح فصل البرامج والأجهزة.

وقالت فيرينا بيكهام، رئيسة Khronos SYCL SC: "تقوم صناعة السيارات بدمج الرقائق المدمجة المتباينة في شرائح نفطية مركزية غير متجانسة لتحقيق قوة الحوسبة وكفاءة الطاقة التي تتطلبها الخوارزميات الحاسوبية المكثفة، مثل خوارزميات الذكاء الاصطناعي المطلوبة للسلوك المستقل". فريق العمل. "أحد التحديات هو اختيار نموذج البرمجة المناسب لتمكين تطوير التعليمات البرمجية الفعالة والمحمولة والآمنة لهذه الأنظمة واعتمادها بسهولة. تعمل مجموعة عمل SYCL SC في خرونوس على نموذج البرمجة هذا، والذي يعتمد على SYCL وC++، ولكن تم تصميمه خصيصًا لتسهيل الحصول على شهادات السلامة. نظرًا لشعبية منصة AUTOSAR التكيفية، تتعاون Khronos مع أعضاء AUTOSAR لتمكين SYCL، وفي النهاية، SYCL SC، لاستخدامها من داخل بنية AUTOSAR لفتح القدرة على تفريغ العمليات الحسابية إلى المسرعات، مثل وحدات معالجة الرسومات.

هناك حاجة إلى بنية SDV جديدة
في المستقبل المنظور، ستتضمن تصميمات SDV مزيجًا من أنظمة تشغيل البرامج، ومئات من وحدات التحكم الإلكترونية، والمزيد من أجهزة الاستشعار لدعم الانتقال من L3 إلى L5. ومع ذلك، على المدى الطويل، يفضل مصنعو المعدات الأصلية بنية وشبكات سيارات أبسط، بالإضافة إلى مجموعات البرامج التي يمكن التحكم فيها.

"بالنسبة لمركبة محددة برمجيًا بالكامل، حيث يتم نشر الوظائف الموجودة في السيارة وتحديثها بسهولة، يوصى باستخدام بنية حسابية مركزية ومنطقية جديدة،" قال Arm's Day. "سترتبط وحدات التحكم المنطقية بأجهزة الاستشعار ثم تستخدم اتصالاً عالي السرعة لنقل كمية كبيرة من البيانات إلى الكمبيوتر المركزي الذي سيقوم بتشغيل الوظائف المحددة بالبرمجيات. ستظل أنظمة تشغيل السيارات مطلوبة لوظائف الوقت الفعلي ووظائف السلامة، ولكن يمكن أيضًا استخدام أنظمة التشغيل للأغراض العامة لوظائف مثل المعلومات والترفيه. إن التقنيات مثل المحاكاة الافتراضية والحاويات التي تعمل على بنية الحوسبة المركزية ستسمح لأنظمة التشغيل هذه ووظائفها المحددة بالبرمجيات بالعمل دون خوف من التدخل من بعضها البعض.

بغض النظر عن بنية النظام الإلكتروني للمركبة، ستكون هناك حاجة إلى نظام تشغيل آمن وموثوق لتوفير التجريد والاتصال بالأجهزة.

وأشار فرانسيس تشاو، نائب الرئيس والمدير العام لنظام التشغيل داخل السيارة والحافة في شركة Red Hat: "مع تزايد الطلب من العملاء على البرامج الأكثر تعقيدًا، سيكون من الضروري تنفيذ نظام تشغيل حديث ومثبت مثل Linux".

كيف يؤثر SDV على سلسلة التوريد
تؤثر SDVs على سلسلة التوريد بأكملها، وليس فقط على مصنعي المعدات الأصلية. سيحتاج موردو المستوى الأول والمستوى الثاني إلى العمل معًا لدعم مصنعي المعدات الأصلية للسيارات. على عكس الأجزاء الميكانيكية، قد تتفاعل البرامج من موردين مختلفين مع بعضها البعض أثناء مرور البيانات من جهاز إلى آخر. عند حدوث مشكلات، قد يتطلب الأمر من أطراف متعددة محاكاة الأعراض وتكرارها من أجل استكشاف المشكلات وإصلاحها.

قال كريس كلارك، المدير الأول لبرامج السيارات والأمن في الشركة: "سيتعين على موفري البرامج المختلفين العمل بشكل أوثق معًا". سينوبسيس. "منذ حوالي ثلاث إلى خمس سنوات، على سبيل المثال، كانت إحدى الشركات المصنعة لوحدة التحكم في الفرامل من المستوى الأول، تصمم نظامًا يبحث عن بعض الرسائل من جهاز آخر أو نظام فرعي آخر ويقوم بوظائف الكبح. وقد توسع ذلك بشكل كبير. لا تقوم وحدة التحكم الإلكترونية بهذه الأنشطة فحسب، بل تحتاج إلى تقديم تعليقات حول كيفية عملها، وتعتمد قدراتها على الظروف البيئية للمركبة. إذا كان لديه تحديث للبرنامج، متى يكون من الآمن تطبيق تحديث البرنامج هذا في هذا النشاط؟ وهذا يفتح بيئة معقدة للغاية ومليئة بالتحديات لجميع المشاركين في مجال السيارات.

ومع ذلك، هناك الكثير من الفوائد التي تأتي مع هذا. قال كلارك: "أحد المواضيع التي ينجذب إليها الجميع هو OTA باعتباره عامل تغيير كبير في قواعد اللعبة". "عندما نتحدث عن SDV، هناك عملية كاملة لكيفية تصميم السيارة على مستوى أكثر شمولية. جزء من هذا النشاط هو كيفية إجراء التحديث. وهنا يأتي دور OTA كجزء من هذا النشاط الشامل. لا يوفر OTA تحديثات البرامج التي تذهب إلى الأنظمة التي تعمل داخل السيارة فحسب، بل يعمل أيضًا بمثابة نقل لتلك المعلومات التي تم إنشاؤها وجمعها وتحليلها على مستوى السيارة قبل إرسالها مرة أخرى إلى الشركة المصنعة الأصلية أو الطرف الذي يحتاج إليها للحصول على فهم أفضل لكيفية أداء الجهاز والمركبة بشكل عام. ومن المثير للاهتمام أن نرى جميع هؤلاء اللاعبين مضطرين إلى العمل معًا بشكل أوثق وتطوير هذه الحلول التي توفر قدرات أكبر بكثير مما اعتقد السائقون أنه ممكن، ولكن أيضًا القيام بذلك بطريقة فعالة من حيث التكلفة مع مرور الوقت.

وفي الختام
في المستقبل المنظور، سيستمر عدد أسطر التعليمات البرمجية الخاصة بـ SDV في النمو. سيطرح هذا عددًا من التحديات بما في ذلك إدارة كمية هائلة من البرامج، وصعوبة إنتاج تعليمات برمجية خالية من الأخطاء، واختبار البرامج المكثف، وتتبع التحديثات والتغييرات، وأخيرًا، الحفاظ على أمان البرنامج. وسيتعين على مصنعي المعدات الأصلية الاستمرار في مواجهة هذه التحديات إلى أجل غير مسمى، حيث لا يوجد خط نهاية في الأفق.

القراءة ذات الصلة
التحديات المتزايدة التي تواجه المركبات المتصلة بشكل متزايد
لدى مصنعي المعدات الأصلية توقعات عالية فيما يتعلق بالمركبات المتصلة وفرص النمو العالمية، لكن الأمر ليس بهذه البساطة.
تصميم المركبات افتراضيا
إن زيادة المحتوى الإلكتروني ستتطلب المزيد من المحاكاة لمواكبة التعقيد المتزايد والتغيرات والتحديثات المستمرة.

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• PlatoData.Network Vertical Generative Ai. تمكين نفسك. الوصول هنا.
• أفلاطونايستريم. ذكاء Web3. تضخيم المعرفة. الوصول هنا.
• أفلاطون كربون، كلينتك ، الطاقة، بيئة، شمسي، إدارة المخلفات. الوصول هنا.
• أفلاطون هيلث. التكنولوجيا الحيوية وذكاء التجارب السريرية. الوصول هنا.
• المصدر https://semiengineering.com/for-sdvs-software-is-the-biggest-challenge/