SNIP_CLASSIC_PDUR_FIGURE_Figure_3_13

Figure 3.13: Transmission from PduR to CanIf There are two reasons why the "global" Pdu has been introduced and why all "local" Pdus have to point to the "global" Pdu only . • When doing the configuration of module PduR only the "global" Pdu needs to be present, there is no need for the "local" Pdu in the CanIf to be present yet. • The References are stored in the "local" Pdu structure, so changes applied do only influence the structure of the changed module. T aking the structure shown in figure 3.13 it is now possible to generate both modules. The CanIf (automatic) configuration editor collects all "local" CanIfTxPduConfigs and generates/stores the values for their handle ID in CanIfCanTxPduId. If the CanIf needs to know where the Pdu transmit request is coming from it can follow the PduIdRef to the "global" Pdu and then "query" all references pointing to that Pdu. By following those references in reversed direction the transmitting module can be found. The PduR generator has to know which handle ID to use for each Pdu that has to be sent to the CanIf. T o get the actual handle ID value the mechanism is the same in the CanIf use-case: follow the "global" Pdu reference and "query" the modules pointing to that "global" Pdu. Then find the module(s) type this Pdu is going to be transmitted to. In case of a multicast there might be several modules to send the same Pdu to. With this approach a high degree of decoupling has been achieved between the configuration information of the involved modules. Even when modules are adjacent and