מגה טיפ מיכשור

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

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

בשנת 2019, מחקר של מיקרוסופט שכלל שלושת אלפיים מובילי צוותי IT המעורבים בפרויקטים של IoT, הגיע למסקנה מאכזבת: 30% מהפרויקטים אינם מגיעים לשלב ב-PoC, וב-75% מהפריסות ה-IoT שבסופו של דבר עוברים את ה-PoC אינם מניבים את התוצאות הצפויות. על פי דו"ח IoT Signals של מיקרוסופט, 38% מהנשאלים מציינים אתגרים טכניים כמחסום העיקרי לאימוץ "האינטרנט של הדברים" (IoT). גורמים אחרים המשפיעים על שיעורי ההצלחה של פרויקט IoT כוללים היעדר כישרון טכני ותקציבים מוגבלים. לאור הממצאים, הנה חמישה טיפים למסע ה-IoT של החברה שלך:

זיהוי מוקדם של חסמים טכנולוגיים

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

מותג תכשיטי כושר פנה לסופטק כדי לעצב צמיד יוקרתי שיעקוב אחר פעילותם הגופנית של המשתמשים; המכשיר היה אמור לדבר עם אפליקציה סלולרית באמצעות בלוטות'. בתחילת דרכה, החברה לא הבינה שמארז המתכת יפריע לאות הבלוטות'. על מנת להבטיח חיבור יציב בין מכשיר למכשיר, צוות סופטק נאלץ לשנות את שבב הרדיו ולהגביר את אות הבלוטות' ב-500%. על כן, מומלץ להתחיל את הפרויקט בשלב של גילוי חסמים ולבצע הוכחת קונספט. גישה זו מאפשרת לך לאמת את הרעיון שלך, למפות את הדרישות הפונקציונליות (מה המערכת עושה) ואת הדרישות הלא פונקציונליות (איך היא עובדת) של פיתרון ה- IoT, ולזהות את החסרונות הטכנולוגיים הפוטנציאליים לפני הצלילה לפיתוח מוצרים.

היכרות עם ניהול פרויקטים רב צוותים

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

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

הימנעות מהיקף פרויקט שיוביל לביצוע "זוחל"

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

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

תכנון פתרון IoT עם יכולות מדרגיות

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

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

לקחת את האבטחה ברצינות

יחידה 42, חטיבת אבטחת הרשת של פאלו אלטו נטוורקס, גילתה לאחרונה כי 98% מכלל התעבורה של IoT עוברת ללא הצפנה. 46% מהחברות האמריקאיות המשתמשות בפתרונות IoT כבר חוו פרצת אבטחה אחת לפחות.

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

חברות שרוצות להצליח בפיתוח IoT צריכות לדבוק בעקרון אבטחת המוצר. ראשית, יש להצפין את הנתונים המאוחסנים במכשיר, או בין רכיבי מערכת IoT. שנית, יש לשים תחת חומת אש את כל תשתיות ה-IT וליישם כלי ניטור אבטחה של IoT, כגוןAWS IoT Device Defender. לבסוף, יש לחזק את האבטחה ברמת החומרה ולפרוס מנגנון עדכון קושחה (OTA) כדי להפעיל תיקוני אבטחה.

מקור: www.iotforall.com

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

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

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

פוליטיקה וקווים של הרשות

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

לפניכם חמישה טיפים למציאת פתרון רובוטי.

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

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

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

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

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

מקור: https://www.therobotreport.com

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

כיצד אנחנו אמורים לזכור את הכמות העצומה של מסמכים שפיתחנו לאורך הדרך?

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

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

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

מקור: www.automationworld.com