استفاده از موتور بازی سازی در طراحی سیستم مونیتورینگ سه بُعدی برای ترمینال کانتینری
ثبت عملیات در ترمینال کانتینری به جهت سرعت و حجم عملیاتی که در آن انجام می‌گیرد، بدون برنامه‌ریزی و انجام عملیات منطبق با برنامه‌ریزی‌های صورت گرفته، تقریباً غیرممکن است، یا در بهترین حالت با اتلاف وقت بسیار زیاد و مشکلات پردامنه و پرهزینه همراه است
  • 1395/5/31 8/21/2016 6:20:49 PM 8/21/2016 6:20:49 PM
  • 0
  • 543

چکيده

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

 

1 مقدمه

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

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

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

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

 

مانیتورینگ3مونیتورینگمونیتورینگ

شکل 1- سیستم مونیتورینگ سه بُعدی در قیاس با مونیتورینگ دو بُعدی و مونیتورینگ زنده با بهره‌گیری از دوربین‌ها

 

2 پیشینه تحقیق

از زمان پیدایش گرافیک کامپیوتری تا کنون همواره ابزارهای نرم‌افزاری و سخت‌افزاری متنوعی تولید شده است تا هر چه بیش‌تر بحث نمایش را به واقعیت نزدیک‌تر کنند. از انواع زبان‌ها و ای-پی-آیهای گرافیکی نظیر دایرکت-ایکس و اوپن-جی-ال گرفته تا شتاب‌دهنده‌های گرافیکی بسیار قدرتمند و ابزارهای تعاملی مثل دست‌کشِ اطلاعات و یا عینک‌های سه‌بُعدی و... (Sutherland,1965). یکی از ابزارهایی که در این میان به سرعت رشد کرده و هم اکنون به جایگاه بسیار خوبی دست یافته است موتور ساختِ بازی است. موتورِ بازی‌سازی مجموعه‌ای از ابزارهای توسعه‌ی بصری و همچنین مولفه‌های نرم‌افزاری با قابلیت استفاده‌ی مجدد ارائه می‌دهد. این ابزارها معمولا در یک محیط توسعه‌ی یک‌پارچه ارائه می‌شوند تا توسعه‌ی بازی‌ها را با یک رویکرد مبتنی بر داده، ساده‌تر و سریع‌تر انجام دهند. موتورهای ساخت بازی را گاهی میان‌افزار بازی نیز می‌نامند(Lewis, 2002).

شروع کار و تحقیقات در این فیلد علمی از اواخر دهه دوم قرن بیستم آغاز شد ولی به دلیل محدودیت امکانات نرم‌افزاری و سخت‌افزاری، رشد چندانی نداشت. ولی از حدود سالهای 1989و1990 کم کم مفاهیم واقعیت مجازی شکل و ساختار به‌تر و قابل قبول‌تری گرفتند و درخواست‌ها برای استفاده از تکنولوژی واقعیت مجازی در زمینه‌های نظامی، هوافضا، تجهیزات پیچیده و ... بسیار زیاد شد و این تکنولوژی وارد یک مرحله‌ی گسترش سریع شد. همچنین صنعت بازی‌سازی نیز دچار تحولات چشمگیری شد و بازی‌هایی با کیفیت و گرافیک بسیار بالاتر پدید آمدند(Ping, 2009).

کاربردهای واقعیت مجازی در حوزه های بسیار زیاد و متنوعی می‌تواند باشد ولی به صورت مختصر می‌توان موارد زیر را به صورت بالقوه برای آن بر شمرد: معماری، تجارت الکترونیک، فروشگاههای سه‌بُعدی و تبلیغات، اینترنت سه‌بُعدی، آموزش علوم، شبیه‌سازی انواع تجهیزات و همچنین برخی عملیات خطرناک برای ماهواره‌ها و یا عملیات نظامی، شهرهای مجازی نظیر سِکِندلایف، سیستم‌های اطلاعاتی و مونیتورینگ، گردشگری، شبیه سازی ورزش‌ها و بازی‌های انفرادی یا چند نفره‌ی آنلاین و ... Ping, 2009)و (Papastamatiou, 2011.

3 مواد و روش‌ها

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

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

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

بعد از تکمیل فرآیند مدلینگ و نگاشت تکسچرها نوبت به ساخت انیمیشن های مورد نیاز برای نمایش عملیات تجهیزات مختلف حمل و نقل می‌رسد. در ساخت انیمیشن‌ها هم باید سعی شود که کم‌ترین تعداد فریم‌کلیدی وجود داشته باشد تا حجم فایل خروجی بی دلیل زیاد نشود. طولانی بودن زمان انیمیشن چندان مهم نیست بلکه تعداد فریم‌های کلیدی به‌کار رفته در آن در حجم آن تاثیرگذار است. در انتها تمام انیمیشن‌ها با فرمت‌های استانداردی نظیر Fbx, 3ds, obj و ... خروجی گرفته می‌شوند که نوع خروجی بستگی به فرمت‌هایی دارد که موتورِ بازی‌سازی می‌تواند ساپورت کند.

دیگر تکنیک‌هایی که به افزایش کیفیت رندر محیط مونیتورینگ و همچنین کاهش بار رندر کمک می‌کنند بیکینگ تکسچر، بامپ نرمال و نقشه‌ی سبک می‌باشند(Zhai, 2011). به این صورت که می‌توان محیط و مدل‌ها را در تری‌دی‌مکس، مایا و ... با استفاده از تکنیک‌های پیشرفته‌ای مانند نورپردازی با اشعه‌ی وی رندر کرد و تکسچرهایی شامل نورها و سایه ها و بامپ‌ها به وجود آورد و در موتور بازی به جای استفاده از نورها و سایه‌های بلادرنگ از تکسچرهایی که قبلا توسط ابزارهای پیشرفته، نورپردازی و رندر شده‌اند استفاده کرد. به عبارتی استفاده از نورها و متریال‌های استاتیک به جای حالت دینامیک آن‌ها تکنیکی است که می‌تواند در کاهش سربار پردازشی به نحوی موثر عمل کند و به این نحو فقط سایه‌ها و نورها را برای اجسامی که حرکت دارند محاسبه نماییم. شکل سه شمایی از سیستم مونیتورینگ سه‌بُعدی اولیه‌ را در کنار یک تصویر واقعی از ترمینال کانتینری نشان می‌دهد. در تصویر حدود سی‌هزار کانتینر یک‌جا دیده می‌شوند و تنها به مدد تکنیک‌های برشمرده شده، بارگذاری یک‌جای آن‌ها در یک تصویر ممکن شده است.

4 ساخت مونیتورینگ  سه‌بُعدی در حوزه خدمات کانتینری با استفاده از موتور بازی

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

مونیتورینگ 10

شکل 2- ساختار نرم‌افزاری سیستم مونیتورینگ سه‌بُعدی اولیه

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

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

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

5 تبدیل سیستم مونیتورینگ سه‌بُعدی اولیه به یک کامپوننت با قابلیت استفاده‌ی مجدد

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

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

شکل 3: تبدیل سیستم مونیتورینگ اولیه به یک کامپوننت

اما در تبدیل برنامه‌ی کاربردی یونیتی به یک کامپوننت، مشکلات گسترده‌ای وجود داشت. برنامه‌ی کاربردی یونیتی، با وجود آن‌که با استفاده از کدهای سی‌شارپ تولید می‌شود، برنامه‌ی اجرایی قابل بازگشایی توسط رفلکتور دات نت ارائه نمی‌کند و به همین دلیل نمی‌توان در داخل یک کامپوننت دات‌نت از آن استفاده کرد. به همین دلیل مجبور به استفاده از تکنیک‌های ارتباط میان‌فرآیندی برای استفاده از برنامه‌ی خروجی یونیتی در قالب یک کامپوننت دات‌نت بودیم. در میان روش‌های ارتباط میان‌فرآیندی متداول در دات‌نت، ابتدا دبلیوسی‌اف مورد توجه توسعه‌دهندگان کامپوننت قرار گرفت، اما تحقیقات بیشتر نشان داد، مونو Costanich, 2011) و (Bluestein, 2011 (که کدهای سی‌شارپ یونیتی توسط آن کامپایل و به کد اجرایی تبدیل می‌شوند) از دبلیو‌سی‌اف به طور کامل و به صورتی که مورد نیاز این قسمت است پشتیبانی نمی‌کند. به همین دلیل ارتباط در این قسمت با استفاده از تکنیک قدیمی دات‌نت ریموتینگ انجام گرفت. شکل (3) شمایی از کامپوننت تولید شده و استفاده از آن در فرم‌های دات‌نت را نشان می‌دهد. تنظیماتی مثل مختصات زمین و بلاک‌های محوطه، اشیاء ثابت مستقر در زمینه و مواردی از این قبیل در قالب تنظیمات کامپوننت، قابل تنظیم هستند و کامپوننت را می‌توان به آسانی با اضافه کردن دی‌ال‌ال آن به رفرنس‌های برنامه مورد استفاده قرار داد.

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

تصویر 11

شکل 4- تبدیل سیستم مونیتورینگ اولیه به یک کامپوننت

 

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

6 معماری چهار تکه (ارسال‌کننده‌ها-تجمیع‌کننده-دریافت‌کننده-نمایش‌دهنده)

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

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

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

تصویر

شکل 5- معماری چهارتکه برای سیستم مونیتورینگ

 

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

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

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

فرمول

فرمول1- محاسبه موجودی ترمینال کانتینری در زمان t

فرمول (1) نحوه‌ی محاسبه‌ی موجودی بر اساس تراکنش‌های ترمینال کانتینری را نشان می‌دهد. در این فرمول nt تعداد تخلیه‌هایی است که از آغاز کار تا زمان t در ترمینال کانتینری انجام گرفته است. mt نیز تعداد بارگیری‌هایی است که از آغاز تا زمان t در ترمینال کانتینری انجام شده است.

با این روش می‌توان تمام تراکنش‌هایی که در ترمینال کانتینری صورت می‌گیرد را ثبت و نمایش داد. منظور از تمام تراکنش‌ها، تراکنش‌هایی است که در قسمت‌های مختلف ترمینال کانتینری صورت می‌پذیرد. یک ترمینال کانتینری در حالت حداقلی شامل سه قسمت مختلف است. محوطه‌ی عملیاتی بین دیوار دریا تا یارد (اسکله)، یارد کانتینری (انبار ترمینال= محوطه‌ی پشته‌سازی) و ناحیه‌ی رو به خشکی ترمینال (شامل گیت و...) (Brinkmann, 2011). تراکنش‌های اسکله که عمدتاً توسط کرین‌ها صورت می‌گیرند، شامل تخلیه و بارگیری کشتی هستند. این تراکنش‌ها نیز می‌توانند همانند تراکنش‌های یارد مدل شوند و تنها تفاوت در این است که در این‌جا به جای یک بلاک، ما با یک کشتی مواجه هستیم. در مورد تراکنش‌های گیت، نیز کار در واقع تخلیه و بارگیری است، اما به جای تخلیه/بارگیری از/به کشتی به/از کشنده، با تخلیه/بارگیری از محوطه‌ی نخست به محوطه‌ی دوم است.

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

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

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

نمایشگر

شکل 6- شمایی از برنامه‌ی کاربردی مونیتورینگ در حال مونیتورینگ یک محوطه‌ی کانتینری

7 ویژگی‌های برجسته و نتایج

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

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

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

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

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

8 نتيجه‌گيري

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

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

منابع مورد استفاده

Ping, Z. Q.  2009, A survey on virtual reality, Springer, Science of china.

Sutherland, I. E. 1965, “The ultimate display”, Proceedings of the International Federation of Information Processing (IFIP) Congress, pp. 506–508.

Lewis, M., Jacobson J., 2002, Game Engines in Scientific Research”, Communications of the ACM, Vol. 45, No. 1, pp. 27-31.

Papastamatiou N., Papastamatiou N., Alexandridis T., Tsergoulas K., Michopoulos A., Karadimas N. V., 2011, “Virtual Reality Applications with User Interface for Dynamic Content Development”, Recent Advances in Computer Engineering and Applications, pp. 201-206.

Creighton R. H., 2010, Unity 3D Game Development by Example Beginner's Guide, Packt.

Eberly D. H., 2007, 3D Game Engine Design: A Practical Approach to Real-Time Computer Graphics, Gulf Professional Publishing.

Costanich Bryan, 2011, Developing C# Apps for IPhone and IPad Using MonoTouch: IOS Apps Development for .Net Developers, Apress, pp. 11-12.

Bluestein Michael, 2011, Learning MonoTouch: A Hands-On Guide to Building IOS Applications with C# and .NET, Addison-Wesley Professional.

Zhai Y., Q. H. He,  X. W. Li, 2011, “Texture Baking Techniques on Construction of Virtual Reality Interactive Scenes”, L. Qi (ed.), Recent Trends In Materials And Mechanical Engineering Materials, Mechatronics And Automation, Van Stockum, pp. 478-483.

Brinkmann B., 2011, “Operations Systems of Container Terminals: A Compendious Overview”, W. Böse (ed.), Handbook of Terminal Planning, Operations Research, Computer Science Interfaces Series 49, Chapter 2, Springer Science+Business Media, pp. 25-39.

 

 
نظرات 0
برای ارسال دیدگاه وارد حساب کاربری خود شوید.

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