Aboshتولیدکننده و مصرف‌کننده با قرارداد داده توافق می‌کنند یک مجموعه‌داده یا رویداد چه معنایی دارد، چگونه تحویل می‌شود، مسئولش کیست و هنگام تغییر یا رد شدن در بررسی چه اتفاقی می‌افتد. قرارداد کارخانه باید علاوه بر نوع فیلدها، اندازهگیری، واحد، شناسهٔ رویداد، زمان، کیفیت و کاربرد مجاز را پوشش دهد. توافق به بررسیهای عملیاتی و افراد مسئول نیاز دارد؛ فایل طرحواره به‌تنهایی این مسئولیت‌ها را اجرا نمیکند.
مقدار تجمعی شمارنده را از افزایش تولید جدا نگه دارید.
تغییرهای ناسازگار و شواهد ناموجود را آشکار کنید.
برای رسیدگی به رویداد ردشده یا دیررس، مسئول مشخص کنید.
بر معنا و مسئولیتِ پیرامون طرحواره توافق کنید
استاندارد باز قرارداد داده یا ODCS، توافق میان تولیدکنندگان و مصرف‌کنندگان داده را توصیف میکند. نسخهٔ 3.2.0 آن شامل طرحواره، اطلاعات کیفیت داده، تیم‌ها، نقش‌ها، پشتیبانی و انتظارهای خدمت است. این بخش‌ها به طرف‌ها کمک می‌کنند توافق را فراتر از فهرست نوع فیلدها ثبت کنند.
برای رویداد کارخانه، مسئول عملیات، اندازهگیری و کاربرد مجاز آن را توضیح می‌دهد. مسئول تولید داده، نگاشت منبع را نگه میدارد. مسئول مصرف داده ثبت میکند کدام محاسبات به سابقه وابسته‌اند. آن‌ها همچنین توافق می‌کنند چه کسی تغییر را بازبینی کند، چه کسی شکست در بررسی را پیگیری کند و چه زمانی مسئلهٔ حل‌نشده به سطح بالاتر ارجاع شود.
کاربرگ، توافق مثال و بررسیهای مورد انتظار را ثبت میکند. سند کامل ODCS، قالب کدگذاری OPC UA یا سرویس اجرای کنترل در تولید نیست. هیچ اقدام کنترلی یا ایمنی را مجاز نمیکند.
رکورد شمارنده چه چیزی را نشان می‌دهد؟
مصرف‌کننده، زمان مبدأ و زمان ورود را جدا نگه میدارد. تعریف DataValue در OPC UA، زمان مبدأ را از زمان سرور جدا میکند؛ ثبت زمان ورود در برنامه، مشاهدهٔ مشخص‌شدهٔ دیگری است. برنامهٔ دریافت‌کننده نباید زمان ورود را جای زمان مبدأِ ناموجود بگذارد و بی‌توضیح آن را زمان اصلی بنامد.
مثال قبلی، تاریخ تقویمی و حد تازگیِ توافقشده ندارد. بررسیکننده فقط با فرض صریحِ یکسان بودن روز در UTC میتواند فاصلهٔ پنج ثانیه را محاسبه کند. تا زمان توافق بر قاعدهٔ ناموجودِ تازگی، استفاده در محاسبات بعدی را معلق نگه میدارد. از این مقدارها نمی‌توان دقت ساعت، زمان‌بندیِ عبور از نیمه‌شب یا تعهد واقعیِ خدمت را تأیید کرد.
| قلم رکورد | مقدار مثال آموزشیِ قبلی | قاعده‌ای که مصرف‌کننده باید ثبت کند |
|---|---|---|
| تجهیز و اندازهگیری | P-07 / accepted-count | منبع فیزیکی و نتیجهٔ شمارش‌شده را مشخص کنید |
| مقدار و معنا | 412 واحد، تجمعی | ثبت‌های لحظه‌ایِ شمارنده را تولیدهای مستقل ندانید و جمع نکنید |
| مبدأ و ورود | 10:15:00 / 10:15:05 UTC | هر دو را نگه دارید؛ تاریخ تقویمی موجود نیست |
| کیفیت و طرحواره | Good / نسخهٔ 1 | وضعیت واقعیِ منبع و معنای پشتیبانی‌شده را حفظ کنید |
| شناسهٔ رویداد | S8 / شمارهٔ توالی 92 | شناسه را در محدودهٔ منبع، اندازهگیری و نشست تعریف کنید |
تأیید دریافت در انتقال، معنای رویداد را مشخص نمیکند
مصرف‌کننده پیش از افزودن رکورد به محاسبهٔ تحلیلی، شناسهٔ آن در سطح برنامه را بررسی میکند. MQTT در استاندارد OASIS، در تحویلِ دست‌کم یکبار، تکرار را مجاز می‌داند و پرچم DUP بسته را از تکرار پیامِ برنامه جدا میکند. بنابراین شناسهٔ بستهٔ انتقال جای شناسهٔ رویدادِ موردنیاز برنامه را نمی‌گیرد.
در مثال قبلیِ شمارنده، دریافت دوبارهٔ همان رکورد، 412 واحد دیگر اضافه نمیکند. مقدار تجمعیِ بعدیِ 413 فقط وقتی نشان‌دهندهٔ یک واحد پذیرفته‌شدهٔ بیشتر است که همان توالی شمارنده بدون بازنشانی یا سرریز ادامه یافته باشد. این شرط را حفظ کنید و هر مقدار کمتر را افزایش منفیِ عادی فرض نکنید.
بررسیکننده، رکورد تکراری را جدا گزارش میکند و برای آن، صفر واحد تازه می‌افزاید. افزایش تولید را برای نخستین ثبتِ شمارنده نامعلوم میگذارد: یک مقدار تجمعی بدون مقدار پیشینِ معتبر، تولید یک بازه را مشخص نمیکند. پیش از محاسبهٔ اختلاف، رسیدگی به بازنشانی و سرریز شمارنده باید جداگانه تعریف شود.
همچنین ببینیدکیفیت داده کارخانه
تغییر معنا را توافق تازه بدانید
تولیدکننده میتواند نوع عدد صحیحِ فیلد را حفظ کند و با تغییر معنای آن از شمار تجمعیِ پذیرفته‌شده به افزایش یا شمار ناخالص، محاسبهٔ مصرف‌کننده را خراب کند. تشخیص تغییر نام فیلد از چنین تغییر بی‌صدایی آسان‌تر است. تعریف معنایی را هم مانند ساختار، نسخه‌بندی کنید.
بررسیکنندهٔ آموزشی از نسخهٔ طرحوارهٔ 1، واحد units، معنای تجمعیِ accepted-count و شناسهٔ مبدأِ مشخص‌شده پشتیبانی میکند. آزمون‌های آن، واحدِ الزامی را حذف می‌کنند، نسخهٔ طرحواره را تغییر می‌دهند و پرچم تجمعی بودن را عوض می‌کنند. این‌ها تغییرهای عمدیِ نمونهٔ قبلی برای بررسی نرم‌افزارند و رخدادهای مشاهدهشده در کارخانه نیستند.
پیش از انتشار تغییر توسط تولیدکننده، هر دو مسئول، رکوردهای قبلی و پیشنهادی را در برابر مصرف‌کنندگان وابسته به آن‌ها مقایسه می‌کنند. آن‌ها تصمیم می‌گیرند مصرف‌کنندهٔ فعلی همچنان همان معنا را دریافت میکند، به مبدل صریح نیاز دارد یا باید نسخهٔ جدید را رد کند. تأیید تغییر، نقطهٔ شروع اجرا و تصمیم بازگشت را همراه توافق نگه دارید.
- تغییر موردنظرِ تولیدکننده را ثبت کنید
مسئول تولید داده، معنا، واحدها، شناسه و رفتار زمانیِ قبلی و پیشنهادیِ فیلد را ارائه میکند.
- مصرف‌کنندگان تحت تأثیر را بررسی کنید
هر مسئول مصرف داده، محاسبه، فرض و نسخهٔ پشتیبانی‌شده‌ای را که تغییر بر آن اثر دارد مشخص میکند.
- بررسیهای پذیرش را اجرا کنید
بازبین، رکوردهای شناخته‌شده، تکراری‌ها، فیلدهای ناموجود، تغییر نسخه و حدهای زمانیِ مشخص‌شده را بررسی میکند.
- گذار و پاسخ را تأیید کنید
مسئولان، نسخهٔ قابل اجرا، مسیر استثنا و تصمیم بازگشت یا قرنطینه را ثبت می‌کنند.
رد، قرنطینه و تعلیق استفاده، نتیجه‌های متفاوتی دارند
تیم دریافت‌کننده هنگام شکست اعتبارسنجی، رکورد خام و دلیل شکست را نگه میدارد. مسیر قرنطینه، رکورد را تا زمان بررسی مسئول مربوط از نتیجهٔ تحلیلیِ تحت تأثیر کنار میگذارد. رویداد را بی‌اطلاع اصلاح نکنید، اصل را پاک نکنید و مقدار ناموجود را صفرِ اندازه‌گیری‌شده ننامید.
بررسیکننده، فیلدهای ناموجود، معنا یا نسخهٔ پشتیبانی‌نشده، مقدارهای عددی نامعتبر و ترتیب زمانیِ ناسازگار با فرض یک روز مشترک را قرنطینه میکند. شناسهٔ دقیقاً تکرارشده را تکراری گزارش میکند. نمونه‌ای با ساختار معتبر و بدون حد تازگیِ توافقشده، وضعیت تعلیق استفاده یا hold میگیرد و پنج ثانیه به‌عنوان زمان مشاهده‌شدهٔ انتقال ثبت می‌شود.
مثال، نام مسئول واقعی، مهلت ارجاع یا عدم‌قطعیتِ اندازه‌گیری‌شدهٔ ساعت ندارد. توافق خالی، این فیلدها را خالی میگذارد. تیم باید پیش از اعمال قاعده در محیط تولید، آن‌ها را ارائه و تأیید کند. قبولی در این بررسی محلیِ نرم‌افزار، قابل اتکا بودن اندازه‌گیریِ منبع، امنیت انتقال یا مناسب بودن برای تصمیم ایمنی را ثابت نمیکند.
پیش از تأیید، رکورد را با مصرف‌کننده بررسی کنید
ماژول قابل دریافت شامل مثال قبلی، فیلدهای خالیِ جداگانه و بررسیکننده است. با یک محیط اجرای JavaScript به‌صورت محلی اجرا می‌شود و هیچ درخواست شبکه‌ای ندارد. خروجی، شمارندهٔ مشاهدهشده و دلیل تعلیق استفاده را گزارش میکند؛ فرمان نمی‌فرستد و سیستم کارخانه را تغییر نمی‌دهد.
برای زمان مبدأ، زمان ورود و عدم‌قطعیت، از راهنمای زمان رویداد استفاده کنید. برای انتخاب روش ارتباط، مقایسهٔ قبلیِ پروتکل‌ها را بخوانید. این مقالهٔ تکمیلی، مسئولیت تولیدکننده و مصرف‌کننده، بازبینی تغییر و رفتار اجراییِ رد داده را اضافه میکند و واژه‌نامهٔ دیگری از پروتکل‌ها نیست.
در تحویل واقعیِ بعدی داده، از هر دو مسئول بخواهید یک محاسبهٔ وابسته و یک تغییر را که آن را نامعتبر میکند مشخص کنند. رکورد اصلی را نگه دارید، بررسیهای توافقشده را اجرا کنید و ثبت کنید چه کسی نخستین فرضِ بدون پشتوانه را روشن میکند.
مثالی از مسئولیت داده در یادداشت ابوش
بخوانید مسئولیت و اختیار تصمیم چگونه به استفادهٔ قابل اتکا از داده کمک می‌کنند؛ سپس همان مسئولیت‌ها را در توافق رویداد تعیین کنید.
یادداشت راهبری داده را بخوانید
به زبان انگلیسی در وبلاگ شخصی ابوش، بنیان‌گذار Vrolen. توضیح مرتبط دربارهٔ مسئولیت، این قرارداد فنی را اعتبارسنجی نمیکند و جای مستندات منبع را نمی‌گیرد.
چک‌لیست عملی
- تولیدکننده، مصرف‌کننده و مسئول اندازهگیری را مشخص کنید.
- نتیجهٔ شمارش‌شده، واحد و معنای تجمعی یا افزایشی را تعریف کنید.
- محدودهٔ شناسهٔ رویداد و رسیدگی به تکرار را مشخص کنید.
- زمان مبدأ، زمان ورود، تاریخ و عدم‌قطعیت را جدا نگه دارید.
- بر قواعد تازگی و کیفیتِ منبع توافق کنید.
- ساختار و معنا را با هم نسخه‌بندی کنید.
- رکوردهای خامِ مردود را حفظ و مسئول رسیدگی به قرنطینه را مشخص کنید.
- پیش از تأیید تغییر، مصرف‌کنندگان تحت تأثیر را بررسی کنید.
پرسش‌های متداول
پرسش‌های متداول
منابع و مطالعهٔ بیشتر
منابع معتبر استفاده‌شده برای پژوهش و بررسی این راهنما.