چگونه معماری سیستم ریسک ناوگان را کاهش می دهد

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

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

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

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

به همین دلیل است که اپراتورهای با تجربه دیگر معماری سیستم را به عنوان یک دغدغه مهندسی نمی بینند. آنها آن را به عنوان یک چارچوب مدیریت ریسک می بینند - چارچوبی که تعیین می کند آیا ناوگان تحت فشار قابل پیش بینی باقی می ماند یا به آرامی غیرقابل مدیریت می شود.

ریسک در ناوگان سیستمی است نه تصادفی

بیشتر خطرات ناوگان ناشی از خرابی های فاجعه آمیز نیست.
آنها توسط تعامل بین اجزایی ایجاد می شوند که هرگز برای کار به عنوان یک سیستم منسجم طراحی نشده اند.

مثال ها رایج هستند:

• به‌روزرسانی نرم‌افزار یک عملکرد حیاتی ایمنی را مختل می‌کند

• یک حسگر جدید یک اتوبوس ارتباطی مشترک را بارگذاری می کند

• خطای رابط کاربری باعث خاموش شدن غیر ضروری خودرو می شود

هر جزء ممکن است مشخصات خود را برآورده کند.
سیستم اینطور نیست.

محصولات مبتنی بر مشخصات، قطعات را بهینه می کنند.
معماری سیستم وابستگی های متقابل را مدیریت می کند.

جداسازی معماری اولین لایه کنترل ریسک است

یکی از مؤثرترین راه‌ها برای کاهش ریسک عملیاتی، جداسازی عملکردی در سطح معماری است.

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

معماری هایی مانند شبکه Dual-CAN نمونه ای از این اصل هستند:

• یک Power CAN که به کنترل حیاتی ایمنی اختصاص داده شده است

• یک CAN هوشمند که داده ها، رابط ها و اتصالات را مدیریت می کند

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

پیش‌بینی‌پذیری شکلی از ایمنی است

خطر ناوگان فقط در مورد تصادفات نیست - بلکه در مورد غیرقابل پیش بینی بودن است.

اپراتورها سیستم های ارزش گذاری که:

• به جای شکست ناگهانی، با ظرافت تنزل دهید

• به جای رفتار مبهم، حالت های خطای واضح را ارائه دهید

• به جای خاموش شدن اضطراری، توقف های کنترل شده را مجاز کنید

معماری هایی که با اصول ایمنی عملکردی ساخته شده اند (مانند طراحی همسو با ASIL) خرابی ها را از بین نمی برند. آنها نحوه رفتار شکست ها را تعریف می کنند.

رفتار شکست قابل پیش بینی به ناوگان اجازه می دهد:

• مداخلات را برنامه ریزی کنید

• تداوم خدمات را حفظ کنید

• هم از دارایی ها و هم از اپراتورها محافظت کنید

در عملیات تجاری، قابلیت پیش بینی ایمنی است.

شفافیت نرم‌افزار، قرار گرفتن در معرض کسب و کار را کاهش می‌دهد

سیستم های بسته نقاط کور عملیاتی ایجاد می کنند.
نقاط کور خطر ایجاد می کند.

هنگامی که تشخیص، سیاهههای مربوط و درختان خطا غیرقابل دسترسی هستند، هر مسئله به یک بازی حدس زدن تبدیل می شود. وسایل نقلیه بیکار می نشینند نه به این دلیل که غیرقابل جبران هستند - بلکه به این دلیل که هیچ کس نمی داند مشکل چیست.

معماری‌های سطح سیستم که بر روی چارچوب‌های استاندارد ساخته شده‌اند (مانند عیب‌یابی AUTOSAR و UDS) این پویایی را معکوس می‌کنند. آنها به عیب ها اجازه می دهند:

• به سرعت شناسایی شد

• از راه دور تشخیص داده شد

• اولویت بندی دقیق

برای مدیران ناوگان، این امر از سه طریق در معرض قرار گرفتن را کاهش می دهد:

1. توقف کوتاه تر

2. هزینه خدمات کمتر

3. استفاده بهتر از دارایی

مالکیت مسیر تشخیصی به معنای مالکیت دارایی است - نه اجاره دادن آن از سازنده.

معماری از ناوگان در برابر خطرات نظارتی محافظت می کند

تحرک تجاری در یک محیط تنظیمی ثابت عمل نمی کند.
حفاظت از داده ها، استانداردهای ایمنی و الزامات عملیاتی به ویژه در اروپا به طور مداوم در حال تکامل هستند.

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

معماری هایی که پشتیبانی می کنند:

• به روز رسانی OTA

• لایه های نرم افزاری مدولار

• استقرار داده های خاص منطقه

به ناوگان اجازه می دهد مطابقت داشته باشند بدون فراخوان فیزیکی یا تعویض سخت افزار .

از منظر ریسک، این بیشتر از عملکرد مهم است. وسیله نقلیه ای که نمی تواند خود را با تغییرات مقررات تطبیق دهد، آینده نگر نیست - این یک مسئولیت است.

ریسک با مقیاس چند برابر می شود - و معماری تنها دفاع مقیاس پذیر است

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

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

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

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

نتیجه گیری: معماری یک ویژگی نیست. بیمه است

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

معماری سیستم خوب:

• غافلگیری های عملیاتی را کاهش می دهد

• حاوی شکست است

• هزینه را در طول زمان تثبیت می کند

در صنعتی که حاشیه ها کم است و قابلیت اطمینان شهرت را تعریف می کند، معماری دیگر یک جزئیات فنی نیست. بیمه نامه است.

و برخلاف بیمه، هر روز که ناوگان بدون حادثه کار می کند، سود سهام پرداخت می کند.