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