EEBUS ، تکنولوژی آینده

صدای عقلانیت، حباب اینترنت اشیا را هدف گرفت

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

ساختار EEBUS
ساختار و قواعد EEBUS شبیه به قوانین و ساختار های استاندارد های دیگر از قبیل بلوتوث است. می بایست یک ساختار ارتباطاتی وجود داشته باشد که بتواند به انعطاف و راحتی هرچه بیشتر ، تعداد زیادی از کاربرد ها و ابزار های کنونی و اتی را پوشش دهد. همچنین به عنوان یک استاندارد وظیفه EEBUS این است که همه دستگاه های ساخته شده توسط شرکت های مختلف را تحت پوششی واحد قرار دهد.
یکی از راه های احتمالی و ممکن برای این امر استفاده از روش ذخیره KV یا مقدار کلیدی است. از یک سو استفاده از این روش بسیار ساده و مشخص است که این مساله به معنای کاهش محدودیت و سختی ورود توسعه دهندگان به این حیطه است. از سوی دیگر با مشخص کردن کلید ها و فرمت هایی برای مقادیر ایجاد یک استاندارد محکم و منطقی امکانپذیر می شود.
زمانی که صحبت از EEBUS می شود ما اغلب به مقدار پروتکل SPINE ( مخفف Smart Premises Interoperable Neutral-message Exchange به معنای تبادل مقدماتی هوشمندانه و مشارکتی پیام های بی طرفانه ) توجه میکنیم. مقدار استاندارد به شدت به نوع کاربری بستگی دارد. برنامه نویس نیازمندی های ارتباطاتی برنامه را مد نظر قرار میدهد و سپس تصمیم میگیرد که پیام های مربوطه باید به چه شکلی باشد. شکل 1 ساختار کلی این موضوع را نشان میدهد. در بالاترین قسمت سلسله مراتب ، ما ابزار های فیزیکی را داریم. این ابزار ممکن است یک ماشین رختشویی یا یک گوشی هوشمند یا یک لامپ باشد.

چه کسی پشت EEBUS قرار دارد؟

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

شروع به کار گروه در همایش تجارت Messe در هانوفر آلمان در سال 2012 بود. در زمان نوشتن این مقاله تعداد اعضا بالغ بر 65 عضو است. نکته جالب و قابل توجه تنوع این گروه است: در لیست اعضا این گروه از تامین کننده های انرژی و تجار خودرو تا تولید کننده های مستقل ابزار های خانگی از قبیل Miele دیده می شود. روند کاری کمیته EEBUS توسط چرخه Deming PDCA (برنامه ریزی، انجام، بررسی، تنظیم) صورت میگیرد که بر اساس مشخصات مشکلات اتخاذ می شود. مستندات مشخصات اولیه در اولین گام برای ایجاد موارد کاربرد ابزار ها مورد استفاده قرار گرفت که سپس به ایجاد مشخصات فنی بیشتری منتهی شد. تجارب به دست آمده از اجرای عملی این مشخصات در نسخه بعدی این استاندارد مورد استفاده قرار خواهد گرفت.

در مورد بخصوص وسایل آشپزخانه یا “ابزار های سفید” استاندارد ها به نحوی است که یک وسیله ممکن است با چندین کارکرد مختلف و مجزا روبرو شود. پروتکل SPINE در مورد دربر دارنده ایده ” ماهیت ” است. که بیانگر یک کارکرد برای یک دستگاه است. مثلا دستگاه خنک کننده نوشیدنی را در نظر بگیرید که در داخل خود قسمت یخساز دارد. قسمت های یخساز و خنک کننده هر کدام ماهیتی جدا گانه دارند.
در پایین این سلسله مراتب استاندارد هایی برای ویژگی های خاص و منفرد وجود دارد که هر کدام از آنها یک جنبه از یک کارکرد یک دستگاه را توصیف میکنند.

مساله فرمت های داده ها
تفاوت سرویس بلوتوث LE با سرویس SPINE در این است که بلوتوث هم جنبه های سخت افزاری و هم نرم افزاری ایجاد ارتباط را مشخص میکند. با این حال SPINE محدود به هفت لایه از مدل هفت لایه ای OSI است : انتخاب فرایند نحوه عبور اطلاعات از یک میزبان به میزبان دیگر کم و بیش بر عهده برنامه نویس است. EEBUS برای این کار استفاده از SHIP ( مخفف Smart Home IP به معنای ای پی خانه های هوشمند) را پیشنهاد میدهد که یک پروتکل بر مبنای TCP/IP است که برای این کار انطباق داده شده است.
EEBUS برای تعیین نحوه رمز گذاری پیام ها نسبتا محدود است. در این روش پیام ها به شکل متن هایی ساده در می آیند که از دستور زبان XML استفاده میکند. این روش باعث راحتی کار استفاده کننده می شود زیرا تقریبا همه زبان های برنامه نویسی با یک یا تعداد بیشتری کتابخانه برای تحلیل XML منتشر می شود. با افزایش روز افزون نیروی پردازشی موجود در دستگاه های نهفته (Embedded Devices)، هزینه های عمومی نسبتا گزاف استفاده از فرمت های مبتنی بر XML به تدریج به عاملی کم ارزش تبدیل تر تبدیل می شود.

یک مثال
یک مثال ساده میزنیم تا ساختار پیام SPINE را با هم ببینیم. فرض کنید ابزاری قصد دارد داده های خوانده شده از یک سنسور را در جواب درخواست دستگاه دیگری ارسال نماید. همه پیام های EEBUS از و قسمت تشکیل شده اند. قسمت اول آن هدر پیام است که در شکل 2 نشان داده شده است و شامل بخش های مختلفی است. قسمت addressSource و adressDestination نشان دهنده مسیری است که پیام از فرستنده تا گیرنده طی میکند. اغلب این آدرس با استفاده از سلسله مراتب ابزار، ماهیت و ویژگی مشخص می شود. در بسیاری از موارد خاص میتواند از مشخص کردن یک آدرس صرفنظر کرد که این خود باعث کاهش حجم هدر می شود.
نوع پیام در قسمت CmdClassifier مشخص می شود . 6 نوع استانداردی برای 6 نوع پیام وجود دارد که نقش آنها را در جدول 1 میبینید.

XML

SPINE اطلاعات را به فرمت XML تبدیل میکند. شما میتوانید به XML به عنوان نوعی HTML برای منابع نگاه کنید: به جای اطلاعات پراکنده ای درون یک صفحه وب، این فایل عناصر دنیای واقعی را توصیف میکند. اگرچه این فرمت از لحاظ پهنای باند قطعا اقتصادی نیست و به خوبی توسط پردازش گر های هشت بیتی مدیریت نمی شود ولی دارای این مزیت است که کم و بیش بر روی همه پلتفرم ها به یک صورت میتواند مورد استفاده قرار گیرد. برای تعیین اینکه چه تگ هایی میتواند در فایل XML مورد استفاده قرار بگیرد از یک فایل XSD استفاده می شود. خود این فایل XSD برای توصیف ساختار پیام XML از XML استفاده میکند.این فایل مشخص میکند که چه فیلدی میتواند مورد استفاده قرار گیرد و اطلاعات موجود در این فیلد ها به چه صورت ساختار دهی شوند و تا ارائه شرایط برای انواع داده های معمولی از قبیل double   نیز گسترش می یابد.

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

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

قسمت های دیگر هدر هم که اجزایی استاندارد در هدر ها محسوب می شوند و مشخص کننده اطلاعاتی در مورد چیزهایی از قبیل نسخه مشخصات مورد استفاده و یا نیاز یا عدم نیاز به یک دریافت رسید وصول هستند. به عنوان یک مثال کوچک برای این مطلب، در اینجا هدر یک بسته اطلاعاتی غیر واقعی، آورده شده است که سازمان استاندارد سازی EEBUS در وبسایت های خودش قرار داده است. جنبه مهمی از این هدر، یک زوج پارامتر MessageCounter است. مقدار msgCounter با ارسال هر بسته افزایش پیدا میکند و در واقع به عنوان یک شناسه پیام عمل میکند که به صورت منحصر به فردی (حداقل در کوتاه مدت) مشخص کننده هر پیامی است که منتقل می شود. قسمت MsgCounterRef به پیامی اشاره میکند که باعث شده این پیغام ارسال شود یعنی میتوان یک پاسخ را با درخواست و دستور مربوطه مطابقت داد. پروتکل هار ارتباطاتی اغلب فرمت های خاص خودشان را برای آدرس ها در نظر میگیرند. در SPINE قسمت های مختلف آدرس با دو نقطه( : ) از هم جدا می شوند. رشته d: در کد زیر نشان دهنده آدرس است (نوعی هدر در هدر) و I به ما اجازه میدهد که اطلاعات مختص شرکت را اضافه کنیم. ایده این روش این است که طرح آدرس میبایست یک رشته منحصر به فرد عمومی تولید کند که بتوان از آن برای شناسایی یک دستگاه خاص استفاده نمود.

<header>
<specificationVersion>1.0.0</specificationVersion>
<addressSource>
<device>d:_i: 46925_TestTempSensor_1</device>
<entity>2</entity>
<entity>1</entity>
<entity>1</entity>
<feature>1</feature>
</addressSource>
<addressDestination>
<device>d:_i:46925_TestSHM_1</device>
<entity>1< /entity>
<feature>1</feature>
</addressDestination>
<msgCounter>15</msgCounter>
<msgCounterReference>8</msgCounterReference>
<cmdClassifier>reply</cmdClassifier>
</header>
<payload>
<cmd>
<function>measurementListData</function>
<filter>
<cmdControl>
<partial/>
</cmdControl>
</filter

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

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

<measurementListData>
<measurementData>
<measurementId>1</measurementId>
<valueType>value</valueType>
<timestamp>2015-1105T10:14:00.0Z</timestamp>
<value>
<number>22</number>
</value>
<valueSource>measuredValue</valueSource>
</measurementData>
</measurementListData>
</cmd>
</payload>

تقاضا ها
درخواستی از یک دستگاه برای خواندن یک سنسور می تواند چیزی شبیه به این باشد.

<cmd>
<function>measurementListData</function>
<filter>
<cmdControl>
<partial/>
</cmdControl>
<measurementListDataSelectors>
<measurementId>5</measurementId>
<valueType>minValue</valueType>
</measurementListDataSelectors>
</filter>
<measurementListData/>
</cmd>

تقاضا باعث می شود که اطلاعات خودشان در فیلتر قرار گیرند.. در اینجا هیچ عنصر اطلاعاتی وجود ندارد.

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

و در نهایت تشخیص
علاوه بر همه چیز هایی که گفته شد ما اکنون به این سوال می رسیم که چگونه یک دستگاه میتواند یک شریک ارتباطی جدید را تحلیل کرده و به آن وصل شود. در پروتکل مورد بحث این فرایند ” ارتباطات کارکردی ” نام دارد. در همین بخش از استاندارد پروتکل توصیفی از فرایند اخطار و اطلاع رسانی وجود دارد.
مشخصات نیازمند این است که ویژگی صفر از ماهیت صفر (یعنی آدرس ویژگی 0 و آدرس ماهیت 0) باعث اجرای NodeManagment شود. هر وسیله راه دوری میتواند با ارسال یک دستور Read که در تابع nodeManagmentDetailedDiscovery اجرا می شود تحلیل و بررسی شود. دستگاه مقصد در پاسخ به این دستور ، یک ساختار کلاسی نسبتا پیچیده ارسال میکند که تصویر کلی از ماهیت و کارکرد های موجود را ارائه میکند.
سازمان استاندارد در رابطه با نحوه شناسایی دستگاهی که با آن در حال ارتباط هستید راهنمایی بیشتری نمیکند. متن استاندارد صرفا مرجع اذیت کننده را به “یک بکارگیری نسبتا هوشمند” تبدیل میکند.

آشنایی با اسناد
سازمانی که در پشت EEBUS قرار دارد با دریافت ایمیل شما اجازه دانلود را میدهد و لزومی عضویت در گروه استاندارد سازی نیست.
فایل EEBUS_SPINE_TR_Introduction.PDF یک دید کلی نسبت به استاندارد EEBUS ارائه میکند. هر کسی که واقعاً میخواهد با EEBUS سر و کله بزند باید از این متن پرینتی داشته باشد.
از بین فایل های مربطو به این استاندارد دو فایل EEBUS_SPINE_TS_ProtocolSpecification.PDF و EEBUS_SPINE_TS_ResourceSpecification.PDF داری اطلاعات فنی بیشتری هستند اگر در فایل اول با مفهومی برخورد کردید و نیاز به تحقیق و بررسی بیشتر داشتید میتوانید به فایل دوم مراجعه کنید.
و در نهایت مقداری فایل XSD (XSL Schema Definition)وجود دارد که در یک فایل Zip قرار دارد. این فایل ها ساختار پیام های منفرد را توصیف میکنند و میتوان با ابزار های مختلف آنها را به فایل های نمایشی تبدیل کرد. برخی از IDE های مبتنی بر XML به شما اجازه میدهند که از این فایل ها برای بررسی کدهایی که به صورت خودکار تولید شده اند بهره بگیرید. وقتی بدانید فایل های اطلاعاتی شما با استاندارد ها همخوانی دارند پیدا کردن یک باگ بسیار راحت تر می شود. با این مراقب باشید که فایل های XSD در بسیاری از موارد در اجرای واقعی مقاوم ترند.

نتیجه گیری
از دیدگاه فنی EEBUS/SPINE به خاطر انعطاف عالی که دارند ، مهم تر هستند. به سختی میتوان کاربردی را پیدا کرد که نتوان با استفاده از مدل ذخیره مقدار با کد از پیش تعیین شده آن را توصیف کرد. با توجه به شباهت هایی که این روش با بلوتوث LE دارد، مفاهیم پشت پرده سیستم ها برای برنامه نویسان تا حدود زیادی آشنا است.
با این حال میبایست در نظر داشت که SPINE صرفا چهارچوبی مقدماتی برای پشتیبانی از ارتباطات بین دستگاه ها به صورت مستقل از تولید کننده فراهم میکند. این روش هیچ راهنمایی برای اجرای خاص بر روی انوع ابزار های خاص فراهم نمیکند. برای درک کامل تعمیم کار، تولید کننده هر دسته از ابزار ها میبایست مشترکا تصمیم بگیرند که کدام نوع از پیام های SPINE و به چه صورتی مورد استفاده قرار گیرند. این فعالیت ها اخیرا شروع شده است و اولین استاندارد ها برای ماشین های لباسشویی و ظرفشویی ایجاد شده است. درست همانند GPIB، اینکه آیا یک ابزار EEBUS در واقعیت هم با همدیگر کار خواهند کرد یا نه، هنوز مشخص نیست.

لینک های مفید:

Specification download:
www.eebus.org/en/download-standard/
List of members:
www.eebus.org/en/initiative/members/
Data model and details:
www.eebus.org/en/technology/data-model/

نظرات خود را در این زمینه با ما در میان بگذارید.