Task Mapping

Filtering and Selection

Allows you to narrow down which runnables or schedulable entities are shown in the editor. Common filter options include:

  • Requires Mapping: Shows elements that still need to be mapped.

  • Show Unmapped Only: Displays only runnables that are not yet assigned to any task.

Drag-and-Drop Mapping

Enables quick assignment of runnables and schedulable entities to OS tasks. You can:

  • Drag items from the Selection Area to the Overview Area to map them to a task.

  • Reorder runnables within a task by dragging them to a new position. This is the primary way to perform mapping in the editor and adjust execution order visually.

  • Remove a mapping by selecting the element in the Overview Area, right-clicking, and choosing Unmap from the context menu. This returns the runnable or schedulable entity to the unmapped state, allowing you to remap it to another task if needed.

Task Table Customization

Lets you tailor the task overview to your needs by hiding unnecessary columns and focusing on relevant details, accessible by right clicking on a column header. Common columns include:

  • Priority: The OS task priority.

  • OS Application: The application context for the task.

  • Core Assignment: Indicates which CPU core the task runs on.

  • Trigger Conditions: Shows what activates the mapped runnables.

Use customization to simplify the view and make mapping decisions easier.

Grouping Options

Software Components

Lets you organize runnables based on their source components. Common categories include:

  • Application Components: These are the SWCs in your ECU project. Each SWC contains runnables that need to be mapped to OS tasks. This category helps you locate runnables based on the component they belong to.

  • Service Components: AUTOSAR service components, such as diagnostic or communication services. They also have schedulable entities or runnables that need mapping. Useful for mapping service-related functionality separately from application logic.

  • Schedulable Entities: Refers to BSW MainFunctions or other entities that the OS can schedule. These are not part of SWCs but still need to be assigned to tasks for proper execution.

  • Execution Order Constraints: Lists any defined constraints that specify the required execution sequence between runnables (e.g., Runnable A must run before Runnable B). If your project doesn’t define these constraints in ARXML or system description, this section may appear empty.

  • SWC Mapping Instructions: Guidelines or rules imported from the system description or configuration files that suggest how SWCs should be mapped (e.g., preferred tasks or cores). They help ensure consistency with system-level design.

Trigger Conditions

Lets you group runnables by the type of trigger that activates them. Common categories include:

  • Operation Invocation: Triggered when a client-server operation call occurs. For example, when one component calls a service interface, the corresponding runnable executes.

  • Periodical: Triggered at a fixed time interval (e.g., every 10 ms). Common for tasks like sensor reading or control loops that need regular execution.

  • Init: Triggered once during ECU initialization. Used for setup routines, initializing variables, or preparing hardware/software states before normal operation.

  • Mode Entry: Triggered when the ECU enters a specific mode (e.g., Normal, Limp-home). Useful for switching behavior when the vehicle changes operating modes.

  • Data Reception: Triggered when new data arrives on a port (e.g., from CAN or LIN). A runnable executes when a new sensor value or message is received.

  • Internal Trigger Occurred: Triggered by an internal event within the ECU (not external communication). For example, a state machine inside an SWC signals an event that activates a runnable.

  • Periodical in Background: Similar to Periodical, but scheduled in a background task with lower priority. Used for non-critical monitoring tasks that run periodically without strict timing.

  • Operation Call Return: Triggered when a client-server call completes and returns a result. A runnable executes after receiving a response from a service.

  • External Trigger Occurred: Triggered by an external event, such as a hardware interrupt or external signal. For example, a runnable executes when a GPIO pin changes state.

  • Execution Order Constraints: Lists any defined sequence rules between runnables (e.g., Runnable A must run before Runnable B). If your project doesn’t define these constraints in ARXML or system description, this section may be empty.