Kubernetes للسيارة: كيفية فتح المطور الوصول إلى الكمبيوتر على متن الطائرة وجعلها آمنة

هذه قصة من جزأين - حول جولة جديدة من تطوير السيارات. هذه "السلسلة" مكرسة لتطوير EPAM الخاص بها ، منصة Aos Connected Vehicle Platform. يشرح Alex Agizim ، CTO ، Auto & Embedded Systems ، كيف يختلف عن الحل السحابي التقليدي وكيف يمنح مطوري البرمجيات الوصول إلى السيارة. يمكنك التعرف على الجزء الأول هنا .



في الجزء الأول ، تحدثت عن كيفية عزل تطورات XEN Hypervisor لجزء الخدمة الخاص ببرنامج السيارات عن برامج الأمان المطلوبة. هذا هو واحد من الحواجز التي تحول دون استخدام واسع النطاق في هذه الصناعة. لأول مرة ، سوف يصبح برنامج hypervisor مفتوح المصدر منافسًا متكاملًا للحلول التجارية المغلقة.

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

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

هكذا.

لماذا تحتاج إلى السماح لمطور الخدمة بالكمبيوتر الموجود على متن السيارة؟ وما هو الخطأ الآن؟

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

تشبيه وثيق هو الهواتف الذكية. حتى عام 2007-9 ، كان من الصعب للغاية كتابة تطبيق يعمل على الهواتف المحمولة المختلفة. حارب الكثير من أنظمة التشغيل وأطر العمل في السوق: حلول من سيمبيان وموتورولا وإريكسون وغيرها ... وكان عدد الأشخاص ذوي المهارات التنموية بالنسبة لهم قليلًا. إذا أراد عمل ما أن يستخدم عدد كبير من الناس خدمته أو تطبيقه ، فستبدأ المشكلة في الحصول على دعم على أنظمة التشغيل وأطر العمل المختلفة.

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

عندما ظهر نظام iOS في عام 2007 ، بعد ذلك بعام - Android - حققت صناعة الهاتف المحمول طفرة على الفور. في AUTOMOBILE ، يستمر تعارض بين نموذجين رئيسيين.

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

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

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

ماذا توصلنا في المقابل؟

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

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

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

ينقسم المفهوم في رؤيتنا إلى قسمين:

1. عزل برامج السلامة عن برامج الخدمات المتصلة ؛
2. لتوفير المستوى اللازم من التجريد للشركات التي ترغب في تطوير أو تعمل بالفعل خدمات المركبات المتصلة. لا ينبغي أن تهتم بالأجهزة المدمجة ، ولكن تطوير الخدمات باستخدام أدواتها المعتادة واستخدام الكمبيوتر الموجود على متن الطائرة كجهاز متطور.

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

ما الحالات التي يمكن أن تغلق؟

حالة الجذر هو عدم وجود اتصال . في الإصدار السحابي الكلاسيكي ، ستفقد الخدمة الوصول إلى السيارة. في متغير Connected Vehicle Platform ، يمكن للمطور التنبؤ بهذا وقبل "فلاش" المنطق داخل السيارة. وللجزء سحابة منه - على الأقل العازلة البيانات.

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

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

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

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

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

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

كيفية إغلاق خدمة رجال الأعمال بشكل آمن من السحابة إلى السيارة؟ ما الذي يمكن أن يمنع هذا وكيف يمكننا حلها؟

1. الحاويات

بما أننا نأتي من أفكار Kubernetes ، فإن مهارته الرئيسية هي نشر الحاويات. لكن من الصعب استخدام كمبيوتر السيارة.

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

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

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

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

2. الأمن

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

قمنا بتطبيق نموذج متقدم وفقًا لتوصيات وكالة الأمن القومي الأمريكية. تقول ما يلي: عند تصميم نظام الأمان الخاص بك ، يجب عليك أولاً تقليل عدد أماكن الهجوم المحتمل ، وكذلك بناء الأمان ككعكة طبقة. اخترق على مستوى ما؟ من الضروري أن تلاحظ ذلك وتبذل قصارى جهدك حتى لا تترك التالي.

في نموذجنا ، تبدو "الكعكة" كما يلي:

1. نستخدم الحاويات كنوع من المعزل على مستوى نظام التشغيل Linux. من الصعب للغاية الخروج من الحاوية ؛
2. الخروج من الحاوية؟ لكن نظام Connected Vehicleslle Platform يعمل في جهاز افتراضي منفصل - نحتاج إلى XEN. يتم عزل هذا الجهاز الظاهري من جميع الأجهزة الطرفية. يمكن أن يحدث التواصل مع الأجهزة الطرفية فقط من خلال بعض واجهات برمجة التطبيقات التي توفرها الشركة المصنعة للسيارة ؛
3. كسر الحاوية والجهاز الظاهري؟ لدينا حاجز آخر - تأمل الجهاز الظاهري: تحليل الأنماط التي يعمل عليها الجهاز الظاهري. على سبيل المثال ، يحاول الجهاز الظاهري فجأة الوصول إلى نوع من الذاكرة ، والتي عادةً لا تلمسها. يمكنك الاستجابة: قم بإيقاف تشغيل هذا الجهاز الظاهري ، والعودة إلى الإصدار الثابت ، إلخ.

3. مقياس

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

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

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

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

4. قنوات الاتصال

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

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

5. التعددية

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

في حالة السيارة والاقتصاد المشترك ، هذه التبعيات ديناميكية للغاية. هناك شركة تصنيع السيارات . هناك مشتر / مالك - دعنا نقول إنها شركة مشاركة سيارات. هناك مشغل الخدمة. وهناك مستخدم نهائي.

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

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

6. مراقبة تشغيل الخدمات

للتواصل مع خدمة السيارة ، هناك واجهة برمجة تطبيقات موحدة تسمى VIS - خدمات معلومات السيارة. هو موحد من قبل W3C. يتم تطبيق واجهة برمجة التطبيقات هذه في مفهومنا والتحكم فيها من قبل الشركة المصنعة للسيارة. خدمة السيارة المتصلة تحت السيطرة الكاملة.

بدأت جهات تصنيع مختلفة في دعم واجهة برمجة التطبيقات هذه. ولا يهتم المطور بالجهة المصنعة التي يقدم لها الخدمة.

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

ما هي مكونات المنصة مكتوبة على؟ وماذا سيكون من الممكن كتابة خدمات للسيارات؟

المنصة نفسها مكتوبة في بيثون. الإدارة العليا لنظام النشر مكتوبة بلغة Python. الجزء المضمن بالكامل مكتوب باللغة C.

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

بشكل عام ، هذه مشكلة تكتيكية. لا يوجد مبرمجين جافا سكريبت - هناك مبرمجين. أعتقد أنه مع تطور السيارات ، سيظهر المبرمجون الذين يشاركون في خدمات المركبات المتصلة بشكل خاص. لمبة "ماذا تفعل إذا لم يكن هناك اتصال؟" سوف تومض دائما في رؤوسهم بغض النظر عما لدينا في الهواء - 5G أو 10G. اتصال لاسلكي لا يعمل 100 ٪ من الوقت.

كيف تتفاعل شركات صناعة السيارات مع المنصة؟

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

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

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

في صناعة الأجهزة المحمولة ، حدث هذا بسرعة. لكننا نفهم: الناس لا يغيرون السيارة كل عام. تستغرق دورة تطوير برامج السيارات من 4-6 سنوات. لذلك ، فإن ما نتحدث عنه مع شركات صناعة السيارات اليوم سيبدأ في الظهور في شكل نوع من أنواع الطيارين بالكاد قبل عام 2022.

هل نحاول نسخ أو التنافس مع تسلا؟

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

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

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

ومع ذلك ، لا أعتقد أنه في المستقبل سيكون هناك منصة واحدة لجميع السيارات.على الأرجح ، سيكون هناك 2-3 كبيرة. من ناحية ، سوف يوحدون شركات صناعة السيارات. ومن ناحية أخرى ، سوف يتيحون مرة أخرى استخدام أطر البرمجة الحديثة. وسنرى حالات جديدة تمامًا لا يمكننا تخيلها الآن.