AUTOSAR Run-Time Interface (Arti)

Service to initialize the ARTI module

Returns the version information of this module.

The ARTI template shall support core specific ARTI additions Description: The ARTI template shall define a mechanism to allow core specific ARTI parameters. Rationale: ARTI needs core specific evaluations. The Template shall define a “class” to define additional parameters to cores as well as an “instance” to define values of specific cores. The core instance shall include a reference to the core definition in the EcuC description. Dependencies: – Use Case: Debuggers and Tracing tools need specific core related information to display and trace the core activity. Supporting Material: -

The ARTI template shall support a parameter for the current application Description: The ARTI template shall define a parameter that contains the evaluation for the “current application” that is running on a specific core. Rationale: ARTI needs to know which application is running at a core at a specific time. Dependencies: [RS_Arti_00001] Use Case: Debuggers and Tracing tools need to know the current application to display and trace the core activity. Supporting Material: -

The ARTI template shall support a parameter for the current task Description: The ARTI template shall define a parameter that contains the evaluation for the “current task” that is running on a specific core. Rationale: ARTI needs to know which task is running at a core at a specific time. Dependencies: [RS_Arti_00001] Use Case: Debuggers and Tracing tools need to know the current task to display and trace the core activity. Supporting Material: -

The ARTI template shall support a parameter for the last error Description: The ARTI template shall define a parameter that contains the evaluation for the “last error” that happened on a specific core. Rationale: ARTI needs to know which error happened at a core at a specific time. Dependencies: [RS_Arti_00001] Use Case: Debuggers and Tracing tools need to know the last error to display and trace the core activity. Supporting Material: -

The ARTI template shall support OS specific ARTI additions Description: The ARTI template shall define a mechanism to allow OS specific ARTI parameters. Rationale: ARTI needs OS specific evaluations. The Template shall define a “class” to define additional parameters to an OS as well as an “instance” to define values of the OS. The OS instance shall include a reference to the OS definition in the EcuC description. Dependencies: – Use Case: Debuggers and Tracing tools need specific OS related information to display and trace the OS activity. Supporting Material: -

The ARTI template shall support task specific ARTI additions Description: The ARTI template shall define a mechanism to allow task specific ARTI parameters. Rationale: ARTI needs task specific evaluations. The Template shall define a “class” to define additional parameters to a task as well as an “instance” to define values of the task. The task instance shall include a reference to the task definition in the EcuC description. Dependencies: – Use Case: Debuggers and Tracing tools need specific task related information to display and trace the task activity. Supporting Material: -

The ARTI template shall support SWC specific ARTI additions Description: The ARTI template shall define a mechanism to allow SWC specific ARTI parameters. Rationale: ARTI needs SWC specific evaluations. The Template shall define an “instance” to define values of an SWC. The SWC instance shall include a reference to the SWC definition in the EcuC description. Dependencies: – Use Case: Debuggers and Tracing tools need specific SWC related information to display and trace the SWC activity. Supporting Material: -

shall include a core class definition. Description: Additional parameters to a core are collected in a class definition, following the ARTI Template. Rationale: An ARTI consuming tool needs to know the layout of a core class used by this implementation. Dependencies: – Use Case: Evaluating the form of display for cores. Supporting Material: -

for a core class shall include a “current task” reference to the interpret the parameter value Description: A core class shall include a reference to a parameter definition that defines how a specific value of the “current task” parameter should be interpreted. Rationale: An ARTI consuming tool needs to know how to interpret the values for a “current task”, used by this implementation. Dependencies: [RS_Arti_00009] Use Case: Defining the display for “current task”. Supporting Material: -

shall include instance definitions for all cores of the ECU. Description: Additional parameter values to a core are collected in an instance definition, following the ARTI Template. Rationale: An ARTI consuming tool needs to know how to evaluate the parameter values of a specific core used by this implementation. Dependencies: [RS_Arti_00009] Use Case: Evaluating the parameter values of a core for debugging and tracing. Supporting Material: -

for a core instance shall include a “current task” reference to evaluate the parameter value Description: A core instance shall include a reference to a parameter value that defines how to evaluate value of the “current task” parameter. Rationale: An ARTI consuming tool needs to know how to evaluate the values for a “current task”, used by this implementation. Dependencies: [RS_Arti_00011], [RS_Arti_00012] Use Case: Evaluating the parameter value of “current task” of a specific core. Supporting Material: -

shall include an OS class definition. Description: Additional parameters to an OS are collected in a class definition, following the ARTI Template. Rationale: An ARTI consuming tool needs to know the layout of an OS class used by this implementation. Dependencies: – Use Case: Evaluating the form of display for cores. Supporting Material: -

shall include an instance definition for the OS of the ECU. Description: Additional parameter values to an OS are collected in an instance definition, following the ARTI Template. Rationale: An ARTI consuming tool needs to know how to evaluate the parameter values of a specific OS used by this implementation. Dependencies: [RS_Arti_00016] Use Case: Evaluating the parameter values of an OS for debugging and tracing. Supporting Material: -

shall include a task class definition. Description: Additional parameters to a task are collected in a class definition, following the ARTI Template. Rationale: An ARTI consuming tool needs to know the layout of a task class used by this implementation. Dependencies: – Use Case: Evaluating the form of display for task. Supporting Material: -

shall include instance definitions for all tasks of the ECU. Description: Additional parameter values to a task are collected in an instance definition, following the ARTI Template. Rationale: An ARTI consuming tool needs to know how to evaluate the parameter values of a specific task used by this implementation. Dependencies: [RS_Arti_00022] Use Case: Evaluating the parameter values of a task for debugging and tracing. Supporting Material: -

shall include instance definitions for all SWCs of the ECU. Description: Additional parameter values to an SWC are collected in an instance definition, following the ARTI Template. Rationale: An ARTI consuming tool needs to know how to evaluate the parameter values of a specific SWC used by this implementation. Dependencies: - Use Case: Evaluating the parameter values of an SWC for debugging and tracing. Supporting Material: -

⌊ DRAFT g The locating process shall allow grouping of “trace- ables” into separate memory regions. Description: Many processors support instruction tracing (“flow-tracing”) which consumes high band-width and also special versions of the processor (cf. Infineon AURIX emulation device). When looking at e.g. the level of tasks or runnables, instruction traces provide far more details than necessary. So for tracing tasks, runnables, etc. instruction tracing is not the right method. More and more processors allow efficient tracing (without any software instrumentation) on a function level as long as the functions to trace are located in the same memory region (in which no other function must be located). Runnables and typically also tasks are implemented as functions so when AUTOSAR offered a way to group all tasks and runnables into memory regions of their own, such efficient non-intrusive tracing would be supported. Rationale: Processors which support non-intrusive high-level tracing need objects to trace (“traceables”) such as tasks, runnables, etc. to be located “together” in a memory-region. Dependencies: – Use Case: Highly efficient tracing of tasks, runnables, functions belonging to dedicated SW-Cs etc. Supporting Material: -

AUTOSAR shall support recording timing events of application states Description: AUTOSAR shall support the recording and tracing of application state changes. Rationale: Provide a standardized way to trace timing events on application state changes to ensure tool compatibility and compatibility to TIMEX. Dependencies: – Use Case: Add a trace instrumentation to application state changes. Supporting Material: -

AUTOSAR shall support recording timing events of tasks Description: AUTOSAR shall support the recording and tracing of task state changes. Rationale: Provide a standardized way to trace timing events on task state changes to ensure tool compatibility and compatibility to TIMEX. Dependencies: – Use Case: Add a trace instrumentation to task state changes. Supporting Material: -

AUTOSAR shall support recording timing events of category 2 interrupt states Description: AUTOSAR shall support the recording and tracing of category 2 interrupt state changes. Rationale: Provide a standardized way to trace timing events on category 2 interrupt state changes to ensure tool compatibility and compatibility to TIMEX. Dependencies: – Use Case: Add a trace instrumentation to category 2 interrupt state changes. Supporting Material: -

AUTOSAR shall support recording timing events of service calls Description: AUTOSAR shall support the recording and tracing of service call entries and exits. Rationale: Provide a standardized way to trace timing events on service call entries and exits to ensure tool compatibility and compatibility to TIMEX. Dependencies: – Use Case: Add a trace instrumentation to service calls. Supporting Material: -

AUTOSAR shall support recording timing events of spinlock states Description: AUTOSAR shall support the recording and tracing of spinlock state changes. Rationale: Provide a standardized way to trace timing events on spinlock state changes to ensure tool compatibility and compatibility to TIMEX. Dependencies: – Use Case: Add a trace instrumentation to spinlock state changes. Supporting Material: -

AUTOSAR shall support recording timing events of protection hooks Description: AUTOSAR shall support the recording and tracing of protection hooks. Rationale: Provide a standardized way to trace timing events on protection hooks to ensure tool compatibility. Dependencies: – Use Case: Add a trace instrumentation to protection hooks. Supporting Material: -

AUTOSAR shall support tracing of arbitrary intervals between a start and a stop event Description: The tracing of arbitrary intervals between a start and a stop event shall be supported. Rationale: Provide a standardized way to define this to ensure tool compatibility. Dependencies: – Use Case: Add user defined instrumentation to software components. Supporting Material: -

AUTOSAR shall support tracing of arbitrary intervals between a start and several stop events Description: The tracing of arbitrary intervals between a start and several stop events shall be supported, with the aim to provide insides to a dataflow. Rationale: Provide a standardized way to define this to ensure tool compatibility. Dependencies: – Use Case: Add user defined instrumentation to software components. Supporting Material: -

AUTOSAR shall support tracing of arbitrary values Description: The tracing of arbitrary values shall be supported. Rationale: Provide a standardized way to define this to ensure tool compatibility. Dependencies: – Use Case: Add user defined instrumentation to software components. Supporting Material: -

AUTOSAR shall support tracing of category 1 interrupts. Description: AUTOSAR shall support the recording and tracing of category 1 interrupts. Rationale: Provide a standardized way to trace timing events on category 1 interrupts to ensure tool compatibility and compatibility to TIMEX. Dependencies: – Use Case: Add a trace instrumentation to category 1 interrupts. Supporting Material: -

The Default Error Tracer shall provide an interface to receive error reports Description: The Default Error Tracer shall provide an interface to get a development error report. Rationale: An interface will be needed to enable handling of development errors Use Case: During software development phase a BSW module has been called using wrong parameters. By generating a development error and reporting it to the DET, configuration errors can be detected. AppliesTo: CP Dependencies: – Supporting Material: –

Report errors shall contain a dedicated set of information Description: Error reports, which the Default Error Tracer receives, shall consist of the ID of the reporting module, the ID of reporting instance, the ID of the API service in which the error has been detected and the error ID itself. Rationale: For optimal support of the error tracing some tracing information is necessary. Use Case: During software development phase a BSW module has been called using wrong parameters. Due to communication of some tracing information the location of the error source will be supported. AppliesTo: CP Dependencies: – Supporting Material: –

The Default Error Tracer shall provide a development error re- port reception service Description: The Default Error Tracer shall be accessible by applications to report development error. Rationale: It shall be possible to perform error tracing during development of applications. Use Case: During software development phase a applictaion has received an unexpected response by a BSW module. By generating a development error and reporting it to the DET, configuration errors can be detected. AppliesTo: CP Dependencies: – Supporting Material: –

The DET module shall support fan-out of received error reports Description: The Default Error Tracer shall forward each received error report by calling each element of a configurable list of functions. Rationale: This implements the debugging concept in R4.0 (DocumentId 298) Use Case: Even development errors shall be captured by the Log and Trace functionality. Error Handling shall be enabled to react on development errors AppliesTo: CP Dependencies: – Supporting Material: –

A configurable list of error report receivers shall be provided Description: The Default Error Tracer shall support a configurable list of functions for fan-out of received error reports. This list can be empty. Rationale: This implements the debugging concept in R4.0 (DocumentId 298). Use Case: Even development errors shall be captured by the Log and Trace functionality. Error Handling shall be enabled to react on development errors AppliesTo: CP Dependencies: – Supporting Material: –

The DET module shall forward its trace events to the DLT Description: The DET receives trace events from errors from the BSW and application during debugging time. If a DLT module exists, these events should be forwarded to the DLT to collect logs and traces only in one instance. Rationale: To have an overview of all log, trace and error messages and to set all of them in the correct context, it is important to have all these messages and events in one list (context). Also it is not practicable to use more than one mechanism to report errors, logs and traces to a debugging interface. So all these sources should be routed to the DLT. Use Case: • A debugging scenario, an application or BSW Module uses the DET interface to trace an error • This error is forwarded by the DET to the DLT • The DLT turns these events in the DLT format and sends it over the debugging interface, together with all the other logs and traces AppliesTo: CP Dependencies: – Supporting Material: –

The Default Error Tracer shall provide an interface to receive runtime error reports Description: The Default Error Tracer shall provide an interface to get a runtime error report, issued by BSW modules. The Default Error Tracer returns to the caller in order to allow continuation of intended program flow. Rationale: An interface will be needed to enable handling of runtime errors, caused by seldom occurring systematic faults. The caller will handle the error and continue appropriate in a deterministic manner. Use Case: CANNM_E_NET_START_IND: Reception of NM PDUs in Bus-Sleep Mode AppliesTo: CP Dependencies: – Supporting Material: –

The Default Error Tracer shall provide an interface to receive transient fault reports Description: The Default Error Tracer shall provide an interface to get a transient fault report, issued by BSW modules. The Default Error Tracer returns to the caller in order to allow continuation of intended program flow. Rationale: An interface will be needed to enable handling of transient faults, caused by seldom occurring transient hardware faults. Use Case: • CAN controller goes offline due to bit-flip in its control register • Peripheral action lasts accidentally longer than expected (and specified) AppliesTo: CP Dependencies: – Supporting Material: –

The Default Error Tracer shall forward received runtime error reports to configured integrator code Description: The Default Error Tracer shall propagate all received runtime error reports using configurable callout. The received callout return value shall be returned to the reporter of the runtime error. If no callout has been configured, a default return value shall be provided. The Default Error Tracer returns to the caller in order to allow continuation of intended program flow. Rationale: Integrator shall be able to recognize runtime errors and to handle in an appropriate manner. Use Case: CANNM_E_NET_START_IND: Reception of NM PDUs in Bus-Sleep Mode AppliesTo: CP Dependencies: – Supporting Material: –

The Default Error Tracer shall forward received transient fault reports to configured integrator code Description: The Default Error Tracer shall propagate all received transient fault report using configurable callout. The received callout return value shall be returned to the reporter of the transient fault. If no callout has been configured, a default return value shall be provided. The Default Error Tracer returns to the caller in order to allow continuation of intended program flow. Rationale: Integrator shall be able to recognize transient faults and to handle in an appropriate manner and to advice the reporter. Use Case: • CAN controller goes offline due to bit-flip in its control register. Integrator decides that reporting CAN driver shall re-initialize the CAN controller. • CAN controller goes offline due to bit-flip in its control register. Integrator decides that reporting CAN driver shall treat offline state of CAN controller as intended. AppliesTo: CP Dependencies: – Supporting Material: –

Define USER_STOPWATCH ARTI shall define a trace class for tracing of arbitrary intervals between a start and a stop event called USER_STOPWATCH .

Macro USER_STOPWATCH ARTI macros of the class USER_STOPWATCH shall compile the following template:

Define USER_DATAFLOW_STOPWATCH ARTI shall define a trace class for tracing of arbitrary intervals between a start and several stop events, with the aim to provide insides to a dataflow, called USER_DATAFLOW_STOPWATCH .

Macro USER_DATAFLOW_STOPWATCH ARTI macros of the class USER_DATAFLOW_STOPWATCH shall compile the following template:

Define USER_DATAPOINT ARTI shall define a trace class for tracing of arbitrary values, called USER_DATAPOINT .

Macro USER_DATAPOINT ARTI macros of the class USER_DATAPOINT shall compile the following template:

Define AR_CP_ARTI_CAT1ISR ARTI shall define a trace class for tracing of category 1 interrupts, called AR_CP_ARTI_CAT1ISR .

Macro AR_CP_ARTI_CAT1ISR ARTI macros of the classes AR_CP_ARTI_CAT1ISR and AR_CP_ARTIEXT_CAT1ISR shall compile the following tem- plate:

If the initialization fails, the function Arti_Init shall raise the error ARTI_E_INIT_FAILED .

If the parameter VersionInfoPtr is a null pointer, the function Arti_GetVersionInfo shall raise the error ARTI_E_PARAM_POINTER .

Generate RTE VFB Trace Client The ARTI module shall gen- erate an RTE VFB trace client that implements the Runnable Entity Trace Events [3, SWS RTE, chapter 5.11.5.5] and BSW Schedulable Entities Trace Events [3, SWS RTE, chapter 5.11.5.6].

Define AR_CP_RTE_RUNNABLE The Runnable Entity Trace Events shall be mapped to the ARTI Trace Class AR_CP_RTE_RUNNABLE .

Define AR_CP_SCHM_SCHEDULABLE The BSW Schedulable Entity Trace Events shall be mapped to the ARTI Trace Class AR_CP_SCHM_SCHEDULABLE .

Macro AR_CP_RTE_RUNNABLE ARTI macros of the class AR_CP_RTE_RUNNABLE shall compile the following template:

Macro AR_CP_SCHM_SCHEDULABLE ARTI macros of the class AR_CP_SCHM_SCHEDULABLE shall compile the following template:

Macro AR_CP_VOID ARTI shall provide a macro of the class AR_CP_VOID that compiles to nothing.

ARTI Tracing Macro Parameters ARTI tracing macros shall ac- cept a set of parameters that define the semantics of the macros.

ARTI Tracing Macro Format (single event) If the event to trace accepts one single event parameter, then ARTI shall use a single event parameter version.

ARTI Tracing Macro Format (multiple events) If the event to trace accepts more than one parameters, then ARTI shall use the multiple event pa- rameter version.

Define AR_CP_RTE_API The RTE API Trace Events shall be mapped to the ARTI Trace Class AR_CP_RTE_API .

Macro AR_CP_RTE_API ARTI macros of the class AR_CP_RTE_API shall compile the following template:

Define AR_CP_BSW_API ARTI shall define a trace class for tracing entries and exits of BSW modules, called AR_CP_BSW_API.

Macro AR_CP_BSW_API ARTI macros of the class AR_CP_BSW_API shall compile the following template:

Type of error Related error code Error value Initialization of ARTI module failed ARTI_E_INIT_FAILED 0x01 API parameter checking: invalid pointer ARTI_E_PARAM_POINTER 0x02