RTD R21-11 AUTOSAR EB: Which modules are Full vs. Stubs? Hello NXP Community, I am working with the SW32K1_S32M24x_RTD_R21-11_3.0.0_D2503 package (S32K1/S32M24x Real-Time Drivers, AUTOSAR R21-11) in an EB tresos environment. Our project does not have a commercial AUTOSAR BSW stack from a third-party supplier (e.g., Vector, ETAS, EB) — we are relying solely on the NXP RTD package and EB configuration. I am aware that some modules in the RTD package are not intended to be complete AUTOSAR implementations. For example, the RTD Release Notes state that "the functions contained in the Dem, Det, EcuC, EcuM, Rte and interface plugins are sample stub functions," and that these stubs exist only to allow applications to compile and run when the corresponding AUTOSAR Basic Software Modules are unavailable. I also understand that RTE is provided as a support stub only and that a fully functional, configurable RTE solution requires a third-party package. However, looking at the list of configurable modules in EB tresos (screenshots attached), I would like to clarify the status of the remaining modules. Specifically, for the following modules, I would like to know: Is it a full, production-ready implementation (e.g., a complete MCAL driver or a complete AUTOSAR service module)? Or is it a sample stub / reference implementation that is not intended for production use and should be replaced by user code or a third-party BSW? Modules in question (from the EB configuration view): Service/ECU Management layer: Dem, Det, EcuM, EcuC, BswM (if present), ComM (if present) Memory stack: Mem, Mem_43_EEP, Mem_43_EXFLS, Mem_43_INFLS, Fee, NvM (if present) MCAL drivers: Adc, Can_43_FLEXCAN, CanIf (interface), Spi, I2c, I2s, Uart, Lin_43_LPUART_FLEXIO, Pwm, Gpt, Icu, Wdg, Mcl, Crc, Dio, Port, Mcu, Platform Other: Eth_43_ENET, EthIf, EthSwt, EthTrcv, CanTrcv_43_AE, LinTrcv_43_AE, Ea/Eep (if present), Rte (already known as stub) I understand that the MCAL drivers (e.g., Port, Adc, Spi, Can) are typically full implementations. My main uncertainty is about the service-layer and interface modules — particularly Dem, Det, EcuM, EcuC, Mem, Fee, CanIf, EthIf, and the *Trcv/EthSwt modules. Are these also stubs, or are they functional implementations provided by NXP? 🙏 A special request for visual clarification: If possible, I would be extremely grateful if the NXP engineer replying to this thread could directly annotate the two attached screenshots to show the status of each module. To make it easy, I suggest using a simple color-coding legend on the images: 🟢 Green (or bold box): Full implementation (production-ready). 🟠 Orange (or dashed box): Sample stub / reference code (not for production). ⚪ Grey (or crossed out): Requires a third-party BSW package (e.g., RTE, OS, NvM). Having the annotations directly on the module list will save me hours of manual cross-referencing and help me accurately scope our project's development effort. Thank you so much for your time and support! Attachments: Two screenshots showing the EB tresos module configuration list. Re: RTD R21-11 AUTOSAR EB: Which modules are Full vs. Stubs? Hi @lukaszadrapa , Thank you very much for your detailed explanation. This clarifies a lot. Knowing that the drivers in Table 3 have "RFP quality" and that the service/interface modules are stubs is exactly the information I needed. I would like to check Table 3 myself. However, I am having trouble locating the exact "Release Notes" document you mentioned on the NXP website for the SW32K1_S32M24x_RTD_R21-11_3.0.0_D2503 package. Could you please provide the exact Document Number (e.g., Document ID/Rev number) or a direct download link to this Release Notes PDF? If it is more convenient, could you please attach the PDF file directly to your reply? I really appreciate your help, and sorry for the trouble in finding the document. Best regards, Chaofan Re: RTD R21-11 AUTOSAR EB: Which modules are Full vs. Stubs? Hi @chaofan
The requested information is already summarized in Table 3 of the Release Notes, which lists the software components included in the package and indicates whether each component is provided as a driver or as a stub. Here’s an example:
Please note that the functions provided in the Dem, Det, EcuC, EcuM, Rte, and interface plugins are sample stub functions intended to support integration and should be replaced by the corresponding user-developed or third-party BSW implementation.
Therefore, I would recommend using Table 3 as the reference for identifying which modules in your EB tresos configuration are actual RTD drivers and which are provided only as stubs.
The drivers listed in Table 3 have RFP quality, meaning they are fully tested and intended for use in production vehicles, as described in the Release Notes.
Regards,
Lukas
記事全体を表示
