Understanding Autosar Structure and MCAL Sample Application

talha_uyar — Wed, 06 May 2020 10:37:56 GMT

Hi,

This is going to be a very general question. I am trying to understand the necessary steps of developing a custom application which satisfies the Autosar Requirements. As far as I can understand the MCAL provided by the NXP takes care of the MCAL layer of Autosar. However, there are still many more modules required in the Autosar structure, such as the I/O Hardware Abstraction Layer etc.

1- What I am having a hard time understanding is that in the sample application, SysDal is accessed by the main application directly; and it uses the IoDal directly to access various drivers. However, according to the Autosar Requirements, shouldn't the main application access everything else through the Rte module? Also, shouldn't we access the I/O drivers through a I/O hardware abstraction layer?

2- Let's say I want to build a custom application which communicates over the CAN bus, and controls a motor based on the received PDU. Would it be sufficient to develop seperate software components for CAN and LED_Control, similar to the SWCs used in the sample application. I.e., these SWCs would the use the Driver APIs through ComDal and IoDal, and the SysDal scheduler would be used for the MainFunction calls?

3- If I follow the External Assumptions provided in the Integration Manual of the MCAL drivers, and reach the drivers through IoDal, SysDal, and ComDal; and use SysDal for the BSW Scheduler, would that be sufficient to satisy the Autosar Requirements? What other rules and requirements should I consider when building an application that satisfies Autosar requirements?

4- Is using IoDal, ComDal, and SysDal required? Or can I simply call the driver functions in the main application, or in the SWCs, and build my own scheduler? If I follow the External Assumptions provided in the Integration Manual of the MCAL drivers, without using SysDal, IoDal, and ComDal; would that violate Autosar Requirements?

All answers are appreciated.

M. Talha Uyar

Re: Understanding Autosar Structure and MCAL Sample Application

namnguyenviet — Fri, 08 May 2020 05:12:58 GMT

Hi talha.uyar@karel.com.tr‌,

1. It's not mandatory to include all the AUTOSAR layers in your application. Depend on your system requirements, performance, adaption,..., you can decide to include RTE or ECU abstraction layers into your application architecture.

2. Yes, it's possible to do that, i.e., you can create your own low level drivers, then use ComDal and IoDal abstract to these low level drivers.

3. AUTOSAR requirements are separated between each components, and as you've said, each components also have external assumptions when integrate to application. I can say if you've followed all the external assumptions while using IODal, SysDal and ComDal to interact with MCAL layers, it's sufficient to be satisfied the AUTOSAR requirement, since each MCAL drivers has followed the AUTOSAR requirements by itself.

4. Even when you don't want to use SysDal, IODal, and ComDal to interact with MCAL layers, and use your own integrator or simply call the MCAL APIs (of course, with following the external assumptions), it's still satisfied with AUTOSAR requirements.

Nam

topic Re: Understanding Autosar Structure and MCAL Sample Application in S32K

Understanding Autosar Structure and MCAL Sample Application

Re: Understanding Autosar Structure and MCAL Sample Application