یک خودرو در یک کشور ساخته و در کشوری دیگر فروخته می‌شود. سیستم تماس اضطراری آن به یک ماژول سلولی متصل است، ماژولی که قبل از خروج خودرو از خط تولید راه‌اندازی شده و برای شبکه‌ای در بازاری تنظیم شده است که سازنده در آن فعالیت نمی‌کند. این سیستم برای چهار سال کار می‌کند. گزارش می‌دهد، ثبت‌نام می‌کند و از هر عیب‌یابی که می‌پرسد آیا متصل است یا خیر، سربلند بیرون می‌آید.

سپس اپراتور در آن بازار، یک نسل از شبکه خود را بازنشسته می‌کند. این کار یک‌شبه اتفاق نمی‌افتد، بلکه سال‌ها پیش در اسنادی اعلام شده است که هیچ‌کس در پروژه خودرو آن‌ها را نمی‌خوانده، زیرا پروژه خودرو در سال ۲۰۲۱ عرضه شده و تیم به سراغ کار دیگری رفته است.

ماژول خطایی نمی‌دهد. به چیزی متصل می‌شود. گزارش می‌دهد که آنلاین است. کاری که دیگر نمی‌تواند انجام دهد، برقراری همان یک تماسی است که برای آن وجود دارد.

هیچ‌کس متوجه نمی‌شود تا زمانی که یک نفر به آن نیاز پیدا کند.

اتصال سلولی جهانی برای خودروهای متصل

این همان حالت خرابی است که حوزه موبیلیتی را از تله‌ماتیک ناوگان متمایز می‌کند و ارزش دارد که با دقت به چرایی آن بپردازیم.

در حوزه لجستیک، اپراتور مالک وسیله نقلیه است. وقتی یک کامیون از دسترس خارج می‌شود، کسی که آن را حس می‌کند همان کسی است که می‌تواند کاری انجام دهد. حلقه بازخورد کوتاه و ناخوشایند است، که این خود نوعی موهبت محسوب می‌شود.

در حوزه موبیلیتی، طرفی که اتصال را انتخاب کرده و طرفی که خرابی را تجربه می‌کند، توسط یک زنجیره تأمین، نمایندگی فروش، یک مرز و اغلب یک دهه از یکدیگر جدا شده‌اند. یک خودروساز (OEM) یک ماژول و یک پروفایل اتصالی را در طول توسعه تعیین می‌کند و پیامدهای آن سال‌ها بعد گریبان‌گیر راننده‌ای در بازاری می‌شود که تیم اتصال آن خودروساز هرگز در آن فعالیت نکرده است. هیچ حلقه بازخورد کوتاهی وجود ندارد. اصلاً حلقه‌ای وجود ندارد.

سه ویژگی ساختاری از اینجا ناشی می‌شود که هیچ‌کدام ارتباطی با پوشش شبکه ندارند.

وسیله نقلیه در تمام طول عمر مفید خود یک رومر دائم است. در یک بازار ساخته شده و در بازار دیگری فروخته می‌شود و هرگز به شبکه مبدأ خود باز نمی‌گردد. هر اتصالی که این خودرو طی پانزده سال برقرار می‌کند یک اتصال رومینگ است که توسط توافق‌نامه‌های تجاری اداره می‌شود؛ توافق‌نامه‌هایی که بدون در نظر گرفتن ناوگان خودروهای وابسته به آن‌ها، مجدداً مذاکره، کم‌اهمیت یا بازنشسته می‌شوند.

سخت‌افزار به100 طراحی قابل دسترس نیست. یک واحد کنترل تله‌ماتیک پشت تریم قرار دارد، به باس خودرو سیم‌کشی شده و انتظار می‌رود که دوران گارانتی را دوام بیاورد. هیچ بازدید میدانی برای تعویض سیم‌کارت (SIM) وجود ندارد. اگر این را در تعداد تولید ضرب کنید، هزینه هر راه‌حل فیزیکی از ارزش ویژگی‌ای که قرار است تعمیر کند، بیشتر می‌شود.

هیچ‌چیز در این پشته به‌دنبال سکوت نیست. عیب‌یابی‌های خودرو به این سؤال پاسخ می‌دهند که «آیا ماژول متصل است؟» آن‌ها به این سؤال پاسخ نمی‌دهند که «آیا این وسیله نقلیه با موفقیت کاری را که قرار است انجام دهد، در این ماه، در این بازار انجام داده است یا خیر؟» این‌ها دو سؤال متفاوت هستند و فقط سؤال دوم اهمیت دارد.

ما شکل این پدیده را در مقیاس وسیع می‌بینیم. یک پروژه ایمنی خودروی متصل در شبکه ما شامل صدها هزار دستگاه است که جمعیت قابل توجهی از آن‌ها به‌طور همزمان در سه کشور در قاره‌های مختلف فعالیت می‌کنند؛ خودروهایی که در یک کشور ساخته شده و در کشورهای دیگر رانندگی می‌شوند. در چنین ابعادی، داشتن رابطه با یک اپراتور تنها یک تصمیم هزینه‌ای نیست؛ بلکه یک نقص طراحی با تاریخ تحویل مشخص است.

هنگام عدم دسترسی به سخت‌افزار، هزینه چقدر خواهد بود؟

هزینه‌های این بخش در بودجه فناوری اطلاعات (IT) قرار نمی‌گیرند و دقیقاً به همین دلیل است که دست‌کم گرفته می‌شوند.

قرار گرفتن در معرض گارانتی و فراخوان. ویژگی اتصالی که در طول یک خط تولید از کار می‌افتد، یک مشکل پشتیبانی نیست. این یک مشکل محصول است، همراه با پیامدهای حقوقی و شهرتی که در مورد سیستم‌های ایمنی اجباری، به معنای مسئولیت تنظیم‌گری (رگولاتوری) نیز هست.

منسوخ شدن ویژگی‌هایی که نمی‌توانید آن‌ها را پچ کنید. خدمات متصل به طور فزاینده‌ای به عنوان بخشی از ارزش خودرو و در برخی بازارها، به عنوان درآمد اشتراکی آن فروخته می‌شوند. خودرویی که نمی‌تواند به شبکه دسترسی پیدا کند، نمی‌تواند هیچ‌کدام را ارائه دهد.

تأخیر در همگون‌سازی (هومولوگیشن) و عرضه. هر بازار اضافی به معنای رابطه با یک اپراتور دیگر، مجموعه‌ای دیگر از گواهینامه‌ها و مذاکره‌ای دیگر است که باید پیش از فروش و به صورت متوالی انجام شوند. اینجاست که اتصال دیگر یک ردیف بودجه مهندسی نیست، بلکه به یک محدودیت برای ورود به بازار تبدیل می‌شود.

هزینه عیب‌یابی به ازای هر حادثه. وقتی یک نمایندگی نمی‌تواند یک خطای اتصالی را بازسازی کند، راه‌حل پیش‌فرض تعویض ماژول است. این شامل قطعات، نیروی کار و مشتری‌ای است که اکنون به آن ویژگی بی‌اعتماد شده است.

همان خرابی، یک سطح پایین‌تر

این ساختار در حوزه موبیلیتی اشتراکی و خرد نیز تکرار می‌شود؛ جایی که مقیاس‌های زمانی کوتاه‌تر هستند و دیدن هزینه راحت‌تر است، و این امر آن را به مکان مفیدی برای مشاهده نحوه کارکرد این مکانیسم تبدیل می‌کند.

Whizz دوچرخه‌های برقی را به رانندگان تحویل مستقل در نیویورک، فیلادلفیا، شیکاگو و واشینگتن دی‌سی اجاره می‌دهد یا به شرط تندیس واگذار می‌کند. بیشتر رانندگان آن‌ها پیمانکاران پروژه‌ای (گیگ) هستند که برای پلتفرم‌های بزرگ تحویل غذا و خواربار کار می‌کنند. همان عدم تقارن پرونده خودروسازان وجود دارد: شرکت سخت‌افزار را مستقر می‌کند، شخص دیگری هنگام خرابی آن را در اختیار دارد و آن شخص هیچ ابزار عیب‌یابی و دلیلی برای ارائه یک گزارش مفید ندارد.

گزارش منتشر شده درباره نقطه شروع آن‌ها به طرز عجیبی صریح است. ویس (Whizz) با سیم‌کارت‌های معمولی از یک اپراتور تلفن همراه استاندارد شروع کرد، که هزینه‌های داده را به هزاران دلار در ماه می‌رساند و شماره شناسایی سیم‌کارت‌ها باید به صورت دستی و یکی‌یکی وارد سیستم‌های آن‌ها می‌شد. و سپس جمله‌ای که باید در هر نسخه از این مجموعه قرار گیرد: وقتی یک دوچرخه اتصال خود را از دست می‌داد، حل کردن آن دست‌وپاگیر بود و هیچ روند مشخصی وجود نداشت.

این توصیفی از یک قطعی نیست. این توصیفِ «نبودِ یک روش» است و نبود روش است که یک خطای قابل اصلاح را به یک هزینه تکرارپذیر تبدیل می‌کند. برای راننده، محاسبات ریاضی به شکلی وحشیانه با مالک خودرو متفاوت است: مطالعه خود شهر نیویورک درباره کارگران تحویل مبتنی بر اپلیکیشن، خالص درآمد قابل برداشت آن‌ها را با احتساب انعام نزدیک به ۱۱ دلار در ساعت و بدون آن نزدیک به ۴ دلار تخمین زده است. دستگاهی که ساعت ۵:۴۰ صبح پاسخ نمی‌دهد، برای یک فرد خاص به معنای از دست رفتن بیشتر شیفت کاری‌اش است.

دارایی متفاوت، مقیاس زمانی متفاوت، مکانیسم یکسان: سخت‌افزاری که نمی‌توانید به آن دسترسی داشته باشید، خرابی‌ای که آخرین نفری هستید که از آن باخبر می‌شوید و هیچ گام بعدی مشخصی هنگام وقوع آن وجود ندارد.

چرا رویکرد سنتی نمی‌تواند این مشکل را حل کند

یک سیم‌کارت اپراتور سنتی فرض را بر این می‌گذارد که مشترکی وجود دارد که می‌توان با او تماس گرفت، برایش صورتحساب فرستاد، پشتیبانی کرد و یک سیم‌کارت جایگزین به او تحویل داد. هر یک از این فرضیات زمانی که مشترک یک خودرو باشد که عمرش از قرارداد بیشتر است، شکست می‌خورند.

دو قابلیت این فاصله را پر می‌کنند و هر دو باید قبل از تولید تصمیم‌گیری شوند، نه بعد از آن.

راه‌اندازی‌ای که از زنجیره تأمین جان سالم به در ببرد و پس از آن قابل تغییر باقی بماند. پروفایل اتصالی باید در کارخانه قابل نصب باشد و در طول عمر دارایی از راه دور (OTA) قابل تغییر باشد، به طوری که تغییر اپراتور، بازنشستگی شبکه یا یک بازار جدید نیازی به دستکاری سخت‌افزار نداشته باشد. استقرار ویس نسخه کوچک و خوانایی از این مورد است: سیم‌کارت‌ها به تأسیسات تولیدی ارسال می‌شوند، در طول تولید نصب شده و به واحدهای خاصی اختصاص می‌یابند، و پلتفرم هر کدام را اولین بار که آنلاین می‌شود به طور خودکار پیکربندی می‌کند و تغییرات بعدی از راه دور اعمال می‌شوند. اگر این الگو را به یک برنامه خودرویی مقیاس‌دهی کنید، تفاوت میان یک به‌روزرسانی نرم‌افزاری و یک فراخوان است.

قابلیت مشاهده‌ای که به جای «آیا متصل است؟»، به این سؤال پاسخ دهد که «آیا کار کرد؟» اتصال به معنای عملکرد نیست. تنها سیگنال مفید این است که آیا یک واحد مشخص رفتار مورد انتظار خود را در بازار واقعی خود کامل کرده است یا خیر و آیا این وضعیت تغییر کرده است یا خیر. سکوت باید یک رویداد قابل تشخیص باشد تا اینکه غیبت چیزی باشد که هیچ‌کس درباره‌اش نمی‌پرسد.

بهترین برنامه‌های موبیلیتی چه کارهایی را به شکل متفاوت انجام می‌دهند؟

برنامه‌هایی که بدون نیاز به صحبت درباره فراخوان، از بازنشستگی شبکه جان سالم به در می‌برند، چهار عادت مشترک دارند و باز هم هیچ‌کدام با یک سفارش خرید شروع نمی‌شوند.

آن‌ها نقشه راه پایان عمر شبکه (Sunset) را به ازای هر بازار فروش، به عنوان یک ورودی محصول ردیابی می‌کنند. بازنشستگی شبکه‌های اپراتور سال‌ها قبل اعلام می‌شود. فاصله موجود به دلیل کمبود اطلاعات نیست، بلکه به دلیل عدم مسئولیت‌پذیری است. هیچ‌کس در برنامه خودرو موظف به خواندن آن‌ها نیست، زیرا برنامه عرضه شده و تیم به سراغ کار دیگری رفته است. برنامه‌های انعطاف‌پذیر این وظیفه را محول می‌کنند و آن را با همان دوره‌ای که برای هر ریسک چرخه عمر دیگری وجود دارد، بررسی می‌کنند.

آن‌ها اتصال را در زمان شروع پروژه به عنوان یک زیرسیستم قابل به‌روزرسانی تعریف می‌کنند. انتظار می‌رود هر جزء دیگر مبتنی بر نرم‌افزار در یک خودروی مدرن از راه دور تغییر کند. اتصال اغلب صرفاً بر اساس قرارداد چنین نیست. رفتار با پروفایل اتصالی درست مانند هر ECU قابل به‌روزرسانی دیگری (تصمیمی که در آغاز برنامه گرفته می‌شود)، همان چیزی است که باعث می‌شود هر مشکل بعدی از راه دور قابل حل باشد.

آن‌ها «کار کردن» را به ازای هر بازار تعریف و اندازه‌گیری می‌کنند. نرخ اتصال مهم نیست؛ بلکه این مهم است که آیا یک جمعیت مشخص، رفتار مورد انتظار خود را در بازاری که در این ماه عملاً در آن رانندگی می‌کنند، به اتمام رسانده است یا خیر. این یک معیار متفاوت و معمولاً یک داشبورد متفاوت است و این تنها معیاری است که یک افت عملکرد خاموش را تشخیص می‌دهد.

آن‌ها جمعیت میدانی را تجهیز (اینسترومنت) می‌کنند، نه ناوگان اعتبارسنجی را. ناوگان‌های آزمایشی در بازارهایی که در آن‌ها فعالیت می‌کنید و روی شبکه‌هایی که خودتان انتخاب کرده‌اید، قرار دارند. خرابی در جایی رخ می‌دهد که شما در آن فعالیت نمی‌کنید. نمونه‌برداری از جمعیت واقعی ناخوشایند است، اما این تنها جایی است که پاسخ در آنجا قرار دارد.

ریشه‌ای که رهبری معمولاً در اینجا از آن غافل می‌شود، یک خطای دسته‌بندی است: اتصال به عنوان یک هزینه به ازای هر واحد بودجه‌بندی می‌شود، در حالی که رفتار آن شبیه به یک وابستگی به چرخه عمر محصول است. هزینه به ازای هر واحد کاهش می‌یابد و بهینه‌سازی می‌شود. یک وابستگی به چرخه عمر محصول مالک دارد، بررسی می‌شود و برای آن برنامه‌ریزی می‌شود. فاصله میان این دو نوع برخورد، همان جایی است که فراخوان‌ها از آنجا سرچشمه می‌گیرند.

سؤالی که باید از تیم خود بپرسید

نسخه مربوط به موبیلیتی در این مجموعه سؤالات، مربوط به سکوت نیست؛ زیرا دستگاه‌های شما در حالی که دچار خرابی هستند، گزارش آنلاین بودن می‌دهند.

برای بازارهایی که به آن‌ها محصول ارسال می‌کنیم: آیا می‌دانیم چه نسل‌هایی از شبکه قرار است بازنشسته شوند و آیا می‌توانیم پایگاه نصب‌شده خود را بدون دست زدن حتی به یک خودرو جابه‌جا کنیم؟

اگر پاسخ به بخش دوم خیر باشد، پاسخ به بخش اول اهمیت چندانی ندارد. شما در حال مدیریت یک ریسک نیستید، بلکه در حال انتظار کشیدن برای وقوع آن هستید.


منبع: Life Without a Signal: The Car That Stopped Calling for Help — IoT For All؛ نویسنده: Monogoto

منبع: iotforall

اشتراک‌ها:
دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *