AUTOSAR Reference
Contents
1.Single components test •Sender-Receiver Interfaces oImplicit (Rte_IRead, Rte_IWrite API) oExplicit ▪Unqueued (Rte_Read, Rte_Dread, Rte_IsUpdated and Rte_Write API) ▪Queued (Rte_Send, Rte_Receive API) •Client Server Interfaces oSynchronous (Rte_Call API) •Mode Switch Interfaces oMode Manager (Rte_Switch API) oMode User(Rte_Mode API) •RTE Events oTiming Event oData Received Event oOperation Invoked Event oMode Switch Event oData Send Completed Event 2.Composition test ✍Assembly Connectors (MxVMC-RTE handles internally) ✍Delegate Connectors (AppIF.c ports used for delegate connectors) 3.RTE Generation process(RTE Modules generation) ✍RTE Contract phase ✍Component API header file (Application header files (Rte_<SW-C>.h file)) ✍RTE Generation phase ✍RTE Source file(Rte.c) ✍RTE Header file(Rte.h) ✍RTE Life cycle file(Rte_Main.h) ✍Memory mapping header file(MemMap.h) ✍Compiler abstraction file(Compiler.h) ✍Compiler abstraction configuration file(Compiler_Cfg.h) ✍Standard types header file(Std_Types.h) ✍Platform types header file(Platform_Types.h) 4.Automatic harness generation ✍AppIF.c: AUTOSAR ports exported to MxV-Dev Signal dictionary, readily available for Test Case development ✍MxVAutosarHarness.c ✍MxVAutosarHarness.h 5.OSEK OS support (Scheduling runnables) ✍MxVOSKEOS.c (PC based emulated TASK, ALARM Configurations) ✍MxVOSEKOS.h 6.RTE Full behavior ✍RTE API returns proper RTE Error codes (RTE_E_OK, RTE_INVALID, etc.) ✍RTE validates the data elements |
We support the following versions of AUTOSAR: •AUTOSAR 3.2.x •AUTOSAR 4.0.x •AUTOSAR 4.1.x •AUTOSAR 4.2.x •AUTOSAR 4.3.0 •AUTOSAR 4.3.1 •AUTOSAR 4.4.0 |
The following Software Component Files are generated by the Transform: MxVHarness : AppIF.c: The MxVMC Application interface file contains stimulus and response signals, used to communicate with RTE Code. MxVAutosarHarness.c: The MxVMC AUTOSAR Harness file has the OSEK OS Initialization. MxVAutosarHarness.h: The MxVMC AUTOSAR Harness header file contains stimulus and response signal declarations. MxVOSEKOS.c: The MxVMC OSEK OS file includes Tasks, Alarms, Counters, and other OS related configurations. MxVOSEKOS.h: The MxVMC OSEK OS header file includes Tasks, Alarms, Counters, and other OS related declarations. MxVRTE: Rte.c: The RTE file contains the RTE code (RTE API, TASK, ISR, etc. definitions)
RTE API definitions:
TASK and ISR definitions:
Alarm Configurations:
Rte.h: The RTE header file defines fixed elements of the RTE that do not need to be generated or configured for each ECU.
Rte_Main.h: The Lifecycle header file defines the two RTE Lifecycle API calls: Rte_Start and Rte_Stop
MemMap.h: The memory mapping file includes the compiler and linker specific keywords for memory allocation into header and source files.
Compiler.h: The file Compiler.h contains the definitions and macros to configure the reachability of elements (pointers, variables, function, etc.).
Compiler_Cfg.h: The file Compiler_Cfg.h contains the module specific parameters (ptrclass and memclass) that are passed to the macros defined in Compiler.h.
Std_Types.h: This is a standard AUTOSAR file that defines basic (BSW) data types.
Platform_Types.h: This file has platform specific definitions of unsigned and signed integers.
Rte_<source>.h: The application header file is central to the definition of the RTE API. An application header file defines the RTE API and any associated data structures that are required by the RTE implementation. However, the application header file is not allowed to create objects in memory.
 Relationships between RTE Header Files
|
|
Effective with 3.38.1.39472 Enable the MODULE_RESET_IN_TESTCASE macro in the AppIF.c source file to restart the SUT including OS at Module Reset in a TestCase. See the example below. When the macro is disabled, the Signals are reset to the initial values, but the SUT is not restarted.
For more information, see System Reset. |
|
Related Topics: