Φlog patterns for Error Handling (EH)

Objective:

The applicant has identified the effects of failures that may occur within the multi-core processor and has planned, designed, implemented and verified means (which may include a safety net external to the multi-core processor) commensurate with the safety objectives, by which to detect and handle those failures in a fail-safe manner that contains the effects of any failures within the equipment in which the multi-core processor is installed.

Image

EH pattern is dedicated to the analysis and mitigation of the failures that may occur during the platform execution. The root claim (EH) is the CAST-32A objective which requests to ensure that mitigation means handle these failures and that the comprehensive platform (integrating the mitigation means) meets the safety objectives. Such a claim is supported by two sub-claims: (E1) the failures of the platform components have been identified and handled by the mitigation means  mplemented on the platform; (E2) the effect of the platform failures (considering the mitigation means implemented in E1) are contained within the equipment containing the platform. E2 enforces the efficiency of external means of mitigation (like safety nets) used to handle failures that cannot be mitigated internally. To support EH the strategy W1 requires that a matching review has been performed on the assumptions used to perform the safety analyses at the platform-level mitigation (E1) and equipment-level (E2).

Since (E1) relies on the design and implementation of mitigation means, this means that again there is some DO178-related activities.A correct design of the mitigation means (E3) is supported by a thorough and exhaustive identification of the possible failures and their effects (E6) and a compelling demonstration of the mitigation means efficiency (E7). The completeness of the mitigation is paramount to claim support (E3), thus the strategy (W4) enforces the completeness through a traceability analysis identifying the mitigation means contributing to the mitigation of the failures. We do not provide more details about the mitigation of the failure since the applicant is free to choose any relevant safety activity to sustain the (E7) evidence (MBSA, FTA, etc.). However, for the identification, we recommend to perform a thorough safety analysis (W6) based on the state-of-art knowledge (E9) of the failures susceptible to occur on the platform (for instance by considering the errata provided by the manufacturer). The safety effect of these failures must be assessed with respect to the safety objectives (G2) and the configuration of the platform (G3) considered in the RU1 pattern. Since the identification of the platform failures and their safety impact is a critical point of the argumentation, the applicant must be very careful during the safety analysis regarding to the accuracy of its analysis assumptions. Thus the applicant must be able to demonstrate its mastery of the architecture (backing of the safety analysis).

The safe equipment-level handling of failure (E2) is supported by a safe handling of the platform failure by the internal mitigation means (E4) and by the external mitigation means (called safety nets) (E5). The safe equipment-level handling of failures (E2) is thus supported by the safety analysis of the comprehensive equipment. The analysis of internal mitigation means must be performed through a safety analysis (W5) considering the safety objectives allocated to the platform (G2), all the mitigation means designed to fulfil the CAST-32A objectives (RU2 for alterations, RU3 for interference and (E7) for internal failures) and the failures identified for any safety-related objective (here only RU2). Note that the safety analysis is relevant only if the internal mitigation means meet there real-time objectives (E8).