S32K MCAL SW integretion environment problem

[joan_ni]

Hi, Teams,

      As we know MCAL is developed as a SEOOC , according to below description in safety manual .

<sMCAL Software Safety Manual
                                                            For S32K14X>    Version 1.0

     we have below questions

1. is the yellow marked assumptions means we should use MPU to protected all safety related MCAL modules list in the safety manual ?

2. base on question 1, even though modules we not used , or not in the safety critical path in our application , need we still protect these not reverent(not in safety critical path) modules in MCAL ? 

3. Are the modules in MCAL are interacting with each other in sub-functions therefore MCAL safety manual request to protect it as complete  ? 

Hope you can give the reply quickly , thank you very much , wish a good day ~~

Joan

[joan_ni]

@JRoberto @danielmartynek @namnguyenviet 

 is there any expert can help to explain this ? thank you very much~~

Joan 

[namnguyenviet]

Hello @joan_ni,

Sorry for late reply.

1. MPU is one of the possible implementations to fulfil the requirements.

2. If a SEooC module is not used/not in safety context application path, then from my point of view, it's not necessary to protect its elements (e.g. global variables, stacks,...) since they are not used/ not in a critical behaviors during runtime eventually in your application.

3. These sub-modules needs to be protected as well, w.r.t SMCAL_CPR_EXT69 and SMCAL_CPR_EXT70

Best Regards,

Nam

[joan_ni]

Hi, Nam ; @namnguyenviet 

      thank you for your kind reply, for the point3, for example , there are CAN modules and SPI modules in MCAL(Both are SMCAL modules), in our product system level, CAN is safety related, but SPI is not safety related, Need we protected both of them, or only protect the CAN module is enough ?

because MCAL is developed by NXP, we don't know if there is any interaction between different modules. 

Joan 

[namnguyenviet]

Hello @joan_ni,

For sure these two communication drivers can't interact by function calling to each other, in that case you just need to protect the driver which is in safety critical scope. A driver will interact to another driver by function calling, only when it's required to configure another MCAL driver affects to that driver itself. For instance, a SPI driver will need to call to a MCL CDD API, in order to enable DMA method. In that case, MCL should be protected as well. We note this dependency in our UM/IM so that you can refer to these document.

Hope it helps.

Best Regards,

Nam

[Samuel_2015]

This is a question also confuse me, hope this question could be responded ASAP.