Search code examples
autosar

Frame Gateway in AUTOSAR instead of PDU or Signal Gateway for N-PDU to pass-through

Is there anything possible in AUTOSAR related to N-PDU based routing, which essentially means Frame Based Routing? If so, some related AUTOSAR System Template Artifact snippets please to help better understand about the implementation details. Related questions Difference between Signal based routing and PDU based routing in AUTOSAR

enter image description here

Solution

  • You have to understand the difference between DBC termina vs AUTOSAR.

    In a DBC, you defined a frame and mapped signals to the frame.

    In AUTOSAR, you have Frames which can have PDUs mapped to it, which in case of ISignalIPdus can have ISignals and ISignalGroups mapped to the ISignalIPdu.

    A CanFrame can only have one PDU mapped to it. (If you have multiple PDUs, you create a ContainerIPdu and map the other IPdus to the ContainerIPdu, similar to MultiplexedIPdus)

    For routing, there are only two types defined:

    • PDU-based routing, handled by the AUTOSAR PduR (PDU Router) component - this is what you currently call frame-based routing
    • Signal-based routing, handled by the AUTOSAR Com component.
    • Frame-based routing in AUTOSAR (even though defined in AUTOSAR_TPS_SystemTemplate see excerpt from chapter 8.1 Frame Mapping, not really supported in AUTOSAR). This would be a routing within the CAN Controller HW, which is not supported by all chip vendors.

    8.1 Frame Mapping

    The FrameMapping arranges those FrameTriggerings that are transferred by the Gateway from one PhysicalChannel to the other in pairs and defines the mapping between them. Each pair consists of a sourceFrame and a targetFrame referencing to a FrameTriggering.

    [TPS_SYST_01116] Frame Mapping is not supported by the AUTOSAR BSW The FrameMapping is not supported by the AUTOSAR BSW. The existence is optional and has been incorporated into the System Template mainly for compatibility in order to allow interchange between FIBEX and AUTOSAR descriptions.

    In order to define routing information in a SystemDescription, you have to define a Gateway as defined in chapter 8 Gateway of the TPS SystemTemplate.

    It is actually pretty easy, but maybe tedious to do it:

    1. Create your topology (CanClusters, EcuInstances)

    2. Create your Frames/Pdus/ISignal(Groups) as normal, and create for them the Frame/Pdu/ISignal-Triggerings on the according networks.

    3. For the gateway ECU, if it is not interested e.g. in certain ISignals, you can remove the receiving ISignalTriggerings for it.

    4. Create a "Gateway" and set its .ecu attribute to the EcuInstance, which is your gateway

    5. Gateway routing relations

      1. For PDU-based routing, you create IPduMapping below the gateway, and select as sourceIPdu the PduTriggering the gateway received on channel A, and for targetIPdu the PduTriggering, the gateway transmits on channel B.
      2. For Signal-based routing, you create ISignalMapping below the gateway, and select as sourceISignal the ISignalTriggering the gateway received on channel A, and for targetISignal the ISignalTriggering, the gateway transmits on channel B.

    For PDU-based routing of ISignalIPdus, you do not need to create additional ISignalMappings for the ISignals contained in this ISignalIPdu. You could even remove receiving ISignalTriggerings for ISignals, your gateway is not interested in itself (to receive over Com and provide per RTE)

      <!-- ARPackage for Gateway definitions -->
  <AR-PACKAGE><SHORT-NAME>Gateways</SHORT-NAME>
    <ELEMENTS>
      <GATEWAY>
        <SHORT-NAME>GW_Ecu1</SHORT-NAME>
        <!-- Reference to the EcuInstance, which will be the gateway -->
        <ECU-REF DEST="ECU-INSTANCE">/EcuInstances/Ecu1</ECU-REF>
        <!-- PDU-based routing -->
        <I-PDU-MAPPINGS>
          <!-- routing IPdu_A from CAN1 to CAN2 -->
          <I-PDU-MAPPING>
            <!-- Source PduTriggering on CAN1 -->
            <SOURCE-I-PDU-REF DEST="PDU-TRIGGERING">/CommunicationClusters/CAN_1/CAN_1_PhyChn/PT_IPdu_A</SOURCE-I-PDU-REF>
            <TARGET-I-PDU>
              <!-- Target PduTriggering on CAN2 -->
              <TARGET-I-PDU-REF DEST="PDU-TRIGGERING">/CommunicationClusters/CAN_2/CAN_2_PhyChn/PT_IPdu_A</TARGET-I-PDU-REF>
            </TARGET-I-PDU>
          </I-PDU-MAPPING>
          <!-- routing IPdu_B from CAN2 to CAN1 -->
          <I-PDU-MAPPING>
            <SOURCE-I-PDU-REF DEST="PDU-TRIGGERING">/CommunicationClusters/CAN_2/CAN_2_PhyChn/PT_IPdu_B</SOURCE-I-PDU-REF>
            <TARGET-I-PDU>
              <TARGET-I-PDU-REF DEST="PDU-TRIGGERING">/CommunicationClusters/CAN_1/CAN_1_PhyChn/PT_IPdu_B</TARGET-I-PDU-REF>
            </TARGET-I-PDU>
          </I-PDU-MAPPING>
        </I-PDU-MAPPINGS>
        <!-- ISignal-based routing -->
        <SIGNAL-MAPPINGS>
          <!-- routing CAN1 ISig_A_Sig1 to CAN2 ISig_A_Sig1 
               could be same as PDU based routing of IPdu_A above just
               on signal routing if you repeat the signal mapping for
               each ISignal of IPdu_A
          -->
          <I-SIGNAL-MAPPING>
            <SOURCE-SIGNAL-REF DEST="I-SIGNAL-TRIGGERING">/CommunicationClusters/CAN_1/CAN_1_PhyChn/ST_ISig_A_Sig1</SOURCE-SIGNAL-REF>
            <TARGET-SIGNAL-REF DEST="I-SIGNAL-TRIGGERING">/CommunicationClusters/CAN_2/CAN_2_PhyChn/ST_ISig_A_Sig1</TARGET-SIGNAL-REF>
          </I-SIGNAL-MAPPING>
          <!-- routing CAN1 ISig_B_Sig1 to CAN2 ISig_C_Sig2 -->
          <I-SIGNAL-MAPPING>
            <SOURCE-SIGNAL-REF DEST="I-SIGNAL-TRIGGERING">/CommunicationClusters/CAN_1/CAN_1_PhyChn/ST_ISig_B_Sig1</SOURCE-SIGNAL-REF>
            <TARGET-SIGNAL-REF DEST="I-SIGNAL-TRIGGERING">/CommunicationClusters/CAN_2/CAN_2_PhyChn/ST_ISig_C_Sig2</TARGET-SIGNAL-REF>
          </I-SIGNAL-MAPPING>
        </SIGNAL-MAPPINGS>
      </GATEWAY>
    </ELEMENTS>
  </AR-PACKAGE>