إثراء بيانات المركبة عبر الأنظمة المؤسسية

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

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

مشروع متكامل لدمج البيانات خلف بضع حقول إضافية

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

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

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

يوفر IoT Logic نهجًا آخر لإثراء بيانات المركبة. يمكن للنظام الخارجي إرسال سمات إضافية إلى جهاز تتم مراقبته بالفعل على المنصة. وتُرسم البيانات الواردة على الجهاز الصحيح وتنضم إلى تدفق بياناته الحالي، حيث يمكن الاستفادة منها في مزيد من المعالجة والأتمتة.

يتم تناول صيغة الطلب وتفاصيل المصادقة في التوثيق الفني. هنا، سنوضح ما يحدث للبيانات بمجرد وصولها إلى المنصة.

كيفية انضمام البيانات الخارجية إلى تدفق بيانات المركبة

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

لا يتغير شيء في جانب الجهاز. يستمر جهاز التتبع في الإبلاغ كما كان من قبل، بينما يمكن لـ IoT Logic استخدام السمات الإضافية في الحسابات والظروف والأتمتة والمزيد من المعالجة.

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

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

إثراء بيانات المركبة في سيناريوهات العالم الحقيقي

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

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

يمكن أن يؤدي تأكيد الدفع إلى إجراء داخل المركبة

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

يمكن لمزود الدفع إرسال حالة المعاملة جنبًا إلى جنب مع معرف يربطها بالمركبة المعنية. بمجرد دخول تلك الحالة إلى تدفق بيانات المركبة، يمكن لـ IoT Logic استخدامها ضمن المنطق الذي يحدد الإجراء التالي.

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

مثال على تدفق IoT Logic

قد يبدو تدفق محتمل على هذا النحو:

مزود الدفع → HTTP Push → ربط المعاملة بالمركبة → التحقق من حالة الدفع → إرسال أمر الفتح

يدفع النظام الخارجي سمة مثل payment_status للمركبة المربوطة. يقيم IoT Logic تلك القيمة، وعندما تُستوفى الشروط المطلوبة، يوجّه الرسالة إلى العقدة المسؤولة عن إرسال الأمر إلى الجهاز.

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

يمكن لبيانات الطقس أن تجعل قواعد المركبة أقل صرامة

عادةً ما تعمل قواعد المركبة وفق حدود ثابتة. وهذا مقبول إلى أن تتغير الظروف المحيطة بالمركبة.

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

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

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

مثال على تدفق IoT Logic

قد يكون التدفق التوضيحي:

خدمة الطقس → HTTP Push → ربط الظروف بالمركبة → الدمج مع تليمترية المركبة → تطبيق منطق مخصص للظروف → تنبيه أو إجراء

قد يوفر النظام الخارجي سمات تصف معدلات الهطول ومدى الرؤية ودرجات الحرارة أو ظروف الطرق. يمكن لـ IoT Logic استخدام تلك القيم مع ما يرد من تليمترية المركبة في الحسابات أو المنطق الشرطي.

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

يمكن نقل سجلات الأعمال جنبًا إلى جنب مع بيانات المركبة

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

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

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

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

مثال على تدفق IoT Logic

قد يبدو تدفق أساسي على النحو التالي:

ERP / CRM / نظام داخلي → HTTP Push → ربط السمات التجارية بالمركبة → بيانات المركبة المثرية → المعالجة أو الوجهة اللاحقة

على سبيل المثال، ربما يرسل النظام الداخلي قيمًا مثل contract_id أو service_type أو أي سمة تشغيلية أخرى مرتبطة بالمركبة. يمكن لـ IoT Logic الاحتفاظ بهذا السياق أثناء تحرك بيانات المركبة عبر التدفق، مما يسمح للمنطق اللاحق أو الأنظمة الأخرى باستخدام كل من التليمترية والمعلومات الخاصة بالأعمال.

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

يمكن لبيانات بطارية OEM سد الثغرات في تليمترية جهاز التتبع

تختلف بيانات البطارية بعض الشيء؛ إذ إن كثيرًا من أجهزة التتبع يبلغ بالفعل عن معلمات خاصة بالبطارية. تظهر الفائدة عندما تقدم منصة الشركة المصنعة للمركبة الكهربائية (OEM) أو نظام إدارة البطارية (BMS) معلومات لا يوفرها الجهاز.

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

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

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

مثال على تدفق IoT Logic

قد يكون أحد التدفقات:

منصة OEM / BMS → HTTP Push → ربط البيانات بالمركبة → إضافة سمات البطارية → الدمج مع تليمترية الجهاز → المعالجة أو التنبيه أو النظام اللاحق

افترض أن نظام OEM يوفر معلمة بطارية لا يوفرها الجهاز. يستطيع النظام دفع هذه القيمة سمة إضافية تخص المركبة المربوطة. بعد ذلك يكون لدى IoT Logic تليمترية الجهاز الأصلية وبيانات البطارية الإضافية معًا في التدفق.

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

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

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

عندما لا يعني مصدر بيانات إضافي ضرورة إنشاء تكامل جديد

بالنسبة إلى الشركاء ومدمجي الأنظمة، يغير هذا فكرة مألوفة لدى العملاء. لم يعد السؤال "هل يمكننا جلب هذه البيانات إلى Navixy أيضًا؟" يقود تلقائيًا إلى "سنحتاج إلى بناء تكامل."

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

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

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