Miscellaneous – ARXML Configuration Settings

Template for accessing Dt

Template for accessing the dT variable; possible per runnable associated with timing event.

Allowed template parameters:

• %METHOD.NAME% – name of specified AUTOSAR runnable
• %COMPONENT.NAME% – name of the SWC
• %COMPONENT.IMPL.NAME% – name of associated implementation set
• %SWCOMPONENT.NAME% – name of the SWC
• %SWCOMPONENT.IMPL.NAME% – name of associated implementation set of the SWC

Artificial Type Template

Template for types (artificially) created by ASCET from element specification.

Allowed template parameters:

• %FORMULA.NAME% – name of associated ASCET formula
• %IMPL.TYPE.NAME% – AUTOSAR related name (shortname) of ASCET implementation type
• %IMPL.INTERVAL.LEFT% – lower bound of implementation interval OR empty string if the element's lower bound is identical to the lower bound of the implementation data type
• %IMPL.INTERVAL.RIGHT% – upper bound of implementation interval OR empty string if the element's upper bound is identical to the upper bound of the implementation data type
• %IMPL.ZERONOTINCLUDED% – value of implementation-specific flag "Zero not included"

Runnable Symbol

Template for symbols of runnables.

Allowed template parameters:

• %METHOD.NAME% – name of specified AUTOSAR runnable
• %COMPONENT.NAME% – name of the SWC
• %COMPONENT.IMPL.NAME% – name of associated implementation set
• %SWCOMPONENT.NAME% – name of the SWC
• %SWCOMPONENT.IMPL.NAME% – name of associated implementation set of the SWC

Generate Application Init Values

Activated: Initial values for elements associated with an application data type are generated as <APPLICATION-VALUE-SPECIFICATION>.

Deactivated: Initial values for elements associated with an application data type are generated as numerical values (<NUMERICAL-VALUE-SPECIFICATION>).

See the ASCETV6.4 AUTOSAR User Guide for further information.

Generate Internal Data Structure

Activated: Descriptions of internal data structure (e.g., static memory, constant memory, per-instance memory) of the SWC is added to the generated ARXML code.

Deactivated: Descriptions of internal data structure are not added to the generated ARXML code.

See section Description of Internal Data Structures in the ASCETV6.4 AUTOSAR User Guide for details.

Support Multiple Instantiation

Activated: This information is passed to the RTE to influence the generation of the SWC-specific code.

See section Multi-Instance Software Components in the ASCETV6.4 AUTOSAR User Guide for details.

Generate System Constants

Activated: System constants are generated and added to the ARXML code for usage of SW variation, e.g., used for variation points or variation point proxies.

Deactivated: ASCET generates the system constants, but they are not included in the ARXML code, i.e. they are not known to the RTE.

For details on variant handling, see section Variant Handling in the ASCETV6.4 AUTOSAR User Guide.

Generate API including SWC type name

Activated: Generate API for access of system constants with the type name of the associated SWC included. This allows the macros to be used in a more global context.

Deactivated: Generate the API without the type name of the associated SWC.

Generate System Constant Values

Activated: The specified default values of the system constants are included in the generated ARXML code.

Deactivated: The specified default values of the system constants are not included in the generated ARXML code. The information needs to be provided externally in order for the RTE to generate successfully.

Generate System Constant Variant

Activated: Variant information is included in the generated ARXML code. This information is used by the RTE for generating the needed #define macro for each system constant.

Deactivated: Variant information is included in the generated ARXML code. The information needs to be provided externally in order for the RTE to generate successfully.

Default Binding Time of Variation Points

Specifies the binding time for resolution of the variation points. The binding time is passed to the RTE for resolving the variation-point condition at the specified time. This applies to regular and user-defined system constants that are resolved at compile time.

Possible values: CodeGenerationTime / PreCompileTime / None

Use Imported ARXML Info

If an ARXML file is imported, and the contents of the access usage per runnable is stored at the SWC, this information can be used during code generation. See also Usage Information from Imported ARXML Files.

The following settings are available:

• Ignore: The information in the ARXML file is ignored, i.e. not used during code generation.

• Match: The information in the ARXML file is matched with the access information derived from the model during code generation and in case of mismatches, users are informed.

• DeriveAndMatch: The information in the ARXML file is used to decide about implicit or explicit read/write access semantics prior to matching the information.

  Note
  Deriving the semantics from the imported ARXML information has highest priority, i.e. it overwrites any other means to determine the access semantics, including the Use Explicit Semantics for * options.

Use Explicit Semantics for Access to Mapped Messages

Activated: Use explicit instead of implicit access semantics for all messages mapped to data elements of SenderReceiver interfaces.

Deactivated: Use implicit access semantics for all messages mapped to data elements of SenderReceiver interfaces.

Use Explicit Semantics for Access to Mapped Non-Volatile Variables

Activated: Use explicit instead of implicit access semantics for all non-volatile variables mapped to data elements of NVData interfaces.

Deactivated: Use implicit access semantics for all non-volatile variables mapped to data elements of NVData interfaces.

Restrict to AUTOSAR Platform Types

Activated: Use AUTOSAR platform types as implementation data types.

Deactivated: Generate corresponding implementation data type for each application data type generated.

Support for Dt handling

In the AUTOSAR context, no Dt variable is generated by ASCET. Instead, there are a number of ways to handle the Dt access.

The following settings are available:

• None: An error is issued when Dt is accessed within the current project.

• RunnablePeriod: A specific system constant is created for each runnable associated with a timing event. The constants are named according to the template given in Template for accessing Dt. Each access to Dt is mapped to the associated Dt system constant; the associated Dt system constant is found via call stack analysis.

  If the Dt variable is not used within a runnable, the respective constant is not generated, i.e., it does not appear in the C code.

  If Dt is used, but there is no associated runnable, or the associated runnable does not have a timing event associated, ASCET issues an error message.

• External: The template for accessing Dt is generated in order to access the current Dt value.

Use Boolean Implementation Type

Activated: All model elements of type logic are represented in ARXML with the Boolean implementation data type, independently of the specified ASCET Implementation data type.

Deactivated: The specified ASCET implementation data type is used as implementation data type in ARXML for each logical element.

Generate Resource Consumption

Activated: The resource consumption is generated for the software component implementation.

Deactivated: The resource consumption for the software component implementation is not generated.

Memory Allocation Keyword Policy

The Memory Allocation Keyword Policy specifies the name pattern of the Memory Allocation Keyword, which is used for the MemorySection shortNames of referring MemorySections and therefore the belonging Memory Allocation Keywords in the code.

The following settings are available:

• Shortname: Equals addrMethodShortName, i.e. the Memory Allocation Keyword is built with the shortname of the address method (memory section).
• Shortname and Alignment: Equals addrMethodShortNameAndAlignment, i.e. the Memory Allocation Keyword is built with the shortname of the address method (memory section) and a variable alignment postfix.

Avoid temporary variable for multiply mapped messages

If a message is mapped multiple times, e.g., to an interrunnable variable and a data element in a sender/receiver provide port, ASCET generates a temporary variable that buffers the value before writing it to the two AUTOSAR elements. When this option is enabled, the temporary variable is not generated under the following conditions:

• The message has a scalar type (cont, sdisc, udisc, limitInt, wrapInt, enum, log).
• The message and all AUTOSAR elements have the same type (impl. type, formula, value range, limit flags).

The option has no effect on the behavior of the generated code, but may effect the resource consumption:

• A temporary variable may consume stack space.
• An access to static memory may be slower than to a temporary variable (which will likely be hold in a CPU register).

Generation of COMPU-METHODs

The ASCET formulas used within an AUTOSAR context are generated as so-called COMPU-METHODs into the ARXML files. There are several possible ways on how to define a COMPU-METHOD based on an ASCET formula:

The following settings are available:

• Simplify: The category is changed from the model category to a simpler one if possible, e.g., from linear to identity. In addition, the fraction coefficients of the formula are reduced as much as possible.
• Keep Category: The category, i.e. linear, identity, etc. is used with the fraction coefficients of the formula being reduced as much as possible.

• Follow Specification: The generation of the COMPU-METHODs follows strictly the specification of the ASCET formula, with one exception:

  Fractions cannot be used as coefficients for COMPU-METHODs, they must be transformed preserving the numerical equivalence of the formula. If this happens, a warning (WIle560) is issued.