CLASSIC
Modul: ecuconfiguration
Rolle: heuristic
Konfidenz: 80%
SNIP_CLASSIC_ECUCONFIGURATION_SECTION_4_4_1_1_Handle_ID_concept
Wortlaut
4.4.1.1 Handle ID concept
The API definitions in the COM-Stack utilize two concepts to achieve the interaction between adjacent modules:
• Pointers to PDU data buffer (the PDU data buffer contains the actual communicated information, depending on the actual layer the interaction happens)
• Handle IDs to identify to what PDU the pointer is referring to. A typical API call is for instance: PduR_ComTransmit(PduIdType ComTxPduId, PduInfoType *PduInfoPtr) Which BSW Module is actually providing the value of the Handle ID is specified in the ECU Configuration Parameter Definition of the corresponding BSW Module (see section 4.4.1.2 for details on the specification). The choice of the value for a Handle ID is open to the implementation of the providing module. There might be different strategies to optimize the Handle ID values and therefore the internal structures of the implementation may have an influence on the choice of the values. Also the Handle IDs can be chosen freely per module, so a PDU might be sent from Com to the PduR with the ID=5 and then the PduR transmits it further to the CanIf with ID=19. In the configuration information of the PduR it has to be possible to conclude that if a PDU arrives from Com with ID=5 it has to be forwarded to the CanIf with ID=19. It has to be guaranteed that each Pdu does have a unique handle ID within the scope of the corresponding API. For example: The PduR gets transmission requests from both, the Com and the Dcm modules. But there are also two distinct APIs defined for those requests:
• PduR_ComTransmit(...)
• PduR_DcmTransmit(...) Therefore the PduR can distinguish two PDUs, even when they have the same handle ID but are requested via different APIs. Another use-case in the COM-Stack only provides one API for all the callers: the interface layer (CanIf, FrIf, LinIf).
• CanIf_Transmit(...) 4Modules are called adjacent if they share an interface, so PduR and Com are adjacent, while PduR and Can driver are not. Specification of ECU Configuration R4.0 Rev 3 Here it has to be guaranteed that each transmit request for a distinct PDU does have a unique handle ID. The actual values of the handle IDs can only be assigned properly when the configuration of one module is completed, since only then the internal data structures can be defined. In the next sections the patterns used to define and utilize Handle IDs are described.
Versionen & Provenienz · Zugeordnete Anforderungen
Diese Angaben zeigt der Versions-Explorer.
Begründung & Zuweisungs-Evidenz
Explains routing path identification with handle IDs.
Dokumenten-Herkunft & Rückverfolgbarkeit
| Spezifikations-Dokument | ECUConfiguration.pdf |
|---|---|
| Dokumentseite | Seite 156 |
| Ziel-Modul | ecuconfiguration (classic) |
| Ziel-Anforderung | SWS_PduR_00828 |
| Semantische Rolle | heuristic |
| Automatisierungs-Konfidenz | 0.80 |