Complex Driver design and integration guideline

AUTOSAR CP R23-11

Complex Driver design and

Document Title integration guideline
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 622

Document Status published

Part of AUTOSAR Standard Classic Platform
Part of Standard Release R23-11

Document Change History

Date Release Changed by Description
AUTOSAR
2023-11-23 R23-11 Release • No content changes
Management
AUTOSAR
• Update of the figure which describes the
2022-11-24 R22-11 Release
header files hierarchy of a CDD module
Management
AUTOSAR
2021-11-25 R21-11 Release • No content changes
Management
AUTOSAR
• Update for Module IDs for
2020-11-30 R20-11 Release
non-AUTOSAR BSW modules
Management
AUTOSAR • Add a note in the 7.3.8 chapter
2019-11-28 R19-11 Release • Changed Document Status from Final to
Management published
AUTOSAR
• Remove SWS_EcuMfixed in Chapters
2018-10-31 4.4.0 Release
4.1 and 7.3.2
Management
AUTOSAR
2017-12-08 4.3.1 Release • Adapt the 7.3.9 chapter title
Management
AUTOSAR • Add chapter to interface with StbM
2016-11-30 4.3.0 Release module
Management • Update for Module ID
5

1 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

4
AUTOSAR • Update for Default Error Tracer
2015-07-31 4.2.2 Release
Management • Re-entrancy of interfaces
AUTOSAR
2014-10-31 4.2.1 Release • Update for TcpIp
Management
• Update of CDD code files chapter
AUTOSAR
2014-03-31 4.1.3 • Removed chapters on change
Administration
documentation
AUTOSAR
2013-03-15 4.1.1 • Initial release
Administration

2 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

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.

3 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

Contents
1 Introduction 6
1.1 Scope of Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Definition of terms and acronyms 7
2.1 Glossary of terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Conventions to be used 8

4 Related Documentation 9
4.1 Input documents & related standards and norms . . . . . . . . . . . . . 9
5 Introduction to CDD 11

6 CDD design recommendations 12

6.1 Documentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1.1 User’s Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1.1.1 Module ID . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3 CDD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3.1 Code file(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3.2 Header file(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3.3 Recommended files structure . . . . . . . . . . . . . . . . . . . 14
6.3.4 Coherence checks . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4 Behaviour and Interfaces description . . . . . . . . . . . . . . . . . . . . 15
6.5 Parameters configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Interfacing to other modules 17
7.1 Interfacing to Rte and SW-C . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2 Interfacing to libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3 Interfacing to standard BSW modules . . . . . . . . . . . . . . . . . . . . 17
7.3.1 Interfacing with MCAL modules . . . . . . . . . . . . . . . . . . 18
7.3.2 Interfacing with BSW Mode Manager & ECU State Manager . 18
7.3.3 Interfacing with Memory Stack . . . . . . . . . . . . . . . . . . 19
7.3.4 Interfacing with Watchdog Stack . . . . . . . . . . . . . . . . . 19
7.3.5 Interfacing with Communication Stack . . . . . . . . . . . . . . 19
7.3.5.1 Interfacing with PDU Router . . . . . . . . . . . . . . . 20
7.3.5.2 Interfacing <Bus> Interfaces modules . . . . . . . . . 20
7.3.5.3 Interfacing with Com Module . . . . . . . . . . . . . . 20
7.3.5.4 Interfacing with Com Manager . . . . . . . . . . . . . . 21
7.3.5.5 Interfacing with Network Management Interface module21
7.3.5.6 Interfacing with TCP/IP module . . . . . . . . . . . . . 21
7.3.6 Interfacing with XCP module . . . . . . . . . . . . . . . . . . . 21
7.3.7 Interfacing with Diagnostic Log and Trace . . . . . . . . . . . . 22
7.3.8 Interfacing with Default Error Tracer and Diagnostic Event
Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

7.3.9 Interfacing with OS . . . . . . . . . . . . . . . . . . . . . . . . 22

7.3.10 Interfacing with StbM module . . . . . . . . . . . . . . . . . . . 23
7.4 CDD in multi-cores system . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.5 CDD module of the MCAL . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

1 Introduction

1.1 Scope of Document

The purpose of this document is to:
• Give an overview of Complex Driver (CDD)
• Give recommendations for implementation and integration of a CDD within
AUTOSAR architecture.
This document is aimed at developers and integrators of CDD.

6 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

2 Definition of terms and acronyms

Acronyms and abbreviations, which have a local scope and therefore are not contained
in the AUTOSAR glossary, must appear in a local glossary.
Abbreviation / Acronym Description
CDD CDD used to be the acronym for Complex Device Driver or
Complex Driver, but is not limited to drivers.

2.1 Glossary of terms

The glossary of terms is available in the document [1] AUTOSAR Glossary.
Term Definition
<MODULENAME> This term is defined in the document [2] General
Requirements on Basic Software Modules

7 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

3 Conventions to be used
In requirements, the following specific semantics shall be used (based on the Internet
Engineering Task Force IETF).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as follows.
Note that the requirement level of the document in which they are used modifies the
force of these words.
• MUST: This word, or the adjective "LEGALLY REQUIRED", means that the defi-
nition is an absolute requirement of the specification due to legal issues.
• MUST NOT: This phrase, or the phrase "MUST NOT", means that the definition
is an absolute prohibition of the specification due to legal issues.
• SHALL: This phrase, or the adjective "REQUIRED", means that the definition is
an absolute requirement of the specification.
• SHALL NOT: This phrase means that the definition is an absolute prohibition of
the specification.
• SHOULD: This word, or the adjective "RECOMMENDED", means that there may
exist valid reasons in particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed before choosing a
different course.
• SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED", means that
there may exist valid reasons in particular circumstances when the particular be-
havior is acceptable or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior described with
this label.
• MAY: This word, or the adjective "OPTIONAL", means that an item is truly op-
tional. One vendor may choose to include the item because a particular market-
place requires it or because the vendor feels that it enhances the product while
another vendor may omit the same item.
An implementation, which does not include a particular option, SHALL be prepared
to interoperate with another implementation, which does include the option, though
perhaps with reduced functionality. In the same vein an implementation, which does
include a particular option, SHALL be prepared to interoperate with another implemen-
tation, which does not include the option (except, of course, for the feature the option
provides.)

8 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

4 Related Documentation

4.1 Input documents & related standards and norms

[1] Glossary
AUTOSAR_FO_TR_Glossary
[2] General Requirements on Basic Software Modules
AUTOSAR_CP_SRS_BSWGeneral
[3] Layered Software Architecture
AUTOSAR_CP_EXP_LayeredSoftwareArchitecture
[4] List of Basic Software Modules
AUTOSAR_CP_TR_BSWModuleList
[5] General Specification of Basic Software Modules
AUTOSAR_CP_SWS_BSWGeneral
[6] Specification of Standard Types
AUTOSAR_CP_SWS_StandardTypes
[7] Specification of Platform Types for Classic Platform
AUTOSAR_CP_SWS_PlatformTypes
[8] Specification of Communication Stack Types
AUTOSAR_CP_SWS_CommunicationStackTypes
[9] Basic Software Module Description Template
AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate
[10] Specification of ECU Configuration
AUTOSAR_CP_TPS_ECUConfiguration
[11] Specification of ECU State Manager
AUTOSAR_CP_SWS_ECUStateManager
[12] Specification of Watchdog Manager
AUTOSAR_CP_SWS_WatchdogManager
[13] Specification of PDU Router
AUTOSAR_CP_SWS_PDURouter
[14] Specification of Communication
AUTOSAR_CP_SWS_COM
[15] Specification of Communication Manager
AUTOSAR_CP_SWS_COMManager
[16] Specification of Network Management Interface
AUTOSAR_CP_SWS_NetworkManagementInterface
[17] Specification of TCP/IP Stack

9 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

AUTOSAR_CP_SWS_TcpIp
[18] Description of the AUTOSAR standard errors
AUTOSAR_CP_EXP_ErrorDescription
[19] Specification of Operating System
AUTOSAR_CP_SWS_OS
[20] Specification of Synchronized Time-Base Manager
AUTOSAR_CP_SWS_SynchronizedTimeBaseManager

10 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

5 Introduction to CDD
A Complex Driver is a software entity not standardized by AUTOSAR that can access
or be accessed via AUTOSAR Interfaces and/or Basic Software Modules APIs.
According to the document [3] Layered Software Architecture, a CDD is a specific
module located in the Complex Drivers Layer of the Basic SoftWare which interacts
with standard BSW modules or Rte.
• A CDD may need to interface to modules of the layered software architecture
• A module of the layered software architecture may need to interface to a CDD
• A CDD may need to interface SW-Cs via Rte

Figure 5.1: CDD in Layered Software Architecture

The main goal of the CDD is to implement complex sensor evaluation and actuator
control with direct access to the microcontroller using specific interrupts and/or complex
microcontroller peripherals, external devices (communication transceivers, ASIC...) to
fulfill the special functional and timing requirements.
In addition it might be used to implement enhanced services / protocols or encapsu-
lates legacy functionality of a non-AUTOSAR system.
CDD Implementation might be application, Microcontroler and ECU dependent.
Finally, the CDD can serve as mechanism of migration to introduce existing or new
concepts into the AUTOSAR Software Architecture.

11 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

6 CDD design recommendations

To interface and ease CDD integration in AUTOSAR architecture, the designer shall
take into consideration the following points.

6.1 Documentations

6.1.1 User’s Manual

CDD designer shall provide a User’s Manual to ease the integration and provide infor-
mation to customers:
• CDD introduction and overview
• Description of the functional operations (initialisation, normal, shutdown, fault op-
eration...)
• Description of the relationship with and need from other BSW Modules, SchM
and Rte; e.g. memory blocks from NvM, critical sections to configure.
• Files structure and dependencies
• Description of the interfaces (including services): name, description, re-entrancy,
parameters (names, types, ranges, values), return value (name, type, range, val-
ues), configuration class.
• Description of the non-functional requirements: timing and behaviour require-
ments, resource usage, behaviour with other BSW modules or SW-C...
• Description of the Dem errors, optionally Det errors, debug variables
• Description of the configuration parameters (names, types, ranges, values).
• Description of the memory mapping needs (Flash, RAM)
• Usage limitations and open issues
• Integration constraints and requirements to other modules
• Examples

6.1.1.1 Module ID

The range of possible module IDs for CDDs is described in the document [4] List of
Basic Software Modules.

12 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

6.2 Implementation
There are few constraints coming from AUTOSAR regarding CDD implementation. At
least:
• CDD shall respect the input specifications [2], [3], [5], [6], [7], [8], [9], [10].
• CDD shall protect its critical resources defining critical sections which can be
handled by SchM or OS mechanisms.
• CDD mode may be manageable by EcuM and BswM modules.
• CDD may handle its memory sections using the memory mapping mechanisms.
• CDD may report its errors using Det or Dem modules.

6.3 CDD Files

This section is only a recommendation and does not completely define the module files
structure.

6.3.1 Code file(s)

The code file structure of the CDD module is not fixed, beside the requirements in the
document [2] General Requirements on Basic Software Modules and the document [5]
General Specification on Basic Software Modules.
At least, a CDD_<MODULENAME>.c shall be provided.
Interrupt functions may be placed in a CDD_<MODULENAME>_Irq.c.
Callout functions may be placed in a CDD_<MODULENAME>_Callout.c.
Depending of the need, C objects generated at Link time from configuration may be
placed in CDD_<MODULENAME>_Lcfg.c file.
Depending of the need, C objects generated at Post Build time from configuration may
be placed in CDD_<MODULENAME>_PBcfg.c file.
If an implementation of the CDD module requires additional code files, it is free to
include them.

6.3.2 Header file(s)

The following figure contains the defined AUTOSAR header file hierarchy of the CDD
module.

13 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

CDD module shall provide a header file structure, so that users of the CDD module
needs only to include the CDD_<MODULENAME>.h file.
CDD module may provide a CDD_<MODULENAME>_Cbk.h header file if some call-
back functions has to be handled by other BSW modules.
Depending of the need, C objects declarations generated from configuration may
be placed in CDD_<MODULENAME>_Cfg.h, CDD_<MODULENAME>_PBcfg.h,
CDD_<MODULENAME>_Lcfg.h files.
If an implementation of the CDD module requires additional header files, it is free to
include them. The header files are self contained, that means they will include all other
header files which are required by them.
CDD module may include Det.h and/or Dem.h header files to report errors.
CDD module may include <Mip>_MemMap.h header file if some memory mapping
area have to be defined where <Mip> is the Module Implementation Prefix.
CDD module may include Rte_CDD_<MODULENAME>.h header file if interfaces to
the Rte are configured.

6.3.3 Recommended files structure

The following figure describes the basic defined AUTOSAR header files hierarchy of a
CDD module.

Figure 6.1: Header File Structure for CDD

14 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

6.3.4 Coherence checks

The CDD module shall avoid the integration of incompatible (.c or .h) files as defined in
the document [5] General Specification on Basic Software Modules.

6.4 Behaviour and Interfaces description

Some CDD not only have interfaces to other BSW modules or clusters, but have also
more abstract interfaces accessed from application SW-Cs via the Rte.
In these cases a CDD SW-C type is needed to interface the Rte and CDD shall respect
the requirements of the document [9] Basic Software Module Description Template
This description file should contain:
• Description of the CDD services
• Types and ports interfaces
• Description of internal behaviour and runnable Entities
• Description of the required triggered events of runnable Entities
• Description of exclusive Areas for shared resources protection
• Memory mapping
The more abstract interfaces required here are called AUTOSAR Interfaces which are
described by means of the Software Component Template (SWCT), they consist of
ports, port interfaces and their further detailing.
The root classes of the SWCT used to describe these elements for CDD are
ComplexDeviceDriverSwComponentType.
The function calls from the Rte into these CDD shall be modelled as RunnableEn-
tities which are also contained in the SWCT. The root class of the SWCT used to
describe the RunnableEntities (and a few other things) is called SwcInternal
Behavior.
Hints: CDD runnables should be designed to reduce Rte overhead, e.g.
• Server runnables is prefered to be re-entrant: can be invoked con-
curently = TRUE.
• Runnables signature to be: void or StdReturnType RunnableName(void
or parameters)

15 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

6.5 Parameters configuration

If parameters has to be configured using an AUTOSAR GCE, CDD shall respect the
requirements of the document [10] Specification of ECU Configuration.
At Least:
• AUTOSAR and Software versions of the modules shall be identified by the con-
figuration file.
• Det should not be included for production phase, so a parameter is needed in the
configuration to deactivate the error report.

16 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

7 Interfacing to other modules

This section describes the relations to other modules within the basic software.

7.1 Interfacing to Rte and SW-C

CDD may need to interface to SW-Cs through the Rte:
• Required ports and interfaces shall be specified and implemented according to
AUTOSAR (AUTOSAR interface).
• In some cases, CDD has to use some port specific parameters defined by Rte.
Refer to previous chapter 6.4 .

7.2 Interfacing to libraries

CDD can use AUTOSAR libraries.
Example: CDD can use E2E library mechanism to transmit the communication protec-
tions against a corruption or a loss of data.

7.3 Interfacing to standard BSW modules

CDD may need to interface to other modules in the layered software architecture, or
modules in the layered software architecture may need to interface to a CDD. If this is
the case, the following recommendations apply:
Interfacing from modules of the layered software architecture to CDD:
CDD shall offer interface(s) which can be generically configured by the accessing AU-
TOSAR module.
A typical example is the PDU Router: a CDD may implement the interface module of
a new bus system. This is already taken care of within the configuration of the PDU
Router.
Interfacing from a CDD to modules of the layered software architecture:
This is only allowed if the respective modules of the layered software architecture offer
the interfaces, and are prepared to be accessed by a CDD. Usually this means that:
• CDD shall take care of re-entrancy of interfaces. For non-re-entrant interfaces
only one caller can access the interface. For conditionally re-entrant interfaces
several callers may access the interface concurrently if they use different IDs.

17 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

• If call back routines are used, the names are configurable

• No upper module exists which does a management of states of the module (par-
allel access would change states without being noticed by the upper module)
CDD shall provide all configuration parameters which are necessary to satisfy other
AUTOSAR modules which rely on the information, e.g. if Dem is called to report pro-
duction errors, the Dem error codes must be defined and referenced inside the CDD
configuration in line with the configuration standard for Dem error code definition.
In case of multi core architectures, refer to chapter 7.4 .
In general, it is possible to access the following modules:

7.3.1 Interfacing with MCAL modules

CDD may directly access to microcontroller resources (e.g. a hardware timer). CDD
should use the MCAL if the needed resource is managed by a MCAL module and if
there are no specific constraints (e.g. real time need). This is highly recommended
to avoid conflicts (e.g. Parallel access to the same group/channel/etc. is mostly not
allowed because DIO services are not re-entrant).
In this case, CDD shall use the standard API of the MCAL modules to access MCAL
modules.

7.3.2 Interfacing with BSW Mode Manager & ECU State Manager

The EcuM and the BSW Mode Manager shall be the exclusive access points to the
mode management in case the ECU State Manager is used.
ECU State Manager should be used for:
• Init and De-Init functions shall be exclusively called by the EcuM and/or the BswM
modules.
• If a CDD handles a wakeup source, it must follow the protocol for handling
wakeup events specified in the document [11] Specification of ECU State Man-
ager.
BSW Mode Manager should be used for:
• CDD modes changed management
• The BswM (which is on the master core) ascertains that the ECU should be shut-
down and distributes an appropriate mode switch to each core. The CDD on
the slave cores must catch this mode switch, de-initialize appropriately and send
appropriate signals to the BswM to indicate their readiness.

18 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

7.3.3 Interfacing with Memory Stack

Direct access outside NVRAM manager is possible if it is exclusively managed by CDD.

If CDD uses the standard memory stack, the NVRAM Manager is the exclusive access
point to the memory stack: CDD shall use the NVM’s API to access memory.

7.3.4 Interfacing with Watchdog Stack

The Watchdog manager may supervise the execution of one or more runnables of a
CDD as supervised entities. The watchdog manager shall be configured and CDD
runnable shall call Watchdog API as described in the document [12] Specification of
Watchdog Manager.
The Watchdog Manager is the exclusive access point to the watchdog stack.
CDD should not interact directly with the watchdog manager but through the Rte de-
fined ports.
Usually, the Rte is responsible for propagating Checkpoint information from Supervised
Entities in CDD to the Watchdog Manager module. The Watchdog Manager module
uses the services of the Runtime Environment to inform CDD about changes in the
supervision status.
To control the state-dependent behavior of CDD, the Rte provides the mechanism of
mode ports. A mode manager can switch between different modes that are defined in
the mode port. The CDD that connects to the mode port can use the mode information
in two ways:
• The CDD can query the current mode via the mode port.
• The CDD can declare Runnables that are started or stopped by the Rte because
of mode changes.
In case of failure, the Watchdog Manager may inform the CDD Supervised Entity about
supervision failures via the Rte Mode mechanism. The CDD Supervised Entity may
then take its actions to recover from that failure.

7.3.5 Interfacing with Communication Stack

Several access points are possible:

• It is possible to interface to the PDU Router module to handle IPDU.
• It is possible to interface to the <Bus> Interface.
• It is possible to interface to the NM module.
• It is possible to interface the TcpIp module.

19 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

• It is possible to directly interface to Com module as it is possible to have signal

interface.
Generally, it is not suitable to mix the access points, i.e. use PduR access at the same
time as Com access or <Bus> Interface.
CDD which handles communication and may trigger transmission of PDUs should pro-
vide an API to enable/disable transmission. This will e.g. enable the Dcm to disable the
whole communication in a corresponding diagnostic request. These functions provided
by the CDD may be called in the configured action list which is linked to this function.
For example to these functions, refer to similar API within the communication stack.

7.3.5.1 Interfacing with PDU Router

The PduR is the exclusive bus and protocol independent access point to the commu-
nication stack for IPDU.
CDD shall use standard APIs of the PduR module to access IPDU.
When CDD Interacts with the PduR, one container per CDD shall be configured within
the PduR.
Refer to the document [13] Specification of PDU Router to get more details.

7.3.5.2 Interfacing <Bus> Interfaces modules

The <Bus> Interfaces modules are the exclusive bus specific access point to the com-
munication stack.
CDD shall use standard APIs of the <Bus> Interfaces modules to access IPDU.
When CDD interacts with <Bus> Interface, CDD uses the access functions defined
for <Bus> Interface and <Bus> Interface callbacks shall be configured according to
CDD needs. <Bus> Interface shall be configured to include CDD_<MODULENAME>_
Cbk.h header file.
Refer to <BUS> Interface specifications and user’s manual for details.

7.3.5.3 Interfacing with Com Module

If CDD handles Com signals, CDD shall use standard APIs of the Com module or Rte
define to access signals.
Refer to the document [14] Specification of Communication to get more details.

20 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

7.3.5.4 Interfacing with Com Manager

If CDD uses Com signals, CDD shall use standard APIs of the Com Manager to request
a "Communication Mode".
If CDD handles a <Bus> which is not AUTOSAR Standard, <Bus> States should be
handled by ComM to coordinate bus communication stack.
Refer to the document [15] Specification of Communication Manager to get more de-
tails.

7.3.5.5 Interfacing with Network Management Interface module

If CDD handle a <Bus> which is not AUTOSAR Standard, <Bus> States should be
handled by a <Bus>Nm_CDD module.
The <Bus>Nm_CDD should provide services to the Network Manager to manage <Bus>
States.
Refer to the document [16] Specification of Network Management Interface to get more
details.

7.3.5.6 Interfacing with TCP/IP module

The TcpIp module is the exclusive socket-based access point to the communication
stack.
CDD shall use standard APIs of the TCP/IP module to access sockets.
Refer to the document [17] Specification of TCP/IP Stack to get more details.

7.3.6 Interfacing with XCP module

If CDD handle a <Bus> which is not AUTOSAR Standard, XCP can interface <Bus>_
CDD to forward the data.
The XCP module offers configurable interfaces to be used by CDD:
• <Cdd_Transmit> : API to request the sending of a PDU via CDD
• <Xcp_CddTxConfirmation> : API to confirm the successful transmission of
the PDU
• <Xcp_CddRxIndication> : API API called by the CDD to indicate a successful
reception of a LPDU.
The XCP module shall be configured to allow CDD functionalities: XcpOnCddEnabled
parameter shall be activated.

21 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

If needed, CDD may call callback function Xcp_<module>RxIndication.

7.3.7 Interfacing with Diagnostic Log and Trace

If CDD handle a <Bus> which is not AUTOSAR Standard, Dlt can interface <Bus>_
CDD to forward the data.
The Dlt forwards the data to the Dcm or a CDD which uses a serial interface for exam-
ple.
Dlt does not define a specific communication interface. The Dlt specification defines
an API to an internal Dlt communication module. It is up to the implementer, how this
communication module is implemented and how it communicates with a possible CDD
(e.g. Serial or USB).

7.3.8 Interfacing with Default Error Tracer and Diagnostic Event Manager

CDD shall report errors using Det, Dem as described in the document [18] Description
of the AUTOSAR standard errors.
CDD shall use standard APIs of the Det & Dem modules.
CDD shall react as any BSW modules. Error ID shall be defined locally in the CDD
module. CDD is responsible for initiating an internal recovery.
Note: For calls to the Det the module id and/or the instance id parameter can be used
to distinguish between different CDDs.

7.3.9 Interfacing with OS

Usually, only the BSW Scheduler and the Rte shall use OS objects or OS services.
Therefore, the CDD should only access to GetCounterValue and GetElapsed
CounterValue services of the OS.
The OS can be accessed by CDD as long as the used OS objects are not used by
another BSW module, e.g. CDD could create an OS alarm and use it.
OS can notify CDD by OsRestartTask that an OS-Application has been terminated
and restarted. The CDD will then have to take appropriate clean-up actions.
Refer to the document [19] Specification of Operating System to get more details.

22 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

7.3.10 Interfacing with StbM module

If a CDD module implements a user defined Timebase Provider, i.e., if it handles Global
Time Synchronization messages, the CDD module shall use the StbM module API:
• StbM_GetCurrentTime to read latest time base value from StbM
• StbM_GetCurrentTimeRaw, StbM_GetCurrentTimeDiff to calculate time
base value updates
• StbM_BusSetGlobalTime to forward time base values received on the bus to
StbM
This interface is currently limited to Timebase Providers without HW time stamping.
Refer to the document [20] Specification of Synchronized Time Base Manager for de-
tails about the API.
Relevant details of the configuration of the CDD module for Global Time Synchro-
nization are specified by the container CddGlobalTimeContribution in the CDD’s
module definition. Refer to the document [10] Specification of the ECU Configuration.

7.4 CDD in multi-cores system

CDD can be used in multi-cores architecture.
In case of multi core architectures, CDD can reside on any core(s) respecting the
following rules:
• Crossing partition and core boundaries is permitted for module
internal communication only, using a master/satellite implementation.
• Consequently, if the CDD needs to access standardized interfaces of the BSW, it
needs to reside on the same core.
• In case a CDD resides on a different core, it can use the normal port mechanism
to access AUTOSAR interfaces and standardized AUTOSAR interfaces. This in-
vokes the Rte, which uses the IOC mechanism of the operating system to transfer
requests to the other core.
• However, if the CDD needs to access standardized interfaces of the BSW and
does not reside on the same core,
– either a satellite providing the standardized interface can run on the core
where the CDD resides and forward the call to the other core
– or a stub part of the CDD needs to be implemented on the other core, and
communication needs to be organized CDD-local using the IOC mechanism
of the operating system similar to what the Rte does.

23 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline

 Complex Driver design and integration guideline
AUTOSAR CP R23-11

• Additionally, in the latter case the initialization part of the CDD also needs to
reside in the stub part on the different core.

7.5 CDD module of the MCAL

CDD for microcontroller driver can be performed but it cannot access to other standard
module as it is in the lower layer except Det, Dem, SchM...
In general, if some limitations are applied to a specific layer, it applies also to CDD.

24 of 24 Document ID 622: AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline