Compare OSEK/VDX and AUTOSAR CP
| 分類 | OSEK/VDX | AUTOSAR CP | character |
|---|---|---|---|
| OS | priority ceiling protocol, without OS ISR and With OS ISR, release resource before Extended Task go to Waiting | add task table, memory protection, timing protection, multi core, RTE | extend |
| COM | RPC concept | add PDUR, ComM and RPC with RTE | detailing |
| NM | Linphome | simplification | |
| methodology | |||
| tool | open osek.toppers osek | artop, davinci, tresos,toppers atk2... |
CHat GPT
Please compare osek/vdx and autosar classic Platform in terms of OS, COM , NM , methodology and tool.
19s
Nice request — here’s a focused, side-by-side comparison of OSEK/VDX vs AUTOSAR Classic Platform across the five areas you requested: OS, COM, NM, methodology, and tools. I’ll keep it practical and cite the core specs/tools where helpful.
Quick summary (one-line)
OSEK/VDX: light, static, ECU-centric RTOS + simple COM/NM stack with OIL/ORTI for offline config and debugger visibility — designed for small, static ECUs.
osek-vdx.org+1
AUTOSAR Classic: a superset and industrialization of OSEK ideas — layered architecture (SW-Components / RTE / BSW), richer standard services, standardized XML (ARXML) toolchain, and ecosystem tooling for large multi-ECU projects.
autosar.org+1
Detailed comparison
- OS (real-time kernel)
OSEK/VDX
Static, minimal real-time kernel defined by the OSEK OS specification (task types: basic vs extended, well-defined priority model, deterministic scheduling options including non-preemptive and mixed). Designed for MCU without MMU; configuration happens at build time.
osek-vdx.org
AUTOSAR Classic
The AUTOSAR OS is a backwards-compatible superset of OSEK OS — it reuses and extends OSEK concepts but integrates with the Classic layered architecture (RTE, BSW). Supports richer features required by modern ECUs (extended scheduling, multicore support in recent releases, timing protection, timing extensions) and must satisfy AUTOSAR top-level requirements.
autosar.org+1
Net/implication
OSEK is simpler and lighter — excellent for small ECUs. AUTOSAR OS adds overhead but provides standardized interfaces and features needed in Tier-1 / OEM workflows and multi-ECU systems.- COM (communication stack / in-ECU communication)
OSEK/VDX
OSEK COM spec defines message/event communication services and abstracted send/receive semantics; simpler, oriented to CAN/LIN era with static configuration via OIL/related files. Good for predictable, offline-configured message flows.
osek-vdx.org
AUTOSAR Classic
COM is part of Basic Software (BSW). AUTOSAR provides standardized PDU/Signal semantics, I-PDU gateway concepts, and richer mapping to transceivers and network layers. Communication is modeled in ARXML and integrated into RTE generation so SW-components communicate via ports and RTE, decoupling apps from transport. Supports CAN, LIN, FlexRay, MOST, Ethernet (as features evolved).
autosar.org
Net/implication
AUTOSAR COM is more feature-rich and tool-driven (model → generated RTE glue). OSEK COM is simpler, easier to implement on tiny ECUs.- NM (Network Management)
OSEK/VDX
NM defined as a separate OSEK part: basic NM services for bus idle/wakeup, node states, and coordination across ECUs. Static, simple state machine and intended for CAN/LIN era; configuration via OIL/related descriptors.
osek-vdx.org
AUTOSAR Classic
AUTOSAR NM is integrated into the BSW services with more modularization and richer configuration options, and supports more sophisticated strategies (e.g., ECU state management, partial network wakeup, gateway behavior) adapted to multi-ECU and multiple bus types. AUTOSAR provides standardized interfaces so NM interacts cleanly with Diagnostics, ComM, etc.
autosar.org
Net/implication
AUTOSAR NM is essentially an industrialized, extensible evolution of OSEK NM to support complex vehicle networks and OEM policies.- Methodology (architecture, development approach)
OSEK/VDX
ECU-centric, static configuration model. You describe the system offline (OIL) and generate a small kernel + glue code. Emphasis on lean, deterministic runtime. Less emphasis on component reuse across ECUs.
osek-vdx.org+1
AUTOSAR Classic
Model-driven, component-based methodology: Application SW is written as AUTOSAR Software Components (SW-C) with ports and interfaces; the RTE provides virtualization so components can be mapped to ECUs later (Virtual Functional Bus concept). System description and module configuration are expressed in ARXML and are processed by toolchains to generate RTE and BSW configuration. This enables reuse, supplier/OEM interface standardization, and large-scale integration.
autosar.org
Net/implication
OSEK fits small, single-supplier ECU development. AUTOSAR enforces a more rigorous model-based, multi-supplier, multi-ECU integration methodology — more setup cost but scales to modern vehicle architectures.- Tools (config, codegen, debug)
OSEK/VDX
Configuration: OIL (OSEK Implementation Language) files describe tasks, ISRs, resources, alarms, communication.
Debug/trace: ORTI (OSEK Run Time Interface) exposes kernel objects for tools (debuggers like Lauterbach support ORTI), enabling kernel-aware debugging and trace.
osek-vdx.org+1
Example tool ecosystem historically included smaller vendors / vendor-specific generators (RT-OS vendors, NXP examples, open RTOS like Erika). Simpler toolchains vs AUTOSAR.
AUTOSAR Classic
Configuration & generation: ARXML model files processed by AUTOSAR authoring/configuration tools (e.g., Vector DaVinci/DaVinci Configurator, EB tresos Studio, ETAS ISOLAR/INTECRIO, etc.). Tools validate, generate BSW/MCAL/RTE and provide project/workflow support. EB tresos is a typical example of a Classic AUTOSAR tool suite.
Elektrobit+1
Debug/validation: toolchains integrate with CANoe/CANalyzer for network simulation and vector tools for config checks. There’s a large, mature ecosystem for testing, simulation, static checks, and autosar compliance.
community.nxp.com
Net/implication
OSEK: light, file-based (OIL) config and ORTI for debugger support — fast to get running but limited automation.
AUTOSAR: heavy, model-based toolchain with validation, importers (DBC/FIBEX/LDF), code generators, and richer vendor support — essential for OEM/Tier-1 processes.
Practical advice / migration notes
If you’re building a small, single-function ECU with tight footprint and simple timing — OSEK (or an OSEK-derived kernel) remains attractive for simplicity and determinism.
osek-vdx.org
If you’re integrating across many ECUs or want supplier/OEM reuse, diagnostic and versioning workflows, or evolving bus types (Ethernet etc.), AUTOSAR Classic is the practical choice because of RTE/BSW, ARXML, and ecosystem tooling.
autosar.org+1
Many vendors provide hybrid paths: AUTOSAR Classic is backwards compatible with OSEK semantics in the OS layer, and some AUTOSAR toolchains can import/assist migration from OIL/OSEK projects.
autosar.org+1
Sources (key specs / tool pages)
OSEK/VDX Operating System specification.
osek-vdx.org https://www.osek-vdx.org/mirror/os221.pdf?utm_source=chatgpt.com
OSEK/VDX Communication specification.
osek-vdx.org https://www.osek-vdx.org/mirror/com2-2-2.pdf?utm_source=chatgpt.com
AUTOSAR Classic Platform — official overview.
autosar.org https://www.autosar.org/standards/classic-platform?utm_source=chatgpt.com
AUTOSAR SWS — Operating System specification (Classic).
autosar.org https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_SWS_OS.pdf?utm_source=chatgpt.com
EB tresos Studio (example Classic AUTOSAR tool suite).
Elektrobit https://www.elektrobit.com/products/ecu/eb-tresos/studio/?utm_source=chatgpt.com
If you want, I can:
produce a one-page comparison table (CSV/Markdown) you can paste into documentation, or
map specific features you care about (timing protection, multicore, diagnostics integration, memory protection, code size targets) and recommend concrete toolchains and BSW stacks for a given MCU.
Which of those would you like next?
map specific features you care about (timing protection, multicore, diagnostics integration, memory protection, code size targets) with source code and recommend concrete toolchains and BSW stacks for a given MCU.
31s
Great — I mapped each requested feature (timing protection, multicore, diagnostics integration, memory protection, code-size targets) to (1) how it’s normally realised in AUTOSAR Classic / OSEK-derived projects, (2) short concrete source-code or config examples you can copy/adapt, and (3) concrete toolchain + BSW stack recommendations for three representative MCUs (NXP S32K — Cortex-M, Infineon AURIX — TriCore multicore, Renesas RH850). I also list open / lightweight alternatives (OSEK style) for small ECUs. Each load-bearing statement has an authoritative source cited.
Short TL;DR recommendations
Small single-ECU, tight flash/RAM → use OSEK/ERIKA (OpenERIKA) or a minimal AUTOSAR OsekCore (EB tresos OsekCore), keep simple static config.
Erika3+1
Production multi-ECU or OEM/Tier-1 integration → AUTOSAR Classic with RTE + BSW (Vector MICROSAR or EB tresos AutoCore are industry choices). Use vendor MCAL (NXP/Infineon/Renesas) for close-to-silicon support.
vector.com+1
Feature mapping (what to do & why) — table summary
(Condensed; details + code follow.)
Feature How AUTOSAR / OSEK handle it Practical config/code Tool / BSW recommendations
Timing protection AUTOSAR-OS supports timing protection (configured in OS and validated by toolchain). Prevents tasks/ISRs from overrunning. Configure timing-protection in OS config (ARXML) / validate with timing analysis; add watchdog/ShutdownOS path on violation. Example task skeleton below. Vector MICROSAR, EB tresos AutoCore (support OS timing protection). AUTOSAR SWS OS spec.
autosar.org+1
Multicore AUTOSAR Classic supports multicore OS and RTE partitioning. Use core-local RTE + inter-core communication via port mapping / COM / BSW multicore modules. Partition SW-Cs per core in system description (ARXML). Use mailbox or IPdu-gateway for communication. Example mapping notes below. Infineon AURIX: use Infineon MCAL + Vector/EB/ETAS Autosar stacks.
infineon.com+1
Diagnostics integration Diagnostics (UDS) lives in BSW: Dem, Dcm, FiM + interaction with ComM/NM/RTE; configure ARXML and generate RTE. Add Dcm/Dem config in ARXML. Show example of calling Diagnostic event report via RTE or Dem API below. Vector MICROSAR or EB tresos BSW modules + CANoe for test/simulation.
Elektrobit+1
Memory protection AUTOSAR allows memory protection (MPU) as OS scalability class; vendor MCAL + OS must implement MPU setup; used for partitioning/sw-isolation. Example CMSIS MPU setup for Cortex-M (copyable). Map linkerscripts sections per partition. For Cortex-M (S32K): NXP MCAL + EB tresos AutoCore or Vector MICROSAR (support MPU).
NXP Semiconductors+1
Code size targets Use tailored BSW builds (remove unused modules), link-time optimizations, compiler selection (IAR/GCC/Arm-clang), and AUTOSAR module exclusion in tool to reduce footprint. Show basic compiler flags + how to reduce BSW by disabling modules in EB/Vector config. Use EB tresos for aggressive source-level slimming; Vector MICROSAR offers enterprise tuning. OpenERIKA/ArcticCore for small footprints.
Elektrobit+1
- Timing protection — what & how (with code pattern)
What it is
Timing protection ensures a task/ISR cannot run longer than its configured Worst-Case Execution Time (WCET) budget. In AUTOSAR Classic, the OS supports timing protection (OS SWS + functional safety measures) and the timing behavior is configured in ARXML / tool. On violation, OS invokes a predefined error/Shutdown path.
autosar.org+1
How to implement (practical)
Perform WCET analysis (measurement or static) for each task.
Configure timing protection in OS (tool/ARXML). Tool generates monitoring hooks.
In task code, keep cooperative checkpoints minimal; don't spin in loops without bounds.
Optionally use a hardware timer / watchdog and a monitoring task.
Task skeleton (AUTOSAR style pseudocode — portable):
/* AUTOSAR-style task body (C) */
#include "Os.h" /* generated OS header */
TASK(MyTask)
{
/* timing budget is enforced by OS configuration, not by this code */
/* do minimal work: call RTE provided APIs */
Std_ReturnType rc = Rte_Call_MyIf_Operation(...);
if (rc != E_OK) {
/* report via Dem or take safe action */
(void)ShutdownOS(E_OS_PANIC); /* escalate on persistent failure */
}
TerminateTask();
}
Notes: ShutdownOS is the standardized entry to escalate on fatal conditions — set up by OS config. AUTOSAR OS timing protection is configured in OS ARXML and enforced by OS implementation.
autosar.org
2) Multicore — partitioning & comms (practical notes)
What it is
Multicore support in AUTOSAR Classic means the OS and RTE can run per core, SW-Components are mapped to cores, and inter-core comms are defined in the system description. The BSW provides multicore primitives and synchronization. Infineon AURIX is a common multicore target.
infineon.com+1
How to implement (practical)
In system model (ARXML / tool), assign each SW-C to an ECU and core.
Use the RTE generator to create core-local RTEs. Inter-core signals become inter-RTE communication (configured as sender/receiver on different cores).
Use MCAL vendor primitives for cross-core interrupts and hardware mailboxes where required.
Example mapping (conceptual ARXML excerpt idea) — (tools generate the actual ARXML):
<!-- pseudo-ARXML fragment: SW-C allocation (conceptual) -->
<System>
<RunnableEntity name="EngControl_run" swcRef="EngControl" core="Core0"/>
<RunnableEntity name="Diag_run" swcRef="Diag" core="Core1"/>
</System>
Practical toolchain: use Vector/EB/ETAS that support multicore RTE generation and Infineon MCAL for AURIX.
infineon.com+1
3) Diagnostics (UDS/DEM/DCM) — integration pattern & example
How AUTOSAR organises it
Diagnostic services live in BSW: Dcm (Diagnostic Communication Manager), Dem (Diagnostic Event Manager), FiM (Function Inhibition Manager), interfacing with RTE and ComM/NM for session and bus control. Configure in ARXML and generate glue.
Elektrobit
Typical runtime action (example)
When a fault is detected in app code, call Rte_Call(Dem_ReportErrorStatus...) (or Dem API) to record an event.
Dcm handles UDS requests from tester tools; Dem provides freeze frames/fault codes.
Pseudo code example for reporting event (conceptual):
#include "Rte_Dem.h" /* or Dem.h from BSW */
void SensorFaultDetected(void)
{
/* report an event to DEM via RTE or direct API */
Dem_ReportErrorStatus(MY_SENSOR_DIAG_ID, DEM_EVENT_STATUS_FAILED);
}
Tools: Vector MICROSAR and EB tresos provide preintegrated Dcm/Dem modules and CANoe is typically used to exercise UDS tests.
Elektrobit+1
4) Memory protection (MPU) — concrete Cortex-M example
Approach
AUTOSAR OS can be configured with memory protection (MPU regions) if the scaling class / OS implementation supports it. For Cortex-M (e.g., NXP S32K), use the MCAL + OS that sets up the MPU at context switches or in init.
Elektrobit+1
Concrete CMSIS example to configure the MPU (copy/paste ready):
/* Example: basic Cortex-M MPU init (CMSIS) */
#include "core_cm4.h" /* or core_cm0, cm33, depending on target */
void mpu_init(void)
{
/* disable MPU while configuring */
MPU->CTRL = 0;
/* Region 0: flash, execute, read-only for user */
MPU->RNR = 0;
MPU->RBAR = 0x00000000; /* Flash base */
MPU->RASR = (0U << MPU_RASR_XN_Pos) | /* executable */
(0U << MPU_RASR_AP_Pos) | /* full access in this sample (adjust!) */
(0x09U << MPU_RASR_SIZE_Pos) | /* region size (e.g. 2^9=512 bytes) adjust */
MPU_RASR_ENABLE_Msk;
/* Region 1: SRAM, non-executable for user tasks */
MPU->RNR = 1;
MPU->RBAR = 0x20000000; /* SRAM base */
MPU->RASR = (1U << MPU_RASR_XN_Pos) | /* non-executable */
(0U << MPU_RASR_AP_Pos) |
(0x0BU << MPU_RASR_SIZE_Pos) |
MPU_RASR_ENABLE_Msk;
/* Enable default memory map for privileged code and enable MPU */
MPU->CTRL = MPU_CTRL_PRIVDEFENA_Msk | MPU_CTRL_ENABLE_Msk;
/* Ensure MPU settings take effect */
__DSB();
__ISB();
}
Integration tips
Linker sections: place code/data for partitions into dedicated sections; configure MPU regions accordingly.
OS must coordinate MPU on context switch for user/privileged isolation; many AUTOSAR OS implementations (Vector/EB) provide ready support.
Elektrobit
5) Code-size targets — concrete levers and example compiler flags
Levers
Build a minimal BSW (remove unused modules via EB/Vector config).
Compiler optimization: -Os, LTO / thin-LTO, link-time GC of sections (--gc-sections), function/data sectioning (-ffunction-sections -fdata-sections).
Use smaller C library (newlib-nano / microlib / minimal runtime).
Use open lightweight stack (ArcticCore, OpenERIKA) for tiny ECUs.
Example GCC flags
CFLAGS = -Os -ffunction-sections -fdata-sections -fno-exceptions -fno-rtti
LDFLAGS = -Wl,--gc-sections -Wl,--relax
Tool/BSW recommendations
If you must hit very tight budgets, pick OpenERIKA / ArcticCore or a vendor OSEKCore. If you need AUTOSAR compatibility but tight size, EB tresos OsekCore or trimmed Vector MICROSAR with source-level slimming are options.
Erika3+1
Concrete stack recommendations per MCU
A) NXP S32K (Cortex-M family)
Goal: zone/body control / small ASIL tasks.
Recommended AUTOSAR stack: NXP MCAL (S32 SDK) + EB tresos AutoCore or Vector MICROSAR (MCAL/BSW support). Use S32 Design Studio or standard GCC/IAR toolchain.
NXP Semiconductors+1
If tiny: ERIKA / OpenERIKA for OSEK-style minimal footprint.
Erika3
Why: NXP provides MCAL & AUTOSAR support targeted for S32K; EB tresos has strong MCAL integration for vendors (importers).
community.nxp.com+1
B) Infineon AURIX (TriCore multicore)
Goal: powertrain, safety, multicore partitioning.
Recommended AUTOSAR stack: Infineon MCAL for AURIX + Vector MICROSAR (or EB tresos/ETAS offering) with multicore RTE and BSW modules. Use HighTec/Tasking/Infineon compilers or GNU TriCore toolchains recommended by Infineon.
infineon.com+1
Why: AURIX is built for multicore real-time; Vector/EB have mature multicore RTE / BSW support for Infineon.
vector.com+1
C) Renesas RH850
Goal: medium/high throughput ECUs in older powertrain domains.
Recommended AUTOSAR stack: Renesas MCAL + Vector MICROSAR or vendor-preintegrated BSW; ArcticCore forks exist if exploring open option for legacy support. Use Renesas compilers and tools.
ルネサス+1
Open / Lightweight alternatives (if you want small footprint / OSEK)
OpenERIKA / ERIKA Enterprise — OSEK certified, small footprint, good if you need certified OSEK behavior.
Erika3+1
Arctic Core / openAUTOSAR classic-platform — open source AUTOSAR Classic forks; helpful for prototyping / research. Beware license (GPL) and limited active maintenance on some forks.
GitHub+1
Practical checklist you can copy into a project plan
Select target MCU & BSW (vendor MCAL + Vector/EB/ETAS or OpenERIKA/ArcticCore).
NXP Semiconductors+1
WCET & timing analysis (for timing protection): instrument tasks, produce evidence, configure OS timing budgets.
autosar.org
Design multicore partition map (map SW-Cs to cores in system ARXML). Use RTE generator to produce core-local RTE.
infineon.com
Plan diagnostics: decide DTC strategy, Dcm/Dem config, test with CANoe.
Elektrobit
MPU plan: create linker sections for partitions; implement MPU setup in MCAL/OS init. Use CMSIS example above as starting code.
Elektrobit
Trim BSW: disable unused modules in configuration tool; enable compiler LTO and -Os.
Elektrobit
Sources (selection of the most relevant pages I used)
Vector MICROSAR Classic product page.
vector.com
EB tresos Studio & BSW / AutoCore product pages (tooling + BSW options).
Elektrobit+1
Arctic Core / openAUTOSAR classic forks (open source).
GitHub+1
ERIKA / OpenERIKA (OSEK / small footprint).
Erika3+1
AUTOSAR SWS — Operating System specification (timing protection references).
autosar.org+1
NXP S32K AUTOSAR support / MCAL pages.
NXP Semiconductors+1
Infineon AURIX product / AUTOSAR info.
infineon.com+1
Renesas RH850 tools and software pages.
ルネサス
If you want I will:
Generate a concrete ARXML snippet for one sample RW-signal + RTE mapping and the exact tool steps to generate RTE for a chosen tool (Vector / EB), or
Produce a small demo project for one MCU (e.g., S32K144) showing: OS ARXML (or OIL if you prefer OSEK), RTE stub, a timing-protected task plus an MPU init file and a Makefile with the recommended compiler flags.
Which of those two do you want me to produce now?