CODEWITHSUNDEEP
autosar
Lkaf Temravet
Lkaf Temravet

Reputation: 993

What makes a BSW an ASIL BSW in AUTOSAR?

In Autosar, what determines if a BSW module is ASIL qualified?

I'm talking mainly about COM RTE OS modules for example.

Are there some added safety options?
Or is the module redesigned in some kind of a safe way?

Upvotes: 1

Views: 1102

Answers (3)

kesselhaus
kesselhaus

Reputation: 1496

The OS and RTE are actually the main parts of AUTOSAR, to provide an safety environment. The OS has means to separate the QM and ASIL applications by different OsApplication and OsTasks with according MPU settings per OsApplication and/or OsTasks, which are reconfigured on context switches.

The RTE is the glue code, which also includes the actual Task bodies, because the Runnables are added to Tasks by the RteEventToTaskMapping and RteBswEventToTaskMappings. The RTE generator also generates the SWCs RTE interfaces, including e.g. the E2E Transformer generation for E2E protected signals read/written on SWC S/R-ports. Also C/S-interfaces should be decoupled if called from different safety context (e.g. ASIL SWC calling QM SWC C/S interface).

The COM does not necessarily need to be ASIL, but it could be if the COM Timeout Monitoring is used. But this could also be done by E2E Protection and the ASIL-SWC runnable in the ASIL-context. But also consider, if COM through RTE calls callback handlers in ASIL-SWCs.

Usually, also the WDGM (or an extension) is used, for Runnable Alive/Logical-supervision as part of the safety concept.

Unfortunately, the Dem/FiM combo was never specified in a way to actually handle DemEvent reporting and FunctionInhibition Mapping to use for safety handling, in order to bring a function into a safe state. I'm not sure, if this can still be changed or not. The drawback is, that for safety reasons, some AUTOSAR stack vendors provide their own, some OEMs have some specific modules, and/or companies have to find their own way/component, to handle this separately, adding a lot of incompatible solutions and more resource usage.

Consider here the following scenario: MonitorA reports failure DemEvent_A (MonitorInternalDebouncing) MonitorB reports failure DemEvent_B (DemInternal Debouncing) MonitorC reports failure DemEvent_C (DemInternal Debouncing)

// DemEvent to FiM mapping, meaning, which functions are impacted
// If DemEvent is active, Functions are not allowed to run -> safe-mode
DemEvent_A --> FiM_FuncA, FiM_FuncB
DemEvent_B --> FiM_FuncA
DemEvent_C --> FiM_FuncC

In the example above, FuncA shall not be allowed to run, in case DemEvent_A or DemEvent_B are active. FuncB is not allowed if DemEvent_A is active, but still allowed even with DemEvent_B active. FuncC only depends on DemEvent_C.

In this way, a function (implemented in SWC_A, SWC_B, SWC_C) could check for failure handling by querying FiM:

SWC_A:

void SWC_A_MainFunction(void) {
    boolean bPerm = FALSE;
    uint8   FuncAStat;
    FiM_GetFunctionPermission(FiM_FuncA, &bPerm);
    if (TRUE == bPerm) {
        // FuncA allowed to run
        FuncAStat = FUNCA_RUNNING;
        Rte_Write_pFuncAStat_Status(FuncAStat);
    } else {
        // FuncA not allowed to run
        Rte_Invalidate_pOutPort();
        FuncAStat = FUNCA_MALFUNCTION;
        Rte_Write_pFuncAStat_Status(FuncAStat);
    }
}

To make all components ASIL does usually not make sense, but at least, they should be qualified for FFI (Freedom-for-Interference), which make sure, they e.g. access only memories they are designed for. Then, these components could also be executed in an ASIL-context (e.g. OS "Trusted functions" vs "non-trusted functions"). This allows to call them within the ASIL context, without switching the OsAppl/OsTask context, which could take up a lot of runtime.

Upvotes: 1

Adam Horvath
Adam Horvath

Reputation: 1286

RTE is not a BSW module; it is generated glue code. The way to qualify RTE is to qualify its generator.

Other than that, @Yunnosch' answer can be applied to both SwCs and BSWMs.

In AUTOSAR modelling, safety level can be declared (but not determined) for components/modules. The configurator can raise an error if you try to allocate non-ASIL module to a trusted partition.

Upvotes: 0

Yunnosch
Yunnosch

Reputation: 26703

There are different aspects to your question.
(Almost independent of what you were meaning to ask.)

  1. What are the requirements for a component to be ASIL qualified?
  2. When does a component need to be ASIL qualified?
  3. How can I tell wether code I look at has/needs ASIL qualification?

Concerning 1:

  • To a large extend code quality
    • as measured by reviews
    • as measured by test status, including test depth, test coverage, compatibility class test design
    • as measured by static analysis code results (e.g. MISRA in AUTOMOTIVE industry) being within very strict borders
  • But not to be neglected process quality
    • e.g. ASPICE processes
    • documentation
    • requirement engineering
    • version control
    • archiving
    • change management
    • system architecture/design
    • bidirectional traceability of all that

Concerning 2:

  • a component needs ASIL qualification if the product safety architecture requires it
  • all components in a ASIL-relevant functional chain need the qualification; having one of them qualified (even of a higher level than necessary) does not suffice
  • of two identical components, doing the same job in two similar products, one might need it, the other not; because the safety architecture might cover the safety aspect in question with that particular component - or a different one in the product (or functional chain)

Concerning 3:
Not. See above.
The same code can need it or not, depending on architectural decisions.
The same code can have it or not, depending on involved development processes being sufficiently strict - or not.

By the way, I do not see how AUTOSAR is relevant for this. Though ASIL and AUTOSAR often, but not always, are close neighbours.

Upvotes: 2

Related Questions