AUTOSAR CP SWS CommunicationStackTypes
AUTOSAR CP SWS CommunicationStackTypes
AUTOSAR CP R23-11
Specification of Communication
Document Title Stack Types
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 50
4
• Removed Type BusTrcvErrorType
because it is not used at all
AUTOSAR
• Updated PduInfoType for addressing in
2016-11-30 4.3.0 Release
Upper Layers using MetaData
Management
• Update of SWS document as per BSW
General document
AUTOSAR
2015-07-31 4.2.2 Release • Editorial changes
Management
AUTOSAR
• MetaData information is added in
2014-10-31 4.2.1 Release
PduInfoType
Management
AUTOSAR
• Added support for Pretended network
2014-03-31 4.1.3 Release
data type
Management
• Removed the published information
AUTOSAR
• Editorial changes
2013-10-31 4.1.2 Release
Management • Removed chapter(s) on change
documentation
• Added support for Partial network data
type
4
• Typo errors are corrected throughout the
document
• NTFRSLT_E_TIMEOUT_Cr changed to
AUTOSAR NTFRSLT_E_TIMEOUT_CR
2006-11-28 2.1.2
Administration
• Definitions according to compiler
abstraction added
Disclaimer
This work (specification and/or software implementation) and the material contained in
it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the
companies that have contributed to it shall not be liable for any use of the work.
The material contained in this work is protected by copyright and other types of intel-
lectual property rights. The commercial exploitation of the material contained in this
work requires a license to such intellectual property rights.
This work may be utilized or reproduced without any modification, in any form or by
any means, for informational purposes only. For any other purpose, no part of the work
may be utilized or reproduced, in any form or by any means, without permission in
writing from the publisher.
The work has been developed for automotive applications only. It has neither been
developed, nor tested for non-automotive applications.
The word AUTOSAR and the AUTOSAR logo are registered trademarks.
Contents
1 Introduction and functional overview 7
3 Related documentation 9
3.1 Input documents & related standards and norms . . . . . . . . . . . . . 9
3.2 Related specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Constraints and assumptions 10
4.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Applicability to car domains . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Applicability to safety related environments . . . . . . . . . . . . . . . . . 10
5 Dependencies to other modules 11
6 Requirements Tracing 12
7 Functional specification 13
7.1 General issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2 Error Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2.1 Development Errors . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2.2 Runtime Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2.3 Transient Faults . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2.4 Production Errors . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2.5 Extended Production Errors . . . . . . . . . . . . . . . . . . . . 14
7.3 Security Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8 API specification 15
8.1 Type definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1.1 PduIdType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1.2 PduLengthType . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1.3 PduInfoType . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1.4 PNCHandleType . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1.5 TPParameterType . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1.6 BufReq_ReturnType . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1.7 TpDataStateType . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1.8 RetryInfoType . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1.9 NetworkHandleType . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1.10 CbkHandleIdType . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1.11 TimeTupleType . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1.12 TimeStampType . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1.13 TimeStampQualType . . . . . . . . . . . . . . . . . . . . . . . 21
8.1.14 ListElemStructType . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2 Function definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9 Sequence diagrams 23
10 Configuration specification 24
10.1 Published Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A Not applicable requirements 25
Acronym: Description:
API Application Programming Interface
DCM Diagnostic Communication Manager
I-PDU Interaction Layer PDU. In AUTOSAR the Interaction Layer is equivalent to the
Communication Services Layer.
L-PDU Data Link Layer PDU. In AUTOSAR the Data Link Layer is equivalent to the
Communication Hardware Abstraction and Microcontroller Abstraction Layer.
N-PDU Network Layer PDU. In AUTOSAR the Network Layer is equivalent to the
Transport Protocol.
OSEK/VDX In May 1993 OSEK has been founded as a joint project in the German
automotive industry aiming at an industry standard for an open-ended
architecture for distributed control units in vehicles. OSEK is an abbreviation for
the German term "Offene Systeme und deren Schnittstellen fà 41 r die Elektronik
im Kraftfahrzeug" (English: Open Systems and the Corresponding Interfaces for
Automotive Electronics). Initial project partners were BMW, Bosch, Daimler
Chrysler, Opel, Siemens, VW and the IIIT of the University of Karlsruhe as
co-ordinator. The French car manufacturers PSA and Renault joined OSEK in
1994 introducing their VDX-approach (Vehicle Distributed eXecutive) which is a
similar project within the French automotive industry. At the first workshop on
October 1995 the OSEK/VDX group presented the results of the harmonised
specification between OSEK and VDX. After the 2nd international OSEK/VDX
Workshop in October 1997 the 2nd versions of the specifications were published.
PDU Protocol Data Unit
SDU Service Data Unit - Payload of PDU
TP Transport Protocol
Abbreviation: Description:
Com Communication
EcuC ECU Configuration
e.g. [lat.] exempli gratia = [eng.] for example
i.e. [lat.] it est = [eng.] that is
3 Related documentation
[1] Glossary
AUTOSAR_FO_TR_Glossary
[2] General Specification of Basic Software Modules
AUTOSAR_CP_SWS_BSWGeneral
[3] Requirements on Communication
AUTOSAR_CP_SRS_COM
4.1 Limitations
No limitations.
6 Requirements Tracing
The following tables reference the requirements specified in [3] and links to the fulfill-
ment of these. Please note that if column “Satisfied by” is empty for a specific require-
ment this means that this requirement is not fulfilled by this document.
Requirement Description Satisfied by
[SRS_BSW_00441] Naming convention for type, macro [SWS_COMTYPE_91005]
and function
[SRS_Com_02043] AUTOSAR COM and LargeDataCOM [SWS_Comtype_00004] [SWS_Comtype_00006]
shall provide a receive indication [SWS_Comtype_00007] [SWS_Comtype_00010]
function [SWS_Comtype_00014] [SWS_Comtype_00015]
[SWS_Comtype_00017] [SWS_Comtype_00030]
[SRS_Com_02045] AUTOSAR COM and LargeDataCOM [SWS_Comtype_00004] [SWS_Comtype_00006]
shall provide a function to request the [SWS_Comtype_00007] [SWS_Comtype_00010]
transmit buffer data for lower layer [SWS_Comtype_00014] [SWS_Comtype_00015]
triggered transmission [SWS_Comtype_00017] [SWS_Comtype_00030]
[SRS_Com_02095] AUTOSAR COM and LargeDataCOM [SWS_Comtype_00004] [SWS_Comtype_00006]
shall use the TP to fragment and [SWS_Comtype_00007] [SWS_Comtype_00010]
reassemble large signals [SWS_Comtype_00014] [SWS_Comtype_00015]
[SWS_Comtype_00017] [SWS_Comtype_00030]
[SRS_Com_02114] AUTOSAR COM and LargeDataCOM [SWS_COMTYPE_91001]
shall support independent
development of CP Software Clusters
[SRS_Eth_00105] Support of time stamping in hardware [SWS_COMTYPE_91002] [SWS_COMTYPE_91003]
[SWS_COMTYPE_91004]
[SRS_Eth_00167] PTP Physical Clock Adjustment [SWS_COMTYPE_91002]
[SRS_Eth_00172] Ethernet Driver hardware supported [SWS_COMTYPE_91005]
data transfer
Table 6.1: RequirementsTracing
7 Functional specification
8 API specification
8.1.1 PduIdType
c()
[SWS_Comtype_00006] dVariables of this type serve as a unique identifier of a PDU
within a software module or a set thereof, and also for interaction of two software
modules where the PduId of the corresponding target module is being used for refer-
encing.c(SRS_Com_02043, SRS_Com_02045, SRS_Com_02095)
[SWS_Comtype_00007] dIn order to be able to perform table-indexing within a soft-
ware module, variables of this type shall be zero-based and consecutive.
There might be several ranges of PduIds in a module, one for each type of operation
performed within that module (e.g. sending and receiving).c(SRS_Com_02043, SRS_-
Com_02045, SRS_Com_02095)
[SWS_Comtype_00014] dPduIdmax, the maximum number of a PduId range, is the
number -1 of PDUs dealt with in the corresponding type of operation within that mod-
ule.c(SRS_Com_02043, SRS_Com_02045, SRS_Com_02095)
8.1.2 PduLengthType
c()
[SWS_Comtype_00010] dVariables of this type serve as length information of a PDU.
The length information is provided in number of bytes.c(SRS_Com_02043, SRS_-
Com_02045, SRS_Com_02095)
[SWS_Comtype_00017] dPduLengthmax, the maximum length of a Pdu, is the length
of the largest (possibly segmented) PDU to be sent by the ECU.c(SRS_Com_02043,
SRS_Com_02045, SRS_Com_02095)
8.1.3 PduInfoType
4
Type uint8*
Comment Pointer to the SDU (i.e. payload data) of the PDU. The type of this
pointer depends on the memory model being used at compile time.
MetaDataPtr
Type uint8*
Comment Pointer to the meta data (e.g. CAN ID, socket ID, diagnostic addresses)
of the PDU, consisting of a sequence of meta data items. The length
and type of the meta data items is statically configured for each PDU.
Meta data items with more than 8 bits use platform byte order.
SduLength
Type PduLengthType
Comment Length of the SDU in bytes.
Description Variables of this type shall be used to store the basic information about a PDU of any type,
namely a pointer variable pointing to its SDU (payload), a pointer to Meta Data of the PDU, and
the corresponding length of the SDU in bytes.
Available via ComStack_Types.h
c()
8.1.4 PNCHandleType
c()
8.1.5 TPParameterType
c()
8.1.6 BufReq_ReturnType
c()
8.1.7 TpDataStateType
c()
8.1.8 RetryInfoType
c()
8.1.9 NetworkHandleType
c()
8.1.10 CbkHandleIdType
c(SRS_Com_02114)
8.1.11 TimeTupleType
Elements timestampClockValue
Type TimeStampType
Comment Value of the clock, which is used of ingress/egress timestamping
disciplinedClockValue
Type TimeStampType
Comment Value of the adjustable HW clock
timeQuality
Type TimeStampQualType
Comment Status of time tuple
Description The Time Tuple represents the clock values of two related HW clocks
• the value of the clock used for timestamping of frames
• and the corresponding value of the adjustable HW clock, derived by cross-timestamping
Tags: atp.Status=draft
Available via ComStackTypes.h
c(SRS_Eth_00167, SRS_Eth_00105)
8.1.12 TimeStampType
Elements nanoseconds
Type uint32
Comment Nanoseconds part of the time
seconds
Type uint32
Comment 32 bit LSB of the 48 bits Seconds part of the time
secondsHi
Type uint16
Comment 16 bit MSB of the 48 bits Seconds part of the time
5
4
Description Variables of this type are used for expressing time stamps including relative time and absolute
calendar time. The absolute time starts at 1970-01-01.
Value range of Seconds part:
• 0 .. (2 48 -1), i.e. 0 to 3257812230d [0xFFFF FFFF FFFF]
c(SRS_Eth_00105)
8.1.13 TimeStampQualType
c(SRS_Eth_00105)
8.1.14 ListElemStructType
4
Type ListElemStructType*
Comment Pointer to next list element
Description This type defines one element of a single linked list. Each element represents on part of an
associated data block. The data block could form for example an Ethernet frame. Each element
addresses a data location, the data length and a pointer to the next element. The last node (tail)
has NextListElemPtr set to NUL_PTR. The re-construction process of a data block (e.g. Ethernet
frame) is performed by traversing from the first data element (head) to the last data element (tail).
The single linked list is linked in network order (big-endian). Thus, the head element represents
the most significiant part of the data block (e.g. Ethernet frame)
Tags: atp.Status=draft
Available via ComStack_Types.h
c(SRS_BSW_00441, SRS_Eth_00172)
9 Sequence diagrams
Not applicable.
10 Configuration specification