How to make CAN Frame Identifier as Dynamic Data Element in AUTOSAR ARXML File

Shown below one example ARXML File Content and System Template for CAN Frame Triggering which has Identifier value. Is it allowed by AUTOSAR Standard to have this Identifier value as Dynamic so that I can define the final Identifier value as Calibration Data instead of Compile Time Fixed Value data? Some hints and snippets/references from AUTOSAR Standard will help me better understand how to implement in ARXML this Identifier Field Value as Dynamic, so that BSW/RTE Configurator tool behaves properly and produce this Identifier field value as Dynamic instead of Static in generated source code.

There are several ways to handle reconfigurable SW in AUTOSAR:

• You could use a POSTBUILD_LOADABLE or even a POSTBUILD_SELECTABLE (or even a mix of both).
  • POSTBUILD_LOADABLE is a feature to change an configuration separate from the implementation, e.g. a gateway is updated because a new ECU is added on a network, and requires new routing relations of messages it received or transmits over the gateway.
  • POSTBUILD_SELECTABLE is a feature to have multiple configurations of EcuInstances included, where one of it is selected at runtime. This feature we use here for our corner radars for over a decade now, in order to have one ECU and one SW, instead of 4 separate ECUs with all the overhead in maintenance and logistics. We even had in the pre-AUTOSAR time with the old CANbedded Stack from Vector a feature called "Multiple ECU / Multiple Config". At runtime, we have some mechanisms to detect which EcuInstance we are, and then select the corresponding configuration and also which features/functions are running and which not.
• The above features allow to separate the config from the application, and leverage the optimization possible in HW configuration, e.g. also selection of FullCAN vs BasicCAN handling.
• Your idea needs the following:
  • do not set identifier in FrameTriggering --> dynamic IDs
  • set the txMask for TX or rxMask for RX --> used to mask the dynamic IDs for TX / RX
  • do not set txMask for transmission, then the content of MetaData is taken as CanID as is for TX.
  • But this requires to enable MetaData-Support. Which ID is then finally used, can be done by passing it through the MetaData, e.g. Com_TriggerIPDUSend vs Com_TriggerIPDUSendWithMetaData. The final setting of the CanID is done in CanIf (see AUTOSAR SWS CanInterface ch. 7.4 Dynamic L-PDUs).
  • This type might be used for some very dedicated messages, but is maybe to cumbersome compared to more complex changes handled by the POSTBUILD_LOADABLE or POSTBUILD_SELECTABLE feature.
  • For some modules like Dcm (Diagnostics) or Xcp, it might not be possible to change the CanIDs that way at all. I'm currently also not sure, if you can hook into these.