MCAL, Actuators and Sensor PART-2

Hello Readers,
My name is Santosha S Chikkur, and I work at Luxoft India as a Junior Software Developer. Luxoft has given me several opportunities to work on various projects, which has inspired me to learn the essential processes involved in developing AUTOSAR Modulеs and Add-Ons in MCAL, Actuators and Sensor PART-2

CDD Development and Integration

Introduction

• A Complex Driver is a software program entity now no longer standardized via way of means of AUTOSAR that could get right of entry to or be accessed through AUTOSAR Interfaces and/or Basic Software Modules APIs.
• As per 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.
• Used to fulfill the special functional and timing requirements for handling complex sensors and actuators and used to handle the tasks related to the strict timing.
• Complex drivers functionality is highly dependent on the MCU and application, and the code may not be easily portable.

• Which connects the SWC of the application layer directly to the MCU via RTE.
• Useful for writing functions/controllers for peripherals/external devices not defined by AUTOSAR.
• It is highly hardware dependent and hence there is very less scope of reuse ability or portability.

Key Characteristics of CDDs:

Direct Hardware Access: CDDs talk immediately with the hardware, bypassing the BSW and RTE. This lets in for quicker reaction instances and finer manage over hardware interactions. Highly Efficient: CDDs are optimized for performance, making them best for time-crucial programs consisting of engine manage and driving force help systems.
Non-Portable: Due to their direct hardware interaction, CDDs are generally particular to a selected MCU and hardware configuration. This reduces their portability throughout extraordinary platforms.
Customizable: CDDs provide more flexibility in comparison to conventional AUTOSAR drivers. They may be custom designed to satisfy particular hardware necessities and functionalities now no longer supported via way of means of the standard

When to Use a CDD:

Hardware-precise functionalities: If the preferred capability isn't always to be had withinside the popular AUTOSAR driving force set, a CDD may be evolved to at once get admission to the hardware and put into effect the specified capability. High-overall performance requirements: When the timing constraints are stricter than what the AUTOSAR OS can handle, a CDD may be hired to gain the preferred overall performance.
Interacting with outside gadgets: CDDs are perfect for speaking with outside gadgets that aren't supported via way of means of the usual AUTOSAR interfaces.

CDD in Software Development

• Introduced a modularized and layered architecture called Common Embedded Software Architecture (CESAR).
• In CESAR Architecture, we are focusing on CDD (Complex Device Driver) layer. It consists of Target Layer, Hardware Layer and Device Layer.
• Used to deal with different sensors like Wheel Speed Sensor, Acceleration Sensor, Analog Inputs, Digital Inputs, etc and actuators like Switches, Valves, etc.

CDD Development Steps – Refer the CDD Module Development.pdf

• Analysis of requirements provided by the customer.
• Create a Detailed Design Document.
• Create a CDD software component using Davinci Developer.
• Configure the respective MCAL modules.
• Add a runnable to CDD Developer and map to specified task using Configurator.
• Configure the P-R ports connections. Functional testing of CDD module.
• Implement watchdog monitoring mechanisms due to the strict timing purposes.

Module Files Structure in AUTOSAR/CESAR

AUTOSAR File Structure

• static file

  1. Module.h
  2. Module.c

• Generated Files

  1. Module_cfg.h
  2. Module_cfg.c

• Other Specific Files

  1. PlatformTypes.h
  2. StdTypes.h
  3. Compiler.h

CESAR File Structure

• static file

  1. Module.h
  2. Module.c

• User Files

  1. Cdd_Module.c
  2. Module_Usr.inc
  3. Module_Signals.inc

• Other Specific Files

  1. PlatformTypes.h
  2. StdTypes.h
  3. Compiler.h

Software Development Cycle (SDLC)

Different Steps:-

1. Planning And Requirement Analysis.
2. Defining Requirements.
3. Designing Architecture.
4. Designing Architecture.
5. Developing Product.
6. Product deployment and maintenance.
7. Documentation, Support and Training.

Benefits of Using CDDs:

• Flexibility and manage: CDDs provide more flexibility and manage over hardware interplay than fashionable AUTOSAR drivers. - Better overall performance: CDDs can attain substantially higher overall performance way to direct hardware get right of entry to and decrease overhead.
• Faster time to market: bypassing fashionable levels, improvement and integration of CDDs may be quicker than improvement and integration of AUTOSAR software program components.

Challenges of Using CDDs:

• Non-portability: CDDs are generally precise to a particular MCU and hardware configuration, making them difficult to reuse all through high-quality platforms. - Increased complexity: Developing and finding out CDDs require specialized device and methodologies, consisting of complexity to the development process. - Limited integration: CDDs have constrained integration with the same old AUTOSAR layers, which could bring about disturbing conditions in device integration and finding out.

Conclusion

AUTOSAR CDDs are a effective device for growing high-performance, hardware-particular functionalities that aren't supported with the aid of using the same old AUTOSAR framework. However, their non-portability and improved complexity require cautious attention earlier than identifying to apply them. By expertise the benefits, challenges, and use instances of CDDs, builders could make knowledgeable choices approximately the usage of them of their AUTOSAR projects.