איך מתאימים בחירת RTOS לדרישות רגולציה: ISO 26262 ו-IEC 62304

בעולם פיתוח המוצרים הבטיחותיים-קריטיים של היום, בחירת מערכת ההפעלה בזמן אמת (RTOS) אינה רק החלטה טכנית – היא החלטה רגולטורית עם השלכות מרחיקות לכת. בענפי הרכב והרפואה, שבהם פועלות שתי הרגולציות הדומיננטיות – ISO 26262 ו-IEC 62304 – בחירה שגויה בשלב הראשוני יכולה לעלות מיליוני דולרים בעבודה רגולטורית מיותרת, לעכב את שחרור המוצר בשנים, ובמקרים קיצוניים – לחסום אישור רגולטורי לחלוטין. בחברת TandemG אנו מלווים חברות גלובליות בפיתוח מוצרים תחת תקני בטיחות פונקציונלית – בעיקר ISO 26262 בתחום הרכב ו-IEC 62304 במכשור הרפואי.

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

הערה חשובה: המאמר מציג מסגרת הנדסית כללית. כל פרויקט תחת תקן בטיחות חייב להתבצע בליווי יועצי תאימות מוסמכים, ובהתאם לדרישות הרגולטור הספציפי. החלטות סופיות חייבות להיבדק עם מהנדסי בטיחות פונקציונלית מוסמכים (TÜV, exida, BSI, או ארגונים מקבילים).

למה בחירת RTOS היא החלטה רגולטורית, לא רק טכנית

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

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

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

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

ISO 26262: סטנדרט הבטיחות הפונקציונלית לרכב

ISO 26262 (Road vehicles – Functional Safety) הוא הסטנדרט הבינלאומי לבטיחות פונקציונלית של מערכות חשמליות ואלקטרוניות ברכב. הוא פורסם לראשונה ב-2011 על ידי ISO, נגזר מ-IEC 61508 (סטנדרט הבטיחות הגנרי), ועבר עדכון משמעותי ב-2018 שהרחיב את הכיסוי לרכבים מעל 3.5 טון, אופנועים, ומשאיות. בענף הרכב הגלובלי, עמידה ב-ISO 26262 היא דרישת חובה דה-פקטו עבור OEMs ו-Tier 1 Suppliers.

ארבע רמות ה-ASIL

ISO 26262 מגדיר 4 רמות של Automotive Safety Integrity Level (ASIL) – לפי השילוב של חומרת הפגיעה (Severity), חשיפת הנהג (Exposure), ויכולת השליטה במצב (Controllability):

ASIL Decomposition: גמישות ייחודית של ISO 26262

יכולת ייחודית של ISO 26262: ASIL Decomposition מאפשרת לפצל פונקציה ב-ASIL D לשני רכיבים בלתי תלויים שכל אחד ב-ASIL B(D) – או לאחד ב-ASIL C(D) ולשני ב-ASIL A(D). הדבר מאפשר ארכיטקטורות בטוחות בעלות נמוכה יותר. דורש הוכחה קפדנית של אי-תלות (Freedom From Interference) בין הרכיבים – לא טריוויאלית.

AUTOSAR והקשר ל-ISO 26262

ענף הרכב פיתח סטנדרט תוכנה משלים – AUTOSAR (AUTomotive Open System ARchitecture). שתי גרסאות נפוצות:

• AUTOSAR Classic Platform – לבקרים מסורתיים (ECUs) מבוססי MCU, פועל בצמוד ל-RTOS תואם
• AUTOSAR Adaptive Platform – לבקרים בעלי ביצועים גבוהים (כמו ל-ADAS), פועל על POSIX-compliant OS

ספקי AUTOSAR Stack מובילים: Vector Microsar, ETAS RTA-CAR, Elektrobit (EB) tresos, Mentor (Siemens) Volcano. רובם מסופקים עם תיעוד הסמכה ל-ASIL D.

עבור Real-Time Embedded ברכב ב-ASIL D, הבחירה כמעט תמיד נופלת על RTOS מוסמך מראש שמשולב עם AUTOSAR Stack – כי הסמכה עצמית של RTOS חדש מאפס דורשת השקעה של מיליונים ושנים.

IEC 62304: סטנדרט התוכנה למוצרים רפואיים

IEC 62304 (Medical device software – Software life cycle processes) הוא הסטנדרט הבינלאומי לפיתוח תוכנה במכשור רפואי. הוא פורסם ב-2006, עודכן ב-2015, וההתחייבות לו היא חובה ברגולציות מרכזיות: FDA (510(k), De Novo, PMA) בארה"ב, EU MDR (Medical Device Regulation 2017/745) באירופה, ו-PMDA ביפן.

שלוש רמות ה-Software Safety Class

בניגוד ל-ASIL שמבוסס על חומרה + חשיפה + שליטה, IEC 62304 מסווג לפי תוצאת כשל אפשרית בלבד:

מושג ה-SOUP – חשוב במיוחד לבחירת RTOS

קונספט מרכזי וייחודי ב-IEC 62304: SOUP (Software Of Unknown Provenance) מתאר תוכנה שלא פותחה תחת ה-Lifecycle של IEC 62304 – כמו ספריות צד שלישי, RTOS, או Kernel Linux. השימוש ב-SOUP מותר – אבל דורש:

• זיהוי וניהול רשמי של כל רכיב SOUP במוצר
• ניתוח סיכון של כל רכיב SOUP (Risk Analysis)
• תיעוד של דרישות תפקודיות צפויות מכל SOUP
• ניטור באגים ופגיעויות לאורך כל מחזור החיים של המוצר
• תיק בדיקות (Verification) שמוכיח התנהגות תקינה

זוהי הסיבה המהותית שבגללה FreeRTOS, Linux Kernel, ו-RTOS אחרים יכולים להיות חלק ממוצר IEC 62304 – בתנאי שהם מנוהלים כ-SOUP בצורה נכונה. ה-FDA אינו מסמיך RTOS – הוא מסמיך מוצרים, ומעוניין בתהליך ה-SOUP Management.

תקנים נלווים שכל פרויקט רפואי מתמודד איתם

IEC 62304 אינו עומד לבדו. מוצר רפואי טיפוסי מתמודד עם:

המיפוי בין ASIL ל-Software Safety Class

לעיתים קרובות שואלים: ASIL ו-Class הם אותו דבר? התשובה: לא, אבל יש מקבלות מקובלות:

ההבדל המהותי: ASIL מבוסס על שילוב של 3 פרמטרים (Severity, Exposure, Controllability), בעוד Class מבוסס רק על תוצאת כשל. זה אומר שפונקציה ASIL B עשויה להיות חמורה יותר מ-Class B כי המנגנון שונה.

ארבע משפחות ה-RTOS לפרויקטים רגולטוריים

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

משפחה 1: Bare Metal – כשפשטות מנצחת

מתי מתאים: מערכות עם פונקציונליות מוגבלת מאוד, שיכולות להתבצע ללא Multi-tasking. מתאים במיוחד למוצרים רפואיים פשוטים ב-IEC 62304 Class B-C (חיישנים בודדים, מכשור ניטור פשוט) – שבהם פשטות הקוד היא יתרון מובהק לבדיקות ולתיעוד.

יתרונות רגולטוריים: אין שכבת SOUP להוכיח. כל הקוד הוא של הפרויקט, וכל שורה מבוקרת ומתועדת לפי דרישות הסטנדרט. מסלול ההסמכה פשוט יותר. ב-IEC 62304 – לא נדרש ניהול SOUP. ב-ISO 26262 – קוד יחיד וברור, ניתוח Coverage מלא.

חסרונות: מערכות מורכבות נעשות בלתי ניתנות לתחזוקה. אין Multi-threading, אין ניהול זיכרון, אין שירותי OS.

משפחה 2: FreeRTOS – לעיתים קרובות יותר ממה שחושבים

זוהי הנקודה הקריטית שמרבית המאמרים בנושא מפספסים: FreeRTOS לעיתים קרובות מקובל בפרויקטים תחת רגולציה – בתנאי שיש תיעוד מתאים של תהליך הפיתוח, בדיקות, ו-Software Bill of Materials.

במיוחד ב-IEC 62304 (רפואה): פרויקטים רבים תחת FDA Class II ואף Class III משלבים FreeRTOS בהצלחה, מנוהל כ-SOUP. ה-FDA מעוניין בתהליך הפיתוח ובאיכות התיעוד, לא בשם ה-RTOS. רישוי MIT של FreeRTOS אינו מהווה מכשול – הוא דווקא מקל על תהליך הביקורת.

ב-ISO 26262 ASIL A-B: FreeRTOS עם תיעוד יסודי, ניתוח סיכון, ו-Verification מקיף הוא אופציה אפשרית. דורש Customization מסוים – לרוב הסרת חלקי API שלא ניתן לאמת במלואם.

מתי FreeRTOS אינו מספיק: ASIL D ברכב, IEC 62304 Class C במוצרים מורכבים, ASIL C במערכות עם דרישות בטיחות גבוהות במיוחד. במקרים אלו, יש צורך באלטרנטיבה.

משפחה 3: SafeRTOS – הצעד הטבעי מעל FreeRTOS

כש-FreeRTOS אינו מספיק רגולטורית, האלטרנטיבה הראשונה לבחינה היא לא RTOS מסחרי – אלא SafeRTOS, פיתוח של HighIntegritySystems (לשעבר WITTENSTEIN).

SafeRTOS הוא בעצם FreeRTOS שעבר תהליך הסמכה רגולטורי, עם תיעוד מלא ומסלול הסמכה מוכח. הוא מסופק עם Pre-Certified Artifacts לתקנים הרלוונטיים לרכב ולרפואה: ISO 26262 ASIL D, IEC 62304 Class C, ו-IEC 61508 SIL 3 (לפי גרסה ותצורה).

יתרונות מעשיים:

• API דומה ל-FreeRTOS – מעבר פשוט יחסית
• עלות מסחרית נמוכה משמעותית מ-VxWorks Cert / INTEGRITY
• תיעוד שמקצר משמעותית את משך ההסמכה
• מתאים לרוב הפרויקטים הרפואיים והאוטומוטיביים שלא דורשים אינטגרציה עמוקה עם AUTOSAR

משפחה 4: RTOS מסחריים מוסמכים מראש

עבור הרמות הגבוהות ביותר – ASIL D ברכב באפליקציות הקריטיות ביותר, IEC 62304 Class C במוצרים מורכבים – נדרש RTOS מסחרי שהוסמך מראש לדרישות הספציפיות. השחקנים המרכזיים:

עלויות: רישוי שנע בין $50K ל-$500K+ לפרויקט, בנוסף ל-Royalties לכל יחידה. עבור פרויקטים בהיקף גדול, מדובר בהוצאה של מיליונים – אבל זול בהשוואה להסמכה עצמית של RTOS מאפס.

טבלת השוואה מסכמת

מסגרת ההחלטה: בחירת RTOS לפי תקן ורמה

הטבלה הבאה מציעה גישה ראשונית לבחירה – הסופי תמיד דורש בחינה ספציפית של דרישות הפרויקט:

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

עלות ההסמכה: מה באמת עולה

הבנת עלות ההסמכה היא קריטית לקבלת החלטות נכונות. הטבלה הבאה מציגה הערכות עלות אופייניות לפרויקט תוכנה בטיחותית:

מסקנה: עבור פרויקט ASIL D טיפוסי, עלות ההסמכה הכוללת יכולה להגיע ל-25%-40% מעלות הפיתוח הכוללת. לכן, בחירת ארכיטקטורה שמפשטת את ההסמכה היא חיסכון אסטרטגי משמעותי.

Tool Qualification: הדרישה הסמויה

נושא שלעיתים קרובות מפספסים בשלבים מוקדמים של פרויקט: Tool Qualification. כל כלי שמשתתף בייצור או באימות הקוד – קומפיילר, Linker, Static Analyzer, Test Framework, IDE – חייב להיות "מוסמך" לרמת הביטחון של הפרויקט.

גישות ל-Tool Qualification ב-ISO 26262 וב-IEC 62304

ב-ISO 26262: כלים מסווגים ל-Tool Confidence Level (TCL 1-3). TCL 3 הוא הכבד ביותר – נדרש לכלים שיכולים להכניס שגיאות בלתי-נראות (כמו קומפיילרים).

ב-IEC 62304: הסטנדרט פחות מפורט בנושא Tool Qualification, אבל ה-FDA דורש Validation של Software Tools בתהליכי GMP. בפועל – דרישות דומות.

עלות מעשית

קומפיילר מסחרי מוסמך כמו GreenHills MULTI או IAR EWARM מוסמך עולה $20K–$80K לרישיון, אבל הוא חוסך עבודה של חודשים על Tool Qualification עצמית. שימוש ב-GCC לא מוסמך – אפשרי, אבל דורש הוכחה עצמית של תקינות הקומפילר לפרויקט הספציפי.

תרחישי יישום מהשטח

תרחיש 1: יצרנית מכשור רפואי – מד אינסולין מתמשך (CGM)

מצב: חברת רפואה גלובלית מפתחת CGM שדורש אישור FDA Class III וסיווג IEC 62304 Class C.

ההחלטה הראשונית של הצוות: לרכוש QNX OS for Safety בעלות של $300K לפרויקט.

הניתוח האמיתי: האפליקציה אינה מורכבת – מספר משימות בסיסיות. תהליך הסמכה של FreeRTOS עם תיעוד SOUP מקיף + Static Analysis + Code Coverage = פתרון מקובל ל-FDA, בעלות נמוכה משמעותית.

הבחירה הסופית: FreeRTOS עם תהליך תיעוד מובנה לפי IEC 62304 Class C ו-SOUP Management מלא.

התוצאה: חיסכון של $250K, מעבר ביקורת FDA, אישור 510(k) קיבל בלוח הזמנים המתוכנן.

תרחיש 2: יצרנית רכב – מערכת ניהול סוללה לרכב חשמלי (BMS)

מצב: Battery Management System שדורש ISO 26262 ASIL C. הצוות הוא מהנדסי Real-Time Embedded מנוסים, אבל ללא ניסיון בהסמכת ASIL.

הבחירה: SafeRTOS – שילוב של API מוכר (כמו FreeRTOS) עם Pre-Certification Artifacts ל-ASIL D.

התוצאה: העברת תיעוד הסמכה תוך 8 חודשים, מעבר Audit של TÜV, BMS מאושר ASIL C, פריסה בייצור המוני.

תרחיש 3: יצרנית רכב – בקר ADAS לרכב מסחרי

מצב: מערכת Lane Keeping Assist (LKA) ברכב מסחרי, סיווג ASIL D תחת ISO 26262. דרישת אינטגרציה עם AUTOSAR Classic.

הבחירה: Vector Microsar (AUTOSAR Stack מוסמך ASIL D), שילוב עם QNX OS for Safety לחלק עיבוד התמונה. ASIL Decomposition: עיבוד התמונה ב-ASIL B(D), בקרת ההיגוי ב-ASIL B(D).

התוצאה: הסמכה מוצלחת תוך 22 חודשים, עלות הסמכה כוללת של $1.4M (כולל RTOS, AUTOSAR Stack, כלים, ובדיקות), אישור OEM גלובלי.

תרחיש 4: יצרנית מכשור רפואי – משאבת תרופות תוך-ורידית

מצב: משאבת תרופות תוך-ורידית (Infusion Pump) – מוצר IEC 62304 Class C ברמת הסיכון הגבוהה ביותר. דרישת אישור FDA, EU MDR, ו-Health Canada.

הבחירה הראשונית של הצוות: RTOS מסחרי יקר.

ניתוח חוזר: האפליקציה מורכבת אבל מובנית. ארכיטקטורת Dual-Channel עם Bare Metal בערוץ הראשי + FreeRTOS עם SOUP Management מקיף בערוץ המבקר = פתרון מקובל לאחר ניתוח Risk מלא.

הבחירה הסופית: ארכיטקטורה Dual-Channel עם 2 MCUs נפרדים – Bare Metal + FreeRTOS.

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

טעויות נפוצות בבחירת RTOS לפרויקטים רגולטוריים

טעות 1: ההנחה ש"רגולציה = RTOS מסחרי יקר"

הטעות הנפוצה ביותר. רבים מניחים שרק RTOS מסחרי כמו QNX או VxWorks מתאים לפרויקט רגולטורי. במציאות, FreeRTOS עם תיעוד מתאים מקובל ברוב פרויקטי IEC 62304, וב-ISO 26262 ASIL A-B. כש-FreeRTOS אינו מספיק, האלטרנטיבה הראשונה לבחינה היא Bare Metal או SafeRTOS – לא בהכרח RTOS מסחרי.

טעות 2: שכחה של Tool Qualification בתקציב

עלות הסמכת RTOS לעיתים קרובות נמוכה מעלות Tool Qualification של הקומפיילר וה-Static Analyzer. בפרויקט ASIL D טיפוסי, Tool Qualification יכול להגיע ל-30% מעלות ההסמכה הכוללת. תכנון תקציב Tool Qualification בשלב התכנון הראשוני חיוני.

טעות 3: בחירת RTOS ללא בדיקת תאימות למעבד

אפילו במקרה שיודעים שצריך RTOS מסוים, חשוב לוודא שהוא נתמך רשמית על ידי יצרן המעבד. RTOS מסחרי שמסופק עם תמיכה רשמית ל-NXP S32K3 (לרכב) הוא בחירה אחרת מ-RTOS שדורש Porting עצמי. Porting עצמי של RTOS למעבד שלא נתמך = ביטול חלקי של היתרון של ה-Pre-Certification.

טעות 4: התעלמות מקיום פתרונות "Pre-Certified" משולבים

חברות מסוימות מציעות חבילות שלמות (RTOS + AUTOSAR Stack + Toolchain + Middleware) שכולן מוסמכות יחד. רכישת חבילה משולבת זולה משמעותית מאיסוף רכיבים נפרדים. בדיקת חבילות Pre-Certified של Vector, ETAS, או GreenHills לפני בחירת RTOS לבד.

טעות 5: שינוי RTOS באמצע פרויקט

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

טעות 6: הנחה שהסמכה של RTOS = הסמכה של המוצר

RTOS מוסמך מספק Pre-Certification Artifacts – אבל ה-RTOS אינו מוסמך לבדו. הוא מוסמך בהקשר של פרויקט מסוים, על מעבד מסוים, עם הגדרות מסוימות. שינוי בהגדרות RTOS עלול להפר את ההסמכה. קריאת מסמכי ה-Safety Manual של RTOS וההגבלות המופיעות שם – חיונית.

טעות 7: ניהול SOUP חסר ב-IEC 62304

ב-IEC 62304, RTOS וספריות צד שלישי הן SOUP – ודרושות תהליכי ניהול ספציפיים. צוותים רבים מתעלמים מהדרישה ומוצאים את עצמם תקועים בביקורת ה-FDA. תיעוד SOUP מקיף הוא חלק מהפרויקט מהיום הראשון.

טעות 8: ביצוע פרויקט רגולטורי ראשון ללא ייעוץ רגולטורי

פרויקט ISO 26262 או IEC 62304 ראשון של חברה הוא לא המקום ללמוד תוך כדי תנועה. ייעוץ עם יועצי רגולציה (TÜV, exida, BSI, או דומים) בשלבים הראשונים של הפרויקט חוסך זמן וכסף משמעותיים. ההשקעה של $30K–$80K בייעוץ ראשוני יכולה לחסוך מיליונים.

שאלות נפוצות

האם FreeRTOS באמת מקובל ב-FDA?

כן, ברוב המקרים. FDA אינו מסמיך RTOS – הוא מסמיך מוצרים. מה שחשוב הוא תהליך הפיתוח של המוצר, לא שם ה-RTOS. עשרות מוצרים רפואיים שאושרו על ידי FDA Class II ו-Class III משתמשים ב-FreeRTOS עם תיעוד מתאים לפי IEC 62304, מנוהל כ-SOUP. מומלץ לעבוד עם יועץ רגולטורי שמנוסה ב-IEC 62304 כדי לוודא תהליך נכון.

האם FreeRTOS מתאים ל-ISO 26262?

תלוי ברמת ה-ASIL. ל-ASIL A – בהחלט, עם תיעוד יסודי. ל-ASIL B – אפשרי במקרים רבים, אבל דורש Customization נרחב והוכחת התאמה. ל-ASIL C ו-D – לא מקובל בפועל; נדרש SafeRTOS לפחות. ב-ASIL D נדרש לרוב RTOS מסחרי או AUTOSAR Stack מוסמך.

מה ההבדל בין SafeRTOS ל-FreeRTOS מבחינה טכנית?

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

האם אפשר להשתמש ב-Embedded Linux בפרויקטים רפואיים?

מורכב יותר. Linux Kernel הוא ענק ומתפתח במהירות – קשה מאוד לנהל אותו כ-SOUP בצורה מלאה. עבור פרויקטי IEC 62304 Class A-B, Linux אפשרי עם תיעוד מתאים. עבור Class C, גישות נפוצות הן: ארכיטקטורות Mixed Criticality (Linux לפונקציות לא בטיחותיות + RTOS לחלקים הקריטיים), שילוב Cortex-A (Embedded Linux) + Cortex-M (RTOS מוסמך) על אותו SoC, או שימוש ב-Linux בוגר כמו Red Hat Device Edge עם תהליכי SOUP מובנים.

האם ASIL D ב-ISO 26262 דורש RTOS שונה מ-ASIL C?

לא בהכרח. אותו RTOS (כמו SafeRTOS או QNX OS for Safety) יכול לתמוך בשתי הרמות. ההבדל הוא בקפדנות הבדיקות, בתיעוד, ובארכיטקטורת המערכת (Redundancy, Diversity, Fault Tolerance, ASIL Decomposition). RTOS שמוסמך ל-ASIL D יכול לשמש גם ל-ASIL C, אבל הפרויקט כולו צריך לעמוד בדרישות הרמה הספציפית.

מה לגבי פיתוח חומרה – האם הוא משפיע על בחירת RTOS?

באופן מהותי. בחירת המעבד משפיעה ישירות על אילו RTOS-ים זמינים – ועל אילו הסמכות זמינות עליהם. מעבדים מסוימים תוכננו במיוחד לאפליקציות בטיחותיות ומגיעים עם תמיכה ב-RTOS מוסמכים: NXP S32K3 ו-S32G (לרכב – ASIL D), Infineon AURIX TC3xx/TC4xx (לרכב – ASIL D), TI Hercules (לבקרי בטיחות – SIL 3, ASIL D), STM32H7-Safety MCU (לרפואה – Class C). מעבדים גנריים יותר עשויים לדרוש Porting עצמי של RTOS – מה שמבטל את היתרון של Pre-Certification.

האם Zephyr מתאים לרגולציה רפואית או אוטומוטיבית?

נכון ל-2026, Zephyr הוא RTOS פתוח חזק עם תמיכה גוברת בתחומי בטיחות, אבל עדיין אין לו Pre-Certification מקובל ל-ASIL D או ל-IEC 62304 Class C ברמת ההסמכה הסופית. הקהילה עובדת על מסלולי Pre-Certification – אך זה צפוי להיות זמין בצורה רחבה רק ב-2027-2028. עבור פרויקטים פחות קפדניים (ASIL A-B, Class A-B) – אפשר לשקול Zephyr עם תהליך תיעוד מתאים.

האם AUTOSAR חובה לפרויקט ASIL D ברכב?

לא חובה, אבל סטנדרט דה-פקטו. רוב OEM-ים גלובליים דורשים AUTOSAR – בעיקר AUTOSAR Classic ל-ECU-ים מסורתיים ו-AUTOSAR Adaptive ל-Domain Controllers ולמערכות ADAS. פרויקטים שיוצאים מההסכמה הזו (למשל יצרני סטארטאפ של רכב חשמלי) לפעמים בוחרים פתרונות חלופיים – אבל זה מקשה על שילוב עם ספקי Tier 1.

כמה זמן לוקח להסמיך מוצר תחת ASIL D?

תלוי במורכבות. מוצר טיפוסי בהיקף של 50,000 שורות קוד ASIL D: 18–30 חודשים מתחילת הפיתוח עד אישור. זה כולל פיתוח, תיעוד, בדיקות, Tool Qualification, ו-Audit. פרויקטים גדולים יותר (ADAS, EV Platform) יכולים להגיע ל-3–5 שנים.

היתרון של TandemG: מומחיות רגולטורית כחלק מפיתוח מקצה לקצה

פיתוח מוצר תחת רגולציה הוא הרבה יותר מבחירת RTOS – הוא תהליך מערכתי שדורש תיאום בין כל שכבות המוצר. בחברת TandemG, צוותי ה-Real-Time Embedded שלנו עובדים בצמוד למחלקות פיתוח החומרה והענן, עם ניסיון מצטבר בעשרות פרויקטים תחת תקני הבטיחות הרלוונטיים – IEC 62304 ברפואה ו-ISO 26262 ברכב.

ניסיון זה מאפשר לנו ללוות לקוחות בכל שלבי הסמכת המוצר: מבחירת ה-RTOS המתאימה (כולל ניתוח Cost-Benefit מעמיק שלעיתים מסיק ש-RTOS מסחרי אינו נדרש), דרך אינטגרציה עם פיתוח חומרה על מעבדים בטיחותיים (NXP S32, Infineon AURIX, STM32H7-Safety), ועד הכנת תיק התיעוד הרגולטורי המלא. אנו עובדים בשיתוף פעולה הדוק עם יועצי רגולציה (TÜV, exida, BSI) כדי להבטיח שהפרויקט מתקדם במסלול הנכון מהיום הראשון. עבור פרויקטי IoT מקצה לקצה שכוללים רכיבים בטיחותיים – כמו ציוד רפואי מחובר או רכיבי רכב מחוברים – אנחנו מספקים את הראייה המערכתית הכוללת.

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

הפרויקט הבא שלכם מתחיל בשיחה

מחפשים שותף מנוסה שילווה אתכם בפיתוח מוצר תחת רגולציה – ISO 26262 ברכב או IEC 62304 ברפואה? הצוות של TandemG ישמח לשוחח.

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