Hi raghurajappa,
I think this is a very good topic. I would like to invite everyone to participate into this discussion and share their knowledge and expectations.
We (NXP Model-Based Design Team) are pursuing a similar investigation into this direction and we have also engaged MathWorks in discussions about this topic.
Here is what we know so far as facts to support such investigation:
- ~70% of automotive customers are using AUTOSAR
- ~90% of the software development effort is reduces when using AUTOSAR
- 100% of user software application is reused when using AUTOSAR
The interaction between customer applications and HW provider drivers is shown below.
Currently, MathWorks is providing a solution Embedded Coder Support Package for AUTOSAR Standard - File Exchange - MATLAB Central that covers the Application Layer and some components within the Services Layer as shown below highlighted in red
For some of the users this kind of approach would be good enough. They can use Model-Based Design to create AUTOSAR compliant applications (App Layer) and may use PIL just to test the applications on the NXP hardware.
The missing link for a complete AUTOSAR solution in MATLAB/Simulink is: how to support ECU & MCU Layers ?
Regarding your questions:
The intention is to make Simulink models(blocks) out of the AUTOSAR MCAL drivers.
Is this possible?
For the moment this is something we want to understand better prior in formulating an answer. In fact i'm looking for the same answers.
In theory, that should be possible at least as a static configuration.
Here is what i know: the NXP MCAL drivers (Microcontroller Abstraction Layers) are shipped as c/h/ sources BUT they also require an EB Tresos Studion configuration file that is used to generate the appropriate structures for the MCAL drivers. This is an important bottleneck in creating the Simulink Blocks because you will still need to execute this step prior of getting all the header files for the MCAL driver. If we assume static configurations for the MCAL drivers, then that becomes suddenly possible.
Question: Is that an acceptable solution ? (static driver configuration pre-built with Tresos)
I know that SWC (AUTOSAR software components) can be imported provided their SWC ARXML, but I don't know if it's possible to import MCAL drivers into Simulink using only BSWMD?
My understanding is MATLAB supports 2 development flows that are applicable only for Application Layer.
- Top-Down approach where you can import existing ARXML into Simulink to create Simulink Models based on software components created with AUTOSAR Authoring Tools
- Bottom-up approach where you start from Simulink models and then export the ARXML descriptions and C code to be used in the AUTOSAR environment.
But, both approaches are only applicable to the Application Layer. Am i wrong ?
I do not know how BSWMD are working and what is their exact content, but i would love to know more about it. This might be a good followup question with Mathworks AUTOSAR team. Can you share more insights about how you plan to use BSWMD ?
If this is not possible, is it possible to atleast import MCAL drivers (C/H files) into Simulink just like regular S-function/MEX files?? If yes, could you please help me realise this workflow?
My vision is to have the c/h file as resources in the MCAL external delivery package (do not even touch them) and use the MATLAB TLC to inject functions calls for each driver.
Nonetheless, the big gap in the workflow, which i do not fully understand yet, is how a Simulink user is going to link the applications from (App Layer) with the MCAL drivers via ECU/Service Layers. That is a missing piece of information i do not own yet ?
If there are users here that have experience with normal AUTOSAR development flow, i would love to hear how they did it. All i know is that the link between Applications and MCAL should happen via RTE. It is not clear to me how this will be done in a Simulink environment.
Looking forward for new insights and questions
Best regards,
Daniel
