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

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

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

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

איזה גורם צורה מתאים במיוחד עבור היישום הנדון?
COMs ו-SBCs יכולים להציע יכולות דומות, אך כל אחד לוקח נתיב תכנון שונה כדי לאפשר את הביצועים. ההשפעה לטווח הארוך של החלטה זו היא משמעותית, וכורכת את הפיתרון אל גורם הצורה הנבחר ומחזור החיים הנלווה של המוצר. אם המערכת מוגבלת על-ידי שיקולי ירושה, שדרוגים או חיבור אל מערכות קיימות, האופציות עשויות להיות פחות גמישות מאשר במקרה שהמערכת היא חדשה וללא היסטוריה.
SBCs של PC/104 מאפשרים למודולים לערום יחד כמו אבני בניין, פיתרון מודולרי מאוד המונע שימוש בלוח אחורי. כרטיסים מתאימים לרוב עבור תכנונים המשתמשים בעד 25 ואט, נקודת תכנון תרמי גבוהה (thermal design point – TDP) עבור מערכות בעלות הספק גבוה יותר. בתור רכיבים מבוססי-תקנים, למפתחים יש גישה לכרטיסים חלופיים תמיד בין יצרן ליצרן, ומוסיפים גמישות וערך לתהליך הרכישה. גם אין צורך בכרטיס-בסיס (baseboard), והמערכת פשוט דורשת את ספק הכוח ומערך הכבלים שלה. ניתן להציב מחברי I/O בכל ארבע הפינות של הכרטיס, גם מעל וגם מתחת. אם כי מערך הממשק איננו מוגדר, ממשקי CPU/chipset מכוונים אופיינית אל כותרות של IDC, מחברי מעגל מודפס תקניים או מחברים מיוחדים לצפיפות גבוהה. עבור המתכננים, מדובר בהערכת הזמן, העלות והמומחיות. האם הזמן לשיווק (Time to Market) מושהה על-ידי התאמת הפיתוח של כרטיס-בסיס? והאם קיימת דרגה גבוהה של אמון בידע הטכני הדרוש כדי להשלים כרטיס-בסיס מהר וביעילות לעלות? האם היישום יכול להרשות לעצמו בקלות תכנון בעל שני כרטיסים? אם אלה הן אבני הדרך לקראת השימוש בכרטיס-בסיס, אזי PC/104 מהווה פיתרון יעיל.
בניגוד לכך, COMs מיועד לספקטרום גדול יותר של אופציות הספק, החל מ-38 ואט ב-®COM Express, ומתחת ל-12 ואט בתקני ®Qseven ו- (Smart Mobility ARChitecture).
לא כל תכונה או ממשק חייב להיות נתמך על-ידי כל מודול תקני; במקום, כרטיס בסיס חיוני כדי לתרום ביצועים מיוחדים וה-I/O הדרוש עבור היישום הספציפי. שדרוג הוא יעיל-לעלות, כאשר ניתן להחליף מודול כדי לשדרג את הביצועים, אך עדיין ניתן להסתמך על אותו כרטיס-בסיס מיוחד למשימה. יישומים אחדים יראו ערך ממשי בפיתרון של שני כרטיסים, בשעה שכרטיס הנושא (carrier) עשוי לפי מידה מציע התאמה מושלמת של ביצועים ומתמשק במקום פיזי קטן ביותר. התאמה לצרכי המשתמש יכולה לשרוד בדורות מוצר מרובים, בשעה שהביצועים משתפרים בהתמדה עם המודולים החדשים הניתנים להחלפה ממגוון רחב של יצרנים. האם אתה קשור לגודל פיזי קיים? COMs מציע גם מגוון גדלים ואופציות ביצועים המגדילים את המטרה אליה ניתן לשמש אותם.
ככלל, SBC מספק מבנה של מחשב עצמאי. המערכת מוכנה; רק הוסף הספק וחבר את ה-I/O שבחרת. COMs מסתמך על כרטיסי הבסיס והמחברים שלו כדי להוביל את כל נתיבי ה-I/O דרך המערכת שלך, ללא אפשרות של I/O יותר גמישים שיתחברו ישירות למודול. כרטיס הבסיס דורש משאבי פיתוח נוספים אך מאפשר גמישות במונחים של מיקום הממשקים. חשוב יותר, מיתוג ממושג של מודול ל-SBC איננו דבר פשוט. עם הרבה הבדלים על כיצד הן ממומשות, בחירה של פלטפורמה אחת לעומת אחרת מחייבת את התכנון למשך הרבה זמן. המפתחים צריכים לשאול אילו מרכיבים מאפשרים לא רק את נקודת ההתחלה החזקה ביותר עבור המערכת שלהם, אלא גם את נתיב הפיתוח המועדף במונחים של כרטיסי בסיס. האם אתה רוצה להעביר משאבי תכנון לכרטיס הבסיס או שמא אתה יכול לעבוד עם המבנה המוגדר של מערכת לוח אחורי (carrier)?

האם התכנון שלך מאופיין על-ידי צריכת הספק נמוכה או נמוכה ביותר?
ביצועי ה-CPU קשורים ישירות לצריכת ההספק; ככלל, גורמי צורה קטנים יותר מבטיחים צריכת הספק נמוכה יותר ולכן ביצועים נמוכים יותר. כאשר התכנונים מוגבלים לקירור פסיבי בשל המקום הפיזי או מגבלות תכנון אחרות, יש להתחשב בפשרות הביצועים במונחים של CPU בעל ביצועים נמוכים יותר.
אם התכנון יכול לשאת קירור אקטיבי- הדרוש כדי לנהל יתר חום המופק על-ידי מעבד בעל ביצועים גבוהים יותר, קיים לרוב מספר יותר גדול של אופציות במונחים של פלטפורמה, עריכה, CPU ועוד. לדוגמה, ® COM Express יכול לשנות את גודלו עם מגוון של גדלי-שטח מודול שונים לשם התאמה אל האופציות הרבות של בחירת CPU .COM Express® Basic and Compact sizes הם הגדלים הגדולים יותר בתוך גורם צורה זה, הניתן להפחתה אל גודל מיני, דומה בהשוואה עם גורם הצורה הקצר של ה-® SMARC.
תכנונים דורשים לרוב מבט ישיר בהערכת ניהול ההספק כנגד דרישות לביצועים, אך עדיין יש כמה אופציות עדינות הפותחות דלתות חדשות עבור מערכות בעלותה ספק נמוך ביותר, וביצועים גבוהים יותר. בתחום של הספק נמוך בתכנונים קטנים, קלים ואמינים, פלטפורמות x86 אותגרו בעבר על-ידי מעבדי ARM. אולם ההתקדמות עדיין נמשכת, וכיום למפתחים יש גישה לאופציה אמינה של תכנוני x86 בעלי הספק נמוך בגודל קטן ביותר. מעבדי מערכת-על-שבב חדשים של אינטל מציעים ביצועים גבוהים יותר מאשר הקודמים בשבב x86 הצורך פחות מ-10 ואט. על המפתחים לקבוע אם עדיף שהמערכות יקריבו ביצועים יותר מאשר הספק. המפתח כאן הוא שהתכנונים יהיו בעלי ממדים הנכונים במונחי-מפתח של הספק וביצועים. לדוגמה, אם היישום דורש ביצועי CPU גבוהים בממדים קטנים, מודולים של ® COM Express בגדלים של Basic ו-Compact יכולים לספק את גורם הצורה האידיאלי. כאשר ביצועי CPU הם קבילים, למפתחים יש יותר אופציות ועליהם לשקול ארכיטקטורה ומערך ממשקים כדי לסייע להם להחליט על גורם הצורה שלהם.

האם יש איזה נימוק מכריע עבור ארכיטקטורה אחת כנגד אחרת?
הן ל-x86 והן ל-ARM יש תפקידים מוגדרים היטב בשוק המשובצים – כל אחת מהן מתאימה אידיאלית לסוג מסוים של יישומים, וכל אחת מוגדרת במהות על-ידי ההבדלים באופן בו הן מתקשרות עם ה-I/Os. התקשורת בעלת שלושת השלבים של ARM שומרת על תהליכים חלקים אך מקטינה את ההספק ומבצעת את העבודה, בשעה שהתהליך בעל 10 שלבים של x86 הוא יותר מפורט אך גם דורש יותר זמן, הספק וזיכרון לשם השלמה.
ב-x86, תהליך תקשורת זה מסתמך על CISC או Complex Instruction Set Computing architecture .CISC היא ארכיטקטורה בוגרת, עם בחירות ליבת ארכיטקטורה הכוללות הוראות לעבוד ישירות עם I/O, כמו גם עם זיכרון. פרוטוקול התקשורת של ARM ידוע כ-RISC, או Reduced Instruction Set Computing architecture, ואינו כולל הוראות לעבוד ישירות עם ה-I/O. תהליכי RISC פועלים רק באוגרים בעלי הוראות מעטות על ההעמסה ושמירה של נתונים אל ומהזיכרון.
הארכיטקטורה היותר פשוטה וטבעית בעלת 32 ביט מובילה לשטח קטן עבור סיליקון ותכונות חיסכון בהספק משמעותיות, מיועדות יותר עבור התקנים ידניים כגון טלפונים חכמים וטאבלטים. אם יישום דומה דורש מערך ממשקים של x86, המפתחים יגלו את ההתאמה האידיאלית במודול COM Express® Mini sized, המספק הספק נמוך וכל הממשקים הדרושים לרוב. כאשר דרושים ממשקי ARM – או אולי תערובת של שניהם, למשל בתמיכה ישירה במצלמה או I2S- אזי מודולי ®SMARC הופכים לבחירה ברורה. שני ה-®COM Express ו-®SMARC הם מיועדים עבור פתרונות ניידים בשל האופציה של שימוש בהזנה מסוללה.

תכנון לשם השפעה אסטרטגית
האם אתה מתכנן תמיכה DIY בתוכנה, או שמא אתה זקוק לעזרה ממערכת eco מבוססת?
תמיכה בתוכנה היא מרכיב אסטרטגי עבור תהליך התכנון. מערכות בכירות כוללות Windows או Linux – המעודדות מתכננים להעריך דרישות I/O, אילוצי מערכות eco והקלות הכוללת של הפיתוח. ככלל, Windows ,VxWorks ו-QNX מתאימות יותר לארכיטקטורות של x86, ו-Linux היא בחירה טובה יותר מאשר ARM.
Windows מציעה תמיכה בוגרת של ארכיטקטורת x86 עם תמיכה מקיפה עבור כל הכרטיסים; דבר זה מאפשר פיתוח יחסית נוח כאשר עובדים עם SBCs דוגמת ה-PC/104 ו-COMs בפלטפורמות של
®COM Express ו-® Qseven. המערכת האקולוגית היא נגישה ביותר, ואם תוכנות driver אינן נגישות, המפתחים יכולים להשתמש בקלות בתוכנות התקניות כאמצעי למימוש כרטיסים חדשים. סביבות x86 מוכרות נתמכות היטב על-ידי כלי פיתוח המסייעים לממש, לנפות ולכוון עדין את התוכנה.
באשר ל-drivers, Linux דומה מאוד ל-Windows, אם כי התמיכה ב-driver היא יותר מוגבלת ויכולה לגרום לאתגרי תכנון וזמני פיתוח מאורכים. כאשר drivers אינם זמינים, יותר מאתגר הוא לשפר גרסאות ישנות יותר כדי להתאים לכרטיסים חדשים. דבר זה הוא בחלקו בגלל אופי המקור הפתוח של Linux, עם drivers חדשים הדורשים בחינה של התאגיד ואישורו.
בניגוד לכך, Android משחקת תפקיד שונה והיא מתאימה במיוחד עבור התקנים יותר קטנים וחכמים כגון טלפונים חכמים וטאבלטים. Android, הכתובה במיוחד עבור ארכיטקטורות ARM ומבוססת על Linux, מציעה תמיכה מוגבלת של I/Os x86. סביבת ה-ARM היא יותר מורכבת ומופרדת, עם מוקד ייחודי על מוצרי SoC המיוטבים לעתים קרובות עבור יישום ספציפי. בניית הגדרות I/O תקניות לא הייתה מוקד ייחודי. כתוצאה, שוק ה-ARM כולל מספר גורמי צורה והגדרות של מחברים קנייניים; תכנונים יכולים להינעל על יצרן בודד שעשוי לא לתמוך ביותר מאשר דור סיליקון יחיד. אם כי התמיכה בx86- צפויה להתרחב בעתיד, כיום היא גורמת לעלויות פיתוח גבוהות יותר ומאמצי תכנון תוכנה מוגברים.
אולם, תקן ה-®SMARC מאפשר חיבור משופר כלשהו בין מעבדי ה-x86 ו-ARM. מתוכנן מקורית כדי לתכנן את השימוש במעבדי ARM®, SMARC תומכת עתה גם במעבדי x86 בעלי הספק נמוך. למתכננים יש עתה יותר מבחר וגישה למוצרים תואמים-לאחור, בעלי אנרגיה נמוכה, כמו גם ההיכרות של העבודה עם המערכת האקולוגית של x86.

אילו גורמים יוצרים את הבסיס עבור עלות המערכת?
הציפייה לעלות היא מפושטת-מידי לעתים קרובות, כאשר במציאות, העלויות הממשיות מבוססות על מגוון מורכב של גורמים. לדוגמה, התובנה הכללית יכולה להניח שעלויות תלויות פשוט בממדי המודול, כאשר מודול קטן יותר נמצא יותר במסגרת האפשרויות הכספיות מאשר מודול גדול יותר. בתרחיש של העולם האמיתי, אולם, מודול קצר עשוי להיות יותר יקר מאשר מודול בגודל-מלא. מפרטים טכניים, מעבד יחיד לעומת בעל ארבע-ליבות וממשקי I/O ממומשים הם חלק מהמרכיבים אשר יקבעו את העלות הכוללת של המודול עצמו.
מומחיות בתכנון ומשאבים מוסיפים לעלות גם כן. עיינו במודול ®SMARC המשתמש במעבדי x86 בעלי הספק נמוך בגרסאות הקצרות והגודל המלא; למודול הקצר יש בפירוש פחות מקום, אולם התכנון עשוי לדרוש את אותן התכונות הקיימות במודול בגודל מלא. ניתן להנדס את התכנון ביעילות, אך הוא ידרוש יותר שכבות מעגל מודפס כדי לממש את ה-I/O. זהו תהליך הנדסי יקר וכואב; זמן הפיתוח עולה בהתאם, ביחד עם עלות הייצור. כאשר מממשים מערכת דומה על פלטפורמות שונות של גורם צורה קטן, העלויות ההנדסיות הן לרוב הגבוהות ביותר עם PC/104, פחות עם ®COMExpress ועוד פחות עם ®SMARC או ®Qseven – כולם חלקים של ההערכה האסטרטגית המקדמת את בחירת הפלטפורמה שלך. עלויות הנדסיות ככלל מתנהלות בדרך זו בשל התכנון המלא, המוכן לפעולה, של ה-PC/104, בניגוד לאופציות התכנון בעלות ממדים משתנים הנמצאות עם ה-®COM Express. מאידך, ל-®SMARC ול-®Qseven יש פחות רכיבים והם אופיינית פחות פונקציונליים מאשר
®COM Express, עדיין תוך מילוי דרישות ההנדסה הכלליות.
ככלל, הלקוחות נוטים לחשוב שגורמי צורה קטנים יעלו פחות מאשר פלטפורמות מחשוב גדולות יותר. למעשה דבר זה נכון רק לגבי גורמי צורה קטנים בעלי ביצועים נמוכים יותר, כלומר אלה ללא I/Os בעלי ביצועים גבוהים. אולם, לעתים די קרובות, המערכות הקטנות של היום צריכות לכלול I/O מתוחכם ולספק את התכונות והביצועים של מערכת גדולה יותר בתוך מקום קטן יותר. התכנון הנובע הוא יותר מאתגר ולכן יותר יקר, ויוצר השפעה גדולה יותר על בחירת הפלטפורמה הכוללת.
מהו היישום החכם ביותר של משאבי זמן ותכנון?
זמן הפיתוח תלוי בגורמים רבים, כאשר כל פלטפורמה מביאה את האתגרים הייחודיים והיתרונות שלה. יש להתאים את התוכנה עבור כל פלטפורמה והיא תנקוט נתיב שונה בתלות האם דרוש או לא השימוש בכרטיס בסיס.
SBCs מציעים חומרה מוכנה – לדוגמה ניתן להשלים מערכות PC/104 בעזרת התוספת הפשוטה יחסית של הספק ומערך כבלים, ביחד עם ה-I/Os שנבחרו על-ידי המתכנן.
לאחר התאמת התוכנה, מערכות כאלה הם לרוב פועלות ומתפקדות במהירות. COMs משלבת מודול תקני מהמדף, אך דורשת זמן ומומחיות לשם פיתוח של כרטיס הבסיס המלווה. בתלות בסידור הפינים (לדוגמה סוג 2, סוג 6 או סוג 10), מודולים בתקן ®COM Express יכולים להסתמך על מחבר מרובה-פינים כדי להתחבר לכרטיס הבסיס, תקני ®SMARC ו-®Qseven יכולים להסתמך על מחבר קצה שיחבר אל כרטיס הבסיס, אך דבר זה מספק את היכולת להתאים אותו לצרכים לטווח ארוך של היישום.
ארכיטקטורה, תסדיר, כושר שדרוג – איזה גורם-מפתח מגדיר את הסיכון הגדול ביותר שלך?
הסיכון למתן איננו בהכרח סוגיה חופשית, וסביר כי יש לו השפעה על כל בחירה הנעשית בתהליך התכנון. לדוגמה, מבחינת המתכנן, אין הבדלים בין ארכיטקטורות ה-x86 וה-ARM ברמת מערך הכרטיס. שניהם כוללים I/Os תקניים, נתיבים מהירים, ממשקי זיכרון וכו’. בכל זאת, בשלב התכנון הראשוני, כמו גם בניפוי הבא אחריו, התהליך קל יותר כאשר עובדים עם ארכיטקטורת x86. פלטפורמת ה-ARM היא יותר מורכבת לניתוח ולאיתור תקלות, סוגיה שעשויה לכוון את המפתח לקראת ארכיטקטורה חלופית. לדוגמה, COMs נשאר בעל שדרוג בעזרת מתג במודול; PC/104 דורשת כרטיס חדש ועשויה גם לכלול מחברי I/O שונים הממוקמים באתרים שונים על הכרטיס.

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