The modern cockpit has become one of the most complex software environments in any consumer product. A single infotainment stack must manage navigation, climate control, voice assistance, connectivity, entertainment, driver notifications, and safety features – all within milliseconds and under strict reliability standards.

لسنوات عديدة، بنى العديد من مصنّعي المعدات الأصلية هذه الأنظمة على حزم Linux مخصصة.

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

لقد غيّر Android Automotive OS (AAOS) هذه الديناميكية.

With its modular structure and mature developer ecosystem, AAOS allows carmakers to design infotainment and cluster systems that can evolve over time, not just be frozen at SOP. It offers over-the-air updates, secure app isolation, access to Google services, and familiar Android tooling.

لكن البرمجيات المعيارية لا تزال بحاجة إلى تصميم معياري. وهنا يأتي دور بنية MicroHMI.

لماذا يُعد MicroHMI مهمًا؟

The automotive HMI used to be a monolith – one codebase, one development flow, one large team. As vehicles move towards software-defined architectures, this approach no longer scales. Dozens of features must be developed, tested, and maintained in parallel by distributed teams and suppliers.

MicroHMI borrows the microservices idea from enterprise IT. Instead of one massive HMI, you create a set of lightweight, self-contained micro-applications, each responsible for a specific function: climate control, media, navigation, settings, or vehicle status.

كل وحدة MicroHMI:

  • يمتلك مسؤولية واحدة وحدوداً واضحة؛
  • يتواصل عبر واجهات مُصدَّرة بإصدارات أو ناقل أحداث؛
  • يمكن اختباره أو تحديثه أو استبداله دون المساس ببقية المكونات؛
  • ويعمل كعملية أو حاوية خاصة به.

The benefits are immediate: faster prototyping, easier parallel work, and reduced regression risk. For large OEM programmes, it also improves supplier collaboration – different teams can own separate features while maintaining system consistency through shared APIs.

نعتقد أن MicroHMI هي وسيلتك للتغلب على تعقيد قمرة القيادة.

تواصل معنا للاستشارة أو لتطوير فكرة واجهة الإنسان والآلة الخاصة بك

اعرف المزيد

Android Automotive كمضيف طبيعي

AAOS supports this architecture natively. Each function can be packaged as an independent Android app or service, signed and updated separately. The Vehicle HAL exposes signals from the car, and Android’s robust permission model keeps modules secure.

كما يتيح Android Automotive:

  • تحديثات OTA للتحسين المستمر؛
  • تكامل خدمات Google للسيارات (Assistant، Maps، Play)؛
  • ملفات تعريف متعددة المستخدمين؛
  • تجريد الأجهزة عبر منصات مثل Qualcomm SA8155P أو غيرها من أنظمة SoC للسيارات.

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

من التصميم المعياري إلى القابلية للتكيف

تقسيم واجهة الإنسان والآلة إلى وحدات مصغّرة ليس سوى نصف القصة.

تتمثل الفرصة الحقيقية في جعل قمرة القيادة قابل للتكيّف. يتوقع السائقون الآن نفس السلوك الحواري والواعي بالسياق من سياراتهم كما يحصلون عليه من هواتفهم ومكبرات الصوت الذكية.

هنا يأتي دور النماذج اللغوية الكبيرة (LLMs).

النماذج اللغوية الكبيرة في السيارة: التحول من الأوامر إلى المحادثة

تطلّب التحكم الصوتي المبكر صياغة صارمة: "اتصل بجون سميث", "اضبط درجة الحرارة على اثنتين وعشرين درجة." تغيّر النماذج اللغوية الكبيرة ومعالجة اللغة الطبيعية (NLP) الحديثة ذلك الأمر بالكامل.

يمكن للسائق الآن أن يقول:

«أشعر بالبرد – هل يمكنك تدفئته قليلاً؟»
"ابحث عن مقهى على الطريق."
«اخفض الموسيقى، ثم انتقل إلى المنزل.»

يحلل المساعد النية، ويفهم السياق، ويمكنه ربط إجراءات متعددة. لم يعد يطابق الكلمات المفتاحية – بليفسّر المعنى.

داخل قمرة القيادة، يعني ذلك:

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

تجعل النماذج اللغوية الكبيرة واجهة الإنسان والآلة متعدد الوسائط، بالجمع بين الصوت واللمس والإيماءات في نموذج تفاعل سلس.

خط الأنابيب متعدد الوسائط

ولتحقيق ذلك، تدمج واجهة HMI للسيارات عدة طبقات من الذكاء الاصطناعي ومنطق البرمجيات.

  1. كلمة التنبيه وكشف النشاط الصوتي (VAD): استماع دائم ولكن منخفض الطاقة لعبارة التنشيط.
  2. التعرف التلقائي على الكلام (ASR): يحوّل الكلام إلى نص.
  3. تفسير NLU أو LLM: يستخرج النية والكيانات والسياق.
  4. مدير الحوار: يحافظ على الحالة عبر الأدوار.
  5. منسق الإجراءات: يربط النية بواجهة MicroHMI API (على سبيل المثال، Climate.setTemperature(zone, value)).
  6. التغذية الراجعة: توفر استجابة تحويل النص إلى كلام وتحديث واجهة المستخدم على الشاشة ذات الصلة.

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

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

الموازنة بين السحابة والحوسبة الطرفية في الذكاء الاصطناعي

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

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

This design ensures critical functions remain available offline, while advanced conversational capabilities are delivered when connected. It also gives OEMs flexibility to comply with regional data-protection laws such as GDPR.

Our engineers frequently combine this hybrid approach with context caching and intent confidence thresholds – the system decides dynamically whether to execute, ask for confirmation, or escalate to a cloud query.

السلامة الوظيفية والجودة حسب التصميم

بغض النظر عن مدى ذكاء المساعد، فإن بيئة السيارات تتطلب الموثوقية والامتثال.

مع أخذ ذلك في الاعتبار، ندمج السلامة الوظيفية ونضج العمليات مباشرة في دورة حياة HMI:

  • ISO 26262 للسلامة الوظيفية (مستويات ASIL من A إلى D)
  • Automotive SPICE لقدرة العمليات
  • IEC 61508 و ISO 14971 لإدارة المخاطر والبرمجيات المتعلقة بالسلامة

الـ Wavey platform integrates Squish GUI Tester in a Docker-based CI/CD pipeline, ensuring that every code change triggers unit, smoke, and regression tests. GitLab automation validates modules continuously – a practice essential for maintaining quality across distributed teams.

بالمناسبة، استكشف Wavey المنصة وتعرّف على كيف يمكن للبنية المعمارية المعيارية والاختبار الآلي وتكامل الذكاء الاصطناعي أن تحوّل نهجك في تجربة المستخدم للسيارات.

لا يتعلق الاختبار الآلي بالكفاءة فحسب. بل يتعلق بالثقة. فعندما تتحكم واجهة HMI في السيارة بوظائف حرجة، تصبح الثقة في كل إصدار بنفس أهمية الابتكار.

التصميم من أجل قابلية التوسع والتعاون

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

على سبيل المثال:

  • يصمم فريق واجهة المستخدم/تجربة المستخدم (UI/UX) التدفق البصري لبلاطة التنقل
  • يقوم فريق التطوير بتنفيذه باستخدام Qt/QML
  • يكتب فريق ضمان الجودة نصوص Squish التي تختبر الوحدة بمعزل عن غيرها

يمكن للثلاثة العمل في وقت واحد. يدمج التكامل المستمر مخرجاتها في وحدة قابلة للاختبار كل ليلة.

غالباً ما تستخدم Spyrosoft هذا الهيكل في برامج قمرة القيادة المعقدة، مما يتيح لعدة موردين أو فرق داخلية تقديم الميزات دون إدارة تبعيات مستمرة.

This modularity also simplifies variant management. The same set of MicroHMIs can be combined differently across model lines – for example, a premium trim might add 3D visualisation via Unity, while an entry version reuses the same base modules without it.

الصوت والإيماءات واللمس: تجربة متعددة الوسائط

MicroHMI والذكاء الاصطناعي معاً يفتحان آفاق التفاعل متعدد الوسائط حقاً.

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

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

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

إدارة السياق والتخصيص

يتذكر المساعد الفعّال داخل السيارة السياق عبر أربع طبقات:

  1. الجلسة: ما قيل في هذا التفاعل.
  2. المستخدم: التفضيلات والعادات الشخصية.
  3. المركبة: الحالة الحالية – السرعة، درجة الحرارة، المسار.
  4. التطبيق: أي وحدة HMI نشطة.

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

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

الهدف واضح: اجعل السيارة مفيدة دون أن تكون متطفلة.

الأداء والتحسين

الاستجابة في الوقت الفعلي أمر بالغ الأهمية. يجب أن تتوافق النماذج اللغوية الكبيرة ونماذج الصوت مع ميزانية زمن الاستجابة الصارمة للمركبة المتحركة.

تشمل تقنيات التحسين:

  • تكميم النماذج وتقطيرها لتقليل الحجم؛
  • تسريع GPU أو NPU على أنظمة SoC للسيارات؛
  • خطوط أنابيب غير متزامنة لإبقاء خيوط واجهة المستخدم حرة؛
  • خفض الأداء الديناميكي لتحقيق التوازن بين الأداء واستهلاك الطاقة.

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

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

الأمان والسلامة وثقة المستخدم

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

تشمل أفضل الممارسات:

  • معالجة الصوت محليًا حيثما أمكن؛
  • اشتراط التأكيد للإجراءات الحرجة؛
  • توفير مؤشرات مرئية واضحة عند تنشيط الميكروفون؛
  • السماح للمستخدمين بكتم الصوت أو حذف البيانات؛
  • اتباع إرشادات الأمن السيبراني UNECE R155/R156.

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

هذا ليس مجرد تجربة مستخدم جيدة. إنه الامتثال في الممارسة العملية.

تواصل معنا للاستشارة أو لتطوير فكرة واجهة الإنسان والآلة الخاصة بك

اعرف المزيد

من إثبات المفهوم إلى الإنتاج

في Spyrosoft، نضع هذه الأفكار موضع التنفيذ من خلال Wavey، مقصورة IVI الداخلية المطورة داخلياً والمُتحكم بها بالإيماءات، والمبنية على معمارية MicroHMI القائمة على Qt لنظام Android Automotive.

Each feature – navigation, media, HVAC – exists as a standalone micro-application. Automated Squish tests validate every build in Docker containers. Gesture and voice inputs feed into the same backend APIs, demonstrating the modular design’s flexibility.

Wavey shows how quickly a production-ready cockpit can be assembled when architecture, AI and testing are aligned. The result is a ready-to-deploy automotive IVI and cluster platform that’s both functional and brandable.

المزالق الشائعة وكيفية تجنبها

عند اعتماد MicroHMI والتفاعل القائم على LLM، غالبًا ما تواجه الفرق تحديات متكررة:

  • الاعتماد المفرط على السحابة: وفّر دائماً بدائل تعمل دون اتصال.
  • حدود وحدات غير واضحة: حدّد الملكية والواجهات في وقت مبكر.
  • غياب الاختبار الآلي: يجب أن تكون لكل وحدة خط أنابيب تكامل مستمر خاص بها.
  • تجاهل الضوضاء في العالم الحقيقي: اختبر الصوت والإيماءات في ظروف المقصورة الفعلية.
  • الخصوصية كفكرة لاحقة: ادمج تصميم حماية البيانات في أول دورة تطوير.

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

الطريق إلى الأمام

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

توفر بنية MicroHMI الهيكل.
توفر النماذج اللغوية الكبيرة والذكاء الاصطناعي الذكاء.
يوفر Android Automotive النظام البيئي.

ومعاً، تمكّن هذه التقنيات من واجهات HMI معيارية وقابلة للتكيف ومتطورة باستمرار – وهي سمات أساسية للمركبات من الجيل التالي.

العمل معنا

يتطلب تسليم مثل هذه الأنظمة أكثر من مجرد التكنولوجيا. إنه يتطلب الخبرة.

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

تشمل كفاءاتنا:

  • تطوير واجهات HMI باستخدام Qt/QML وC++؛
  • تكامل Android Automotive OS؛
  • Squish وأتمتة CI/CD؛
  • السلامة الوظيفية (ISO 26262، ASPICE)؛
  • تكامل الذكاء الاصطناعي / LLM على الجهاز وفي السحابة؛
  • تصميم تجربة المستخدم متعدد الوسائط بالإيماءات والصوت.

سواء كنت تطوّر قمرة قيادة جديدة من الصفر أو تحسّن منصة موجودة، يمكننا مساعدتك في:

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

لنتحدث عن قمرة القيادة التالية الخاصة بك

تمكّن خدمات تطوير واجهة الإنسان والآلة (HMI) من Spyrosoft الشركات المصنعة للمعدات الأصلية وموردي المستوى الأول من تصميم واختبار وإطلاق أنظمة مركبات ذكية قابلة للعلامة التجارية مبنية لعصر البرمجيات المعرّفة.

ألقِ نظرة على حلول HMI أو تواصل مع مدير HMI لدينا وناقش أفكارك المتعلقة بـ HMI.