مع تطور تقنيات مثل السفن الصديقة للبيئة وسفن الدفع الكهربائي وسفن الدفع متعدد الوقود، يتوسع نطاق تطبيقات إنترنت الأشياء (IoT) في المجالات البحرية، مما يزيد تعقيد عوامل التحكم. كما يدفع التقدم التدريجي نحو السفن السطحية البحرية ذاتية القيادة (MASS) تطور تطبيقات إنترنت الأشياء على متن السفن، مما يبرز الحاجة إلى منصة تضمن اتصالًا موثوقًا بين السفن والشاطئ. وتتجلى في هذا السياق محدودية بنية السحابة الأحادية الحالية.
استجابة لهذه التحديات، تقدم هذه الورقة بنية منصة بيانات سحابية متجذرة في معمارية سحابة ضبابية متعددة المناطق، وتقترح نهجًا استراتيجيًا لتعزيز أداء تجنب التصادم عبر المشاركة السلسة لبيانات خطط الملاحة بين السفن من خلال المنصة المقترحة. وتُظهر النتائج أنه مع 100 سفينة مجاورة مشتركة في البيانات، عندما اختلفت المناطق، كان فقدان الحزم أعلى بنحو 28 مرة منه في المنطقة نفسها.
تُبنى المنصة باستخدام سحابة AWS وتُقيَّم عبر قياسات زمن الذهاب والإياب (RTT) ومعدل فقدان الحزم (PLR) عبر المناطق، مما يثبت أن الاتصال بسحابة الضباب في المنطقة نفسها يوسّع كثيرًا عدد السفن المشتركة بمعدل فقدان منخفض في المناطق عالية الكثافة، ويرسي أساسًا متينًا لبحوث إنترنت الأشياء البحري والحوسبة السحابية.
يبشر تقدم أنظمة الأتمتة ودمج تقنية إنترنت الأشياء بعصر تحولي للعمليات البحرية [1]، فولّد عمليات سفن مبتكرة تشمل السفن الذكية والسفن المشغلة عن بُعد والسفن ذات التوائم الرقمية [2، 3]. وإدراكًا لهذه القفزات، تناقش المنظمة البحرية الدولية (IMO) بنشاط التشغيل الآمن للسفن السطحية البحرية ذاتية القيادة (MASS)، وهي سفن تبحر بأقل تدخل بشري أو دونه وتُصنف في أربع مراحل حسب درجة الأتمتة [4]. ويؤكد الاعتراف المتزايد بـ MASS الحاجة لمعالجة تحديات مشاركة البيانات والاتصالات [5] والتشغيل البيني بين السفن والعمليات الشاطئية [6]، فالإدارة الفعالة للبيانات والرصد الآني واتخاذ القرار المستنير أمور حاسمة للسلامة والكفاءة والأداء [7].
لهذا، لا غنى عن منصة بيانات سحابية قوية ومتعددة الاستخدامات قائمة على إنترنت الأشياء تتفاعل مع أنظمة أتمتة السفن القائمة وتطور خدمات جديدة. وتعرض الورقة بنية منصة بيانات أفقية سحابية جديدة مصممة لدعم خدمات متعددة في المجال البحري باستخدام بيانات إنترنت الأشياء المجموعة من السفن، إذ تتيح المنصة الأفقية لعدة سفن وخدمات العمل عضويًا على منصة موحدة [8]، ودمج الخدمات الجديدة بضبط العناصر المعمارية ذات الصلة. وبما أن السفن تجوب العالم وشركاتها موزعة عالميًا، يصعب الحفاظ على جودة خدمة متسقة ببنية سحابية واحدة، لذا تقدم الورقة منصة تضم سحب ضبابية متعددة ومركز سحابي عالمي واحدًا، تُمكّن خادم الحافة (المسؤول عن جمع بيانات السفن وإدارتها) من التفاعل مع سحابة الضباب في المنطقة ذات الزمن الأمثل، ثم تُنقل البيانات وتُدار في المركز السحابي ببنية بيانات وواجهات موحدة تبسّط تطوير الخدمات الجديدة.
اكتسبت نماذج الحوسبة الضبابية شعبية كوسائل فعالة لتعظيم الاستفادة من موارد أجهزة إنترنت الأشياء، إذ تمد جودة الخدمة إلى جوار المستخدم وتمكّن المعالجة السريعة ضمن منظومات إنترنت الأشياء-السحابة الديناميكية [9]، وتستكشف دراسات بحرية بنشاط جمع البيانات بكفاءة عبر الحوسبة الضبابية وتحسين الوظائف بتفريغ الأحمال (offloading) [10، 11]. وفي القسم 3 تُصمم بنية هرمية للمنصة تميّز بين المتن والشاطئ، وتُحدد الأطراف والعناصر الوظيفية لكل طبقة، مع مكونات خادم الحافة وسحابة الضباب والمركز السحابي، وتُستثمر مزايا الاتصال (زمن الاستجابة وفقدان الحزم) لاقتراح طريقة مشاركة بيانات لتجنب التصادم. أما البحوث السابقة فتنبأت بالتصادم من الحالة الملاحية الراهنة عبر استشعار معقد، بينما تقترح الورقة مشاركة الحالة الراهنة والمسار المخطط والحالة الملاحية مع السفن المحيطة عبر المنصة — مما يحسّن الأداء ببيانات مؤكدة رغم حركة إضافية — وتُنمذج فقدان الحزم بتوزيع Poisson عبر فترة استقبال بيانات AIS، فتُظهر المقارنة أن فقدان المنطقة المختلفة أعلى بنحو 28 مرة. ويقترح القسم 4 معمارية تنفيذ على AWS مع اختبارات RTT وPLR عبر المناطق لتقييم مزايا الشبكة في المنطقة نفسها.
أُجريت خلال العقد الماضي بحوث واسعة تحت عنواني «الملاحة الإلكترونية» و«MASS» لأتمتة تشغيل السفن وإدارتها، مستخدمة إنترنت الأشياء في المجال البحري فدمجت تقنية التشغيل (OT) بتقنية المعلومات (IT) وطورت أنظمة مؤتمتة لتقليل التدخل البشري. ومنها بحوث تجنب التصادم للملاحة الآمنة استعدادًا لعصر السفن الذاتية [12]، وبحوث تعزيز الوظائف وابتكار الخدمات عبر مشاركة البيانات وإدارتها بالاتصال بين السفن أو بين السفن والشاطئ [6]، وجهود إرساء MASS عبر دمج نظام أتمتة السفن مع الحلول الشاطئية بمنصة سحابية جسرًا لتبادل البيانات والتعاون [10، 11].
يؤدي نظام أتمتة السفن دورًا حاسمًا في دعم القرارات بجمع البيانات التشغيلية ودمج مكونات التحكم. ويوضح الشكل 1 التكوين الشامل: نظام الملاحة المتكامل (INS) ونظام التحكم والمراقبة المتكامل (ICMS) المشرف على المنشآت. ويضم INS أنظمة ECDIS والرادار TCS ونظام إنذار الجسر BAMS والطيار الآلي لتخطيط المسار وتنفيذه وفق المعيار IEC61924-2 الذي يحدد البنية المعيارية ومعايير الأداء ورصد توافر الحساسات وسلامتها [13]. وبينما تدعم أنظمة INS التقليدية القرار البشري بالعرض المرئي، تهدف البحوث لتقليل التدخل البشري وتمكين الملاحة الذاتية بإدراك المحيط، عبر خوارزميات مستقرة وآليات توجيه وتحكم لتجنب التصادم [14، 15]. أما ICMS فهو نظام تحكم لامركزي للآلات والمعدات الكهربائية (الشكل 2): منطقة خضراء يدير فيها المتحكم كل معدة، ومنطقة برتقالية فيها محطة المشغل OWS بواجهة HMI للمراقبة والتحكم المباشر. وقد زاد الطلب على السفن الصديقة للبيئة (ناقلات LNG والدفع الكهربائي ومحركات الوقود المزدوج) تعقيد عوامل التحكم، فتركزت جهود على التوائم الرقمية [16] وبيئات المحاكاة الافتراضية للتكامل والأمثلية [17] — لكن تحويلها لنتائج على سفن حقيقية يقتضي منصة بيانات آنية تربط بيانات السفن وتديرها بسلاسة.
تتولد بيانات الملاحة وفق المعيار IEC61162-1 [18] للاتصال التسلسلي وIEC61162-450 [19] للإيثرنت، ويستخرج نظام AIS البيانات ويبث رسائل الموقع والرحلة للسفن المحيطة عبر VHF، بفترات أقصر للسفن الأسرع. وتشمل رسائل AIS الحالة الملاحية (الأنواع 1 و2 و3) [20] التي تكشف الحالة والموقع الراهنين، وتُمرر للشبكة INS ببروتوكول IEC61162-1 [18] لعرضها للمستخدمين. وتوظف دراسات AIS لتحسين الأداء: تجميع المسارات للتنبؤ بها وتجنب التصادم [21]، وتقنيات معالجة مسبقة لإدارة الكميات الضخمة ومراقبة الطرق [22]، وتجاوز محدودية مدى VHF بسبب انحناء الأرض عبر الأقمار الصناعية لتتبع السفن وكشف الدخول غير المصرح [23]. لكن بيانات AIS تقتصر على حالة السفينة الراهنة لقيود النطاق، ومع توسع أقمار LEO وتحقق MASS تدريجيًا، تلزم طرق إيصال بيانات أوسع لفتح قدرات السفن الذاتية المتقدمة.
إلى جانب AIS، تولد حساسات المحركات بيانات آنية عن الحالة التشغيلية، وتسهم بحوث في بناء منصات تجمعها وتوسّع المشاركة بين السفن والشاطئ: إطار ملاحة إلكترونية يربط السفن غير المأهولة بالأنظمة الشاطئية عبر إنترنت الأشياء (التعرف الذكي ودمج الحساسات والاتصالات) [24]، وإطار اتصالات آلية MTC للتواصل الفعال بين السفن الطرفية وأنظمة السحابة بالوصلات قصيرة المدى والعريضة [6]، وطرق مثلى آمنة واقتصادية باستخدام بيانات الطقس [25]، وبيئات محاكاة تدريب المشغلين OTS التي تحاكي ظروف التشغيل لتدريب الطاقم والأنظمة دون زيارة الموقع [26] — وثبت أن التدريب عن بُعد عبر OTS يحسّن مهارات الملاحة لمشغلي MASS [27] — وتخصيص موارد ضمان جودة البرمجيات SQA بالتنبؤ بالعيوب من البيانات التاريخية [28]، ومنصات خدمة إنترنت أشياء سحابية [10، 11، 29] مستفيدة من قابلية السحابة للتوسع والمرونة والأمن والتوافر [30] ومنصات AWS IoT وAzure IoT وWatson IoT وThingWorx وGoogle IoT [31]، وأشهرها AWS IoT بمراجع وبحوث تصميم مستمرة [32، 33]. لكن السفن الكبيرة للتجارة العالمية وشركاتها الموزعة عالميًا والاستخدام المتزايد لأجهزة إنترنت الأشياء يجعل تحسين الجودة ضمن السحابة الأحادية مهمة شاقة، فيصبح نموذج الحوسبة الضبابية ضروريًا — رغم أن دمجه مع أنظمة أتمتة السفن الكبيرة ما يزال غير مستكشف. لذلك تقترح الدراسة منصة متجذرة في نموذج سحابة الضباب متعدد المناطق لتعزيز التزامن الشاطئي بربط سلس مع نظام الأتمتة على متن السفينة، وتمكين مشاركة البيانات الآنية للمسارات المخططة والنوايا الملاحية عبر سحابة الضباب في المنطقة نفسها لتحسين تجنب التصادم ببيانات مؤكدة — مع نمذجة وقياس فقدان الحزم لمقارنة السحابة الأحادية بسحابة الضباب متعددة المناطق عبر AWS (القسم 2.4).
استعدادًا لعصر MASS، تلزم منصة متعددة الاستخدامات تستوعب المتطلبات المميزة لكل خدمة مع مراعاة خصائص حركة السفن. ويقدم القسم 3 منصة بيانات سحابية متعددة الخدمات تشمل سحابة ضبابية متعددة المناطق مع إطار تشغيلي يتيح عمل خدمات متنوعة على المنصة الموحدة بقابلية وتوسعية تمهد لأنظمة السفن الذاتية. فتبرز سحابة الضباب مكونًا حاسمًا يستثمر موارد أجهزة إنترنت الأشياء ويعزز جودة الخدمة قرب المستخدمين [9]، ومع نشر مئات الحساسات والمشغلات للملاحة الآلية والتحكم بالمحركات [1]، توفر حلًا واعدًا مع تزايد السفن المجهزة. وتؤدي دورًا محوريًا في تبادل البيانات السلس والعمليات الوظيفية الآنية بين السفن المتصلة والمنشآت الشاطئية أو السفن الأخرى، مشكّلة شبكة ديناميكية للتواصل والتعاون الآني. ويوضح الشكل 3 طوبولوجيا المنصة: مركز سحابي لإدارة البيانات وتطوير الخدمات، وسحابة ضبابية محسّنة لتنفيذ الخدمات، مع اتصال سلس بسحابة ضبابية تتكيف حسب الموقع، عبر قناة Edge Secure Channel آمنة بتفاصيل توفير الأجهزة العالمية المسجلة مسبقًا للاتصال المشفر.
يمكن للعملاء في المنطقة نفسها (الموانئ واللوجستيات) تطوير خدمات عبر سحابة الضباب بسلاسة، بينما تُبنى خدمات سفينة محددة (كشركة شحن) ببيانات مخزنة من المركز السحابي — المقتصرة على الخدمات المتسامحة مع زمن أعلى لأنها جُمعت عبر سحابة الضباب في موقع السفينة. ويصل العملاء لخدمة الويب عبر الإنترنت العام، ويدير المركز السحابي البيانات المجموعة ويشرف على توزيع البرمجيات وتشغيلها على خادم الحافة وسحابة الضباب بكل منطقة، فينشر المطورون الخدمات الجديدة بكفاءة بتحليل بيانات المركز. أما البنية الوظيفية للمتن والشاطئ (القسم 3.1.2) فتكيّف بنية الضباب المدروسة [9، 34]: أربع طبقات (خدمة إنترنت الأشياء وجمع البيانات، فالضباب، فالسحابة)، ونموذج حافة-ضباب-سحابة للزراعة [34]، وتطبيقات بحرية مماثلة [10، 11] — مقسمة هنا لمتن وشاطئ (الشكل 4): فيجمع خادم الحافة بيانات نظام الأتمتة ويجري معالجة ETL ويقدم خدمات للبحارة ويدير الاتصال عبر نقطة دخول موحدة تحدد أقرب سحابة ضبابية وتحافظ على الاتصال بها؛ وتُوزع على سحابة الضباب الخدمات عالية الآنية (تجنب التصادم للعمليات الذاتية أو التحكم بالمحركات) لتفادي التأخير؛ ويتصل المركز السحابي بسحب الضباب عبر شبكة سحابية افتراضية مستودعًا للبيانات، مع تخزين مسبق لما يلزم العملاء إقليميًا.
يحدد القسم 3.1.3 (الشكل 5) المكونات والترابطات حسب الطبقة: طبقة معالجة البيانات (الاكتساب والتخزين والإدارة — يترجم خادم الحافة بيانات السفن لنموذج المنصة ويوزعها لخدمات المتن أو يرسلها للشاطئ، وتُدار دورة حياة البيانات شاطئيًا: أساسية فقط في سحابة الضباب، وتخزين شامل في المركز حسب سياسة الاحتفاظ للتحليل والاستعادة)؛ وطبقة التبادل (تبادل البيانات والوظائف بين السفن أو المتن/الشاطئ — اتصال دائم بين الحافة وأقرب سحابة ضبابية تحكم المصادقة والعناصر الوظيفية لخدمات آمنة مستقرة)؛ وطبقة التطبيق (تشغيل التطبيق الخاص بكل مكون مع توسعية حسب الحجم والهدف — ثابتة للحافة والمركز، ومتغيرة لسحابة الضباب حسب الموقع وحركة السفن، بمعجّلات شبكة وموازنات حمل). ويُعبر عن زمن التأخير الكلي لمعالجة البيانات والطلبات الواردة من خادم الحافة شاطئيًا بالمعادلة (1): Ltot = LT(i)fog + LP(i)tot + LService(i)fog حيث LT زمن إرسال المهمة i لسحابة الضباب (حسب حجم حزمة الطلب)، وLP إجمالي زمن المعالجة شاطئيًا، وLService زمن تقديم الخدمة. وبما أن المعالجة الشاطئية تتم متوازية في سحابة الضباب والمركز، فإن LP(i)tot = max(LP(i)fog, LP(i)cloud) + LT(i)onshore وفق المعادلة (2). ومع تجوال السفن عالميًا، تتفاوت أزمنة السحابة الأحادية حسب المسافة وحالة الشبكة، بينما تقللها بنية الضباب متعددة المناطق وتثبتها، وتخفض الإجمالي بالتشغيل المتوازي مع المركز.
يقترح القسم 3.2 تبادل بيانات الملاحة بين السفن لتجنب التصادم: فتعتمد السفن على AIS القانوني لاستقبال بيانات المجاورة وبث بياناتها، مضمّنة الحالة الملاحية في رسائل تقارير الموقع [20] — لكنها لا تقدم إلا الموقع والحالة الراهنين. لذا تُشارك المنصة لا المسار المخطط فحسب بل معلومات السفن المحيطة. وبما أن رقم MMSI المدخل يدويًا قد لا يضمن التفرد، تطلب السفينة رقم التعريف الفريد SIN بالاشتراك من خدمة سحابة الضباب باستخدام MMSI والموقع، ويستخرج خادم الحافة بيانات محددة (الجدول 1) من نظام الأتمتة وينشرها لسحابة الضباب عبر MQTT أثناء التشغيل: مواضيع ais/vdo/[SIN]/cab لسفينتنا (دون احتفاظ)، وais/vdi/[SIN]/cab للسفن الأخرى (دون احتفاظ)، وroute/voyage/[SIN]/rtz للمسار المخطط قيد الملاحة (مع احتفاظ). وتنشر كل سفينة دوريًا بيانات AIS والمسار، وتطلب SIN للمياه المحيطة بمعلومات MMSI والموقع، فيعرّف SIN السفينة على المنصة للاشتراك والاستقبال (الشكل 6): فـ SIN1 تنشر دوريًا، وعند دخولها مدى استقبال SIN2 تحصل SIN2 على معلوماتها عبر سحابة الضباب لتجنب التصادم، وحتى SIN3 خارج المدى تحصل استباقيًا على معلومات SIN1 المستقبلية عبر بيانات SIN2، بينما تلغي SIN4 خارج مدى SIN2 الاشتراك لوقف الاستقبال. وتعزز سحابة الضباب عدد المشتركين مقارنة بالسحابة الأحادية، لكن الاشتراط المفرط يسبب فقدان حزم حسب خصائص الاتصال اللاسلكي وظروف المنطقة، فيلزم إلغاء الاشتراك خارج مدى الاستقبال ونمذجة إجمالي المشتركين المستقرين.
تقدم الخوارزمية 1 دليلًا لإدارة إجمالي السفن المشتركة بحساب احتمال فقدان الحزم المرتبط بكثافة السفن: فالقدرة على الاشتراك عند عتبة Ploss_th تحكمها Ploss (مؤشر استقرار الاتصال بالمنصة) — مرتفعة في السحابة الأحادية لبعد المنطقة المتصلة، ومنخفضة في سحابة الضباب متعددة المناطق باستقرار أفضل. المدخلات: بيانات AIS الجديدة AISnew، وعدد المشتركين Nsub، وتوزيع عدد الرسائل المستقبلة Pmsg، وتوزيع الفقد حسبها Ploss، والفقد الكلي Ploss_tot(Nsub)، والعتبة Ploss_th؛ والمخرج قرار الاشتراك Rsub: تُهيأ Ploss حسب المنطقة والموقع، وتُستخرج MMSI والموقع، ويُطلب SIN الجديد، فإن وُجد حُسب Pmsg(Nsub+1) ثم Ploss_tot، فإن كان دون العتبة اشترك وزاد العدّ وإلا امتنع. وإن حدث فقدان فقد يستدعي إعادة إرسال تشكل خطرًا ملاحيًا، فيُنصح بالاشتراك دون العتبة وتُجنّب فوقها. وتدير الخوارزمية 2 إلغاء الاشتراك بمعيارين: مهلة استقبال AIS (تُراقب RTsub لآخر استقبال — وبما أن السفن تبث كل 3 دقائق على الأقل، فتجاوز 3 دقائق دون استقبال يعني مغادرة المدى فيُلغى تلقائيًا)، وأهمية معلومات السفينة (الموقع والسرعة والمسار — فعند رفض الخوارزمية 1 سفينة جديدة تُقارن الأهميات ويُلغى اشتراك الأقل أهمية لإفساح المجال). وتُنمذج القسم 3.2.3 توزيع استقبال AIS بتوزيع Poisson: Pmsg = P(N(t)=k) = e^(−λ(t))·λ(t)^k/k! حيث λ(t) = λ0·D(t) وفق المعادلة (3)، وD(t) عدد السفن المجاورة وλ0 متوسط معدل الإرسال للسفينة وk عدد البيانات المستقبلة. ومن دورات الإرسال الست حسب الحالة التشغيلية (الجدول 2 [35]: راسية دون 3 عقد 3 دقائق؛ راسية فوقها 10 ثوانٍ؛ 0–14 عقدة 10 ثوانٍ؛ مع تغيير الاتجاه 3 و1/3 ثانية؛ 14–23 عقدة 6 ثوانٍ؛ مع التغيير 2 ثانيتين؛ فوق 23 عقدة 2 ثانيتين) يُحسب λ0 = 6/(10+3⅓+6+2+2+2) = 0.2369 وفق المعادلة (4)، فيصبح التوزيع P(N(t)=k) = e^(−λ(t))·(0.2369·D(t))^k/k! وفق المعادلة (5)، مما يضبط عدد المشتركين ليبقى معدل الرسائل/ثانية دون حد يتفادى الفقد. وتضمن استراتيجيات التوسعية (القسم 3.3): خادم الحافة (صيغة موحدة لمواضيع MQTT وهياكل القيم وواجهات API مع تهيئة قابلة للتخصيص)، وسحابة الضباب (نمط [الوظيفة]/[الكائن]/[SIN]/[نوع البيانات] مع فهرسة برقم السفينة تتيح التوسع بمنح الأذونات فقط)، والمركز السحابي (توليد الوظائف وتوزيعها بصيغ موحدة تسهل تطوير الخدمات).
يكشف هذا الفصل نتائج تطوير معمارية منصة سحابة الضباب متعددة المناطق باستخدام AWS المصممة لمفهوم السفن متعددة الخدمات من القسم 3، مع تقييمات اتصال شبكية شاملة عبر المناطق العالمية لقياس مزايا البنية حين تكون مصادر البيانات (السفن) متحركة عالميًا والعملاء متفرقين جغرافيًا. ويوضح الشكل 7 المعمارية متعددة المناطق على AWS: يُنصح بتموضع المركز السحابي في منطقة نشاط مشغل المنصة وتطوير الخدمات، وتوزع سحب الضباب في مناطق تركز نشاط السفن أو شركات الشحن والموانئ اللوجستية. ويتضمن البناء AWS Global Accelerator [36] لتنسيق شبكة فعالة بأقل زمن وصول عندما تمتد سحابة الضباب لأوروبا والأمريكتين وآسيا، فيصل المستخدمون لبياناتهم الإقليمية ويولدون بيانات أنظمة OLTP من التحليل أو الطلبات. وبما أن السفن متحركة عالميًا، تتصل بأقرب نسخة إقليمية بتوجيه الموقع الجغرافي عبر AWS Route53 [37] كنقطة دخول مشتركة ذكية تحقق الزمن الأمثل، فيرتبط خادم الحافة بسحابة الضباب الموفّرة عالميًا لخدمات رصد البيانات وتخطيط الطرق بالطقس والتحديثات البرمجية السلسة. وتُخزن البيانات المحصودة في سحابة الضباب للخدمات المحلية وفي المركز للتحليل والرصد الشامل — تحتفظ سحابة الضباب ببيانات قصيرة الأمد وتستورد من المركز عند الحاجة لإدارة ديناميكية فعالة. ويعمل المركز محورًا للمطورين والمشغلين لتطوير الخدمات وصيانة البرمجيات، وموطنًا لأنظمة OLAP كثيفة الموارد والبيانات، مع بيئة DevOps متكاملة لإدارة الشيفرة والبناء والنشر لبيئة الاختبار ثم التوزيع لبيئات النشر في كل سحابة ضبابية (خادم حافة السفينة وبيئة حاويات سحابة الضباب).
أُجريت اختبارات تحسين أداء الشبكة بسحابة الضباب متعددة المناطق بقياس RTT وPLR في المنطقة نفسها ومناطق مختلفة (إعداد الشكل 8): حاسوب محمول كسفينة في منطقة سيول ينشر ويشترك برسائل إلى IoT Core كوسيط MQTT عبر ثلاث مناطق (سيول وكاليفورنيا وفرانكفورت). وقيس زمن الاستجابة بـ RTT بين إرسال الحزم المنشورة واستقبالها، حتى 120 كيلوبايت (بزيادة 20 كيلوبايت من 20) — الحد الأقصى لـ IoT Core هو 128 كيلوبايت — بخدمة QoS 0 مكررًا 100 مرة لكل حمولة (الشكل 9 صندوقيًا). ومن سيول، كان أدنى وسيط RTT في سيول (0.072–0.175 ثانية)، ثم كاليفورنيا (0.21–0.292)، وأعلاها فرانكفورت (0.326–0.400)؛ وبمقارنتها بسيول (الشكل 10) تتباين الحمولات الصغيرة أكثر: فعند 20 كيلوبايت تراوح الفرق بين ضعفين وخمسة أضعاف، وعند 120 كيلوبايت نحو ضعفين. وبأداة Azure Speed Test مفتوحة المصدر [38] قيس زمن مناطق سيول وكاليفورنيا وفرانكفورت: 45 و150 و193 ms (الشكل 11) — فإذا اختلفت سحابتا AWS وAzure معًا زاد الزمن بنحو أربعة أضعاف أو أكثر. وقُيّم PLR بزيادة معدل توليد الحزم PGR لكل حمولة بإعداد QoS0: بعد الاتصال تُنشر 100 حزمة حسب PGR ويُحدد PLR بعدّ المستقبلة عند الاشتراك، مكررًا 10 مرات لكل حمولة ومنطقة. وعبر كل المناطق ومعدلات PGR، كان PLR صفرًا عند حمولة 60 كيلوبايت أو دونها، وبدأ الظهور فوق 80 كيلوبايت (الشكل 11/12): فبدأت فرانكفورت الأعلى زمنًا توليد الفقد عند PGR قدره 3 Hz، وكاليفورنيا عند 5 Hz، مقابل سيول عند 20 Hz. ولم يتصاعد PLR باطراد مع PGR بل تقارب عند مستوى معين، ومعظم الفقد في الرسائل المنشورة قبل العشرين. وتؤكد النتائج أن الخدمات المحتاجة استجابة بضع مئات من الميلي ثانية لا تحافظ على الجودة المثلى إلا بتشغيلها في سحابة المنطقة نفسها، مع احتمال فقدان عند إعادة الاتصال بـ IoT Core فوق 60 كيلوبايت — فيُنصح بهيكلة الخدمات الحساسة للفقد في المنطقة نفسها، أو استخدام QoS1 عند غياب قيود الحركة. ومع تزايد مكونات التحكم الدقيقة (أنظمة غاز LNG والدفع الكهربائي والمولدات) سيرتفع الطلب على الخدمات السحابية المتفاعلة، خاصة مع تقدم السفن الذاتية، فتقدم منصة سحابة الضباب متعددة المناطق حلًا للاتصال اللازم أثناء التجوال العالمي.
يقترح القسم 4.3 استخدام بيانات السفن عبر المنصة لتجنب التصادم الفعال بالتعرف على المجاورة عبر AIS والاشتراك في بياناتها — لكن الاتصالات الفضائية البحرية مكلفة حسب الحركة وقد يؤدي الفقد لحوادث سلامة، فيلزم الحفاظ على حركة مناسبة. ويُعرّف احتمال الخطأ الشامل بجمع احتمال الخطأ من نموذج القسم 3.2.3 والقيم المقاسة تجريبيًا في القسم 4.2 وفق المعادلة (6): P(L) = ∑ P(L|K=k)·P(K=k) حيث P(L|K=k) احتمال الفقد عند معدل توليد الرسائل وP(K=k) احتمال توليد k رسائل. ويوضح الشكل 13 توزيع معدل الفقد المقاس حسب المنطقة بتوزيع Poisson وحمولة 80 كيلوبايت عند 10 و50 و100 سفينة مشتركة مجاورة: فيزداد عدد الفقد مع حزم/ثانية ثم يستقر فينخفض معدل الفقد مع k، ويحسب الشكل 14 قيم P(L) لكل منطقة حسب عدد السفن. ففي المناطق الأخرى عند 50 أو 100 سفينة يتداخل توزيع عدد الحزم المستقبلة k مع مقطع حدوث الفقد فيرتفع الاحتمال عن المنطقة نفسها: ففي بيئة 100 سفينة كانت معدلات الفقد في كاليفورنيا وفرانكفورت أعلى بنحو 5 و27 مرة على التوالي منها في المنطقة نفسها — مما يؤكد أن الاتصال بسحابة المنطقة نفسها يزيد كثيرًا عدد السفن المشتركة بمعدل فقدان منخفض في المناطق عالية الكثافة (الشكل 14).
تعتمد التجارة العالمية على السفن الكبيرة العابرة للمحيطات بإشراف شركات عالمية، ويشكل الاعتماد المتزايد على أجهزة إنترنت أشياء السفن تحديًا كبيرًا لتحسين الجودة ضمن السحابة الأحادية التقليدية، فيصبح نموذج الحوسبة الضبابية ضرورة — بينما يبقى دمجه مع أنظمة أتمتة السفن الكبيرة مجالًا غير مستكشف. وتقدم الورقة منصة بيانات مرتبطة بأنظمة أتمتة السفن تراعي خصائص حركتها الفريدة، بإنشاء سحب ضبابية متعددة عالميًا تتصل بها السفن في مناطق الزمن الأدنى، مع مشاركة فعالة لبيانات الرحلات المخططة بين السفن. وبينما ترتكز بحوث تجنب التصادم الحالية على بيانات الملاحة الراهنة، تفتح الورقة تحسين الأداء بمشاركة البيانات المخططة — مع الإقرار بتضخيمها للحركة وارتفاع احتمال الفقد في المناطق الكثيفة بازدياد الحركة/وحدة الزمن.
لتقييم احتمال الفقد، نُذج عددُ الرسائل المستقبلة/وحدة الزمن بتوزيع Poisson حسب عدد السفن المشتركة المجاورة، وجُمع مع معدل الفقد المقاس عبر AWS وقُورن الاتصال في المناطق الأخرى بالبنية الأحادية مع المنطقة نفسها في البنية المقترحة: فعند 100 سفينة كان احتمال الفقد أعلى بنحو 28 مرة للاتصال في المنطقة الأخرى منه في المنطقة نفسها — وتتيح طريقة الحساب هذه إدارة فعالة لعدد السفن المشتركة لتخفيف الفقد عبر نهج الإدارة المقترح. ونُفذت البنية وقُيّمت مزايا الشبكة متعددة المناطق عبر AWS: معمارية شاملة بـ IoT Core في سيول وكاليفورنيا وفرانكفورت لقياس RTT وPLR، فتفاوتت فروق RTT حسب الحمولة وحققت سيول الأدنى باستمرار (0.072–0.175 ثانية)، وظهر الفقد غالبًا بداية الاتصال (نحو 10–20 Hz في المنطقة نفسها و3–5 Hz في المناطق الأخرى).
أخيرًا، تحقق عمليًا تطوير الوظائف وتوزيعها على المنصة بإنشاء خدمة ويب لرصد عمليات السفن: طُوّرت الوظائف ونُشرت عبر شيفرة حوسبة عديمة الخوادم ثنائية وصور Docker، عارضة بيانات السفن المجموعة عبر خادم الحافة على الواجهة. وأرست الدراسة أساسًا متينًا لبحوث مستقبلية: تجنب التصادم للأجسام غير المستقبلة للمعلومات (تمكينها بالمشاركة عبر سحابة الضباب بالتعرف على المحيط والاستجابة)؛ وتطبيق سحابة الضباب لخدمات متنوعة (تحسين الطرق بالطقس، ومحاكيات التدريب، وخفض انبعاثات الكربون)؛ وتوسيع قابلية المنصة ومرونتها مع نمو السفن والخدمات ونقاط البيانات — لصناعة بحرية أكثر أمانًا وكفاءة وتقدمًا تقنيًا.
As technologies such as eco-friendly ships, electric propulsion vessels, and multi-fuel propulsion systems advance, the scope of IoT applications in maritime fields is expanding, resulting in increased complexity in control factors. The gradual progression towards Maritime Autonomous Surface Ships (MASS) is further driving the evolution of ship-based IoT applications. These advancements underscore the necessity for a platform capable of ensuring reliable connectivity between ships and onshore. The limitations of the existing single cloud architecture become evident in this context.
In response to these emerging challenges, this paper presents a cloud-based data platform structure anchored in the architecture of a multi-region fog cloud. Concurrently, we propose a strategic approach aimed at enhancing collision avoidance performance. This is achieved through the seamless sharing of navigation plan data among ships facilitated by the proposed platform structure. Results demonstrate that with 100 nearby ships subscribing to data, when the regions differed, packet loss was about 28 times higher than in the same region.
The platform is built using the AWS cloud and evaluated through Round Trip Time (RTT) and Packet Loss Rate (PLR) measurements across regions, proving that connecting to the same-region fog cloud greatly expands the number of subscribable ships at low loss rates in high-density areas, laying a solid foundation for maritime IoT and cloud computing research.
Automation systems and IoT integration are ushering in a transformative era for maritime operations [1], giving rise to smart ships, remote operating vessels, and digital twin ships [2, 3]. Recognizing this potential, the International Maritime Organization (IMO) actively discusses safe operation of Maritime Autonomous Surface Ships (MASS) — vessels navigating with minimal or no human intervention, in four automation stages [4]. Growing MASS recognition demands addressing data sharing, communication [5], and ship–onshore interoperability [6]; efficient data management, real-time monitoring and informed decision-making are paramount for safety, efficiency and performance [7].
Hence a robust, versatile IoT-based cloud data platform interacting with existing ship automation systems and developing new services is essential. This paper presents a novel cloud-based horizontal data platform tailored to maritime multi-service support using ship-collected IoT data: the horizontal platform lets multiple ships and services operate organically on one unified platform [8], integrating new services by adjusting architectural elements. Since ships traverse the globe under worldwide-distributed companies, consistent service quality through a single cloud is challenging; this paper introduces a platform of multiple Fog Clouds plus one global Cloud Center, letting the Edge Server (collecting/managing ship data) interact with the lowest-latency regional Fog Cloud, with data transferred to and managed in the Cloud Center under a standardized data structure and interface simplifying new-service development.
Fog computing paradigms have gained popularity for maximizing IoT-device resource utilization, extending quality of service to the user's vicinity and enabling rapid processing in dynamic IoT-cloud ecosystems [9], with maritime studies exploring efficient fog-based data collection and offloading optimization [10, 11]. Section 3 designs a hierarchical platform distinguishing onboard from onshore, with stakeholders and functional elements per layer — Edge Server, Fog Cloud, Cloud Center components — leveraging connectivity benefits (latency, packet loss) for a collision-avoidance data-sharing method. Prior research predicted collisions from current navigation status via complex sensing, whereas this paper shares current status plus planned route and navigation status through the platform — improving performance with confirmed plan data at the cost of extra traffic — modeling packet loss with a Poisson distribution over the AIS-data reception period, showing ~28× higher loss across differing regions. Section 4 implements the architecture on AWS with RTT and PLR tests across regions to assess same-region network benefits.
Over the past decade, substantial "e-navigation" and "MASS" research has automated ship operation and management, applying maritime IoT to merge operational technology (OT) with information technology (IT) into automated systems minimizing human intervention. This includes collision-avoidance measures for safe navigation ahead of the autonomous-ship era [12], enhancing functions and creating services through data sharing and management via ship-to-ship or ship-to-onshore communication [6], and grounding MASS by integrating ship automation with onshore solutions through a cloud platform bridging ships and onshore entities [10, 11].
The ship automation system aids informed decisions by collecting operational data and integrating control components (Figure 1): the Integrated Navigation System (INS) — ECDIS, RADAR, Track Control System (TCS), Bridge Alarm Monitoring System (BAMS), Autopilot — plans and executes routes per IEC61924-2 defining modular structure, performance criteria and sensor monitoring [13]. While traditional INS visualizes data for humans, research aims at autonomous perception-driven navigation with stable collision-avoidance algorithms, guidance and control [14, 15]. The Integrated Control and Monitoring System (ICMS) is a decentralized machinery/electrical controller (Figure 2): a green equipment-control zone and an orange Operator Work Station (OWS) with HMI for monitoring/direct control. Rising eco-friendly ships (LNG carriers, electric propulsion, Dual Fuel engines) diversified ICMS control factors, driving digital-twin environments [16] and virtual-simulation integration [17] — yet real-ship deployment demands a real-time data platform seamlessly connecting and managing ship data.
Navigation sensor data follows IEC61162-1 [18] (serial) and IEC61162-450 [19] (Ethernet); AIS extracts these and broadcasts location/voyage messages over VHF with shorter periods for faster vessels. AIS messages carry navigation status (types 1, 2, 3) [20] revealing current status and surroundings, forwarded to the INS network via IEC61162-1 [18] for display. AIS-data studies improve performance: trajectory clustering for path prediction and collision avoidance [21], preprocessing for massive-data management and route monitoring [22], and overcoming VHF range limits from Earth's curvature via satellites tracking ships and detecting unauthorized access [23]. But AIS is confined to current-ship-state data by bandwidth; with expanding LEO satellites and gradual MASS realization, broader delivery methods are imperative for advanced autonomous capabilities.
Alongside AIS, engine-system sensors generate real-time operational data, with research building platforms gathering ship data and expanding ship–onshore sharing: IoT for unmanned ships (intelligent recognition, sensor fusion, communication) in an E-Navigation framework linking ships to shore [24]; a Machine-Type Communication framework for peripheral-ship-to-cloud exchange over short-range and broadband links [6]; weather-forecast optimal routing for safe, cost-effective performance [25]; Operator Training Simulator (OTS) environments replicating operating conditions for crew/system collaboration without site visits [26] — remote-OTS training demonstrably improving navigation skills toward MASS remote operators [27]; Software Quality Assurance (SQA) resource allocation predicting defects from historical data [28]; and cloud-based IoT service platforms [10, 11, 29] leveraging cloud scalability, flexibility, security and availability [30], including AWS IoT, Azure IoT, Watson IoT, ThingWorx and Google IoT [31], with AWS IoT the most-used with continuous design research [32, 33]. But large global-trade ships under worldwide companies and growing ship-IoT use make quality improvement within single-cloud confines daunting — Fog computing is imperative, though its integration with large-vessel automation remains unexplored. This study therefore proposes a multi-region Fog Cloud platform boosting onshore concurrency via seamless linkage with onboard automation, enabling real-time planned-route and intention sharing within same-region Fog Clouds for confirmed-plan collision avoidance — with packet-loss modeling and measurement comparing single-cloud versus multi-region fog-cloud communication over AWS (Section 2.4).
For the MASS era, a versatile platform accommodating each service's requirements alongside ships' movement characteristics is paramount. Section 3 introduces a cloud-based multi-service data platform with a multi-region Fog Cloud and an operational framework for diverse services on one unified, adaptable, scalable platform paving the way to autonomous ships. The Fog Cloud is pivotal, harnessing IoT-device resources while enhancing near-user service quality [9]; with hundreds to thousands of sensors/actuators for automated navigation and engine control [1], it is promising as equipped ships grow. It enables seamless data exchange and real-time operations between ships and onshore facilities or other ships — a dynamic network for effortless real-time communication and collaboration. Figure 3 shows the topology: a data-management/service-development Cloud Center plus an execution-optimized Fog Cloud, with seamless connection to a location-adaptive Fog Cloud via a secure Edge Secure Channel using pre-registered global device provisioning for encrypted vessel communication.
Same-region clients (ports, logistics) develop services seamlessly through the Fog Cloud, while designated-ship services (e.g. a shipping company) use Cloud Center cached data — restricted to higher-latency-tolerant services since collected via the ship-location Fog Cloud. Clients access Fog Cloud Web Services over the public Internet; the Cloud Center manages collected data and supervises software/service distribution and operation on each region's Edge Server and Fog Cloud, letting developers deploy and enhance services by analyzing Cloud Center data. The onboard/onshore functional structure (Section 3.1.2) adapts studied fog structures [9, 34]: four-layer frameworks (IoT service/data-collection, fog, cloud), an edge-fog-cloud agricultural model [34], and marine applications [10, 11] — here split onboard/onshore (Figure 4): the Edge Server collects automation-system data, performs ETL processing, serves seafarers, and manages worldwide-mobility connectivity via a unified cloud entry point locating the nearest fog cloud and sustaining that connection; the Fog Cloud hosts high-real-time services (collision avoidance for autonomy, engine safety control) interacting with the Edge Server to avoid delay; the Cloud Center connects to regional Fog Clouds over a Virtual Cloud Network as a repository for Edge- or service-generated data, with the Fog Cloud pre-caching client-serving regional data.
Section 3.1.3 (Figure 5) details components and interconnections per layer: Data Processing Layer (acquisition, storage, management — the Edge Server translates ship-model data into the platform model for onboard services or onshore transmission; onshore lifecycle management keeps only essential data in the Fog Cloud and retention-policy storage in the Cloud Center for analysis/restoration); Exchange Layer (ship-to-ship and onboard/onshore data/function exchange — persistent Edge-to-nearby-fog connections with fog-governed authentication and functional elements for secure, stable provisioned services); Application Layer (per-component service-specific operation with scale-appropriate scalability — static for Edge Server and Cloud Center, variable for the Fog Cloud by user location and ship mobility, with Network Accelerator and Load Balancer). Onshore processing/service delay for edge-server data and requests is given by Equation (1): Ltot = LT(i)fog + LP(i)tot + LService(i)fog, where LT is Task-i transmission latency to the Fog Cloud (request-packet-size dependent), LP total onshore processing time, and LService service-provision delay. With parallel onshore processing in Fog Cloud and Cloud Center, LP(i)tot = max(LP(i)fog, LP(i)cloud) + LT(i)onshore per Equation (2). Single-cloud delays vary with cloud distance and network state amid worldwide ship mobility, while the multi-region Fog Cloud minimizes and stabilizes delay, further reduced by parallel Cloud Center operation.
Section 3.2 proposes ship-to-ship navigation data exchange for collision avoidance: ships rely on statutory AIS for nearby-vessel data and own-data dissemination, with navigation status in position-report messages broadcast to ships and coastal stations [20] — but only current location and status. The platform additionally shares planned routes and surrounding-ship information. Since user-entered MMSI numbers cannot guarantee uniqueness, a ship requests the unique subscription ID, Ship Identification Number (SIN), from the Fog Cloud service using MMSI and location; the Edge Server extracts specified data (Table 1) from the Ship Automation System and publishes it to the Fog Cloud via MQTT during operation: own-ship AIS topics ais/vdo/[SIN]/cab (not retained), other-ship AIS ais/vdi/[SIN]/cab (not retained), and planned route under navigation route/voyage/[SIN]/rtz (retained). Each vessel periodically publishes AIS, surrounding-AIS and route-plan data; SIN is requested/received via surrounding-water MMSI and position, identifying the ship for subscription and receipt (Figure 6): SIN1 publishes periodically; as SIN1 enters SIN2's AIS reception range, SIN2 receives SIN1 data via the Fog Cloud for collision avoidance; even out-of-range SIN3 proactively obtains future-encounter SIN1 data through SIN2-published nearby-vessel data; out-of-SIN2-range SIN4 unsubscribes to stop reception. Fog Cloud connectivity raises subscribable ship counts versus Single Cloud, but excessive subscriptions cause packet loss depending on wireless characteristics and regional cloud conditions — requiring unsubscription beyond reception range and modeling of stably receivable subscriber totals.
Algorithm 1 guides total-subscribed-ship handling by computing ship-density-linked packet-loss probability: subscribability at threshold Ploss_th is governed by Ploss (platform-connection-stability indicator) — typically high in single-cloud structures from cloud-region distance, mitigated in multi-region fog clouds via stable connectivity. Inputs: new AIS data AISnew, subscribed count Nsub, received-message-count distribution Pmsg, loss distribution by Pmsg Ploss, total loss Ploss_tot(Nsub), threshold Ploss_th; output subscription decision Rsub: initialize Ploss by region/location, extract MMSI and position, request new SIN; if it exists compute Pmsg(Nsub+1) then Ploss_tot, subscribing (Nsub+1) below threshold and declining above. Loss can trigger retransmission traffic posing navigation safety hazards, so below-threshold subscription is advised and above-threshold avoided. Algorithm 2 manages unsubscription by two criteria: AIS reception timeout (monitoring last-reception time RTsub — ships transmit at least every 3 min, so over 3 min without reception implies out-of-range departure and automatic unsubscription) and ship-information importance (location, speed, trajectory — when Algorithm 1 rejects a new ship, importance levels are compared and lower-importance existing subscribers unsubscribed to admit new ships). Section 3.2.3 models AIS reception counts with the Poisson distribution: Pmsg = P(N(t)=k) = e^(−λ(t))·λ(t)^k/k!, λ(t) = λ0·D(t) per Equation (3), with D(t) nearby-ship count, λ0 per-vessel average transmission rate, k received-data count. From the six operational-state transmission cycles (Table 2 [35]: anchored/moored ≤3 knots 3 min; anchored/moored >3 knots 10 s; 0–14 knots 10 s; 0–14 knots with course change 3⅓ s; 14–23 knots 6 s; with course change 2 s; >23 knots 2 s; with course change 2 s), λ0 = 6/(10+3⅓+6+2+2+2) = 0.2369 per Equation (4), giving P(N(t)=k) = e^(−λ(t))·(0.2369·D(t))^k/k! per Equation (5), regulating subscriber counts to keep per-second message rates below the loss-averting level. Scalability strategies (Section 3.3) cover: Edge Server (standardized MQTT topics, value structures, APIs with customizable configuration for new IoT/automation integration), Fog Cloud ([function]/[object]/[SIN]/[data type] MQTT pattern with ship-number indexing expanding via permission grants), and Cloud Center (function generation/distribution with uniform formats/APIs easing service development).
This chapter presents the AWS-built multi-region fog-cloud platform architecture for the Section-3 ship multi-service concept, with comprehensive global cross-region network assessments measuring the architecture's advantages when data sources (ships) are world-mobile and customers geographically dispersed. Figure 7 shows the AWS multi-region architecture: the Cloud Center is best placed in the platform operator's service-development region, with Fog Clouds distributed across concentrated ship-activity or shipping-company/logistics-port regions. Embedded AWS Global Accelerator [36] orchestrates an efficient minimal-latency network as the Fog Cloud spans Europe, the Americas and Asia, letting users promptly access own-domain Regional Data and generate/validate OLTP-system data from analysis or requests. With worldwide ship mobility, vessels connect to the nearest regional instance via Geo-location routing, with AWS Route53 [37] as the intelligent common entry point achieving optimal latency; the ship's Edge server links to the Global Device Provisioned Fog Cloud for data monitoring, weather-based route planning and seamless software updates. Harvested ship data resides in the Fog Cloud for localized services and in the Cloud Center for comprehensive analysis and monitoring — the Fog Cloud retaining short-term data and importing from the Cloud Center only as needed for efficient resource use. The Center serves platform developers/operators for service development and software maintenance, hosting resource-/data-heavy operations including the OLAP database, with an integrated DevOps environment for source configuration, build-based development and test-environment deployment, then distribution to each Fog Cloud's deployment environments (ship Edge Server and Fog Cloud container services).
Network-performance tests measured RTT-based latency and Packet Loss Rate (PLR) same-region versus cross-region (setup in Figure 8): a laptop as a Seoul-region vessel publishing/subscribing to IoT Core as MQTT broker across Seoul, California and Frankfurt. Latency used publish–receive RTT up to 120 KBytes (20-KByte steps from 20; IoT Core maximum 128 KBytes) at QoS 0, repeated 100 times per payload (Figure 9 box plot). From Seoul, the lowest median RTT was Seoul (0.072–0.175 s), then California (0.21–0.292 s), highest Frankfurt (0.326–0.400 s); versus Seoul (Figure 10), smaller payloads varied more across regions: 20 KB payloads differed two-to-five-fold, 120 KB about two-fold. Open-source Azure Speed Test measurements [38] gave Seoul/California/Frankfurt latencies of 45, 150 and 193 ms (Figure 11) — differing AWS and Azure clouds raise latency ~4× or more. PLR was evaluated as packet generation rate (PGR) increased per payload at QoS0: after connection, 100 packets published per PGR with PLR from subscription-received counts, repeated 10 times per payload and region. Across all regions and PGRs, PLR was consistently 0 at ≤60 KB payloads, emerging above 80 KB (Figures 11/12): highest-latency Frankfurt began generating PLR at 3 Hz PGR, California at 5 Hz, versus Seoul at 20 Hz. PLR did not escalate continuously with PGR but converged at a level, with most losses in pre-20th published messages. Results confirm that services needing several-hundred-millisecond responses sustain optimal quality only within same-region clouds, with reconnection packet-loss risk to IoT Core above 60 KB — so loss-sensitive services should be structured same-region, or use QoS1 without traffic restrictions. As high-precision controls (LNG gas systems, electric propulsion, generators) grow with autonomous ships, cloud-service demand for interacting with them will rise, and a multi-region Fog Cloud platform keeps ships connected worldwide.
Section 4.3 addresses error-rate variation with subscribed ship counts: using platform ship data for collision avoidance by AIS-recognizing nearby ships and subscribing — but maritime satellite communication costs scale with traffic and packet loss can cause safety incidents, requiring appropriate traffic levels. The comprehensive error probability combining the Section-3.2.3 probability model with Section-4.2 measurements is defined by Equation (6): P(L) = ∑ P(L|K=k)·P(K=k), where P(L|K=k) is loss probability at message generation rate and P(K=k) the k-message generation probability. Figure 13 shows measured regional loss-rate distributions under Poisson distribution at 80 KB payload with 10, 50 and 100 subscribed nearby ships: loss counts rise with packets-per-second then stabilize, so loss rate decreases with k; Figure 14 computes P(L) per region by ship count. In other regions at 50 or 100 ships, the received-packet-count-k distribution overlaps the loss-occurring section, giving higher loss probability than same-region: at 100 ships, California and Frankfurt loss rates were ~5× and ~27× higher than same-region — affirming that same-region cloud connection greatly increases subscribable ship counts at low loss rates in high-density areas (Figure 14).
Global trade relies on large ocean-going ships overseen by worldwide companies, and ever-growing ship-IoT adoption challenges quality improvement within traditional single-cloud limits — making the Fog computing paradigm a necessity, though its fusion with large-vessel automation remains underexplored. This paper introduces a ship-automation-linked data platform accounting for ships' unique movement: multiple worldwide Fog Clouds that ships join in minimal-latency regions, with efficient planned-voyage-data sharing among ships. While current collision-avoidance research hinges on current navigation data, this paper enables further improvement via planned-data sharing — while acknowledging traffic amplification and rising packet-loss probability with per-unit-time traffic in dense-ship areas.
For loss-probability evaluation, per-unit-time received-message counts were modeled with a Poisson distribution by nearby subscribed-ship count, combined with AWS-measured loss rates, comparing other-region single-cloud communication against same-region proposed-structure communication: at 100 ships, loss probability was ~28× higher for other-region communication than same-region — and this calculation method effectively manages subscriber counts to mitigate loss via the proposed subscription-ship management. Platform implementation and multi-region network-advantage assessment ran on AWS: a comprehensive AWS Cloud architecture with IoT Core in Seoul, California and Frankfurt measuring RTT-based latency and PLR, with payload-dependent RTT differences and Seoul consistently lowest (0.072–0.175 s), and loss emerging mostly at connection outset (~10–20 Hz same-region, 3–5 Hz other regions).
Finally, function development and distribution on the platform were practically verified through a ship-operation-monitoring web service: functions innovatively developed and disseminated via binary serverless computing code and Docker images, showcasing Edge-Server-collected ship data on the web interface. The study lays a strong foundation for future maritime-IoT and cloud-computing research: collision avoidance for non-information-receiving objects (fog-cloud-enabled participation via surrounding recognition and response); fog-cloud application to diverse services (weather-informed route optimization, training simulators, carbon-emission reduction); and expanding platform scalability and flexibility with growing ships, services and data points — toward a safer, more efficient, technologically advanced maritime industry.
Source: MDPI Electronics 2023, 12(20), 4250 · DOI: 10.3390/electronics12204250 · License: CC BY 4.0 · PDF