Composable Telematics

    التليماتية منصةٌ تبني عليها

    Navixy منصة قابلة للتركيب: كتالوج قدرات يمتد من الرؤية التشغيلية الجاهزة (Location Intelligence) إلى تنسيق البيانات (IoT Logic)، والوصول إلى بيانات القياس عن بُعد عبر SQL (IoT Query)، ومنتجٍ يحمل علامتك التجارية. خذ المجموعة كاملةً أو لبنات مفردة منها وابنِ منتجك.

    في التليماتية منذ 2005800K+ أصل متصلعملاء في 130+ دولة
    IoT Logic · القياس عن بُعد قيد الحركة
    دخل · حمولة الجهاز الخام
    { "adc1": 156, "din": 5, "lat": 43.238, "lng": 76.889 }
    خرج · قياس عن بُعد مُوحَّد
    { "fuel_level": 62.4, "ignition": true, "location": ... }
    Navixyوسيط MQTT الخاص بك
    التدفّق نشط · فكّ ترميز → تحويل → توجيه
    ما وراء المنصة المتجانسة

    الميزات لدى الجميع، والسؤال بيانات مَن وخارطة طريق مَن

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

      تعريف الفئة

      ماذا تعني التليماتية القابلة للتركيب

      التليماتية القابلة للتركيب (Composable Telematics) نهجٌ يُجمَّع فيه المنتج التليماتي من قدرات مستقلة للمنصة ذات واجهات موثقة، بدل أن يُؤخذ ككتلة متجانسة مغلقة. تعمل كل قدرة على حدة، وتتصل بالبقية عبر واجهات API، ويمكن استبدالها دون إعادة كتابة الحزمة بالكامل. تسلك التليماتية مسارًا من white-label إلى headless ثم composable — وصولًا إلى agent-ready، حين لا يتعامل مع المنصة البشر وحدهم بل وكلاء الذكاء الاصطناعي أيضًا.

      • كل قدرة مكتفية بذاتها: Location Intelligence وIoT Logic وIoT Query وطبقة التطبيق، يعمل كلٌّ منها على حدة. لا وجود لتبعيات من نوع «الكل أو لا شيء».
      • الواجهات مفتوحة في الاتجاهين: يمكنك الدخول إلى أي قدرة ببياناتك والخروج إلى أنظمتك — عبر API وSDK وMCP.
      • الكتالوج مفتوح: تنضاف إلى النواة مصادرُ الأجهزة وOEM، ووصول وكلاء الذكاء الاصطناعي، والتكاملات. قائمة القدرات تنمو ولا يحدّها منتج واحد.

      كتالوج قدرات المنصة

      النواة هي القدرات الأربع أدناه؛ ابدأ من الرؤية الجاهزة أو انزل إلى مستوى البيانات. والمنصة أوسع من ذلك: واجهات API وSDK، ودعم الأجهزة وOEM، ووصول وكلاء الذكاء الاصطناعي عبر MCP.

      Location Intelligence

      رؤية تشغيلية جاهزة: خريطة حيّة، وأسيجة جغرافية، وقواعد للأحداث، وإعادة تشغيل المسارات (Time Machine)، وتقارير، وروابط جغرافية آمنة. تحوّل إشارة الجهاز إلى صورة تشغيلية للميدان — دون تطوير أي واجهة. الوثائقالوثائق

      IoT Logic

      استقبل البيانات من الأجهزة ومصادر OEM، وفكّ ترميز البروتوكولات، وأثرِ التدفقات ووجّهها — إلى أنظمتك أو إلى مراحل أعمق في الحزمة. تُهيَّأ المصادر الجديدة وقواعد المعالجة في مُنشئ التدفقات، دون إصدار جديد للمنصة. الوثائقIoT Logicتليماتية OEM

      IoT Query

      وصول عبر SQL متوافق مع PostgreSQL إلى بيانات التليماتية الخام. لوحات BI، ونماذج ML، وتحليلاتك الخاصة — باستعلام مباشر لا بتصدير CSV. إعداد الاتصالمخطط البياناتIoT Query

      طبقة التطبيق

      تطبيقات ويب وجوال بنمط white-label: النطاق والشعارات وسمات الألوان تحمل علامتك التجارية. أطلِق دون تطوير واجهة أمامية. وحين تحتاج إلى واجهتك الخاصة، تتوفّر البيانات نفسها بنمط headless عبر API. White-labelHeadless

      البنية

      اتصل عند أي طبقة. واسحب البيانات حيثما تحتاج

      يتحرّك القياس عن بُعد من الأسفل إلى الأعلى: من الأجهزة عبر IoT Logic إلى طبقة البيانات وLocation Intelligence والتطبيقات. لكنك لست مضطرًا إلى استخدام الحزمة كاملةً. أدرِج مصدرك أو واجهتك أو مخزنك حيثما تحتاجه بنيتك. عمليات المنطقالوصول إلى البيانات

      • استبدل طبقة واحدة بدل ترحيل الحزمة كاملةً.
      Agent-ready

      وكيل الذكاء الاصطناعي عميل للمنصة تمامًا كتطبيقك

      يفتح خادم Navixy MCP بيانات الحساب للوكلاء: القياس عن بُعد، والكائنات، والقواعد، والتقارير. يُصادق الوكيل، ويعمل ضمن صلاحيات الحساب، دون حاجة إلى تكامل منفصل. اسأل الوكيل «أي المركبات تجاوز خمولها ساعتين أمس؟» — فيُنفّذ الاستعلام بنفسه. Navixy MCP

        Navixy MCP · وحدة تحكّم الوكيل
        الوكيل: أي المركبات تجاوز خمولها ساعتين أمس؟
        Navixy MCP → المصادقة: رمز الحساب (User MCP)
        IoT Query: 7 مركبات تجاوز خمولها ساعتين

        يتطلب User MCP وAdmin Panel MCP مصادقة الحساب، أما MCP الخاص بالتوثيق فعام. ويتصرّف الوكيل ضمن حدود صلاحيات الحساب.

        لمن هذا

        بنية تحتية واحدة — منتجات مختلفة

        البنية التحتية نفسها لمزوّدي خدمات التليماتية (TSP) وفرق المنتجات وأقسام الهندسة — لكن كل مجموعة تستخدمها بطريقتها الخاصة.

        • مزوّدو الخدمات والمكاملون: كُفّ عن إعادة بيع منصة سواك — واطرح منتجًا قطاعيًا: علامتك التجارية، وتسعيرك، ومنطقك فوق بنية تحتية جاهزة.
        • مورّدو البرمجيات المستقلون (ISV) والمنتجات العمودية: التليماتية كمكوّن: إدارة الخدمة الميدانية (FSM)، والتأمين، وسلسلة التبريد. أدمِج البيانات والأحداث في منتجك عبر API، دون بناء استقبال القياس عن بُعد من الصفر.
        • فرق هندسة المؤسسات: بيانات المعدّات في مستودع بياناتك وBI، عبر استعلام SQL. دون لوحة معلومات من المورّد لا يفتحها أحد.
        فريق Navixy محترف ومهذب ومستعد دائمًا للاستماع. شركة رائعة وأشخاص رائعون. هذه أكثر منصة شمولية استخدمتها على الإطلاق. لم يكن دمج الأجهزة الجديدة بهذه السهولة من قبل.
        WM
        Warren M.
        مدير · تقنية المعلومات والخدمات، 11-50 موظف
        10K+
        مشروع مكتمل
        800K+
        أصل متصل
        130+
        دولة للعملاء

        مراجعة من برنامج مراجعات عملاء Navixy، مترجمة عن الإنجليزية.

        أسئلة شائعة

        أسئلة حول التليماتية القابلة للتركيب

        هل التليماتية القابلة للتركيب معيار قطاعي؟
        لا — إنها نهج معماري، لا معيار معتمد. التحقّق منها بسيط: لكل قدرة توثيق عام، والقدرات تعمل باستقلالية، والبيانات متاحة مباشرةً. وإذا تطلّب أيٌّ من هذه الثلاثة عبارة «تواصل مع مدير حسابك»، فهي ليست composable.
        هل يكفي وجود API لجعل المنصة قابلة للتركيب؟
        لا. واجهة API في المنصة المتجانسة ثانوية عادةً: تغطي بعض الوظائف ولا تتيح لك الدخول إلى الحزمة ببياناتك. أما القابلية للتركيب فتعني أن API هي الواجهة الأساسية لكل قدرة، وأن واجهة المنصة نفسها ليست إلا أحد مستهلكيها. عمليات المنطق
        هل Headless Telematics والتليماتية القابلة للتركيب شيء واحد؟
        نموذج headless حالة خاصة: بيانات ومنطق دون واجهة جاهزة. أما القابلية للتركيب فأوسع: تتجمّع اللبنات — بما فيها واجهة white-label الجاهزة — بأي تركيبة. سيناريو headless متاح دائمًا في حزمة قابلة للتركيب، والعكس غير صحيح. Headless
        هل تليماتية white-label قابلة للتركيب بالفعل؟
        بمفردها، لا. مع مورّد تقليدي، يغيّر white-label المظهر لكن الحزمة تبقى متجانسة: البيانات والمنطق والواجهة كتلة واحدة. القابلية للتركيب تضيف الجوهر — القدرة على أخذ البيانات، أو استبدال طبقة، أو إدماج طبقتك الخاصة. ويبقى white-label أسلوب تسليم مشروعًا: فهو في المنصة القابلة للتركيب أحد أنماط طبقة التطبيق، لا سقفًا لها. White-label
        متى لا يستحقّ بناء البنية التحتية بنفسك العناء؟
        حين لا تكون التليماتية منتجًا لك بل مهمة: تتبُّع بضع مركبات واستخراج تقارير. عندئذٍ يكون التطبيق الجاهز أرخص من أي بنية. وتؤتي القابلية للتركيب ثمارها حين تبني منتجًا لعملائك أو تدمج القياس عن بُعد في أنظمتك الخاصة.
        ماذا تضيف Location Intelligence فوق استقبال البيانات؟
        رؤية تشغيلية جاهزة دون تطوير واجهة. تعمل فورًا: خريطة حيّة، وأسيجة جغرافية، وقواعد للأحداث، وإعادة تشغيل المسارات (Time Machine)، وتقارير، وروابط جغرافية آمنة. وهي قدرة مستقلة في الكتالوج: فعّلها فوق IoT Logic، أو استبدلها بواجهتك الخاصة عبر API. الوثائقالوثائق
        هل تُزيل التليماتية القابلة للتركيب الارتهان للمورّد؟
        تقلّله ولا تُزيله. استبدال قدرة يبقى عملًا، لكنه عمل محدود النطاق: تستبدل طبقة واحدة، لا الحزمة كلها مع ترحيل البيانات. والاختبار الحاسم — هل تستطيع تصدير كل بياناتك بطريقة قياسية. في Navixy، هذا وصولٌ عبر SQL من خلال IoT Query.
        ما الأدلة التي ينبغي أن أطلبها من المورّد؟
        توثيق API عام لكل قدرة، ومخطط البيانات، ووصف كيفية تصدير كل شيء، وقائمة بروتوكولات الأجهزة المدعومة، وشروط عمل القدرات كلٌّ على حدة. وإذا كان الجواب «سنرسل لك عرضًا تقديميًا»، فالنتيجة واضحة.
        هل يمكن توصيل وكيل ذكاء اصطناعي أو أداة مطوّر بمنصة Navixy؟
        يتصل الوكيل مثل أي تكامل عادي. يعمل User MCP وAdmin Panel MCP عبر مصادقة الحساب، أما MCP الخاص بالتوثيق فعام. ويحصل الوكيل على الصلاحيات نفسها والتحكّم في الوصول نفسه كأي تطبيق. Navixy MCP

        ابدأ من التوثيق

        استعرض البنية بنفسك — أو خلال 30 دقيقة مع مهندس من Navixy، على السيناريو الخاص بك.

        ابدأ بقدرة واحدة أو اجمع الحزمة كاملةً بما يناسب سيناريوك.