נכנסתם לרכב שלכם, לחצתם על כפתור ההתנעה והמנוע התעורר לחיים תוך זמן קצר, אבל איך הרכב שלכם החליט אם הוא צריך להתניע או לא?
ובכן, כדי לגרום למכונית להתניע, מספר אנטנות ויחידות בקרה אלקטרוניות תקשרו עם שלט המפתח. פרוטוקול Controller Area Network (CAN) מבטיח שהתקשורת בין שלט המפתח, האנטנות וה-ECU שלך מתרחשת כראוי בתוך המכונית שלך.
אז מהו פרוטוקול ה-CAN, וכיצד הוא עוזר להתקנים במערכות הרכב שלך לעבוד יחד? ובכן, בוא נגלה.
מהו פרוטוקול ה-CAN, ומדוע הוא נחוץ?
בזמנו, למכוניות לא היו הרבה מוצרי אלקטרוניקה. למעשה, אם רציתם להתניע את הרכב שלכם בתחילת שנות ה-1900, הייתם צריכים לצאת מהרכב ולהניע את המנוע ביד.
למכוניות של היום, להיפך, יש כמה חיישנים אלקטרוניים, ומכשירים אלקטרוניים עוקבים אחר הכל, החל מטמפרטורת תא הנוסעים ועד סיבובי גל הארכובה.
עם זאת, הנתונים המתקבלים מהחיישנים הללו אינם בעלי ערך עד שהם מעובדים. עיבוד נתונים זה מבוצע על ידי התקני מחשוב הידועים כיחידות בקרה אלקטרוניות (ECU).
בניגוד למחשב עם מעבד יחיד, לרכב יש מספר ECU, שכל אחד מהם אחראי על ביצוע משימה מסוימת. למרות ש-ECU אלה יכולים לבצע משימה בודדת ביעילות, הם חייבים לעבוד יחד כדי להבטיח תכונות כמו
שרירי בטן ו יציאה עובד בצורה תקינה.בשל כך, כל ה-ECU במכונית צריכים להיות מחוברים. אפשר להשתמש בטופולוגיה מנקודה לנקודה כדי ליצור את החיבורים האלה, כאשר כל ECU מחובר ישירות לכל ECU אחר. עם זאת, ארכיטקטורה זו תהפוך את המערכת למורכבת. למעשה, לרכב מודרני יש יותר מ-70 ECU, וחיבורם באופן אחד לאחד יגדיל את משקל החיווט באופן אקספוננציאלי.
כדי לפתור בעיה זו, בוש, יחד עם מרצדס-בנץ ואינטל, יצרו את פרוטוקול Controller Area Network ב-1986. פרוטוקול זה איפשר ל-ECU לתקשר זה עם זה באמצעות אפיק נתונים משותף המכונה אפיק CAN.
איך CAN עובד?
פרוטוקול CAN הוא מתודולוגיית תקשורת מבוססת הודעות המסתמכת על קבוצה של כבלים מפותלים להעברת נתונים. חוטים אלו ידועים כ-CAN גבוה ו-CAN נמוך.
כדי לאפשר העברת נתונים על חוטים אלה, רמות המתח שלהם משתנות. שינויים אלה ברמות המתח מתורגמים לאחר מכן לרמות לוגיות המאפשרות ל-ECU במכונית לתקשר זה עם זה.
להעברת לוגיקה אחת באפיק ה-CAN, המתח של שני הקווים מוגדר ל-2.5 וולט. מצב זה ידוע גם כמצב רצסיבי, כלומר אפיק ה-CAN זמין לשימוש על ידי כל ECU.
להיפך, לוגיקה 0 משודרת באפיק CAN כאשר קו ה-CAN הגבוה במתח של 3.5 וולט וקו ה-CAN נמוך ב-1.5 וולט. מצב זה של האוטובוס ידוע גם בתור המצב הדומיננטי, אשר אומר לכל ECU במערכת כי ECU אחר משדר, אז עליהם לחכות עד שהשידור יסתיים לפני שהם יתחילו להעביר את ההודעה שלהם.
כדי לאפשר שינויי מתח אלה, ה-ECU של המכונית מחוברים לאפיק ה-CAN באמצעות מקלט משדר CAN ובקר CAN. מקלט המשדר אחראי להמרת רמות המתח באפיק ה-CAN לרמות שה-ECU יכול להבין. הבקר, לעומת זאת, משמש לניהול הנתונים שהתקבלו ולהבטיח שהדרישות של הפרוטוקול מתקיימות.
כל ה-ECU האלה המחוברים לאפיק ה-CAN יכולים להעביר נתונים על הכבל המעוות, אבל יש תפס, רק ההודעה עם העדיפות הגבוהה ביותר יכולה להיות משודרת באפיק ה-CAN. כדי להבין כיצד ECU משדר נתונים באפיק ה-CAN, עלינו להבין את מבנה ההודעות של פרוטוקול ה-CAN.
הבנת מבנה המסר של פרוטוקול CAN
בכל פעם ששני ECUs רוצים לתקשר, הודעות עם המבנה שלהלן מועברות באפיק ה-CAN.
הודעות אלו מועברות על ידי שינוי רמות המתח באפיק ה-CAN, ועיצוב הצמד המעוות של חוטי ה-CAN מונע השחתת נתונים במהלך השידור.
- כך F: קיצור של Start Of Frame, סיביות SOF היא מסגרת נתונים דומיננטית של סיביות בודדת. ביט זה מועבר על ידי צומת כאשר הוא רוצה לשלוח נתונים על אפיק ה-CAN.
- מזהה: המזהה בפרוטוקול CAN יכול להיות בגודל של 11 סיביות או 29 סיביות. גודל המזהה מבוסס על גרסת פרוטוקול ה-CAN שבה נעשה שימוש. אם נעשה שימוש בגרסה המורחבת של CAN, אזי גודל המזהה הוא 29 סיביות, ובמקרים אחרים, גודל המזהה הוא 11 סיביות. המטרה העיקרית של המזהה היא לזהות את העדיפות של ההודעה.
- RTR: בקשת השידור מרחוק או ה-RTR משמשת צומת כאשר יש לבקש נתונים מצומת אחר. לשם כך, הצומת שרוצה את הנתונים שולח הודעה עם סיביות רצסיבית במסגרת ה-RTR לצומת המיועד.
- DLC: קוד אורך הנתונים מגדיר את גודל הנתונים המועברים בשדה הנתונים.
- שדה נתונים: שדה זה מכיל את מטען הנתונים. גודל המטען הזה הוא 8 בתים, אבל פרוטוקולים חדשים יותר כמו CAN FD מגדילים את גודל המטען הזה ל-64 בתים.
- CRC: קיצור של Cyclic Redundancy Check, שדה CRC הוא מסגרת לבדיקת שגיאות. אותו גודל הוא 15 סיביות ומחושב הן על ידי המקלט והן על ידי המשדר. הצומת המשדר יוצר CRC עבור הנתונים בעת השידור. עם קבלת הנתונים, המקלט מחשב את ה-CRC עבור הנתונים שהתקבלו. אם שני ה-CRCs תואמים, שלמות הנתונים מאושרת. אם לא, הנתונים מכילים שגיאות.
- שדה אישור: ברגע שהנתונים מתקבלים והם נקיים משגיאות, הצומת המקבל מזין ביט דומיננטי למסגרת האישור ושולח אותו בחזרה למשדר. זה אומר למשדר שהנתונים התקבלו וללא שגיאות.
- סוף מסגרת: לאחר השלמת העברת הנתונים, מועברות שבעה ביטים רצסיביים עוקבים. זה מבטיח שכל הצמתים יודעים שצומת השלים את העברת הנתונים, והם יכולים להעביר נתונים על האוטובוס.
בנוסף לסיביות לעיל, לפרוטוקול CAN יש כמה ביטים שמורים לשימוש עתידי.
פישוט CAN באמצעות דוגמה
כעת, לאחר שיש לנו הבנה בסיסית כיצד נראית הודעה באפיק CAN, אנו יכולים להבין כיצד מועברים נתונים בין ECUs שונים.
לשם הפשטות, נניח שלמכונית שלנו יש 3 ECUs: Node 1, Node 2 ו-Node 3. מתוך 3 ECUs, Node 1 ו Node 2 רוצים לתקשר עם Node 3.
בואו נראה כיצד פרוטוקול CAN עוזר להבטיח תקשורת בתרחיש כזה.
- זיהוי מצב האוטובוס: כל ה-ECU במכונית מחוברים לאפיק CAN. במקרה של הדוגמה שלנו, צומת 1 וצומת 2 רוצים לשלוח נתונים ל-ECU אחר; לפני שעושים זאת, שני ה-ECU צריכים לבדוק את מצב אפיק ה-CAN. אם האוטובוס נמצא במצב דומיננטי, אזי ה-ECU לא יכולים לשדר נתונים כשהאוטובוס נמצא בשימוש. מצד שני, אם האוטובוס נמצא במצב רצסיבי, ה-ECUs יכולים לשדר נתונים.
- שליחת תחילת המסגרת: אם המתח ההפרש באפיק ה-CAN הוא אפס, גם צומת 1 וגם צומת 2 משנים את מצב האפיק לדומיננטי. לשם כך, המתח של CAN גבוה מועלה ל-3.5 וולט, והמתח של CAN נמוך מופחת ל-1.5 וולט.
- החלטה איזה צומת יכול לגשת לאוטובוס: ברגע שה-SOF נשלח, שני הצמתים מתחרים על גישה לאפיק ה-CAN. אפיק ה-CAN משתמש בפרוטוקול Carrier Sense Multiple Access/Collision Detection (CSMA/CD) כדי להחליט איזה צומת מקבל גישה. פרוטוקול זה משווה את המזהים המועברים על ידי שני הצמתים ומעניק גישה לזה בעל העדיפות הגבוהה יותר.
- שליחת נתונים: ברגע שלצומת יש גישה לאוטובוס, שדה הנתונים, יחד עם ה-CRC, נשלח למקלט.
- בדיקה וסיום התקשורת: עם קבלת הנתונים, צומת 3 בודק את ה-CRC של הנתונים שהתקבלו. אם אין שגיאות, צומת 3 שולח הודעת CAN לצומת המשדר עם סיביות דומיננטית על מסגרת האישור יחד עם ה-EOF כדי לסיים את התקשורת.
סוגים שונים של CAN
למרות שמבנה ההודעות המשמש את פרוטוקול CAN נשאר זהה, מהירות העברת הנתונים וגודל סיביות הנתונים משתנים כדי להעביר רוחבי פס גבוהים יותר של נתונים.
בשל הבדלים אלה, לפרוטוקול CAN יש גרסאות שונות, וסקירה כללית של אותם ניתנת להלן:
- CAN במהירות גבוהה: הנתונים על חוטי ה-CAN מועברים באופן סדרתי, וניתן לבצע שידור זה בקצבים שונים. עבור CAN במהירות גבוהה, מהירות זו היא 1 Mbps. בשל מהירות העברת הנתונים הגבוהה הזו, נעשה שימוש בפח במהירות גבוהה עבור ECU, השולטים במערכות ההנעה ובמערכות הבטיחות.
- CAN במהירות נמוכה: במקרה של CAN במהירות נמוכה, קצב העברת הנתונים מופחת ל-125 kbps. מכיוון שהמהירות הנמוכה יכולה להציע קצבי נתונים נמוכים יותר, היא משמשת לחיבור ECU שמנהלים את נוחות הנוסע, כמו מיזוג האוויר או מערכת המידע והבידור.
- יכול FD: קיצור של קצב נתונים גמיש CAN, CAN FD הוא הגרסה החדשה ביותר של פרוטוקול CAN. זה מגדיל את גודל מסגרת הנתונים ל-64 בתים ומאפשר ל-ECU לשדר נתונים במהירויות הנעות בין 1 Mbps ל-8 Mbps. מהירות העברת נתונים זו יכולה להיות מנוהלת על ידי ה-ECU בזמן אמת בהתבסס על דרישות המערכת, מה שמאפשר העברת נתונים במהירויות גבוהות יותר.
מהו העתיד של תקשורת רכב?
פרוטוקול CAN מאפשר למספר ECUs לתקשר אחד עם השני. תקשורת זו מאפשרת תכונות בטיחות כמו בקרת יציבות אלקטרונית ומערכות סיוע מתקדמות לנהג כמו זיהוי נקודה מתה ובקרת שיוט אדפטיבית.
עם זאת, עם הופעתן של תכונות מתקדמות כמו נהיגה אוטונומית, כמות הנתונים המועברת על ידי אפיק ה-CAN עולה באופן אקספוננציאלי. כדי לאפשר תכונות אלה, גרסאות חדשות יותר של פרוטוקול CAN, כמו CAN FD, נכנסות לשוק.
