AUTOSAR (11) Complex device drivers - CDD

AUTOSAR Complex device drivers - CDD

A Complex Device Driver (CDD) is a BSW module which implements complex sensor evaluation and actuator control with direct access to the microcontroller using specific interrupts and/or microcontroller peripherals. The purpose of these drivers is to fulfill the special functional and timing requirements for handling complex sensors and actuators.

    

Mapping from ECU SW-Architecture

The Complex Device Driver could not be mapped to a specific layer and has therefore been taken over from the ECU software architecture with no change. The Complex Device Drivers fulfill the special functional and timing requirements for handling complex sensors and actuators. A Complex Driver implements complex sensor evaluation and actuator control with direct access to the μC using specific interrupts and/or complex μCperipherals (like PCP, TPU), e.g.

• injection control

• electric valve control

• incremental position detection

Implementation is highly μC, ECU and application dependent, and upper interface is specified and implemented as AUTOSAR Interfaces.

Recommended files structure

CDD should have interfaces with DEM, DET , and could have interfaces and data exchange with all other BSW. It is the only module in AUTOSAR which could have access directly to MCAL modules without any interfaces.  So CDD is a badass module and may directly access to microcontroller resources , for example a hardware timer. :)

Component usage

Non-Standardized Drivers

Further on the Complex Device Drivers will be used to implement drivers for hardware which is not supported by AUTOSAR. If for example a new communication system will be introduced in general no

AUTOSAR driver will be available controlling the communication controller. To enable the communication via this media, the driver will be implemented proprietary inside the Complex Device Drivers. In case of a communication request via that media the communication services will call the Complex Device Driver instead of the communication hardware abstraction to communicate. Another example where non-standard drivers are needed is to support ASICs that implement a non-standardized functionality.

Source code template for a CDD

• https://github.com/openAUTOSAR/classic-platform/tree/master/cdd
  

Documentation

• https://www.autosar.org/Classic platform
• https://cdn.vector.com/cms/content/know-how/_case-studies/FAW-AUTOSAR-driver-library-for-engine-controller-CaseStudy-EN.pdf 
• https://elearning.vector.com/mod/page/view.php?id=437
• https://www.vtronics.in/2019/09/autosar-for-dummies-part-8-complex.html 
• https://github.com/openAUTOSAR/classic-platform
  

 AUTOSAR articles (for articles written in Romanian please select your language from right part of webpage)

• https://automatic-house.blogspot.com/search/label/AUTOSAR
• https://automatic-house.blogspot.com/2014/08/calcularea-crc-ului-pentru-standardul.html 
• https://automatic-house.blogspot.com/2019/03/autosar1-prezentare-generala.html
• https://automatic-house.blogspot.com/2019/03/autosar2-arhitectura.html 
• https://automatic-house.blogspot.com/2019/04/autosar3-comstack-can.html
• https://automatic-house.blogspot.com/2019/05/autosar5-comstack-cantp.html 
• https://automatic-house.blogspot.com/2019/07/autosar6-communication-services-in.html
• https://automatic-house.blogspot.com/2021/11/autosar-7-cryptostack-basics.html
• https://automatic-house.blogspot.com/2022/11/autosar-8-communication-over-ethernet.html
• https://automatic-house.blogspot.com/2022/11/autosar-9-error-handling-and-diagnostic.html
• https://automatic-house.blogspot.com/2022/11/autosar-10-memory-stack.html

Thank you for attention !

For question please add a comment or send me an email to: simedruflorin@automatic-house.ro. 

Have a nice day ! 

 Back to top of page