GM3 to AMC 20-115D -- Error-handling at design level

• ED Decision 2017/020/R found in: AMC-20 Amdt 23 - Airworthiness of Products, Parts and Appliances (Jan 2022)

GM3 to AMC 20-115D — Error-handling at design level ED Decision 2017/020/R a.         These practices provide complementary information to ED-12C/DO-178C and ED-12B/DO-178B, Sections 6.3.2, 6.3.3, and 6.3.4. Section 6.3.4.f., and identifies potential sources of errors that require specific activities focused at the source code review level. However, in order to protect against foreseeable unintended software behaviour, it is beneficial and recommended to handle these sources of error at the design level. b.         The possibility of unintended software behaviour may be reduced by considering the following activities: 1.         identification of foreseeable sources of software errors, which include: a.         runtime exceptions or errors, such as fixed/floating-point arithmetic overflow, stack/heap overflow, division by zero, or counter and timer overrun/wrap-around; b.        data/memory corruption or timing issues, such as those caused by a lack of partitioning or improper interrupt management or cache management; and c.         features leading to unpredictable programme execution, such as dynamic allocation, out-of-order execution, or resource contention; 2.         for each foreseeable source of software error, identification of the associated mitigation; 3.         specification of protection mechanisms in the software requirements (high-level or low-level requirements) which should in particular include the specification of error-handling mechanisms; and 4.         for software Levels A and B, it is recommended that consideration be given to incorporating runtime protection mechanisms since reliance on probabilistic approaches or static analyses alone may not be appropriate; it may be a good practice to implement such runtime protection mechanisms for the other software levels as well. c.         The use of FMs in accordance with ED-216/DO-333 may enhance the detection of runtime errors. [Amdt 20/14] GM3 to AMC 20-115D — Error-handling at design level ED Decision 2017/020/R a.         These practices provide complementary information to ED-12C/DO-178C and ED-12B/DO-178B, Sections 6.3.2, 6.3.3, and 6.3.4. Section 6.3.4.f., and identifies potential sources of errors that require specific activities focused at the source code review level. However, in order to protect against foreseeable unintended software behaviour, it is beneficial and recommended to handle these sources of error at the design level. b.         The possibility of unintended software behaviour may be reduced by considering the following activities: 1.         identification of foreseeable sources of software errors, which include: a.         runtime exceptions or errors, such as fixed/floating-point arithmetic overflow, stack/heap overflow, division by zero, or counter and timer overrun/wrap-around; b.        data/memory corruption or timing issues, such as those caused by a lack of partitioning or improper interrupt management or cache management; and c.         features leading to unpredictable programme execution, such as dynamic allocation, out-of-order execution, or resource contention; 2.         for each foreseeable source of software error, identification of the associated mitigation; 3.         specification of protection mechanisms in the software requirements (high-level or low-level requirements) which should in particular include the specification of error-handling mechanisms; and 4.         for software Levels A and B, it is recommended that consideration be given to incorporating runtime protection mechanisms since reliance on probabilistic approaches or static analyses alone may not be appropriate; it may be a good practice to implement such runtime protection mechanisms for the other software levels as well. c.         The use of FMs in accordance with ED-216/DO-333 may enhance the detection of runtime errors. [Amdt 20/14] GM3 to AMC 20-115D — Error-handling at design level ED Decision 2017/020/R a. These practices provide complementary information to ED-12C/DO-178C and ED-12B/DO-178B, Sections 6.3.2, 6.3.3, and 6.3.4. Section 6.3.4.f., and identifies potential sources of errors that require specific activities focused at the source code review level. However, in order to protect against foreseeable unintended software behaviour, it is beneficial and recommended to handle these sources of error at the design level. b. The possibility of unintended software behaviour may be reduced by considering the following activities: 1. identification of foreseeable sources of software errors, which include: a. runtime exceptions or errors, such as fixed/floating-point arithmetic overflow, stack/heap overflow, division by zero, or counter and timer overrun/wrap-around; b. data/memory corruption or timing issues, such as those caused by a lack of partitioning or improper interrupt management or cache management; and c. features leading to unpredictable programme execution, such as dynamic allocation, out-of-order execution, or resource contention; 2. for each foreseeable source of software error, identification of the associated mitigation; 3. specification of protection mechanisms in the software requirements (high-level or low-level requirements) which should in particular include the specification of error-handling mechanisms; and 4. for software Levels A and B, it is recommended that consideration be given to incorporating runtime protection mechanisms since reliance on probabilistic approaches or static analyses alone may not be appropriate; it may be a good practice to implement such runtime protection mechanisms for the other software levels as well. c. The use of FMs in accordance with ED-216/DO-333 may enhance the detection of runtime errors. [Amdt 20/14]