AUTOSAR Classic Security & Intrusion Detection
Das Security-Cluster schützt vernetzte Fahrzeugfunktionen gegen Cyber-Bedrohungen durch Intrusion Detection (IdsM), kryptographische PDU-Authentifizierung und Freshness-Protection (SecOC) sowie Key- und Zertifikatsmanagement (KeyM).
Cluster guideAI-GENERATED
Ensures on-board security through crypto services, PDU authentication, key management, and event detection.
Ensures on-board security through crypto services, PDU authentication, key management, and event detection.
The Security & Intrusion Detection cluster provides cryptographic primitives via CSM, CryIf, and Crypto Driver, protects I-PDUs with authentication data via SecOC, and manages keys as well as certificates with KeyM AUTOSAR_CP_SWS_CryptoServiceManager p. 21. Security incidents are reported as events to the IdsM, buffered there, and asynchronously filtered [SWS_IdsM_00702]. During shutdown, the active deletion of RAM key data protects against unauthorized compromise.
The module cluster Security & Intrusion Detection combines the modules secoc, idsm, keym, csm, cryif, and crypto to secure vehicle communication and to detect security incidents in the AUTOSAR Classic Platform AUTOSAR_CP_SWS_IntrusionDetectionSystemManager p. 21. The basic cryptographic services are provided hierarchically via the Crypto Service Manager (CSM), which encapsulates jobs in Crypto_JobType structures [SWS_Csm_01013] and forwards them via the Crypto Interface (CryIf_ProcessJob [SWS_CryIf_91003]) to the specific hardware or software driver objects of the Crypto Driver.
PDU communication is protected by SecOC via message authentication codes (MAC) and freshness values ([SWS_SecOC_91006], [SWS_SecOC_00012]), while the Key Manager (KeyM) prepares, updates, and validates certificates and keys for the CSM ([SWS_KeyM_00052], [SWS_KeyM_00059]). Security-relevant events—such as failed PDU checks—are reported as Security Events (SEv) to the IdsM [SWS_IdsM_91002], which buffers them synchronously [SWS_IdsM_00701] and qualifies them asynchronously via configurable filter chains [SWS_IdsM_01020].
Architecture diagram: Layered architecture and interface relationships of the security and intrusion detection cluster. Sources: AUTOSAR_CP_SWS_IntrusionDetectionSystemManager p. 21, AUTOSAR_CP_SWS_CryptoServiceManager p. 21.
Execution separates synchronous API entries from computationally intensive background tasks in IdsM_MainFunction, SecOC_MainFunctionTx [SWS_SecOC_00176], and KeyM_MainBackgroundFunction [SWS_KeyM_00075]. In the event of an error or system overload (CRYPTO_E_BUSY), fallback mechanisms such as default authentication patterns in SecOC [SWS_SecOC_91013] and NvM rollbacks in the IdsM [SWS_IdsM_01702] ensure the stability of the overall system; during shutdown, KeyM completely deletes active RAM key material [SWS_KeyM_00047].
System Architecture & Role of the Module Cluster
The module cluster Security & Intrusion Detection of the AUTOSAR Classic Platform (Release R20-11) provides standardized services for cryptography, secure on-board communication, key and certificate management, and intrusion detection. Functionally, the cluster is structured across several layers of the AUTOSAR Basic Software (BSW): At the service layer, the Crypto Service Manager (CSM) encapsulates hardware-independent cryptographic services AUTOSAR_CP_SWS_CryptoServiceManager p. 21. Secure communication of I-PDUs is handled by the Secure Onboard Communication (SecOC) module in the communication layer [SWS_SecOC_00162], while the Key Manager (KeyM) orchestrates the lifecycle of cryptographic keys and certificates as a security service SWS_KeyManager p. 31. In addition, the Intrusion Detection System Manager (IdsM) acts as a central aggregator and filter for security-relevant events in the overall system AUTOSAR_CP_SWS_IntrusionDetectionSystemManager p. 21.
Below the CSM, the Crypto Interface (CryIf) abstracts the hardware- or software-specific access to multiple cryptographic driver objects as layer CryIf and unifies the job and key dispatching mechanism SWS_CryptoInterface p. 1. At the MCAL and driver layer, the Crypto Driver (Crypto) performs the actual computations in software or on Hardware Security Modules (HSM) [SWS_Crypto_91016]. The interaction of these layers ensures complete decoupling of the application software (SW-C) and communication modules from the hardware-specific crypto accelerators.
Architecture diagram: Layered architecture and interface relationships of the security and intrusion detection cluster. Sources: AUTOSAR_CP_SWS_IntrusionDetectionSystemManager p. 21, AUTOSAR_CP_SWS_CryptoServiceManager p. 21.
Interplay & Interaction Paths Between the Modules
The modules of the cluster are linked to one another via clearly defined control and data flow paths. Cryptographic jobs are primarily processed via the CSM. Application modules or BSW modules such as SecOC and KeyM initiate jobs via CSM services such as Csm_MacGenerate [SWS_Csm_00982], Csm_Encrypt [SWS_Csm_00984], Csm_AEADEncrypt [SWS_Csm_01023], Csm_SignatureGenerate [SWS_Csm_00992], Csm_Hash [SWS_Csm_00980], or Csm_RandomGenerate [SWS_Csm_01543]. The jobs are encapsulated in the standardized runtime structure Crypto_JobType [SWS_Csm_01013], which is controlled via operational modes (Crypto_OperationModeType such as CRYPTO_OPERATIONMODE_START, UPDATE, FINISH, or SINGLECALL) [SWS_Csm_00802]. The CSM passes the job to CryIf_ProcessJob [SWS_CryIf_91003], which forwards the call to the responsible crypto driver object.
The SecOC module secures PDU transfer between PduR and the communication bus. Upon reception of a secured PDU via SecOC_TpRxIndication [SWS_SecOC_00125], SecOC first retrieves freshness values via SecOC_GetRxFreshnessAuthData [SWS_SecOC_91006] and constructs the data to be authenticated according to the specification SecOcProtocol p. 19. For MAC verification, SecOC uses the CSM [SWS_SecOC_00012]. After successful verification, the authentic PDU is passed to the upper layers. If the verification fails, the result is captured in status SecOC_VerificationStatusType [SWS_SecOC_00160], [SWS_SecOC_91014]; interpretation: this failure is reported to the IdsM as a Security Event AUTOSAR_CP_SWS_IntrusionDetectionSystemManager p. 21. Question Q-8cfd1660757f3f1f (open)
In the Key Manager (KeyM), key and certificate updates are prepared and executed. During certificate verifications (e.g., via KeyM_VerifyCertificates [SWS_KeyM_00059] or KeyM_VerifyCertificateChain [SWS_KeyM_00061]), KeyM uses the cryptographic primitives of the CSM for signature verification and external time bases of the StbM for validity verification SWS_KeyManager p. 119. Key updates (KeyM_Update [SWS_KeyM_00052]) integrate user-specific handlers (KeyM_KH_Update [SWS_KeyM_00069], [SWS_KeyM_00055]), with resulting key bytes being activated in the crypto driver via Csm_KeyElementSet [SWS_Csm_00957] and Csm_JobKeySetValid [SWS_Csm_91027]. CryIf forwards key derivations and copy operations via CryIf_KeyDerive [SWS_CryIf_91009] and CryIf_KeyElementCopy [SWS_CryIf_91015], respectively, to driver functions such as Crypto_KeyElementCopyPartial [SWS_Crypto_91015].
The IdsM collects security events (Security Events, SEv) from BSW sensors (including SecOC) as well as application SW-Cs via interfaces such as IdsM_SetSecurityEvent [SWS_IdsM_91002] or IdsM_SetSecurityEventWithCount [SWS_IdsM_91018]. The events are buffered, qualified via filter chains (e.g., Block State Filter [SWS_IdsM_01020] or aggregation filter AUTOSAR_CP_SWS_IntrusionDetectionSystemManager p. 40), and finally forwarded via PduR [SWS_IdsM_91009], [SWS_IdsM_91010].
Sequence diagram: Verification of a secured PDU in SecOC using the crypto stack and reporting of security events to the IdsM. Sources: [SWS_SecOC_00125], [SWS_SecOC_00012], [SWS_CryIf_91003], [SWS_CryIf_91013], [SWS_IdsM_91002].
Synchronization, reentrancy and task contexts
The execution of cryptographic computations and security operations requires a strict separation of synchronous call paths and asynchronous task contexts. In the CSM and CryIf, execution behavior depends on the configuration of the crypto primitives: operations can execute in a synchronously blocking or asynchronous manner [SWS_Csm_00982], [SWS_CryIf_91003]. For asynchronous jobs, the crypto driver reports completion via CryIf_CallbackNotification [SWS_CryIf_91013], whereupon CSM serves the caller's registered callback function [SWS_SecOC_00012]. For interruptible or longer-running computations, the CSM provides the cancel function Csm_CancelJob [SWS_Csm_00968], which is delegated to the driver via CryIf_CancelJob [SWS_CryIf_91014].
Transmission in the SecOC module is decoupled in a time-controlled manner: in periodic cycles, SecOC_MainFunctionTx checks whether new authentic PDUs are pending for signing, calculates the authenticators, and initiates the PduR transmission [SWS_SecOC_00176]. In the IdsM, reported events are ingested with high performance in the sensor context (task or ISR) via IdsM_SetSecurityEvent [SWS_IdsM_91002], with the events initially being stored synchronously in configurable event buffers [SWS_IdsM_00701], [SWS_IdsM_00702]. The time-intensive filtering, context data processing, and timestamp enrichment via StbM or RTE are processed completely asynchronously in the context of the periodic IdsM_MainFunction SWS_IntrusionDetectionSystemManager p. 87, AUTOSAR_CP_SWS_IntrusionDetectionSystemManager p. 86.
The Key Manager distinguishes between time-critical and computationally intensive tasks: while standard status queries and callback orchestrations run in KeyM_MainFunction [SWS_KeyM_00074], execution in a preemptive background function KeyM_MainBackgroundFunction is intended for computationally intensive synchronous handler routines (such as KeyM_KH_Update) [SWS_KeyM_00075]. In multicore architectures, the CSM additionally supports partition-specific main functions and initializations [SWS_Csm_00646], SWS_CryptoInterface p. 1; interpretation: this partitioning corresponds to the assignment of dedicated hardware driver objects per processor core. Question (open)
Typical lifecycles and operating modes
Cluster initialization follows a strict bottom-up dependency hierarchy. First, the hardware-related drivers are configured via Crypto_Init [SWS_Crypto_91016], followed by the interface CryIf [SWS_CryIf_91118] and the CSM via Csm_Init [SWS_Csm_00646]. Only afterwards may the dependent modules SecOC, KeyM, and IdsM be initialized. Through initialization, SecOC transitions from state SECOC_UNINIT to SECOC_INIT [SWS_SecOC_00162]. In KeyM, all configured certificates initially receive the status KEYM_CERTIFICATE_NOT_AVAILABLE [SWS_KeyM_00021], [SWS_KeyM_91003] before being read from the NvM or loaded and verified via KeyM_SetCertificate or diagnostics SWS_KeyManager p. 119.
At runtime, vehicle state transitions influence the operational mode of the IdsM: the Basic Software Manager (BswM) notifies the IdsM of state changes via IdsM_BswM_StateChanged [SWS_IdsM_91005]. These states control the Block State Filter [SWS_IdsM_01020], [SWS_IdsM_91017], which suppresses the forwarding of security events during certain operating phases (e.g., programming mode or sleep phases). In addition, reporting modes of events can be modified diagnostically via DCM (IdsM_Dcm_SetReportingMode_Start [SWS_IdsM_91008], [SWS_IdsM_91013]) and stored persistently in the NvM [SWS_IdsM_01700], [SWS_IdsM_01701].
When shutting down the ECU (shutdown), the modules are de-initialized in an orderly manner. SecOC_DeInit stops secure communication, flushes all internal buffers as well as variables, and transitions SecOC back to state SECOC_UNINIT [SWS_SecOC_00161]. When calling KeyM_Deinit [SWS_KeyM_00047], all cryptographic key material located in RAM is actively destroyed and overwritten with initial values for security reasons to prevent unauthorized readout in the quiescent state.
Error Handling, DET Tracing, and Degradation
The module cluster implements end-to-end mechanisms for detecting development errors (Development Error Tracer, DET) and runtime problems. All modules check their initialization and report DET errors upon uninitialized invocation, for example CRYIF_E_UNINIT in CryIf interfaces such as CryIf_RandomSeed [SWS_CryIf_91007], CryIf_CancelJob [SWS_CryIf_91014], CryIf_KeyDerive [SWS_CryIf_91009], or CryIf_CallbackNotification [SWS_CryIf_91013]. Likewise, invalid pointer parameters lead to DET reports, such as CRYPTO_E_PARAM_POINTER in Crypto_GetVersionInfo [SWS_Crypto_91001], while initialization errors in the CSM are reported with CSM_E_INIT_FAILED [SWS_Csm_00646].
In the event of overload or failure of crypto hardware objects, the driver signals the status CRYPTO_E_BUSY [SWS_CryIf_91003], [SWS_Csm_00957]. In such degradation scenarios, SecOC allows the configurable sending of unauthenticated replacement PDUs to the lower layers via SecOC_SendDefaultAuthenticationInformation to maintain vehicle availability [SWS_SecOC_91013]. In the IdsM, exhaustion of the configured event buffers triggers the internal security event SEV_IDSM_NO_EVENT_BUFFER_AVAILABLE [SWS_IdsM_00703]. If NvM persistency of modified IdsM parameters fails, the IdsM performs an automatic rollback to the previous state [SWS_IdsM_01702]. If an error occurs when setting keys in Csm_KeyElementSet, the status of the key element is considered undefined and must be validated via Csm_KeyGetStatus [SWS_Csm_91047] and CryIf_KeyGetStatus [SWS_CryIf_91012].
This guide is based on the AUTOSAR specifications of the Classic Platform for Release R20-11 and summarizes the architecture of the Security & Intrusion Detection cluster.
Topic map
IdsM
21KeyM
42SecOC
33No element data available for this release
IdsM
This callback function is invoked by the BswM to indicate ECU state changes.
void IdsM_BswM_StateChanged (IdsM_Filters_BlockStateType state);This function is called to acquire the transmit data of an I-PDU segment (N-PDU). Each call to this function provides the next part of the I-PDU data unless retry->TpDataState is TP_ DATARETRY. In this case the function restarts to copy the data beginning at the offset from the current position indicated by retry->TxTpDataCnt. The size of the remaining data is written to the position indicated by availableDataPtr.
BufReq_ReturnType IdsM_CopyTxData (PduIdType id, const PduInfoType* info, const RetryInfoType* retry, PduLengthType* availableDataPtr);This function is a request from DCM to the IdsM to read the routine results triggered by function IdsM_Dcm_GetReportingMode_Start().
Std_ReturnType IdsM_Dcm_GetReportingMode_RequestResults (Dcm_OpStatusType OpStatus, uint8* Out_ReportingMode, Dcm_NegativeResponseCodeType* ErrorCode);This function is a request from DCM to the IdsM to start the routine execution to request the current reporting mode of a specific Security Event ID.
Std_ReturnType IdsM_Dcm_GetReportingMode_Start (uint16 In_SecurityEventId, uint8 In_SensorInstanceId, Dcm_OpStatusType OpStatus, Dcm_NegativeResponseCodeType* ErrorCode);This function is a request from DCM to the IdsM to start the routine execution to set the reporting mode of a specific Security Event ID.
Std_ReturnType IdsM_Dcm_SetReportingMode_Start (uint16 In_SecurityEventId, uint8 In_SensorInstanceId, uint8 In_ReportingMode, Dcm_OpStatusType OpStatus, Dcm_NegativeResponseCodeType* ErrorCode);Returns version information, vendor ID and AUTOSAR module ID of the component.
void IdsM_GetVersionInfo (const Std_VersionInfoType* versionInfo);Service to initialize the module IdsM. It initializes all variables and sets the module state to initialized.
void IdsM_Init (const IdsM_ConfigType* configPtr);This function is called periodically. It processes security events asynchronously which are queued during API function calls.
void IdsM_MainFunction (void);This API is the application interface to report security events to the IdsM.
void IdsM_SetSecurityEvent (IdsM_SecurityEventIdType securityEventId);This API is the application interface to report security events with context data to the IdsM.
void IdsM_SetSecurityEventWithContextData (IdsM_SecurityEventIdType securityEventId, const uint8* contextData, uint16 contextDataSize);This API is the application interface for Smart Sensors to report security events with a count value to the IdsM.
void IdsM_SetSecurityEventWithCount (IdsM_SecurityEventIdType securityEventId, uint16 count);This API is the application interface for Smart Sensors to report security events with a count value and context data to the IdsM.
void IdsM_SetSecurityEventWithCountContextData (IdsM_SecurityEventIdType securityEventId, uint16 count, const uint8* contextData, uint16 contextDataSize);This API is the application interface for Smart Sensors to report security events with a timestamp and a count value to the IdsM.
void IdsM_SetSecurityEventWithTimestampCount (IdsM_SecurityEventIdType securityEventId, IdsM_TimestampType timestamp, uint16 count);This API is the application interface for Smart Sensors to report security events with a timestamp, a count value and context data to the IdsM.
void IdsM_SetSecurityEventWithTimestampCountContextData (IdsM_SecurityEventIdType securityEventId, IdsM_TimestampType timestamp, uint16 count, const uint8* contextData, uint16 contextDataSize);This function is called after the I-PDU has been transmitted on its network, the result indicates whether the transmission was successful or not.
void IdsM_TpTxConfirmation (PduIdType id, Std_ReturnType result);The lower layer communication interface module confirms the transmission of a PDU, or the failure to transmit a PDU.
void IdsM_TxConfirmation (PduIdType TxPduId, Std_ReturnType result);Configuration data structure of IdsM module.
Data type used for "Block State" filter values (bit masks)
Reporting modes used by the reporting mode filter
Data type used for local IdsM Security Event IDs
Data type for IdsM timestamps
KeyM
Service KeyM_CertElementGet.
Std_ReturnType KeyM_CertElementGet (KeyM_CertificateIdType CertId, KeyM_CertElementIdType CertElementId, uint8* CertElementData, uint32* CertElementDataLength);Service KeyM_CertElementGetFirst.
Std_ReturnType KeyM_CertElementGetFirst (KeyM_CertificateIdType CertId, KeyM_CertElementIdType CertElementId, KeyM_CertElementIteratorType* CertElementIterator, uint8* CertElementData, uint32* CertElementDataLength);Service KeyM_CertElementGetNext.
Std_ReturnType KeyM_CertElementGetNext (KeyM_CertElementIteratorType* CertElementIterator, uint8* CertElementData, uint32* CertElementDataLength);This function provides the sta tus of a certificate.
Std_ReturnType KeyM_CertGetStatus (KeyM_CertificateIdType CertId, KeyM_CertificateStatusType* Status);Service KeyM_CertificateElementGetByIndex.
Std_ReturnType KeyM_CertificateElementGetByIndex (KeyM_CertificateIdType CertId, KeyM_CertElementIdType CertElementId, uint32 Index, uint8* CertElementDataPtr, uint32* CertElementDataLengthPtr);This function provides the total number of data elements that a re available for the specified certificate element. Typically, only one data element is available. But in some cases, several data elements can be assigned to one certificate element in a row. This function retrieves the total number of elements. The indiv idual data elements can then accessed with Key M_ Certificate Element Get By Index(). It is similar to the functions Key M_ Cert Element Get First/ Key M_ Cert Element Get Next to retrieve a group of data elements of one certificate element. AUTOSAR CP R20 - of
Std_ReturnType KeyM_CertificateElementGetCount (KeyM_CertificateIdType CertId, KeyM_CertElementIdType CertElementId, uint16* CountPtr);Notifies the application that a certificate verification has been finished. The function name is configurable by Key MCertificate Verify Callback Notification Func. Availabl e via Key M_ Externals.h
Std_ReturnType KeyM_CertificateVerifyCallbackNotification (KeyM_CertificateIdType CertId, KeyM_CertificateStatusType Result);This function resets the key management module to the uninitialized state.
void KeyM_Deinit (void);The function is used to finalize key update operations. It is typi cally used in conjunction with the Key M_
Std_ReturnType KeyM_Finalize (const uint8* RequestDataPtr, uint16 RequestDataLength, uint8* ResponseDataPtr, uint16 ResponseMaxDataLength);This function provides the certificate data
Std_ReturnType KeyM_GetCertificate (KeyM_CertificateIdType CertId, KeyM_CertDataType* CertificateDataPtr);Provides the version information of this module.
void KeyM_GetVersionInfo (Std_VersionInfoType* VersionInfo);This function initializes the key management module.
void KeyM_Init (const KeyM_ConfigType* ConfigPtr);If Key MCrypto Key Start Finalize Function Enabled and Key MCrypto Key Handler Start Finalize Enabled is set to TRUE, this function will be called immediately when Key M_
Std_ReturnType KeyM_KH_Finalize (const uint8* RequestData, uint16 RequestDataLength, uint8* ResponseData, uint16* ResponseDataLength);If the configuration parameters Key MCrypto Key Prepare Function Enabled and Key MCrypto Key Handler Prepare Enabled are both set to TRUE, then this function w ill be called immediately when Key M_ Prepare gets called. The function takes over the task to prepare a key management operation. The response data will be passed on as is to the caller of Key_ Prepare.
Std_ReturnType KeyM_KH_Prepare (const uint8* RequestData, uint16 RequestDataLength, uint8* ResponseDataPtr, uint16* ResponseDataLength);If Key MCrypto Key Start Finalize Function Enabled and Key MCrypto Key
Std_ReturnType KeyM_KH_Start (KeyM_StartType StartType, const uint8* RequestData, uint16 RequestDataLength, uint8* ResponseData, uint16* ResponseDataLength);Function is called from a pre - emptive operating system when no other task operation is needed. Can be used for calling time consuming synchronous functions such as Key M_ KH_ Update().
void KeyM_MainBackgroundFunction (void);Function is called periodically according the specified time interval.
void KeyM_MainFunction (void);This function is used to prepare a key update operation. The main intent is to provide information for the key operation to the key server. Other operations may start the negotiation for a common secret that is used further to derive key material. This function is only av ailable if Key MCrypto Key Prepare Function Enabled is set to TRUE.
Std_ReturnType KeyM_Prepare (const uint8* RequestData, uint16 RequestDataLength, uint8* ResponseData, uint16* ResponseDataLength);Notifies the application that the certificate service operation has been finished. This function is used by the certificate submodule. Thi s callback is only provided if Key MService Certificate Function Enabled is set to TRUE. The function name is configurable by Key MService Certificate Callback Notification Func.
This function provides the certificate data to the key managem ent module to temporarily store the certificate.
Std_ReturnType KeyM_SetCertificate (KeyM_CertificateIdType CertId, const KeyM_CertDataType* CertificateDataPtr);This function is optional and only used if the configuration item Key MCrypto Key Start Finalize Function Enabled is set to true. It intents to allow key update operation.
Std_ReturnType KeyM_Start (KeyM_StartType StartType, const uint8* RequestData, uint16 RequestDataLength, uint8* ResponseData, uint16* ResponseDataLength);Service KeyM_VerifyCertificate.
Std_ReturnType KeyM_VerifyCertificate (KeyM_CertificateIdType CertId);Service KeyM_VerifyCertificateChain.
Std_ReturnType KeyM_VerifyCertificateChain (KeyM_CertificateIdType CertId, const KeyM_CertDataType[] certChainData, uint8 NumberOfCertificates);This function verifies two certificates that are stored and parsed internally against each other. The certificat e referenced with Cert Id was signed by the certificate referenced with cert Upper Id. Only these two certificates are validated against each other.
Std_ReturnType KeyM_VerifyCertificates (KeyM_CertificateIdType CertId, KeyM_CertificateIdType CertUpperId);Byte - pointer to the data of the certificate
This structure is used to exchange certificate data through interface functions.
Certificate Element handle.
This structure is used to iterate through a number of elements of a certificate.
Array long enough to store data
Certificate handle.
Type KeyM_CertificateStatusType.
This structure is the base type to initialize the Key Manager module. A pointer to an instance of this structure will be used in the initialization of the Key Manager module.
Byte - pointer to the input or output data
Crypto key handle.
Specifies the type of key handler update operation that was performed in the callback.
Specifies the result type of an asynchronous key management fu nction.
This type specifies the requested service operation and what information is provided with this function.
This type specifies in which mode the key operation will start. The OEM production mode provides higher privileges compared to workshop mode.
Array long enough to store the key or certificate name. base Type Encoding = UTF -
SecOC
This function is called to provide the received data of an I - PDU segment (N - PDU) to the upper layer. Each call to this function provides the next part of the I - PDU data. The si ze of the remaining buffer is written to the position indicated by buffer Size Ptr.
BufReq_ReturnType SecOC_CopyRxData (PduIdType id, const PduInfoType* info, PduLengthType* bufferSizePtr);Service SecOC_CopyTxData.
BufReq_ReturnType SecOC_CopyTxData (PduIdType id, const PduInfoType* info, const RetryInfoType* retry, PduLengthType* availableDataPtr);This service stops the secure onboard communication. All buffered I - PDU are removed and have to be obtained again, if needed, after Sec OC_ Init has been called. By a call to Sec OC_ De Init the AUTOSAR Sec OC module is put into a not in itialized state (Sec OC_ UNINIT).
void SecOC_DeInit (void);Service SecOC_GetRxFreshnessAuthData.
Std_ReturnType SecOC_GetRxFreshnessAuthData (uint16 SecOCFreshnessValueID, const uint8* SecOCTruncatedFreshnessValue, uint32 SecOCTruncatedFreshnessValueLength, const uint8* SecOCAuthDataFreshnessValue, uint16 SecOCAuthDataFreshnessValueLength, uint16 SecOCAuthVerifyAttempts, uint8* SecOCFreshnessValue, uint32* SecOCFreshnessValueLength);This API returns th e freshness value from the Most Significant Bits in the first byte in the array (Sec OCFreshness Value), in big endian format.
Std_ReturnType SecOC_GetTxFreshness (uint16 SecOCFreshnessValueID, uint8* SecOCFreshnessValue, uint32* SecOCFreshnessValueLength);Returns the version information of this module.
void SecOC_GetVersionInfo (Std_VersionInfoType* versioninfo);Requests cancellation of an ongoing transmission of a PDU in a lower layer communication module.
Std_ReturnType SecOC_IfCancelTransmit (PduIdType TxPduId);Requests transmission of a PDU.
Std_ReturnType SecOC_IfTransmit (PduIdType TxPduId, const PduInfoType* PduInfoPtr);Initializes the the Sec OC module. Successful initialization leads to state Sec OC_ INIT. In configurations, in which Sec OC is assigned to more than one partition (i.e. Sec OC_ Main Functions are mapped to partition s), Sec OC may provide one init AUTOSAR CP R20 - of Document ID : AUTOSAR_SWS_SecureOnboardCommunication function per partition. The decision on whether a single Sec OC_ Init() function or one per partition is provided is implementation - specific. In case a given implementation provides one Sec OC_ Init() function per partition, it is up to the implementation to devise a naming pattern that prevents name clashes among the different Sec OC_ Init() functions (e.g., by adding a suffix containing short name the Ecuc Partition.
void SecOC_Init (const SecOC_ConfigType* config);This function performs the processing of the Sec OC module's authentication and verification processing for the Rx path. Per configured Sec OCMain Function Rx instance one Sec OC_ Main Function Rx_ shall be implemented. Hereby is the short name of the Sec OCMain Function Rx configuration container in the ECU configuration.
void SecOC_MainFunctionRx (void);This function performs the processing of the Sec OC module's authentication and verification processing for the Tx path. Per configured Sec OCMain Function Tx instance one Sec OC_ Main Function Tx_ shall be implemented. Hereby is t he short name of the Sec OCMain Function Tx configuration container in the ECU configuration.
void SecOC_MainFunctionTx (void);Indication of a received PDU from a lower layer communication interface module.
void SecOC_RxIndication (PduIdType RxPduId, const PduInfoType* PduInfoPtr);The service provides the ability to enable the sending of un - authenticated PDU to lower layer. (example: in case authentication build counter has reached the configuration value Sec OCAuthentication Build Attempts or the query of the freshness function returns E_ NOT_ OK or the calculation of the authenticator has returned a non - recoverable error such as returning E_ NOT_ OK or KEY_ FAILURE). T his service is optional (the service is available only if Sec OCDefault Authentication Information Pattern is configured). If the service is not available or the service is available but the service was called with send Default
Std_ReturnType SecOC_SendDefaultAuthenticationInformation (uint16 FreshnessValueID, boolean sendDefaultAuthenticationInformation);This interface is used by the Sec OC to indicate that the Secured I - PDU has been initiated for transmission.
void SecOC_SPduTxConfirmation (uint16 SecOCFreshnessValueID);Service SecOC_StartReception.
BufReq_ReturnType SecOC_StartOfReception (PduIdType id, const PduInfoType* info, PduLengthType TpSduLength, PduLengthType* bufferSizePtr);Requests cancellation of an ongoing reception of a PDU in a lower layer transport protocol module.
Std_ReturnType SecOC_TpCancelReceive (PduIdType RxPduId);Requests cancellation of an ongoing transmission of a PDU in a lower layer communication module.
Std_ReturnType SecOC_TpCancelTransmit (PduIdType TxPduId);Called after an I - PDU has been received via the TP API, the result indicates whether the transmission was successful or not.
void SecOC_TpRxIndication (PduIdType id, Std_ReturnType result);Requests transmission of a PDU.
Std_ReturnType SecOC_TpTransmit (PduIdType TxPduId, const PduInfoType* PduInfoPtr);This function is called after the I - PDU has been transmitted on its network, the result indicates whether the transmission was successful or not.
void SecOC_TpTxConfirmation (PduIdType id, Std_ReturnType result);Within this API , the upper layer module (called module) shall check whether the available data fits into the buffer size reported by Pdu Info Ptr - >Sdu Length. If it fits, it shall copy its data into the buffer provided by Pdu Info Ptr - >Sdu Data Ptr and update the length of the actual copied data in Pdu Info Ptr - >Sdu Length. If not, it returns E_ NOT_ OK without changing Pdu Info Ptr.
Std_ReturnType SecOC_TriggerTransmit (PduIdType TxPduId, PduInfoType* PduInfoPtr);The lower layer communication interface module confirms the transmission of a PDU, or the failure to transmit a PDU.
void SecOC_TxConfirmation (PduIdType TxPduId, Std_ReturnType result);Service is used to propagate the status of each verification attempt from the Sec OC module to other modules. This service can be configured such that: Only: "False" Verifica tion Status is propagated to modules Both: "True" and "False" Verification Status are propagated to modules None: No Verification Status is propagated
void SecOC_VerificationStatusCallout (SecOC_VerificationStatusType verificationStatus);This s ervice provides the ability to inform the application about the result of the verification attempt of a received PDU by the Sec OC module.
void SecOC_VerifyStatus (SecOC_VerificationStatusType verificationStatus);Service SecOC_VerifyStatusOverride.
Std_ReturnType SecOC_VerifyStatusOverride (uint16 ValueID, SecOC_OverrideStatusType overrideStatus, uint8 numberOfMessagesToOverride);Configuration data structure of Sec OC module
-
Type SecOC_OverrideStatusType.
States of the Sec OC module
Enumeration to indicate veri fication results.
Data structure to bundle the status of a verification attempt for a specific Freshness Value and Data ID
Module im Cluster
Firewall (Fw)
AUTOSAR Classic Communication Services-Modul Firewall (Fw, Spezifikation: AUTOSAR_CP_SWS_Firewall.pdf).
Intrusion Detection System Manager (IdsM)
Collects and reports onboard security events to detect threats.
Key Manager (KeyM)
Manages lifecycle, storage, and distribution of cryptographic keys and certificates.
MACsec Key Agreement (Mka)
AUTOSAR Classic Communication Services-Modul MACsec Key Agreement (Mka, Spezifikation: AUTOSAR_CP_SWS_MACsecKeyAgreement.pdf, AUTOSAR_SWS_MACsecKeyAgreement.pdf).
Secure Onboard Communication (SecOC)
Provides cryptographic authentication and freshness protection for critical communication PDUs.
gemini-3.8-flash-low· 2026-10-13 · German original