Should FDAL be a Function property?
In my first article I've discussed form and function. The conclusion was that form and function work together. In this article I will be discussing assignment of critical systems' development assurance level and the current guidance provided in ARP4754A.
In ARP4754A, there is a discussion of how to assign Function DAL. However, litlle is said about the relation between function and form in the process of DAL assignment.
According to ARP4754A:
Function is “…intended behavior of a product based on a defined set of requirements regardless of implementation.” and
Functional Independence is “…an attribute where the functions are different in order to minimize the likelihood of a common requirement error”,
Function Development Assurance is “the level of rigor of development assurance tasks performed to functions”,
FDAL is a property of function.
therefore, two different sets of requirements, regardless of implementation, can be considered functionally independent and, therefore, can have two different FDALs assigned to it, based on its own worst failure conditions.
On the other hand, according to DO-178C
Software IDAL is determined "...based upon the failure condition which may result from anomalous behavior of the software".
Item Development Assurance is, therefore, a property of the software. In other words, IDAL is a property of the physical realization of the functions it is supposed to perform, it is a property of form.
IDAL is a property of form.
According to ARP-4754A, FDAL is a function property whereas according to DO178C IDAL is a form property. IDAL is allocated to its physical representation, i.e. a partition. It follows that everything related to that item partition is developed in accordance with the partition IDAL.
ARP4754 guidance for assigning FDAL makes no clear connection with the system form. It does make a connection only with the item form.
However, to assign a Function Development Assurance Level (FDAL) to a function, regardless of implementation (i.e. form), is a mistake.
Please observe that ARP4761 definition of the FHA process indicates that the FHA should be reexamined after allocation of aircraft functions to systems:
“…after aircraft functions have been allocated to systems by the design process, each system which integrates multiple aircraft functions should be re-examined using the FHA process. The FHA is updated to consider the failure of single or combinations of aircraft functions allocated to a system”.
By analogy, The same reexamination of the FHA should occur after the system functions are allocated to equipments and to items.
ARP4754A guidance to Assigning FDALs with System Architecture Consideration is an example of the mistakes that may occur when FDALs are assigned to functions without fully considering form of the systems under analysis.
ARP4754A discusses in section 5.2.3.2.3 FDAL and IDAL assignment cases. Case 3 is an example of FDAL and IDAL assignment when Functional Independence is claimed but not Item Development Independence. The table below depicts the acceptable assignments according to that case.
The table result meets the ARP4754A guidance.
However, it fails to:
- recognize that an error in requirement (functions) feeding the item I2 may cause an I2 error. F1 and F2 independence claim (AND gate below top level Failure Condition, Figure 10 in ARP4754A) is no longer valid, and the error tree should be changed accordingly,
- that ARP4761 guidance requires that “…after aircraft functions have been allocated to systems by the design process, each system which integrates multiple aircraft functions should be re-examined using the FHA process. The FHA is updated to consider the failure of single or combinations of aircraft functions allocated to a system”.
If this is done, there would be two solutions for this proposed architecture:
- Solution 1: create a third system function, which is independent from F1 and F2, and which is allocated to I2 only.
- Solution 2: upgrade F1 and F2 FDALs to , make I2 IDAL = A and assign the I2 and I3 IDAL as proposed in Table 1 above. This is valid only when assuming that the failure of I1 or I3 cannot create a worst than Major hazard condition.
In order to solve that, we need to use different definitions of Functional independence and also integrate the concepts of segregation, separation and independence in standards like DO297, ARP4761 and the DRAFT ARSENAL AC 25.1309.
This is a topic for another article.
Steve Beland, thanks for the feedback. I appreciate it. I’m glad to hear that arp4761a is going to address this topic. I’m not sure I can make it to Montana or Orlando. I knew some of the details you’ve described but it is always good to hear it firsthand. I hope some of the ideas in this article resonate within S18.
Hi Marcelo, I led the team on the S-18 committee that wrote section 5.2 of ARP4754A and have responsibility for the same section in ARP4754B, You correctly observed the sensitivity of I2 in Case 3 as we intended when we designed this example (mainly to cover typical IMA implementations). You are also correct that FDAL is ideally a property of the function but in a traditional systems development the functional architecture is usually not captured and this works out as the FDAL is applied at the system level covering the next best functional representation (system requirements). The idea of functional independence is simply that and intentionally does not consider the form; this is partly why one needs to assess the whole set of FDAL and IDAL assignments for the Functional Failure Sets. The upcoming ARP4761A covers the assignments further in a new appendix (P) with the PASA and PSSA using this assignment method (rather than the FHA as you note in the original ARP4761). Much of the assignment detail in Section 5.2 and App C of ARP4754A will move to the new ARP4761A App P with only the main principles remaining in ARP4754B, This movement of content was our long-term intention because the DAL assignment is principally a safety analysis task and can lead to safety objectives to put forward as requirements in the development process. We are hoping to ballot ARP4761A late this year and publish it early next year. Likewise, we are updating ARP4754 and expect to release Rev B next year a few months after ARP4761A. If you are interested in influencing a change I'd encourage you to attend our committee meetings before the window slips by. The next one is next week in Big Sky, Montana, and the following one is in October in Orlando. You can see the details on the committee website here https://www.sae.org/works/committeeHome.do?comtID=TEAS18
Hi Marcelo, Interesting article. I think the committee that generated ARP-4754A actually made the DAL assignment process more complex than necessary.
Very good understanding about the whole DAL assignment process. The article is very scholar too. Congrats by the clean thought!