یکپارچه‌سازی ITS معمولاً در روز اول ساده به نظر می‌رسد: چند تجهیز خریداری می‌شود و هرکدام نرم‌افزار خود را دارند. مسئله چند سال بعد آشکار می‌شود، وقتی شهر می‌خواهد داده دوربین، چراغ، پارکینگ، V2X و اپلیکیشن را کنار هم استفاده کند یا بخشی از تجهیزات را بدون تعویض کل سامانه نوسازی کند. معماری باز و استانداردهای تبادل داده برای همین مرحله طراحی می‌شوند.

USDOT در برنامه Architecture and Standards تأکید می‌کند که ARC-IT یک چارچوب مشترک برای برنامه‌ریزی و یکپارچه‌سازی ITS فراهم می‌کند و استانداردهای باز و اجماعی می‌توانند هم‌کنش‌پذیری میان اجزای مختلف را تسهیل کنند. نکته مهم این است که معماری مرجع محصول مشخصی را تحمیل نمی‌کند؛ نقش‌ها، جریان‌های اطلاعاتی و رابط‌ها را روشن می‌کند.

معماری باز یعنی چه؟

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

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

نسخه Schema، دسترس‌پذیری API و صف پیام باید در بهره‌برداری پایش شوند.

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

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

در قرارداد، تحویل مستندات API، Schema، حساب‌های مدیریتی، روش Export، نسخه استاندارد و محیط آزمون باید جزو اقلام تحویل باشد. آزمون با یک مصرف‌کننده مستقل قبل از پذیرش، بسیار مؤثرتر از دریافت PDF مستندات در پایان پروژه است.

آزمون انطباق، حاکمیت Schema و مهاجرت نسخه

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

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

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

SLA رابط و مشاهده‌پذیری یکپارچگی

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

همچنین بهتر است Correlation ID یا شناسه قابل ردیابی برای تراکنش‌های مهم وجود داشته باشد تا یک رخداد از منبع تا مصرف‌کننده دنبال شود. وقتی مشکل ایجاد می‌شود، تیم بتواند تشخیص دهد خطا در تولیدکننده، Broker، تبدیل Schema یا مصرف‌کننده رخ داده است. مشاهده‌پذیری مناسب معماری باز را از یک نمودار طراحی به زیرساخت قابل اداره تبدیل می‌کند و کمک می‌کند تغییر یک جزء بدون آزمون دستی تمام زنجیره انجام شود. داشبورد یکپارچگی بهتر است وابستگی هر سرویس به نسخه Schema و مسیر پیام را هم نشان دهد تا پیش از تغییر، دامنه اثر آن برای تیم عملیات روشن باشد.

جمع‌بندی

معماری باز یک تصمیم بلندمدت درباره قابلیت تغییر است. ARC-IT و استانداردهای ITS کمک می‌کنند نقش‌ها و جریان‌های اطلاعاتی مستقل از محصول تعریف شوند. سپس API، Broker و قرارداد داده می‌توانند این معماری را در پیاده‌سازی واقعی اجرا کنند.

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