Adam Titely & Christoph Fritsch, Altera
אפליקציות אוטומציה תעשייתית על פני כל המיגזרים – מאוטומציה של המפעל, של המכונה ושל התהליך ועד להפקת אנרגיה, הפצה, ושינוע – דורשים מידה מוגברת של ציוד המאפשר בטיחות. מאמר זה בוחן את חקר המקרה של מערכת תעשייתית על צ’יפ (SoC) – כונן על צ’יפ – כדי להסביר איך מהנדסים יכולים לחסוך עד 18 חודשי זמן תכנון בהשגת הסמכה (certification) למוצר בהתאם
ל-IEC 61508. עובדת קיומם של כלים מאושרים מראש כמו Altera® FPGAs, פירושה שהמתכנן מפיק תועלת מהגמישות של FPGAs מבלי לחשוש האם
ניתן להשתמש בקלות ב-FPGAs הללו לאפליקציות בטיחות.
חבילת Altera’s Safety Integrity Level (SIL3) Functional Safety Data (נתוני הבטיחות הפונקציונלית ברמה 3 של Altera), אשר כוללת רשיון לשימוש בכלים של Altera, פרוטוקול אינטרנט (IP), ונתוני התקנים של TUV Rheinland, מקצרת ומפשטת פיתוח של אפליקציות בטיחות על פי ה-IEC 61508, תוך כדי התייחסות יעילה לצורך במערכות בעלות נמוכה הניתנות לשילוב ולהטמעה ברמה גבוהה. תרשים הזרימה וכלי התכנון שלפני הרישוי, כמו גם מערכת משולבת לפני הרישוי וקניין רוחני דיאגנוסטי (פרוטוקול אינטרנט IP), מצמצמים את סיכוני הרישוי באפליקציות תעשייתיות החשובות לבטיחות, כגון כונני servo ו-inverter, קלט/פלט בטוח ובקרי PLCs (מחזור חיי המוצר) ואוטומציה.
הקדמה
אוטומציה תעשייתית, שינוע, רשת חכמה, ותעשיות רבות אחרות דורשות שהמיכון והמוצרים יהיו בטוחים ומורשים לבטיחות פונקציונלית. הגמישות והעלות המצטברת של הבטיחות עשוייה להיות גורם החלטה משמעותי כאשר מפתחים מכונות אשר חייבות לעמוד בסטנדרטים עולמיים של בטיחות. אם חברות מתכננות לשלוח את המוצרים שלהם באנייה למדינות אשר דורשות רישוי על מנת להוכיח עמידה בתקנות הבטיחות המקומיות – כמו הוראה חדשה לבניית מכונות (2006/42/EG), אשר מייצגת דרישת חובה למוצרים המיוצאים לאירופה – אזי הן חייבות לאמץ גישה המכוונת כלפי בטיחות בכל תהליך התכנון, על מנת להיות תחרותיות. סיבה נוספת ליישום בטיחות ביישומים, באה מצד מפעיל המפעל אשר דורש הפעלה בטוחה של המיכון כדי לשפר את הפרודוקטיביות, כגון עבודות תחזוקה שיכולות להתבצע בזמן שחלק מהמכונה עדיין פועל, או זמני העמסה והורדה מקוצרים.
בטיחות מכניסה תהליכים חדשים לתהליך פיתוח מכונות, כמו גם גידול
במורכבות האלקטרונית באפליקציות כאלה. המורכבות המוגברת לרוב מביאה לעלות חומרה גבוהה הרבה יותר. תהליכי העיצוב והפיתוח המורכבים יותר, גם מגדילים את זמן היציאה לשוק של אפליקציה חדשה.
כאשר חברה מחליטה לפתח מוצר בטוח, היא צריכה לשקול בטיחות כפונקציונליות בסיסית של המערכת. מבחינה היסטורית, בטיחות התווספה למערכת באמצעות פונקציונליות נוספת כגון מפעיל נוסף או מודולים של תקשורת בשילוב מערכת מעגל חשמלי (circuitry) כדי לווסת את המערכת. רכיבי הבטיחות המוספים הללו, שהוכנסו מאוחר יותר לתפיסת המערכת, גוררים הוצאות גבוהות יותר באופן משמעותי והם פחות גמישים וניתנים להתאמה, מאשר תכנון אפליקציה בטוחה, אופטימלית לבטיחות ותחרותית מבחינה המחיר, כבר מההתחלה.
אתגרי התכנון לפיתוח אפליקציה בטוחה, כוללים:
אימוץ שיטת תכנון ‘בטוחה’ ומושגי בטיחות
לקיחה בחשבון של מאמצים נוספים הנוגעים לפרוייקט (זמן וטכנולוגיה), המביאים להארכת זמן היציאה לשוק ולעלות גבוהה לבעלים
ניהול הפרוייקט, איסוף הנתונים לכל רכיבי המערכת, ותיעוד הפרוייקט על פי הצרכים של מפרט הבטיחות.
מאמר זה ימחיש איך פרוייקט יכול להיות מוצלח בהגשמת המטרות הן של מתן פתרון בטוח והן של העלות וזמן היציאה לשוק. המפתח להצלחה הוא אימוץ שיטות תכנון תקפות, כלים ומכשירים מורשים כחלק מהמוצר, ולקיחה בחשבון של הבטיחות כבר כאשר מתחילים לפתח את המוצר.
תכנון כונן בטוח
(safe drive)
ללא לקיחה בחשבון של בטיחות, שלבי התכנון הטיפוסיים לפיתוח אפליקציה הינם כפי שהם מופיעים בתרשים 1.
בהתבסס על דרישות השוק והחזון של חברות להצליח בשוק, השלב הראשון הוא לפתח את ארכיטקטורת המוצר, כפי שמוצג בתרשים 2. לצורך אפליקציית בקרה מוטורית (motor control application) טיפוסית, כגון כונן, שלב החלוקה (partitioning) מפריד את המערכת לפונקציות של: בקרת מערכת, תקשורת ובקרה מוטורית בזמן אמת. לדוגמה, המתכנן בוחר אפליקציית תוכנה לחלק הבקרה ולחלק זמן אמת של המערכת ומחליט להשתמש בגישה של חומרה/תוכנה לחלק התקשורת כדי לתמוך בפרוטוקולים של התקשורת התעשייתית באתרנט (industrial Ethernet communication protocols).
השלב הבא הוא בחירת הרכיבים (תרשים 3). ההחלטה עשוייה להוביל לאפליקציה שבה תוכנת הבקרה פועלת על מעבד אפליקציות סטנדרטי, כאשר חלק הבקרה המוטורית בזמן אמת ייושם בעיבוד אות דיגיטלי (DSP), והתקשורת בתוך המערכת תבוצע באמצעות גישה המבוססת על FPGA .FPGA מאפשר גמישות במערכת כדי לעמוד בסטנדרטים תעשייתיים שונים של אתרנט, כגון: Etherne/IP EtherCat PROFINET או SERCOS III באותו מכשיר לחלופין. גמישות זו בחלק התקשורת של הארכיטקטורה מאפשרת התאמה אישית של מצע החומרה הסטנדרטי, לצרכי הפרוטוקול הספציפיים של לקוח הקצה, בקלות רבה.
לאחר שהוחלט על החלוקה והרכיבים נבחרו, צוותי התכנון יעבדו על פיתוח החלק שלהם באפליקציה, באופן עצמאי. אחר כך, הם ישלבו את הרכיבים למערכת שלמה, יבחנו את הפונקציונליות של המערכת, וישחררו את המוצר.
הוספת בטיחות
אם התכנון נעשה עם בטיחות פונקציונלית כחלק מדרישות המוצר, יש להוסיף שלבים נוספים לפרוייקט, כפי שמופיע בצהוב בתרשים 4. כאשר מתכננים אפליקציה בטוחה במטרה להשיג רישוי לבטיחות פונקציונלית, כגון IEC 61508, המורכבות של הפרוייקט גדלה באופן משמעותי כדי לספק מבנה פרוייקט ברור ושקוף אשר תואם לתקן. המפרט של ה-IEC 61508 מכסה את כל מחזור חיי הבטיחות (the whole safety life cycle), מפיתוח האפליקציה ועד להוצאתה משירות פעיל. מאמר זה מתמקד בשלבים הראשונים של מחזור חיי הבטיחות, מהסטארט-אפ של הפרוייקט ועד להשגת רישוי. בעקבות הנוהלים והתהליכים בסטנדרטי הבטיחות, יש צורך לפשט את התקשורת עם המעריך כדי לוודא שהמטרות, המושגים, הנוהלים והפתרונות מובנים ועונים על דרישות הבטיחות.
סטארט-אפ של הפרוייקט וניתוח סיכונים
בשלב הסטארט-אפ וניתוח הסיכונים של הפרוייקט, טווח הבטיחות בפרוייקט מזוהה על פי הדרישות הכלליות לאפליקציה. רמת הבטיחות (SIL) הרצוייה וברת-ההשגה לאפליקציה נקבעת, מנוסחת ומתועדת לשלבי היישום ומהווה בסיס לניתוח סיכונים והערכה. ניתוח הסיכונים מספק את הבסיס למדידות אשר חייבות להעשות מאוחר יותר בתהליך כדי לפתח אפליקציה בטוחה. הוא מייצג את ההבנה של מגבלות המוצר וקשור להגדרת טווח המוצרים. הוא מספק את הבסיס לרמת הבטיחות (SIL) הנדרשת, הגדרה מפורטת של פונקציית הבטיחות והמסגרת של תיעוד המוצר. זה חייב להיעשות ברמת הרכיב כמו גם ברמת המערכת.
פיתוח ארכיטקטורה
בעקבות שלב זה, נעשה פיתוח הארכיטקטורה לאפליקציה על מנת לענות על דרישות הפונקציונליות, כמו גם על דרישות הבטיחות. דרישות הבטיחות נידונות והפונקציות הספציפיות האמורות להיות מושגות במהלך הפעולה ועבודת התחזוקה, מתועדות, יחד עם זיהוי אסטרטגיות אשר יש לנקוט בהן כדי לוודא שאמצעי הבטיחות עונים על הדרישות.
פירוט דרישות הבטיחות
לצורך כונן בטוח, הטווח עשוי לכלול כמה אספקטים כגון זיהוי האם פרמטרים של הכונן מצויים בטווח המותר, או הקלט/פלט של הבטיחות מאותת על אירוע קריטי. מאפיין הבטיחות הבסיסי ביותר לכוננים הוא safe torque off (), שבו המנוע מנותק מאספקת הכוח באופן בטוח. ההליך עשוי גם לכלול העברת מידע למערכת האוטומציה הכוללת, שאירוע בטיחות התרחש ושיש לנקוט באמצעים מסויימים במסגרת חלון זמן מסויים, כגון סגירה ברצף של האפליקציה כולה בעקבות סדרת צעדים, על פני פרק זמן שנקבע מראש.
הוכחת תקפות (validation),
תכנית האישור
פיתוח תכנית הוכחת תקפות (validation) עשוי לכלול שיטות להכנסת כשל מבוקר (controlled failure) על מנת לבדוק את המערכת ומכשירי ניטור נוספים אשר משגיחים על המערכת לצורך השוואה של הפרמטר הנוכחי לטווח של ערכים מותרים, הנקבעים מראש.
בחירת הרכיבים, ומתן אישור לשימוש (qualification) ברכיבים, בפרוטוקול אינטרנט (IP), וכלים
שלב בחירת הרכיבים קיים בפרוייקט טיפוסי, אך עם צורך נוסף לוודא שהרכיבים ופונקציות פרוטוקול האינטרנט (IP) שהוקצו ונבחרו מתאימים לשימוש באפליקציה בטוחה. לצורך הבחירה, חשוב לקחת בחשבון את ההסתברות לטעות (error probability), אשר משמשת כבסיס לחישוב ההסתברות לכשל טוטאלי (FIT) של הפרוייקט ולבסוף לרמת הבטיחות (SIL) הניתנת להשגה. באופן חלקי, ניתן לעשות זאת באמצעות איסוף הנתונים הדרושים לגבי אמצעי וכלי התכנון והמידע, כדי לוודא שהמוצרים משמשים באופן רחב על ידי טווח של משתמשים, ולפיכך, חופשיים מטעויות שיטתיות או בדוקים (לפרוטוקול אינטרנט IP, לדוגמה). הדבר יכול להיות מושג גם באמצעות גישה לדוחות אשר מספקים מידע לגבי שיעורי הטעויות ומידע לגבי מהימנות של מוליכים-למחצה כגון מעבדים או FPGAs. אך, לרוב קשה לקבל גישה לדוחות מהימנות של רכיבים ומוליכים-למחצה, המספקים את המידע הנדרש, במיוחד לגבי כלי תכנון קשורים ולפרוטוקול אינטרנט (IP) המשמש לאפליקציה.
יישום תכנון האפליקציה
פונקציות של מערכות מורכבות כמו פרוטוקולים של תקשורת, ממשק זיכרון ל-IP המשמש ב-FPGA או מעבדים המשולבים OP ב-FPGA, כמו המעבד המשולב ב-Altera Nios® II – שלרוב משמשות להרצת מחסנית התוכנה (software stack) לפרוטוקולי אתרנט תעשייתיים באפליקציות כונן – צריכות להיות מנותחות, להיבדק ולקבל אישור גם עבור אפליקציות בטיחות.
פונקציות
בטיחות/דיאגנוסטיות
בנוסף ליישום האפליקציה, יש להוסיף לתכנון פונקציונליות נוספת. פונקציות פיקוח פרמטרים בסיסיות כגון שעון והספק, ופונקציות מורכבות, כגון ווסתי נתונים אשר מוודאים פעולה נכונה של המערכת על ידי השגחה על התפוקה ממודולציה רחבת-פס (PWM), נדרשות. יש צורך ליישם פונקציות אשר מזהות כשלים באופן אוטומטי, ומעבירות את המערכת למצב בטוח. הפונקציות הבסיסיות כוללות בדיקה שתוכן הזיכרון לא השתנה בשל השפעה חיצונית על התכנון, או פיקוח על שעוני המערכת כדי לוודא שהם מניעים את התכנון בתוך הפרמטרים הספציפיים של המערכת (או נכשלו בשל כשל של רכיבים חיצוניים) ושאספקת הכוח תקינה.
שילוב ובדיקה
לאחר פיתוח הרכיבים הבודדים, הם משולבים ליישום הכונן הבטוח ונבדקים מבחינת עמידה בפונקציונליות המצופה של המערכת, כמו גם עמידה בפונקציונליות הבטיחות אשר צויינה. הוכחת התקפות (validation) של הבטיחות צריכה להבטיח שמאפייני הבטיחות הרצויים פועלים וממשיכים לפעול במהלך הפעולה, לדוגמה, כדי לוודא שהשפעה חיצונית על התכנון לא תהיה בעלת השפעה שלילית על פונקציית הבטיחות כגון ניטרולה בטעות, מבלי שהמערכת תודיע על כך.
הוכחת תקפות (validation) הבטיחות, רישוי ושחרור
לאורך התהליך כולו, נדרש שיתוף פעולה עם המעריך כדי לוודא שהאמצעים שננקטו במהלך שלב הפיתוח הינם סבירים ועונים על רמת הפונקציונליות הבטוחה הנכונה. לבסוף, המעריך נותן רשיון למוצר על בטיחות פונקציונלית וניתן לשחררו לשוק.
הוספת בטיחות שאושרה מראש
יש כמה שלבים שבהם ספקי המוליכים למחצה כמו Altera יכולים לסייע בתהליך ולצמצם את המאמץ לפיתוח אפליקציות בטוחות. לדוגמה, גישה מיידית לנתוני המוליכים למחצה, פרוטוקול אינטרנט (IP), תרשימי זרימה וכלי תכנון אשר כבר קיבלו אישור על בטיחות פונקציונלית, יכולים להאיץ באופן משמעותי את תהליך פיתוח המוצר הכולל, כפי שניתן לראות בתרשים 5.
Altera הקדישה כשנתיים כדי להשיג רישוי למוצריה. המבחנים הדרושים ונתוני השימוש לפרוטוקול אינטרנט (IP) ולכלי העיצוב ונתוני המהימנות של הכלי מסוכמים ומנוסחים בדרך כזו שניתן להציגם לצורך קבלת רישוי לבטיחות פונקציונלית. שיטת התכנון המאושרת על ידי (V-Flow) פותחה כדי להתייחס לצרכים ספציפיים של עיצובי FPGA. פונקציות דיאגנוסטיות חיוניות תוכננו כ-FPGA IP והן ניתנות כחלק מחבילת הבטיחות הפונקציונלית. משתמשי חבילת בטיחות פונקציונלית זו נהנים מההשקעה הישירה של Altera ב-TUV ויכולים לחסוך פרק זמן דומה בלוחות הזמנים של הפרוייקט שלהם.
דוגמאות לכונן בטוח
דוגמה זו של כונן עם קלט/פלט בטוח משתמשת בכלי העיצוב המאושרים FPGA של Altera, תוכנת Quartus® II גירסה 9.0 SP2, ובשיטת תכנון מוצעת, ליישום האפליקציה. בנוסף, נעשה שימוש ביישום FPGA-דואלי לאפליקציה, כפי שמוצג בתרשים 6, במקום במעבדים חיצוניים
וב-DSP. האפליקציה מחולקת לכמה ליבות מעבד רך (several Nions II soft processor cores). המעבד הרך הראשון Nios II מספק תמיכה למחסניות התקשורת (communication attacks), השני מטפל בפיקוח על המערכת, ומעבד ה-Nios II השלישי משולב לחלק הבקרה המוטורית. אלגוריתם הבקרה המוטורית מחולק כך שחלק התוכנה שלו פועל על מעבד Nios II ומואץ על ידי בלוקים של חומרה שפותחו במיוחד לאפליקטור הזה להאצת לולאת הבקרה המוטורית. בקר בטיחות חיצוני מספק את הכפילות הנדרשת לאפליקציית SIL3.
הפתרון מאפשר שילוב הבקר הבטוח עם בקר ה-Fieldbus ב-FPGA בודד, ומשתמש בכלי שילוב המערכת SOPC Builder של Altera כדי לשלב את המעבדים הרכים של Nios II עם הבלוקים האחרים של פרוטוקול אינטרנט (IP) לתקשורת, ממשקי המקודד, וממשקי הזיכרון.
בטיחות בכונן-על-צ’יפ (drive-on-a-chip)
לפיקוח ברמה נמוכה על מטלות דיאגנוסטיות חשובות אך שכיחות
ב-FPGA, דוגמה זו משתמשת בבלוקי פרוטוקול אינטרנט (IP) דיאגנוסטים מורשי-בטיחות, שסופקו על ידי Altera. פרוטוקולי האינטרנט (IPs) הדיאגנוסטים הללו, המתוכננים למפרט IEC 61508, מבצעים פונקציות דיאגנוסטיות שכיחות כגון:
• חישובי בדיקת כפילות מחזורית (CRC) – חישוב זה הינו שימושי במערכות רבות, במיוחד לאפליקציות Fieldbus.
• בדיקת שעון נגזרת – גרעין (core) זה בוחן את קיומם ותדירותם של שעונים במערכת.
• בקר בדיקת SEU – בלוק זה פועל עם חומרת בדיקת טעויות רכות (soft error) מובנות במכשיר כדי לפקח על שינויים שנגרמות על ידי מה שנקרא טעויות רכות.
מאחר שהיישום של גרעיני פרוטוקול אינטרנט (IP) חומרה אלה הוא בתחום הלוגיקה של FPGA, מעבד המערכת משוחרר ממטלות אלה.
יישום העיצוב נעשה על פי ההמלצות שניתנו על ידי החברה. בתחום השיטות המורשות, החברה לקחה את IEC spec וניתחה את שיטות התכנון של ה-FPGA וחלקים דומים. מניתוח זה, החברה יצרה מסמך תרשים זרימת כלי. הנושא המכרזי של תרשים זרימת כלי זה הוא התיאור של FPGA V-flow שפותח על ידי החברה, המוצג בתרשים 7.
ה-V-Flow והתיעוד המלווה אותו ממפים את כל השלבים בתכנון של אפליקצייה בטוחה ל-FPGA של החברה למפרט IEC ולדרישות שלו. בנוסף, הוא מסביר אילו כלים של החברה משמשים לשלבי התכנון שצויינו. פרקים ספציפיים במפרט IEC נידונים וניתן הסבר המכוון את משתמש Altera לצעדי הפיתוח הנכונים לפיתוח אפליקציה בטוחה.
החברה מספקת את חבילת נתוני הבטיחות הפונקציונלית הראשונה, המאושרת על ידי TUV, אשר מכסה כלי פיתוח מורשים (לדוגמה, תוכנת Quartus II גירסה 9.0 SP2). התיעוד והנתונים שהמעריך זקוק להם לצורך רישוי נכללים וניתנים בפורמט התואם באופן מדוייק לפורמט של מפרט IEC 61508, כך שהמעריך יכול לעבד אותם בקלות. קיומו של תיעוד זה בפורמט הנכון חוסך עבודה רבה של תיעוד פרוייקט הבטיחות.
בדוח המהימנות שנכלל בחבילת נתוני הבטיחות הפונקציונלית, Altera מספקת ניתוח מקיף של מידע סטטיסטי לגבי המהימנות של FPGAs. כל המידע הנדרש לחישוב שיעור הכשלים-בזמן (FIT) הוא חלק מהתיעוד הניתן, כולל קווים מנחים המסבירים איך לבצע חישוב זה כך שניתן יהיה להציגו בקלות למעריך, לצורך קבלת רישוי.
מסקנה
על ידי שימוש מחדש בתפיסת מערכת עבור כונן, אשר מבוססת על יישום 2-chip המאושר מראש ועל שיטת תכנון מאושרת, תרשים תכנון מאושר, כלים ופרוטוקול אינטרנט (IP), ניתן להאיץ באופן משמעותי את הפיתוח של אפליקציה טיפוסית. הרישוי מואץ כאשר נתוני המהימנות לגבי הרכיבים, נגישים באופן מיידי וניתנים בפורמט שניתן לשילוב בקלות לתיעוד הכולל, לצורך רשיון בטיחות. מתכננים יכולים לנצל את שילוב התכנון הגמיש על ידי שימוש ב FPGAs גם לתכנון הבטיחות וגם לתכנון המערכת. כאשר אספקט הבטיחות נחשב לדרישת מפתח לאפליקציה, הוא משולב לרעיון הכולל ויכול להיות ממומש על ידי הגשמת המטרות של עלות וזמן ההגעה לשוק.
תודות
Adam Titley, מהנדס תכנון MTS, פתרונות משולבים, תאגיד Altera
Christoph Fritsch, שיווק אסטרטגי, יחידה עסקית תעשייתית ורכב, תאגיד Altera
הכתבה נמסרה באדיבות חברת איסטרוניקס.
