CODEWITHSUNDEEP
autosar
Lkaf Temravet
Lkaf Temravet

Reputation: 993

is it allowed to add functionalities to MCAL AUTOSAR modules

when developing MCAL layer for new board, is it allowed to add new functionalities which are not specified in AUTOSAR SPECIFICATIONS?. for example add to MCAL ICU functionality which measure the length of a frame (there is a dedicated module in the MCU which measure the length of a LEVEL of input frame)

Upvotes: 3

Views: 511

Answers (4)

GiatManos
GiatManos

Reputation: 105

In theory, the entire functionality and interfaces of your micro should be covered from the chip manufacturer's provided MCAL. If that is the case, then the ideal solution would be to develop a CDD (Complex Device Driver), as mentioned in another answer above, to implement your desired functionality.

This, of course, requires your AUTOSAR stack provider to verify the CDD implementation and integrate it in the AUTOSAR stack and for any updates you would want to make to it they would have to re-verify it and re-integrate and so on... As you can understand this is a very costly process and in my experience, nobody in the industry, unless maybe OEMs, go with it.

What most reputable suppliers do, is access the MCAL interfaces required through RTE and then create an application/CDD hybrid component that implements the required functionality. This solution makes it possible for you to implement what low level functionality you want without, in theory at least, violating the AUTOSAR standard.

This solution is also fully compliant with the ASPICE standard, as long as the interfaces are explicitly and well defined.

Upvotes: 0

Torsten Knodt
Torsten Knodt

Reputation: 766

People sometimes do that and so far I thought that it is against the intention of AUTOSAR. However, when you take a look onto page 20, to the first bullet point of "AUTOSAR extensibility" in document AUTOSAR Layered Software Architecture, it says:

The AUTOSAR Software Architecture is a generic approach: standard modules can be extended in functionality, while still being compliant, still, their configuration has to be considered in the automatic Basic SW configuration process

However, on the other side, I also overheard an ASPICE audit, in which extensions and usage of the AUTOSAR interfaces where listed as violations.

The right approach, to my feeling, would be to add a CDD for the HW module of the MCU.

However, I understand that this can make things much more complicated and I guess this is the reason why this is allowed.

Upvotes: 0

hrushi
hrushi

Reputation: 296

If adding vendor specific code/ feature, then may be you could add a configuration parameter in the module's paramdef. The user may then configure as per his requirement and the corresponding code can then be enabled/ disabled accordingly.

Upvotes: 0

Naveen
Naveen

Reputation: 31

The very idea of AUTOSAR is abstraction and code portability . When we say adding a non AUTOSAR function to a MCAL driver , No integrator will know the existence of such function (since it is not supposed to be included ) unless he looks into the code ,that being said it doesn't mean that code wouldn't work ,if client insists you can include such function but both should be aware that you violating the rules of AUTOSAR

Upvotes: 3

Related Questions