Communication Stack Types (ComStack_Types)

comstack 모듈은 ComStack_Types.h을 통해 Classic 통신 스택의 모든 계층이 PDU를 어드레싱하고 교환하는 데 사용하는 공통 타입을 제공합니다. 핸들로서의 PduIdType, 길이로서의 PduLengthType, 페이로드 포인터, 메타데이터 포인터 및 길이를 포함하는 PduInfoType입니다([SWS_COMTYPE_00011]). 전송 프로토콜은 StartOfReception, CopyRxData 및 CopyTxData를 통해 큰 PDU를 세그먼트 단위로 복사합니다. 버퍼 상태는 BufReq_ReturnType로 보고하는 반면, RetryInfoType은 확인 및 재시도를 제어합니다([SWS_COMTYPE_00012]). 가장 중요한 제약 조건: PduIdType 및 PduLengthType의 너비는 EcuC 구성에 따라 달라지며 생성됩니다.

자세히 ›

모듈 comstack은 Classic 통신 스택의 공통 타입 세트를 정의합니다. 여기에는 PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType, RetryInfoType와 채널 및 서브네트워크 식별자가 포함되며, 모두 ComStack_Types.h을 통해 사용할 수 있습니다([SWS_COMTYPE_00011], [SWS_COMTYPE_00038]). 버스 인터페이스, 전송 프로토콜, PduR, 진단 모듈 및 RTE는 동일한 타입을 사용하며, RTE는 이를 명시적으로 임포트합니다(SWS RTE 833쪽).

컨텍스트 다이어그램: EcuC 구성을 통해 크기가 결정되는, 모든 계층을 위한 단일 타입 세트. 출처: [SWS_COMTYPE_00005], SWS RTE 833쪽

핸들과 길이는 구성에 따라 달라집니다. PduIdType은 uint8 또는 uint16이고, PduLengthType은 uint8, uint16 또는 uint32이며, 둘 다 EcuC 구성에서 생성됩니다([SWS_COMTYPE_00005], [SWS_COMTYPE_00008]). 각 제공 모듈은 자체 핸들 ID를 스스로 선택합니다. 이는 API별로만 고유하면 되며, PduR이 라우팅 경로를 따라 이를 변환합니다(ECU Configuration 156쪽).

PduInfoType은 페이로드 포인터, 메타데이터 포인터 및 길이를 묶습니다. 이를 통해 구조체는 전송 요청, 수신 표시 및 Trigger Transmit을 전달합니다. 큰 PDU는 부분 단위로 복사됩니다. 전송 프로토콜은 PduR을 통해 상위 계층의 CopyTxData을 반복적으로 호출합니다(SWS PduR 109쪽). 수신은 StartOfReception으로 시작하여 CopyRxData로 계속됩니다.

시퀀스 다이어그램: 전송 프로토콜이 루프 내에서 DCM으로부터 전송 데이터를 가져옵니다. 확인은 마지막에 뒤따릅니다. 출처: SWS PduR 109쪽

오류 및 병목 현상은 BufReq_ReturnType이 보고합니다([SWS_COMTYPE_00012]):

• BUFREQ_E_BUSY: 일시적으로 버퍼가 없거나 데이터가 너무 적음. 호출을 반복할 수 있습니다.
• BUFREQ_E_OVFL: 필요한 길이의 버퍼가 없음.
• BUFREQ_E_NOT_OK: 중단.

TP 전송 시 확인 및 재시도는 오프셋 TxTpDataCnt를 포함한 TP_DATACONF, TP_CONFPENDING 및 TP_DATARETRY을 사용하여 RetryInfoType이 제어합니다([SWS_COMTYPE_00027], [SWS_COMTYPE_00037]).

추가 식별자 타입이 세트를 보완합니다. NetworkHandleType(uint8)은 통신 채널을 나타냅니다. TPParameterType는 수정을 위해 STmin, Block Size 또는 대역폭 제어를 선택합니다([SWS_COMTYPE_00031]). PNCHandleType는 R20-11에서 uint8로부터 파생되며([SWS_COMTYPE_00036]), R23-11 버전에서는 이와 다르게 uint16을 명시합니다(SWS ComStackTypes 17쪽).

자세히 ›

역할: 통신 스택의 공통 타입 세트

모듈 comstack은 자체 서비스를 제공하지 않습니다. 이 모듈은 Classic 통신 스택의 모듈들이 서로 통신하는 데 사용하는 데이터 타입을 정의합니다. 여기에는 PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType, TpDataStateType, RetryInfoType, TPParameterType, NetworkHandleType 및 PNCHandleType가 포함됩니다. 이들은 ComStack_Types.h을 통해 사용할 수 있습니다([SWS_COMTYPE_00011], [SWS_COMTYPE_00037], [SWS_COMTYPE_00038]). 해석: 따라서 모듈 자체에는 런타임 동작이 없습니다. 질문 Q-766338989232e06a (열림) 동작 순서, 상태 및 오류 반응은 인터페이스에서 이러한 타입을 사용하는 모듈에서 비로소 발생합니다.

따라서 시스템 경계는 전체 스택을 가로질러 이어집니다. 동일한 타입을 사용하는 대상:

• CanIf와 같은 버스 인터페이스 및 CanTp와 같은 전송 프로토콜(SWS CanIf 87쪽),
• PDU Router 및 DCM과 같은 진단 모듈(SWS PduR 109쪽),
• SecOC(SWS SecOC 110쪽),
• ComStack_Types.h에서 BufReq_ReturnType, PduIdType, PduInfoType, PduLengthType 및 RetryInfoType를 명시적으로 임포트하는 RTE(SWS RTE 833쪽).

컨텍스트 다이어그램: 버스 인터페이스부터 RTE까지 모든 계층이 ComStack_Types.h의 동일한 타입 세트를 기반으로 합니다. 그 크기는 EcuC 구성에서 생성됩니다. 출처: [SWS_COMTYPE_00005], SWS RTE 833쪽, SWS PduR 33쪽, SWS ComM 171쪽

PDU 핸들 및 길이: PDU의 식별자 및 크기

PduIdType은(는) 0…<PduIdmax> 범위의 0부터 시작하는 정수입니다. 너비(uint8 또는 uint16)는 단일 소프트웨어 모듈이 관리하는 최대 PDU 수에 따라 달라집니다. 생성기 툴은 가상 EcuC 계층의 ComStack_Cfg.h에 구성된 값으로부터 이를 생성합니다([SWS_COMTYPE_00005]). 관련 파라미터 PduIdTypeEnum은(는) 다음과 같은 규칙을 정의합니다. 256개를 초과하는 PDU를 처리하는 모듈이 없는 한 UINT8(으)로 충분하며, 그렇지 않은 경우에는 UINT16이(가) 필요합니다(ECU Configuration 153쪽).

유사하게 PduLengthType은(는) 구성에 따라 uint8, uint16 또는 uint32(으)로 구현됩니다. 기준이 되는 것은 ECU가 전송하는 PDU의 최대 길이입니다([SWS_COMTYPE_00008]). 또한 전송 프로토콜은 EcuC로부터 길이를 도출합니다. CanTp는 EcuC 파라미터 PduLength로부터 N-PDU의 최대 전송 길이를 결정합니다(SWS CanTp 60쪽).

스택의 API는 두 가지 요소를 결합합니다. 즉, PDU 데이터 버퍼에 대한 포인터와 이 포인터가 어느 PDU에 속하는지 정의하는 핸들 ID입니다. 핸들 ID의 값은 제공 모듈이 자유롭게 선택합니다. 따라서 동일한 PDU가 ID 5로 Com에서 PduR로 전달되고, PduR에서 ID 19로 CanIf에 전달될 수 있습니다. ID는 해당 API의 유효 범위 내에서만 고유하면 됩니다(ECU Configuration 156쪽). 두 모듈이 동일한 PDU를 참조할 수 있도록 가상 모듈 구성 EcuC에는 모듈 독립적인 EcucPduCollection이(가) 존재합니다(ECU Configuration 154쪽). PduR은 소스 ID 및 대상 ID를 통해 라우팅 경로를 식별하고, ID를 변환하며, PduInfoType 값을 변경 없이 그대로 전달합니다(SWS PduR 33쪽).

협력 다이어그램: 각 인터페이스는 자체 핸들 ID를 가지며, 공통 PDU가 EcucPduCollection을 통해 참조되는 동안 PduR이 이를 변환합니다. 출처: ECU Configuration 156쪽, ECU Configuration 154쪽, SWS PduR 33쪽

PduInfoType: 단일 구조체 내 페이로드, 메타데이터 및 길이

PduInfoType은(는) 세 가지 요소를 묶습니다([SWS_COMTYPE_00011]):

• SduDataPtr은(는) 페이로드 데이터를 가리킵니다.
• MetaDataPtr은(는) CAN-ID, 소켓 ID 또는 진단 주소와 같은 메타데이터를 가리킵니다. 이들의 길이와 타입은 PDU별로 정적으로 구성되며, 8비트를 초과하는 요소는 플랫폼 바이트 순서로 배치됩니다.
• PduLengthType 타입의 SduLength은(는) 바이트 단위의 SDU 길이를 지정합니다.

동일한 구조체가 여러 상호작용 형태를 지원합니다:

• 전송 요청: <Mod>_Transmit(TxPduId, const PduInfoType*)은(는) 길이, 데이터 포인터 및 메타데이터 포인터를 전달하고 E_OK 또는 E_NOT_OK을(를) 반환합니다(SWS CanIf 87쪽).
• 수신 지시: <Mod>_RxIndication(RxPduId, const PduInfoType*). CanNm의 경우 데이터 포인터는 지시가 반환될 때까지만 유효합니다(SWS CanNm 73쪽).
• Trigger Transmit: PduInfoPtr은(는) 입력이자 출력입니다. 호출 시 SduLength에는 사용 가능한 버퍼 크기가 포함되고, 반환 시에는 복사된 데이터의 길이가 포함됩니다(SWS CanIf 107쪽). 이전 전송 요청에서 상위 계층은 길이만 전달하며, 이때 SduDataPtr은(는) NULL을 가리킵니다(SWS CanIf 158쪽).
• TP 복사 인터페이스: 반환값 BufReq_ReturnType을(를) 갖는 StartOfReception, CopyRxData 및 CopyTxData(SWS PduR 93쪽).

트랜스포트 프로토콜 버퍼: 직접 전달 대신 세그먼트 단위 복사

대형 PDU는 통째로 전달되지 않습니다. 송신측은 데이터를 조각 단위로 가져옵니다. DCM이 PduR을 통해 CanTp_Transmit을(를) 트리거합니다. 이후 CanTp가 PduR_CanTpCopyTxData을(를) 반복적으로 호출하며, 이는 Dcm_CopyTxData(으)로 전달됩니다. 마지막에는 PduR_CanTpTxConfirmation 및 Dcm_TpTxConfirmation이(가) 위치합니다(SWS PduR 109쪽). CopyTxData의 매개변수에는 다음이 적용됩니다:

• info은(는) 대상 버퍼와 복사할 바이트 수를 제공합니다.
• 0 값의 SduLength은(는) retry 매개변수의 상태 변경만 알리거나 사용 가능한 데이터 양을 조회하며, 이때 SduDataPtr은(는) NULL_PTR일 수 있습니다(SWS PduR 93쪽).
• availableDataPtr은(는) 남아 있는 전송 데이터를 보고합니다. FrIsoTp와 같이 동적 페이로드 길이를 갖는 TP 모듈은 이를 기준으로 후속 Consecutive Frame을 측정합니다(SWS LdCom 34쪽).

시퀀스 다이어그램: TP 전송 시 트랜스포트 프로토콜은 루프 내에서 PduR을 통해 상위 계층으로부터 데이터를 가져오며, 확인(Confirmation)은 마지막 세그먼트 이후에야 이어집니다. 출처: SWS PduR 109쪽, SWS PduR 93쪽, [SWS_COMTYPE_00012]

수신은 세 단계로 진행됩니다:

1. StartOfReception이(가) 연결을 시작합니다. info은(는) 메타데이터와 함께 First Frame 또는 Single Frame의 데이터를 전달하거나, 둘 다 없는 경우 NULL_PTR입니다. TpSduLength은(는) 전체 길이를 지정합니다. 수신측은 bufferSizePtr을(를) 통해 비어 있는 버퍼를 보고하며, 트랜스포트 프로토콜은 이를 바탕으로 Block Size를 계산합니다(SWS PduR 92쪽).
2. 각 CopyRxData 호출은 I-PDU의 다음 조각을 전달하고 남은 버퍼 크기를 다시 기록합니다(SWS PduR 91쪽).
3. RxIndication이 수신을 완료합니다.

TP-PDU가 추가로 게이트웨이되는 경우, DCM은 게이트웨이 처리에 대해 알지 못하므로 PduR이 이를 직접 버퍼링합니다(SWS PduR 112쪽).

시퀀스 다이어그램: TP 수신은 버퍼 협상으로 시작하여 세그먼트 단위로 계속되며 지시(Indication)로 끝납니다. 출처: SWS PduR 112쪽, SWS PduR 92쪽, SWS PduR 91쪽

확인 및 재시도: RetryInfoType 및 TpDataStateType

RetryInfoType은(는) 두 개의 필드를 포함합니다([SWS_COMTYPE_00037]):

• TpDataState은(는) TP 버퍼의 상태를 설명합니다.
• TxTpDataCnt은(는) 현재 위치로부터의 오프셋을 지정하여 재전송할 바이트 수를 결정합니다.

TpDataStateType은(는) 세 가지 값을 가집니다([SWS_COMTYPE_00027]):

• TP_DATACONF: 지금까지 복사된 모든 데이터가 확인되었으며 TP 버퍼에서 제거될 수 있습니다. 이번 호출에서 복사된 데이터는 여기서 제외됩니다.
• TP_DATARETRY: 오류를 복구하기 위해 이미 복사된 데이터를 다시 복사합니다. TxTpDataCnt은(는) 시작 오프셋을 지정합니다.
• TP_CONFPENDING: 지금까지 복사된 데이터는 오류 복구를 위해 TP 버퍼에 유지되어야 합니다.

retry 자체가 NULL_PTR인 경우, 데이터는 복사 직후 해제될 수 있습니다(SWS PduR 93쪽).

액티비티 다이어그램: CopyTxData 호출은 먼저 retry 매개변수를 평가한 후 복사할지 아니면 BUFREQ_E_BUSY를 반환할지 결정합니다. 출처: SWS PduR 93쪽, [SWS_COMTYPE_00027], [SWS_COMTYPE_00012]

J1939 트랜스포트 프로토콜 다이어그램은 이러한 상호작용을 구체적으로 보여줍니다:

• 블록마다 첫 번째 패킷은 TP_DATACONF(으)로 요청되고, 후속 패킷은 TP_CONFPENDING(으)로 요청됩니다.
• TP.DT이(가) 손실되면 전송은 해당 블록의 첫 번째 패킷부터 다시 시작됩니다. 이를 위해 TP_DATARETRY이(가) 설정되고, TxTpDataCnt에는 블록 시작 위치까지의 오프셋이 포함됩니다(SWS J1939Tp 55쪽).

모든 사용자가 이 매개변수를 평가하는 것은 아닙니다. LdCom의 경우 사양에 따르면 retry은(는) LdCom이나 그 상위 계층 어디에서도 처리되지 않습니다(SWS LdCom 34쪽).

시퀀스 다이어그램: 확인 상태를 포함한 블록 단위 전송 및 데이터 패킷 손실 시 블록 시작 위치로의 되돌아가기. 출처: SWS J1939Tp 55쪽, [SWS_COMTYPE_00027], [SWS_COMTYPE_00037]

채널, 서브네트워크 및 TP 매개변수

NetworkHandleType은(는) 0..255의 0 기반 범위를 갖는 uint8입니다. 이는 통신 채널의 식별자를 저장합니다([SWS_COMTYPE_00038]). 이후 릴리스의 예시:

• Bus Mirroring은 LIN 채널에 할당된 ComM 채널과 함께 LIN 프레임을 보고합니다(SWS Mirror 80쪽).
• J1939Dcm은 요청이 수신된 채널을 전달합니다(SWS J1939Dcm 67쪽).

PNCHandleType은(는) Partial Network Cluster의 식별자를 저장하며, R20-11에서는 uint8에서 파생됩니다([SWS_COMTYPE_00036]). 반면 R23-11의 해당 문서는 uint16을(를) 명시합니다(SWS ComStackTypes 17쪽). R20-11의 경우 요구사항이 적용됩니다. PNC 식별자의 사용 맥락은 예를 들어 ComM의 동기화된 PNC 종료에서 확인할 수 있습니다(SWS ComM 171쪽).

TPParameterType은(는) 값을 변경할 트랜스포트 프로토콜 매개변수를 지정합니다([SWS_COMTYPE_00031]):

• TP_STMIN: Separation Time,
• TP_BS: Block Size,
• TP_BC: FlexRay 트랜스포트 프로토콜의 대역폭 제어.

Block Size와 STmin은 예를 들어 FlexRay-AR 트랜스포트 프로토콜의 Flow Control 프레임에 나타납니다(SWS FrArTp 47쪽).

오류가 발생한 경우의 동작

버퍼 요청의 결과는 BufReq_ReturnType이(가) 설명합니다([SWS_COMTYPE_00012]):

• BUFREQ_OK (0): 성공.
• BUFREQ_E_NOT_OK (1): 버퍼에 접근할 수 없습니다.
• BUFREQ_E_BUSY (2): 일시적으로 사용 가능한 버퍼가 없습니다. 요청자는 일정 시간 동안 재시도해야 합니다.
• BUFREQ_E_OVFL (3): 필요한 길이의 버퍼를 제공할 수 없습니다.

인터페이스는 이러한 값들을 다음과 같이 매핑합니다:

• CopyTxData: 전송 데이터가 충분하지 않으면 아무것도 복사되지 않고 BUFREQ_E_BUSY이(가) 반환되며, 하위 계층은 호출을 재시도할 수 있습니다(SWS PduR 93쪽). DCM의 페이징 버퍼 흐름에서는 BUFREQ_E_BUSY이(가) 다음 페이지 준비와 번갈아 발생합니다(SWS DCM 481쪽).
• StartOfReception: BUFREQ_E_NOT_OK은(는) 연결을 거부하고 수신을 중단하며, bufferSizePtr은(는) 변경되지 않은 상태로 유지됩니다. BUFREQ_E_OVFL은(는) 필요한 길이의 버퍼가 준비되지 않아 중단합니다. 요청된 크기의 버퍼가 없는 BUFREQ_OK의 경우 0의 버퍼 크기가 보고됩니다(SWS DCM 273쪽).
• CopyRxData: BUFREQ_E_NOT_OK은(는) 오류로 인해 아무것도 복사되지 않았음을 의미합니다(SWS PduR 91쪽).
• TP의 전송 오류: 복구는 오프셋 TxTpDataCnt을(를) 사용하는 TP_DATARETRY을(를) 통해 진행됩니다([SWS_COMTYPE_00027]).
• TriggerTransmit: E_NOT_OK은(는) 아무것도 복사되지 않았음을 의미합니다. 이 경우 PduInfoPtr은(는) NULL이거나 유효하지 않을 수 있으므로 사용해서는 안 됩니다(SWS CanIf 107쪽).

추가 검사는 이를 사용하는 모듈이 직접 정의합니다. 예시:

• DoIP_SoAdTpCopyRxData은(는) 개발 오류 감지가 활성화된 경우 이전에 DoIP_Init이(가) 호출되었는지 확인합니다(SWS DoIP 77쪽).
• FrIf_Transmit은(는) FRIF_STATE_OFFLINE 상태에서 E_NOT_OK 값을 반환합니다(SWS FrIf 68쪽).
• 이러한 함수 중 다수는 서로 다른 PDU-ID에 대해서만 재진입 가능(reentrant)하며, 동일한 PDU-ID에 대해서는 그렇지 않습니다(SWS DoIP 75쪽).

더 자세한 증거

다음 개요는 주요 근거 자료들을 정리합니다([SWS_COMTYPE_00005]~[SWS_COMTYPE_00038]):

근거	분류
[SWS_COMTYPE_00005], [SWS_COMTYPE_00008]	EcuC에서 생성된 구성 종속적 PduIdType 및 PduLengthType 너비
[SWS_COMTYPE_00011]	메타데이터를 포함한 PduInfoType의 구조
[SWS_COMTYPE_00012]	모든 TP 버퍼 요청의 결과 코드
[SWS_COMTYPE_00027], [SWS_COMTYPE_00037]	TP 전송 시의 확인 및 재시도 로직
[SWS_COMTYPE_00031], [SWS_COMTYPE_00036], [SWS_COMTYPE_00038]	TP 매개변수 선택, PNC 및 채널 식별자
ECU Configuration S. 156	핸들 ID 개념: 모듈별 값 자유 선택 가능, API별 고유
SWS PduR S. 93, SWS PduR S. 92	TP 복사 인터페이스의 참조 시맨틱
SWS J1939Tp S. 55	재시도 처리 다이어그램(R20-11용으로도 식별됨)