מוצר מחובר אוסף נתונים כל הזמן, אך נתונים בפני עצמם אינם שווים הרבה. הערך האמיתי נוצר ברגע שבו המערכת מזהה משהו חריג ופועלת — שולחת הודעה, מכבה משאבה או פותחת קריאת שירות. התראות מנתוני מוצר הן המנגנון שהופך זרם מדידות לפעולה עסקית, והן אחד הרכיבים שמצדיקים מנוי חודשי במוצרי חומרה. אנחנו בפרוג'קטס האוס רואים שוב ושוב שהמנוע הזה, כשהוא מתוכנן נכון, הופך מוצר טוב למוצר שקשה לוותר עליו.

מה עושה מנוע חוקים

מנוע חוקים הוא רכיב שמקבל אירועים ומדידות, בודק אותם מול קבוצת תנאים, ומפעיל פעולה כשהתנאי מתקיים. המבנה הבסיסי הוא שלשה: טריגר, תנאי ופעולה. הטריגר יכול להיות מדידה חדשה, חלוף זמן או שינוי מצב; התנאי הוא ביטוי לוגי על ערכים; והפעולה יכולה להיות התראה למשתמש, רישום ביומן, קריאה למערכת חיצונית או פקודה חזרה למכשיר. היתרון הגדול הוא שהחוקים ניתנים לעריכה בלי לשנות קושחה או להוציא גרסה חדשה של אפליקציה. כך אפשר להתאים את ההתנהגות ללקוח מסוים, לענף מסוים או לעונה מסוימת, בלי מחזור פיתוח שלם ובלי לסכן את שאר הצי.

  • חוקי סף: ערך שחצה גבול עליון או תחתון, למשל טמפרטורה או לחץ.
  • חוקי מגמה: שינוי מהיר מדי לאורך חלון זמן, שמצביע על תקלה מתפתחת.
  • חוקי היעדר: מכשיר שהפסיק לדווח, לעיתים ההתראה החשובה מכולן.
  • חוקים מורכבים: שילוב של כמה חיישנים יחד עם שעה ומיקום.

איפה החוקים רצים: במכשיר או בענן

חוקים שרצים בענן קלים לעדכון, מאפשרים לראות תמונה רוחבית על כל הצי, ואינם מוגבלים במשאבי חישוב. חוקים שרצים במכשיר עצמו פועלים גם בלי קישוריות, מגיבים תוך אלפיות שנייה, וחוסכים תעבורה יקרה. ברוב המוצרים התשובה היא חלוקה: חוקי בטיחות מיידיים במכשיר, חוקים עסקיים בענן. ההחלטה משפיעה גם על בחירת הפרוטוקול, נושא שנדון במאמר MQTT או HTTP, ועל מבנה התשתית שמתואר במאמר שרת וענן למוצר מחובר. כדאי לתכנן מראש גם מה קורה כשהקישוריות חוזרת אחרי ניתוק: אירועים שנצברו במכשיר חייבים להישלח עם חותמת הזמן המקורית שלהם, אחרת ההתראות יגיעו בסדר שגוי ויבלבלו את המשתמש.

הבעיה האמיתית: הצפת התראות

התראות מנתוני מוצר שאינן מסוננות הופכות תוך שבועות לרעש רקע, ומערכת ששולחת יותר מדי הודעות מאבדת את המשתמשים שלה. אחרי כמה עשרות הודעות שווא אף אחד לא פותח את ההודעה הבאה, וגם ההתראה החשובה באמת נבלעת. כמה כלים מעשיים מונעים את זה: השהיה מינימלית בין התראות מאותו סוג, דרישה שהתנאי יתקיים לאורך כמה דגימות רצופות ולא רק באחת, היסטרזיס שמונע ריצוד סביב הסף, וקיבוץ התראות דומות להודעה אחת. חשוב גם להגדיר רמות חומרה ולנתב אותן אחרת — התראה קריטית לטלפון, אזהרה לדוח יומי בלבד. הצגת התמונה המלאה נעשית בדרך כלל דרך דשבורד ניהול למוצר IoT.

איכות הנתונים שמזינים את החוקים

מנוע חוקים מצוין על נתונים גרועים ייצור התראות גרועות. לכן חלק בלתי נפרד מהתכנון הוא סינון רעש, טיפול בקריאות חסרות וכיול. בחירת רכיבי המדידה משפיעה ישירות על מספר התראות השווא, כפי שמוסבר במאמר חיישנים במוצר חדש. ככל שהצי גדל, נדרשת גם יכולת לנהל חוקים לפי קבוצות מכשירים ולקוחות, נושא שמפורט במאמר ניהול צי מכשירים בענן. כלל עבודה פשוט הוא לבדוק כל חוק חדש על נתונים היסטוריים לפני שמפעילים אותו בשטח, ולראות כמה התראות הוא היה מייצר בחודש שחלף.

עלות ותחזוקה לאורך זמן

עיבוד רציף של נתונים עולה כסף, ולכן שווה לחשב מראש כמה מדידות נשמרות ובאיזה רזולוציה. במקרים רבים אפשר לצמצם דרמטית עלות על ידי שמירת סיכומים במקום כל דגימה. הרחבה על כך תמצאו במאמר כמה עולה תשתית ענן למוצר מחובר. בסופו של דבר התראות מנתוני מוצר הן מוצר בפני עצמן שדורש תחזוקה, מדידה ושיפור. מידע נוסף מרוכז בעמוד פיתוח תוכנה ואפליקציה.

רוצים לתכנן מנוע חוקים שמתאים למוצר שלכם ולא מציף את הלקוחות? קבלו מאיתנו הצעת מחיר לאפיון ולפיתוח המערכת.

רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.