Secure Onboard Communication (SecOC)

The synchronous function SecOC_Init serves to initialize the module SecOC and transitions it to the state SecOC_INIT upon successful completion [SWS_SecOC_00106]. The call is made via the interface from SecOC.h with the service ID 0x01 [SWS_SecOC_00106].

Parameters and Return Values

• Parameters: A pointer to a selected configuration structure of type SecOC_ConfigType is passed via the input parameter config [SWS_SecOC_00106].
• Return value: The function has no return value (void) [SWS_SecOC_00106].

Concurrency and Partitioning

The execution of SecOC_Init is specified as non-reentrant (Non Reentrant) [SWS_SecOC_00106].

Special requirements apply to systems with multiple partitions: If the module SecOC is assigned to multiple partitions (by distributing main functions such as SecOC_MainFunction across partitions), an init function can exist per partition [SWS_SecOC_00106]. Whether a central function SecOC_Init or separate functions per partition are provided is implementation-specific [SWS_SecOC_00106]. If partition-specific functions are offered, the implementation must prevent name collisions, for example by appending a suffix with the short name of the respective EcucPartition [SWS_SecOC_00106].

Usage and Semantics

The synchronous function SecOC_DeInit terminates the operation of secure on-board communication in the SecOC module and transitions it into the state SecOC_UNINIT [SWS_SecOC_00161]. The function is declared in header file SecOC.h and has service ID 0x05 as well as signature void SecOC_DeInit(void) [SWS_SecOC_00161]. It processes neither input nor output parameters and returns no value [SWS_SecOC_00161].

Buffer cleanup and state transition

Calling SecOC_DeInit discards all I-PDUs buffered in the module and removes them from the buffers [SWS_SecOC_00161]. If this data is still required after a restart of secured communication, it must be acquired again after calling SecOC_Init again [SWS_SecOC_00161].

Concurrency and Limitations

Fixed requirements and boundary conditions apply to the execution of deinitialization [SWS_SecOC_00161]:

• Non-reentrant: The interface is specified as non-reentrant (Non Reentrant) and therefore must not be executed concurrently [SWS_SecOC_00161].
• Sequence conditions: The module remains in the uninitialized state after the call, so that subsequent communication services unconditionally require calling SecOC_Init again [SWS_SecOC_00161].

use

The synchronous service function SecOC_IfTransmit serves to request the transmission of a PDU in the module SecOC [SWS_SecOC_00112]. It has the service ID 0x49 and is declared via the header file SecOC.h [SWS_SecOC_00112].

The function expects two input parameters [SWS_SecOC_00112]:

• TxPduId: The identifier of the PDU to be transmitted (type PduIdType).
• PduInfoPtr: A pointer to a structure of type PduInfoType that provides the data length as well as pointers to the PDU data and to metadata.

There are neither input/output nor pure output parameters [SWS_SecOC_00112].

Return Values and Error Handling

A status of type Std_ReturnType is returned as the synchronous return value [SWS_SecOC_00112]:

• E_OK: The transmission request was accepted [SWS_SecOC_00112].
• E_NOT_OK: The transmission request was not accepted [SWS_SecOC_00112].

In case of an error, the failure of the request is signaled immediately by E_NOT_OK; specific error codes for DET or DEM are not separately identified in the function specification [SWS_SecOC_00112].

Concurrency and Limitations

Regarding concurrency, the function is reentrant for different PDU IDs, but not reentrant for the same PDU ID [SWS_SecOC_00112].

The synchronous interface SecOC_TpTransmit with service ID 0x53 serves to request a PDU transmission in the module SecOC and is declared via header file SecOC.h [SWS_SecOC_91008]. It accepts the transmit request and initiates further processing within the module.

Usage and Interaction

As input parameters, the function expects the PDU identifier TxPduId and the pointer PduInfoPtr to a constant of type PduInfoType, which comprises details on the PDU length as well as pointers to the payload and metadata [SWS_SecOC_91008]. The functional interaction is determined by the configuration: if SecOCPduType is configured to SECOC_TPPDU, calling SecOC_TpTransmit triggers the actual transmission operation for an Authentic I-PDU [SWS_SecOC_00253].

Return Values and Concurrency

The result of the call is returned via Std_ReturnType: The value E_OK confirms that the transmit request was accepted successfully, whereas E_NOT_OK means that the request was rejected [SWS_SecOC_91008]. Regarding concurrency behavior, the function is implemented reentrantly for different PDU identifiers, but must under no circumstances be called reentrantly for the same TxPduId [SWS_SecOC_91008].

Interpretation: In practice, the rejection of a request with E_NOT_OK is likely attributable primarily to invalid pointer values in PduInfoPtr or to an already blocked or ongoing transmission of the same PDU. Question Q-4c6165f6330c4bc2 (open)

Usage and Call Context

The synchronous interface function SecOC_IfCancelTransmit requests the cancellation of an ongoing PDU transmission in a lower-layer communication module [SWS_SecOC_00113]. It is declared via the header file SecOC.h and has the service ID 0x4a [SWS_SecOC_00113]. Via the input parameter TxPduId of type PduIdType, that PDU is passed whose transmission is to be cancelled [SWS_SecOC_00113]. Additional input or output parameters do not exist [SWS_SecOC_00113].

Return Values and Execution

The result of the cancellation request is transmitted synchronously to the caller via the return value of type Std_ReturnType [SWS_SecOC_00113]:

• E_OK: The lower-layer target module has successfully executed the cancellation of the PDU transmission [SWS_SecOC_00113].
• E_NOT_OK: The cancellation request was rejected by the target module [SWS_SecOC_00113].

Since specific error codes or error notifications to development or diagnostic error detection (DET/DEM) are not specified for this function, only the return value serves for error detection [SWS_SecOC_00113].

Concurrency and Limitations

With regard to parallel calls, SecOC_IfCancelTransmit is reentrant for different PDU identifiers, but explicitly not reentrant for the same TxPduId [SWS_SecOC_00113]. Calling modules must therefore ensure through suitable synchronization that multiple instances do not initiate a transmission cancellation for the same PDU at the same time.

The synchronous function SecOC_TpCancelTransmit serves to request the cancellation of an ongoing PDU transmission in a lower-layer communication module [SWS_SecOC_91009]. It is declared via header file SecOC.h and has service ID 0x54 [SWS_SecOC_91009].

The identifier TxPduId of type PduIdType is passed as an input parameter, which uniquely identifies the transmit PDU to be cancelled [SWS_SecOC_91009]. The result of the cancellation request is reported synchronously via the return value of type Std_ReturnType [SWS_SecOC_91009]:

• E_OK: The cancellation of the transmission was successfully executed by the target module [SWS_SecOC_91009].
• E_NOT_OK: The cancellation was rejected by the target module [SWS_SecOC_91009].

Regarding concurrency, the function is reentrant for different PDU IDs, but explicitly not reentrant for the same PDU ID [SWS_SecOC_91009]. Callers must therefore ensure that concurrent calls with an identical TxPduId are avoided. Since the payload does not define specific error codes for the Default Error Tracer (DET) or Diagnostic Event Manager (DEM), immediate error handling in the caller context is likely to take place primarily via evaluation of the return value E_NOT_OK [SWS_SecOC_91009]. Question Q-c1f907444c4ca270 (open)

The synchronous function SecOC_TpCancelReceive serves to request the cancellation of an ongoing reception process of a PDU in a lower-layer transport protocol module [SWS_SecOC_91010]. Via the sole input parameter RxPduId, the unique identification of the PDU to be cancelled is passed to the module [SWS_SecOC_91010].

Return Values and Execution

Feedback on the success of the cancellation is provided immediately via the return value of type Std_ReturnType [SWS_SecOC_91010]:

• E_OK: The cancellation of the reception was successfully executed by the destination module [SWS_SecOC_91010].
• E_NOT_OK: The cancellation was rejected by the destination module [SWS_SecOC_91010].

Specific error codes, development errors (DET) or production errors (DEM) are not specified in the specification data of the function. Interpretation: The "destination module" mentioned in the specification likely refers to the lower-layer transport protocol module to which the cancellation request is directed. Question Q-bce6ed77e65a6b9b (open)

Concurrency and Integration

Regarding concurrency, the function is declared as non-reentrant (Non Reentrant) [SWS_SecOC_91010]. Therefore, no concurrent or interrupting calls must occur; calling software entities must coordinate accesses accordingly. The function has service ID 0x4c and is declared via header file SecOC.h [SWS_SecOC_91010].

The synchronous function SecOC_VerifyStatusOverride enables the application to specifically override the verification and forwarding behavior of SecOC in order to accept or drop I-PDUs regardless of the actual verification result, as well as to control error handling [SWS_SecOC_00122].

Parameters and call context

Addressing depends on the module configuration: If SecOCOverrideStatusWithDataId is set to FALSE, Value ID identifies the Freshness Value of all assigned Secured I-PDUs; if the parameter is set to TRUE, Value ID directly designates the Data ID of a Secured I-PDU [SWS_SecOC_00122]. The desired behavior and its temporal validity are defined via overrideStatus. The counter numberOfMessagesToOverride determines the number of verifications to be sequentially overridden, but is only evaluated for the modes SECOC_OVERRIDE_DROP_UNTIL_LIMIT, SECOC_OVERRIDE_SKIP_UNTIL_LIMIT, and SECOC_OVERRIDE_PASS_UNTIL_LIMIT [SWS_SecOC_00122].

For the modes SECOC_OVERRIDE_PASS_UNTIL_NOTICE, SECOC_OVERRIDE_SKIP_UNTIL_LIMIT, SECOC_OVERRIDE_PASS_UNTIL_LIMIT, and SECOC_OVERRIDE_SKIP_UNTIL_NOTICE, SecOCEnableForcedPassOverride must mandatorily be configured to TRUE [SWS_SecOC_00122].

Concurrency and return values

The function is reentrant for different Freshness Value IDs, but non-reentrant for the same Freshness Value ID [SWS_SecOC_00122]. A successful call returns E_OK, whereas a failed call is acknowledged with E_NOT_OK [SWS_SecOC_00122].

Interaction during Verification

A set override intervenes in the processing logic of the receive path:

• If separate Authentic and Cryptographic I-PDUs are used (SecOCRxSecuredPduCollection), overrideStatus controls the behavior as soon as both PDUs have been received with a matching Message Linker [SWS_SecOC_00203], [SWS_SecOC_00206], [SWS_SecOC_00211].
• Even if SecOCAuthenticationBuildAttempts or SecOCAuthenticationVerifyAttempts is exceeded, as well as in the event of unrecoverable errors (such as KEY_FAILURE), the verification result and PDU forwarding are primarily governed by overrideStatus [SWS_SecOC_00240], [SWS_SecOC_00241].

use

The synchronous function SecOC_SendDefaultAuthenticationInformation ([SWS_SecOC_91013]) allows specifically enabling or disabling the transmission of unauthenticated I-PDUs to lower layers. The service is declared via SecOC.h and uses the flag send Default Authentication Information to control the behavior for a specific Freshness Value ID. Upon a successful request, the function returns E_OK, otherwise E_NOT_OK ([SWS_SecOC_91013]).

Interaction and Error Behavior

The function is optional and only available if the parameter SecOCDefaultAuthenticationInformationPattern is configured ([SWS_SecOC_91013]). The behavior takes effect when the generation of authentication information fails—for example, if the counter SecOCAuthenticationBuildAttempts has been reached, the freshness function returns E_NOT_OK, or the calculation of the authenticator returns an unrecoverable error such as KEY_FAILURE or E_NOT_OK ([SWS_SecOC_91013], [SWS_SecOC_00229]):

• If the service was called with TRUE, the module uses the pattern SecOCDefaultAuthenticationInformationPattern for all bytes of the freshness value and authenticator to construct the authentication information, and does not abort the transmit request ([SWS_SecOC_91013], [SWS_SecOC_00229]).
• If the service is not available or was called with FALSE for the ID in question, the module removes the authentic I-PDU from its internal buffer and aborts the transmission ([SWS_SecOC_91013], [SWS_SecOC_00229]).

Concurrency

The function is non-reentrant for the same Freshness Value ID, but may be called reentrantly for different IDs ([SWS_SecOC_91013]).

Usage and Call Context

The synchronous interface function SecOC_RxIndication (service ID 0x42) is called by an underlying communication interface module to report the reception of a PDU to the SecOC module [SWS_SecOC_00124]. Upon the call, RxPduId identifies the received PDU, while a pointer to the PDU information is passed via PduInfoPtr. This structure contains the payload length SduLength, the buffer pointer SduDataPtr, and associated metadata of the PDU [SWS_SecOC_00124]. The function has no return value and is declared via the header file SecOC.h [SWS_SecOC_00124].

Error Handling and Length Check

A specific error check applies to the reception of I-PDUs with a static configuration (secured, authentic, or cryptographic I-PDUs with the EcuC parameter DynamicLength equal to FALSE): If the received length is less than the configured length, the SecOC module silently drops the I-PDU [SWS_SecOC_00268]. Interpretation: Since the function returns void, erroneous or incomplete I-PDUs are likely dropped without feedback to the calling layer. Question Q-6e9a176383e1983b (open)

Concurrency and Limitations

The execution of SecOC_RxIndication is reentrant for calls with different PDU IDs, but explicitly non-reentrant for the same PDU ID [SWS_SecOC_00124]. Calling modules must therefore ensure through their execution control that concurrent calls with an identical RxPduId are prevented.

The function SecOC_TpRxIndication serves as a callback interface of the SecOC module and is called after the reception of an I-PDU via the transport protocol API (TP API) [SWS_SecOC_00125]. Via this notification, SecOC learns whether the transmission of the I-PDU was successfully completed or a transmission error occurred [SWS_SecOC_00125].

The interface has the following parameters and properties according to [SWS_SecOC_00125]:

• id (PduIdType): Identification of the received I-PDU for which the reception event is signaled.
• result (Std_ReturnType): Result of the PDU reception, indicating whether the transport was successful or failed.
• Return value: None (void); the function returns no status value to the caller.

With regard to concurrency, SecOC_TpRxIndication is specified as reentrant (Reentrant) and operates synchronously (Synchronous) under service ID 0x45 [SWS_SecOC_00125]. The declaration is provided via the header file SecOC.h [SWS_SecOC_00125]. Interpretation: The call is likely to typically be triggered by a transporting layer such as the PduR or a TP module as soon as the PDU data transfer is completely finished. Question Q-6448356fa3609004 (open)

No specific error codes, DET checks, or DEM error entries are defined in the specification for this function [SWS_SecOC_00125]. Error handling is limited to passing the transport result via parameter result, based on which the SecOC module decides whether the received data is further processed or discarded.

Usage and Call Context

The function SecOC_TxConfirmation is called by the lower-layer communication interface module to confirm to the SecOC module synchronously the successful transmission or failure of sending a PDU [SWS_SecOC_00126]. The service has no return value (void), is declared in the header file SecOC.h, and is listed under service ID 0x40 [SWS_SecOC_00126].

The function expects two input parameters [SWS_SecOC_00126]:

• TxPduId: Identifier of the transmitted PDU (type PduIdType).
• result: Result of the transmission (type Std_ReturnType) with the values E_OK upon successful transmission or E_NOT_OK upon failed transmission.

Error Handling and Concurrency

Transmission errors of the lower layers are passed directly via the argument result with the value E_NOT_OK [SWS_SecOC_00126]. Regarding concurrency, the call is reentrant for different PDU IDs, but defined as non-reentrant for the same PDU ID [SWS_SecOC_00126]. The concrete execution context is likely to be at task or interrupt level of the lower module, as the specification provides no restriction in this regard. Question Q-8bb15b92df860fc1 (open)

Interaction and Forwarding

If configuration SecOCTxSecuredPduCollection is used, SecOC does not forward the confirmation to the upper layer until SecOC_TxConfirmation has been called for both the Authentic I-PDU and the Cryptographic I-PDU [SWS_SecOC_00270].

A strict condition applies to the result status to the upper layer: Parameter result of the forwarded call is E_OK only if the confirmations for both partial PDUs were each passed with E_OK; otherwise, the status is E_NOT_OK [SWS_SecOC_00270].

The function SecOC_TpTxConfirmation serves to confirm an I-PDU transmitted over the network and informs the SecOC module synchronously about the success or failure of the transmission process [SWS_SecOC_00152].

Usage and Parameters

The call occurs after the physical transmission of an I-PDU on the network [SWS_SecOC_00152]. The interface is declared in header SecOC.h and has service ID 0x48 [SWS_SecOC_00152]. It takes two input parameters and provides no return value (void):

• id (type PduIdType): Unique identification of the transmitted I-PDU [SWS_SecOC_00152].
• result (type Std_ReturnType): Indicates whether the transmission on the network was successful or failed [SWS_SecOC_00152].

Concurrency and Execution

According to the specification, the function is to be executed synchronously and is fully reentrant (Reentrant) [SWS_SecOC_00152]. It can therefore be called in parallel for different or the same I-PDUs, provided the call context requires it.

Error Handling and Interaction

Specific DET or DEM error codes are not reported in the payload. Error handling regarding the transmission is primarily carried out via the passed status parameter result, which informs the module whether the transmission succeeded [SWS_SecOC_00152]. Interpretation: The function likely serves primarily as a callback interface for lower transport protocol instances to report back the transmission status after completion of large or fragmented transmissions. Question Q-a2957406d76ee65f (open)

The synchronous interface SecOC_TriggerTransmit serves to copy an SDU requested for transmission [SWS_SecOC_00127]. The SDU is addressed via the parameter TxPduId, while PduInfoPtr provides the pointer to the destination buffer (SduDataPtr) as well as buffer size specifications (SduLength) as an input and output parameter [SWS_SecOC_00127].

Usage and Data Passing

Within the function, the module checks whether the data to be provided fits into the buffer size reported via PduInfoPtr->SduLength [SWS_SecOC_00127]:

• If the data fits, the function copies it into the buffer PduInfoPtr->SduDataPtr, enters the actual number of copied bytes in PduInfoPtr->SduLength, and returns E_OK [SWS_SecOC_00127].
• If the memory space is insufficient, the function returns E_NOT_OK without modifying the content of PduInfoPtr [SWS_SecOC_00127].

Error Handling and Concurrency

If E_NOT_OK is returned, no SDU data was copied. In this case, the caller must not evaluate or use PduInfoPtr, as it may contain a NULL pointer or point to invalid data [SWS_SecOC_00127]. The function is reentrant for different PDU IDs, but non-reentrant for the same TxPduId [SWS_SecOC_00127]. The service is available via the header SecOC.h [SWS_SecOC_00127].

Usage and Semantics

The synchronous function SecOC_CopyRxData is called to pass received data of an I-PDU segment (N-PDU) to the upper layer [SWS_SecOC_00128]. Each call provides the respective next part of the I-PDU data [SWS_SecOC_00128]. The service has the service ID 0x44 and is available via the header file SecOC.h [SWS_SecOC_00128].

Parameters and Buffer Query

The parameter id uniquely identifies the received I-PDU [SWS_SecOC_00128]. The source buffer SduDataPtr and the number of bytes to be copied SduLength are provided via the pointer info [SWS_SecOC_00128]. Passing SduLength with the value 0 serves to query the receive buffer currently available in the upper module; in this case, SduDataPtr may be passed as NULL_PTR [SWS_SecOC_00128]. The remaining buffer size is written to the location referenced by bufferSizePtr after copying [SWS_SecOC_00128].

Return Values and Concurrency

The function returns the status BufReq_ReturnType [SWS_SecOC_00128]. Upon successful data transfer, it reports BUFREQ_OK [SWS_SecOC_00128]. If an error occurs, no data is copied and the function returns BUFREQ_E_NOT_OK [SWS_SecOC_00128]. SecOC_CopyRxData is specified as reentrant [SWS_SecOC_00128].

Usage and Semantics

The synchronous and reentrant function SecOC_CopyTxData is called to retrieve transmit data for an I-PDU segment (N-PDU) [SWS_SecOC_00129]. The destination buffer SduDataPtr and the amount of bytes to be requested SduLength are passed via the parameter info [SWS_SecOC_00129]. A call with SduLength equal to 0 enables querying the available amount of data or reporting status changes via the parameter retry; in this case, SduDataPtr may be a NULL_PTR [SWS_SecOC_00129]. Via availableDataPtr, the module reports back the remaining data amount in the transmit buffer [SWS_SecOC_00129].

Retry and Error Handling

The buffer and retry behavior is controlled via retry [SWS_SecOC_00129]:

• If retry is a NULL_PTR, copied data may be released immediately [SWS_SecOC_00129].
• In the case of TP_CONFPENDING, previously copied data remains in the buffer for error recovery [SWS_SecOC_00129].
• TP_DATACONF confirms all data transmitted prior to this call for buffer release [SWS_SecOC_00129].
• TP_DATARETRY causes already transmitted data to be copied again starting from the byte offset defined by TxTpDataCnt [SWS_SecOC_00129].

As return values, the function provides BUFREQ_OK upon successful copy operation, BUFREQ_E_BUSY if insufficient transmit data is temporarily available (allowing the caller to retry the attempt later), or BUFREQ_E_NOT_OK in case of general failure [SWS_SecOC_00129].

Concurrency

The function is designed to be reentrant, so that concurrent calls for different PDU instances are likely permissible [SWS_SecOC_00129]. Question Q-6420f2ca317efcb4 (open)

use

The synchronous and reentrant function SecOC_StartReception is called at the beginning of receiving an N-SDU to check the connection and provide the necessary receive buffer [SWS_SecOC_00130]. The N-SDU can be received as a single frame (SF) or fragmented across multiple N-PDUs (First Frame, FF, followed by Consecutive Frames, CF) [SWS_SecOC_00130]. The declaration is available via the header SecOC.h [SWS_SecOC_00130].

Parameters and Buffer Query

• id: Identification of the received I-PDU [SWS_SecOC_00130].
• info: Pointer to a PduInfoType structure with the payload of the first or single frame as well as metadata; if neither data nor metadata is available, NULL_PTR is passed [SWS_SecOC_00130].
• TpSduLength: Total length of the N-SDU to be received. If the parameter is passed with the value 0, the service returns the currently maximum available buffer size [SWS_SecOC_00130].
• bufferSizePtr: Output parameter for the available receive buffer, which is used by the transport protocol module to calculate the Block Size (BS) [SWS_SecOC_00130].

Return Values and Error Handling

• BUFREQ_OK: The connection was accepted and reception continues; bufferSizePtr indicates the available buffer size (if no buffer of the required size is available, 0 is reported) [SWS_SecOC_00130].
• BUFREQ_E_NOT_OK: The connection was rejected and reception is aborted; bufferSizePtr remains unchanged [SWS_SecOC_00130].
• BUFREQ_E_OVFL: No buffer of the required length can be provided; reception aborts and bufferSizePtr remains unchanged [SWS_SecOC_00130].

The synchronous interface function SecOC_GetRxFreshness serves the SecOC module to query the current freshness value for a received secured I-PDU [SWS_SecOC_91007]. The call occurs as soon as the secured PDU has been completely received and SecOCQueryFreshnessValue == CFUNC as well as SecOCUseAuthDataFreshness == FALSE are specified for its configuration [SWS_SecOC_00247], [SWS_SecOC_00250].

The function is reentrant [SWS_SecOC_91007] and passes or expects the following parameters:

• SecOCFreshnessValueID: Identifier of the freshness value to be queried [SWS_SecOC_91007].
• SecOCTruncatedFreshnessValue and SecOCTruncatedFreshnessValueLength: Pointer to the truncated freshness value contained in the received PDU and its length in bits [SWS_SecOC_91007].
• SecOCAuthVerifyAttempts: Number of previous verification attempts since PDU reception (starting with 0, incremented with each failed attempt) [SWS_SecOC_91007].
• SecOCFreshnessValue and SecOCFreshnessValueLength: Output buffer for the determined freshness value and input/output parameter for its bit length [SWS_SecOC_91007].

The result of the query controls further processing in SecOC:

• E_OK: The freshness value was successfully provided and is used for the authenticator calculation [SWS_SecOC_91007].
• E_NOT_OK: The provision failed due to general problems or an invalid freshness ID [SWS_SecOC_91007].
• E_BUSY: The information is temporarily unavailable [SWS_SecOC_91007]. In this case, SecOC increments the Authentication-Build-Counter and does not perform any attempt for authentication verification [SWS_SecOC_00236].

The synchronous and reentrant function SecOC_GetRxFreshnessAuthData is called by the SecOC module to determine the current freshness value for authentication when secured I-PDUs are completely received ([SWS_SecOC_91006], [SWS_SecOC_00246]). The call occurs specifically when SecOCQueryFreshnessValue = CFUNC and SecOCUseAuthDataFreshness = TRUE are configured for the respective PDU configuration ([SWS_SecOC_00246], [SWS_SecOC_00249]).

Parameters and passed values

• Input data: The identifier SecOCFreshnessValueID, the truncated freshness value SecOCTruncatedFreshnessValue contained in the I-PDU including bit length SecOCTruncatedFreshnessValueLength, and the counter SecOCAuthVerifyAttempts, which is incremented upon failed attempts, are passed ([SWS_SecOC_91006]).
• Authentication data: A configured excerpt of the received PDU is optionally passed via SecOCAuthDataFreshnessValue and SecOCAuthDataFreshnessValueLength; start position and length are determined by SecOCAuthDataFreshnessStartPosition and SecOCAuthDataFreshnessLen ([SWS_SecOC_91006], [SWS_SecOC_00246]).
• Result data: The complete freshness value is provided via the output buffer SecOCFreshnessValue, whose bit length acts as inout parameter SecOCFreshnessValueLength ([SWS_SecOC_91006]).

Return Values and Error Handling

The function signals the success of the query with E_OK ([SWS_SecOC_91006]). If the freshness value cannot be provided due to general issues or an invalid freshness ID, it returns E_NOT_OK; in case of temporary unavailability, it returns E_BUSY ([SWS_SecOC_91006]). Interpretation: Since the function is interfaced as a C function via CFUNC, the implementation is likely to be performed by an external freshness management module. Question Q-01aa77b7235b9001 (open)

The synchronous and reentrant function SecOC_GetTxFreshness serves to provide the current freshness value for messages to be transmitted and is declared via the header SecOC.h [SWS_SecOC_91004]. According to [SWS_SecOC_00231], the SecOC module calls this function for a PDU if SecOCQueryFreshnessValue = CFUNC and SecOCProvideTxTruncatedFreshnessValue = FALSE are set in the configuration. Interpretation: Since SecOC executes the call under appropriate configuration, the function will likely need to be provided as a callout by an external component. Question Q-99a14f896ffddf5f (open)

The interface uses the following parameters [SWS_SecOC_91004]:

• SecOCFreshnessValueID (In): Numerical identifier of the requested freshness value.
• SecOCFreshnessValueLength (InOut): Passes or receives the bit length of the provided freshness value.
• SecOCFreshnessValue (Out): Pointer to the byte array for holding the freshness value in big-endian format, beginning with the most significant bits in the first byte.

The return value of type Std_ReturnType signals the result of the provision [SWS_SecOC_91004]:

• E_OK: The freshness value was provided successfully.
• E_BUSY: The freshness information temporarily cannot be provided.
• E_NOT_OK: The request failed because no value can be determined for the ID or in general.

The synchronous and reentrant function SecOC_GetTxFreshnessTruncData is called by the SecOC module to query both the full freshness value and the truncated freshness value (Truncated Freshness) for the Secured I-PDU to be transmitted during send operations (TX) [SWS_SecOC_91003]. The call occurs specifically when SecOCQueryFreshnessValue = CFUNC and SecOCProvideTxTruncatedFreshnessValue = TRUE are set for the PDU configuration [SWS_SecOC_00230].

The interface passes the following parameters [SWS_SecOC_91003]:

• SecOCFreshnessValueID (in): Identifier of the requested freshness value.
• SecOCFreshnessValue (out): Destination buffer for the current full freshness value.
• SecOCFreshnessValueLength (inout): Specifies the length of the provided freshness value in bits.
• SecOCTruncatedFreshnessValue (out): Optional buffer for the truncated freshness value embedded in the Secured I-PDU.
• SecOCTruncatedFreshnessValueLength (inout): Passes the configured length of the truncated freshness; the value can be adapted by the function as needed or kept unchanged.

As return value, the function returns E_OK upon successful provision, E_BUSY if the information is temporarily unavailable, or E_NOT_OK if provision fails due to general problems or specifically for the passed ID [SWS_SecOC_91003]. The declaration is available via the header SecOC.h [SWS_SecOC_91003].

use

The synchronous function interface SecOC_SPduTxConfirmation is used by the module SecOC to indicate that the transmission of a secured I-PDU has been initiated [SWS_SecOC_91005]. The function is declared in the header file SecOC.h and has no return value (void) [SWS_SecOC_91005].

As the only parameter, SecOCFreshnessValueID is passed as an input value (in) of type uint16 [SWS_SecOC_91005]. This parameter transports the identifier of the respective freshness value for the affected I-PDU [SWS_SecOC_91005]. No other input, output, or pass-through parameters (inout/out) are present in the interface [SWS_SecOC_91005].

Concurrency and Properties

The interface has the service ID 0x4d, operates synchronously, and is designed to be fully reentrant [SWS_SecOC_91005]. The reentrancy property permits parallel invocation in concurrent execution contexts [SWS_SecOC_91005]. Error notifications via DET or DEM as well as specific error codes are not provided in the interface specification [SWS_SecOC_91005].

Interpretation: Since SecOC calls this function to report the initiation of the PDU transmission, passing only the SecOCFreshnessValueID, the call is presumably intended for updating or confirming the freshness counter in an external component [SWS_SecOC_91005]. Question Q-f234a3c6e9b16362 (open)

Usage and Call Context

The function SecOC_MainFunctionRx handles the central authentication and verification processing of module SecOC for incoming messages in the receive path [SWS_SecOC_00171]. According to its interface specification, the function has the signature void SecOC_MainFunctionRx (void), has the service ID 0x06, expects no passing parameters, and returns no return value [SWS_SecOC_00171]. It is declared via the header file SchM_SecOC.h [SWS_SecOC_00171]; from this it can be deduced (interpretation) that its call occurs periodically by the BSW scheduler in the context of an operating system task. Question Q-d24cb58f541f6674 (open)

Instantiation and Configuration

In system configurations with multiple receive instances, a separate function instance according to the scheme SecOC_MainFunctionRx_<shortName> is implemented for each configured SecOCMainFunctionRx container [SWS_SecOC_00171]. Here, <shortName> corresponds to the short name of the container assigned in the ECU configuration model [SWS_SecOC_00171]. This presumably enables separate scheduling or prioritization of different Rx processing paths. Question Q-ebb55c5d3a3da97d (open)

Error Handling and Concurrency

For SecOC_MainFunctionRx, neither specific return values nor explicit error codes for DET or DEM are documented in the requirements [SWS_SecOC_00171]. Error states or failed verifications are therefore likely processed purely internally and reported asynchronously via the receive path to upper-layer modules. Question Q-5d1e45f7a779bea9 (open)

Usage and Call Context

The main function SecOC_MainFunctionTx performs, according to [SWS_SecOC_00176], the authentication and verification processing of the SecOC module on the transmission path (Tx path). It has the signature void SecOC_MainFunctionTx(void), thus takes no input parameters and returns no value; it is assigned service ID 0x03 [SWS_SecOC_00176]. The declaration is provided via header SchM_SecOC.h [SWS_SecOC_00176]. Interpretation: Since integration takes place via the Schedule Manager, the call is likely to typically occur cyclically through the BSW Scheduler in the context of an operating system task. Question Q-34b30208648c8e30 (open)

Instantiation and naming convention

The specification provides for an instance-specific implementation for multiple configurations: For each configured instance container SecOCMainFunctionTx in the ECU configuration, exactly one function according to the naming scheme SecOC_MainFunctionTx_<shortName> must be implemented, where <shortName> corresponds to the short name of the respective configuration container [SWS_SecOC_00176].

Restrictions and Error Handling

Specific error codes, DET or DEM feedback, and details on reentrancy are not listed separately in the specification element [SWS_SecOC_00176]. Interpretation: Due to the coupling to instance-specific configuration containers, each generated instance is likely to be responsible for an isolated subset of Tx PDU processings and should by design not be interrupted concurrently by the same task context. Question (open)

The synchronous callout function SecOC_VerificationStatusCallout serves to forward the status of verification attempts from the SecOC module to external software modules [SWS_SecOC_00119]. It is declared via the header SecOC_Externals.h and has the service ID 0x50 [SWS_SecOC_00119]. Via the input parameter verificationStatus (type SecOC_VerificationStatusType), a data structure is passed that bundles the verification result for a specific Freshness Value ID and Data ID [SWS_SecOC_00119]. The function has no output parameters and no return value (return type void) [SWS_SecOC_00119].

The status forwarding behavior is configurable and supports three variants [SWS_SecOC_00119]:

• Only: Only failed verification attempts ("False") are propagated.
• Both: Both successful ("True") and failed ("False") verification statuses are forwarded to modules.
• None: No verification status is forwarded.

Regarding concurrency, SecOC_VerificationStatusCallout is reentrant for different Freshness Value IDs, but non-reentrant for the same Freshness Value ID [SWS_SecOC_00119]. Implementing modules must therefore ensure that no concurrent calls occur for an identical Freshness Value ID. The call context is likely synchronous within the internal verification routine of the SecOC module. Question Q-cd6928ca22d48f54 (open) Specific error codes or notifications to DET and DEM are not defined for this callout [SWS_SecOC_00119].

Usage and Semantics

The synchronous function SecOC_VerifyStatus informs the application about the result of the verification attempt of a received PDU by the SecOC module [SWS_SecOC_91014]. The interface has the service ID 0x53, does not return a value (void), and is provided via the header SecOC_Externals.h [SWS_SecOC_91014].

Parameters

The single input parameter is the in parameter verificationStatus of type SecOC_VerificationStatusType [SWS_SecOC_91014]. This structure provides details about the verification status as well as the information on which Data ID and Freshness Value ID the verification was performed for [SWS_SecOC_91014]. Additional input or output parameters do not exist [SWS_SecOC_91014].

Error Handling and Concurrency

Specific error codes and notifications to DET or DEM are not defined for this service [SWS_SecOC_91014]. Interpretation: Failed verifications are presumably communicated to the application primarily via the status values within the passed structure verificationStatus. Question Q-177be3d746f99b24 (open) Regarding concurrency, SecOC_VerifyStatus is non-reentrant for the same Freshness Value ID, but reentrant for different Freshness Value IDs [SWS_SecOC_91014].

The enumeration type SecOC_StateType serves the formal representation of the internal operating states of the SecOC module and is provided via the header file SecOC.h [SWS_SecOC_00162]. It enables consistent state tracking across the entire lifecycle of the software component.

According to the specification, the value range of this enumeration type comprises exactly two discrete states [SWS_SecOC_00162]:

• SECOC_UNINIT: Unambiguously signals that the SecOC module is not initialized [SWS_SecOC_00162].
• SECOC_INIT: Bindingly indicates that the SecOC module has been initialized [SWS_SecOC_00162].

Regarding interaction and sequence conditions, SECOC_UNINIT presumably represents the default state immediately after system startup. Question Q-4d02fe3a0979113f (open) In this phase, functional calls for cryptographic protection or verification of messages are likely to be rejected because required data structures are not yet available. Only after successful module initialization does the status presumably change to SECOC_INIT. Calling modules or internal monitoring routines are likely to use SecOC_StateType to check the current operating status synchronously and reliably prevent unauthorized accesses prior to initialization.

The enumeration type SecOC_VerificationResultType serves to signal results during the verification of secured I-PDUs in the SecOC module and is provided via the header Rte_SecOC_Type.h [SWS_SecOC_00149].

The enumeration specifies the following result values to differentiate the verification status [SWS_SecOC_00149]:

• SECOC_VERIFICATIONSUCCESS (0x00): The verification of the data was successful [SWS_SecOC_00149].
• SECOC_VERIFICATIONFAILURE (0x01): The verification was not successful [SWS_SecOC_00149].
• SECOC_FRESHNESSFAILURE (0x02): The verification failed due to an incorrect freshness value [SWS_SecOC_00149].
• SECOC_AUTHENTICATIONBUILDFAILURE (0x03): The verification was not successful due to incorrectly constructed authentication codes [SWS_SecOC_00149].
• SECOC_NO_VERIFICATION (0x04): Verification was skipped and the data was forwarded unchanged to the upper layer; this state is only possible with active status override SecOC_VerifyStatusOverride [SWS_SecOC_00149].
• SECOC_VERIFICATIONFAILURE_OVERWRITTEN (0x05): Verification failed, but the I-PDU was nevertheless passed to the upper layer as a result of the override status; this state also occurs exclusively when using SecOC_VerifyStatusOverride [SWS_SecOC_00149].

Based on these values, upper layers can evaluate precisely whether a verification succeeded regularly, failed due to cryptographic codes or freshness values, or whether administrative override states governed data forwarding [SWS_SecOC_00149].

Usage of the verification status structure

The structure type SecOC_VerificationStatusType bundles, according to [SWS_SecOC_00160], the result of a verification attempt for a secured I-PDU together with the associated Data ID and the freshness value used. The definition is provided via the header file Rte_SecOC_Type.h and comprises the following elements:

• freshnessValueID (uint16): Identifier of the freshness value that led to the verification status ([SWS_SecOC_00160]).
• verificationStatus (SecOC_VerificationResultType): Detailed result of the verification attempt ([SWS_SecOC_00160]).
• secOCDataId (uint16): Data ID of the affected PDU ([SWS_SecOC_00160]).

The element verificationStatus differentiates specific success and error states ([SWS_SecOC_00160]):

• SECOC_VERIFICATIONSUCCESS: The cryptographic check was successful.
• SECOC_VERIFICATIONFAILURE: The verification failed.
• SECOC_FRESHNESSFAILURE: The verification failed due to an invalid freshness value.
• SECOC_AUTHENTICATIONBUILDFAILURE: Failed verification as a result of incorrectly generated authentication codes.
• SECOC_NO_VERIFICATION: No verification attempt was executed for this I-PDU; it was passed through unchanged to the upper layer.
• SECOC_VERIFICATIONFAILURE_OVERWRITTEN: Verification failed, but the I-PDU was forwarded to the upper layer due to an active override status.

Interpretation: Since the type bundles verification details, it is likely to be used primarily in feedback and notification interfaces in order to inform higher layers about the authentication status of received data. Question Q-a1099bc88a2981e2 (open)

The enumeration type SecOC_OverrideStatusType defines the different modes for overriding the verification status of I-PDUs in the SecOC module and is provided via the header Rte_SecOC_Type.h [SWS_SecOC_00991].

The values of the enumeration type control whether and how the verification of the authenticator is performed and how the incoming I-PDU is handled [SWS_SecOC_00991]:

• SECOC_OVERRIDE_DROP_UNTIL_NOTICE (0x00): Verification is omitted without a CSM call, the I-PDU is dropped, and the verification result is set to SECOC_NO_VERIFICATION [SWS_SecOC_00991].
• SECOC_OVERRIDE_DROP_UNTIL_LIMIT (0x01): As before, verification is suspended and the I-PDU is dropped, but limited until the configured number of messages to be overridden is reached [SWS_SecOC_00991].
• SECOC_OVERRIDE_CANCEL (0x02): Aborts the active override of the verification status and restores regular behavior [SWS_SecOC_00991].
• SECOC_OVERRIDE_PASS_UNTIL_NOTICE (0x40) and SECOC_OVERRIDE_PASS_UNTIL_LIMIT (0x42): Authenticator verification is executed and the I-PDU is forwarded to the upper layer regardless of the result; if verification fails, the result is set to SECOC_VERIFICATIONFAILURE_OVERWRITTEN (either until further notice or counter-limited) [SWS_SecOC_00991].
• SECOC_OVERRIDE_SKIP_UNTIL_LIMIT (0x41) and SECOC_OVERRIDE_SKIP_UNTIL_NOTICE (0x43): Verification is omitted, the result is SECOC_NO_VERIFICATION, and the I-PDU is passed to the upper layer. If SecOCRxSecuredPduCollection is configured, SecOC processes the SecOCRxAuthenticPdu directly without waiting for the SecOCRxCryptographicPdu [SWS_SecOC_00991].