###### Proof.

See Tables 39 and 40. ∎

Table 39: Bell real model instances _do_ satisfy RCI in general: Alice’s case.
Table 40: Bell real model instances _do_ satisfy RCI in general: Bob’s case

Being Bell real but does _not_ guarantee satisfaction of ROI (Tables 41 and
42).

Table 41: Bell real model instances do _not_ satisfy ROI in general (Alice
outcomes) Table 42: Bell real model instances do _not_ satisfy ROI in general
(Bob outcomes)

######  Note 16.

The QM model instances _also_ generally satisfy RCI but not ROI, so in this
sense of locality, QM and Bell real model types have a lot in common!

###  12.3 Why Bell locality does not imply local causality

Tables 41 and 42 provide an opportunity to give a more detailed perspective on
the relationship among Bell reality, Bell locality (equivalent to the
factorization condition (FC)), and local causality (LC). Consider the 32
equations (16 for Alice and 16 for Bob) that must be solved in order to
satisfy ROI. In the following, the first implied equation in Alice’s Table 41
will be used as an example for the other 31 such equations (both Alice and
Bob).

$\frac{\rho_{1}+\rho_{2}+\rho_{5}+\rho_{6}}{\rho_{1}+\rho_{2}+\rho_{5}+\rho_{6}+\rho_{9}+\rho_{10}+\rho_{13}+\rho_{14}}=\rho_{1}+\rho_{2}+\rho_{3}+\rho_{4}+\rho_{5}+\rho_{6}+\rho_{7}+\rho_{8}$
(30)

Rewrite this equation in the form

$\displaystyle\rho_{1}+\rho_{2}+\rho_{5}+\rho_{6}=(\rho_{1}+\rho_{2}+\rho_{5}+\rho_{6}+\rho_{9}+\rho_{10}+\rho_{13}+\rho_{14})*$
(31)
$\displaystyle(\rho_{1}+\rho_{2}+\rho_{3}+\rho_{4}+\rho_{5}+\rho_{6}+\rho_{7}+\rho_{8})$

A solution to Eq. 30 requires that the denominator term
$\rho_{1}+\rho_{2}+\rho_{5}+\rho_{6}+\rho_{9}+\rho_{10}+\rho_{13}+\rho_{14}$
be nonzero, whereas Eq. 31 does not. Any solution for the $\rho_{k}$’s that
satisfies all 32 equations in the form of Eq. 30 will satisfy LC, hence will
also satisfy FC (Thm. 22). Any solution for the $\rho_{k}$’s that satisfies
all 32 equations in the form of Eq. 31 will also satisfy FC, but it will _not
necessarily_ satisfy LC (or ROI). See also Sec. 10.1. Here are two examples to
illustrate the point. Consider Tables 43 and 44.

Note that, in Table 43, all conditional probabilities are well-defined,
whereas in Table 44, four are undefined. These undefined conditionals reflect
the fact, that based on the $\boldsymbol{\rho}$ defined in the caption of
Table 44, some of the denominators in either Table 41 or Table 42 will be
zero. In contrast, the $\boldsymbol{\rho}$ defined in the caption of Table 43
results in all nonzero denominators in both Table 41 and Table 42. Finally
note that both such model instances are Bell local, since in each case, every
entry in the last column is the product of the corresponding entries in the
previous two columns, i.e., the factorization condition is satisfied (Tables
43 and 44).

Table 43: Bell real model instance that satisfies both ROI and LC, based on
$\boldsymbol{\rho}=(\frac{5}{162},\frac{1}{162},\frac{25}{162},\frac{5}{162},\frac{5}{324},\frac{1}{324},\frac{25}{324},\frac{5}{324},\frac{5}{81},\frac{1}{81},\frac{25}{81},\frac{5}{81},\frac{5}{162},\frac{1}{162},\frac{25}{162},\frac{5}{162}).$
Shows Alice’s probabilities; Bob’s case is similar but with different values.
Table 44: Bell real model instance that satisfies _neither_ ROI nor LC, based
on
$\boldsymbol{\rho}=(0,0,0,0,\frac{5}{18},\frac{1}{18},0,0,0,0,0,0,\frac{5}{9},\frac{1}{9},0,0).$
Shows Alice’s probabilities; Bob’s case is similar but with different values.

##  13 Correlation equivalence

In this section, the capability of two different model instances to produce
the same set of correlations will be examined.

######  Definition 34.

Two model instances will be called correlation equivalent if the there is a
correlation vector that is consistent with each instance, that is, the model
instances can achieve a common set of correlations.

######  Definition 35.

Two model instances will be called equivalent if they have exactly the same
generic parameters (conditional probabilities $P(A,B|D_{A},D_{B})$).

######  Note 17.

Obviously, if two model instances are equivalent, then they are also
correlation equivalent, since correlations are simple linear functions of the
generic parameters, i.e., $\mathbf{c}^{T}=C\mathbf{\gamma}^{T}$, where $C$ is
the _correlation matrix_ (see Def. 17).

######  Note 18.

In Sec. 6, it was shown that every Bell local model instance is equivalent to
some Bell real model instance, hence every Bell local model instance is also
correlation equivalent to some Bell real model instance.

###  13.1 Correlation equivalence “truth table”

Table 45: Truth table for correlation equivalence of QM, Bell real, and Bell
local models, with examples

One might ask: “Is there an example of a correlation vector that is consistent
with some QM model instance and also with some Bell real model instance, but
is not consistent with any Bell local model instance?”

All such questions are answered in the Table 45, with pointers to at least one
specific example, when the answer is “True”. For example, row 2 indicates that
there is a positive answer to the question posed above, and to see example 2
below. The answer in rows 3 and 7 is “False” because there cannot be a
correlation vector that is consistent with some Bell local model instance
without also being consistent with some Bell real model instance, since every
Bell local model instance _is_ Bell real (Sec. 6).

###  13.2 Examples 1: QM and Bell real and Bell local

Several examples are given here. The first example in Table 46 is the trivial
one, namely the minimal model with all zero correlations.

Table 46: Parameter assignments for $(w,x,y,z)=(0,0,0,0)$.

Here is a more interesting example.

Table 47: Parameter assignments for $(w,x,y,z)=(-1,1,-1,1)$.

Finally, Fig. 16 shows an infinite number of examples for the QM and Bell
local model types in the cases $w=-1$ and $w=0$ . The red lines indicate the
intersection of the QM and Bell local correlations contours. Every point on
these red lines corresponds to a 4-tuple of correlations $(-1,x,y,z)$ or
$(0,x,y,z)$, respectively, where a Bell local model can achieve the
corresponding QM correlations. The $s$-functions are therefore equal as well,
and thus the CHSH inequalities are satisfied there. Note that each of these
correlation vectors is automatically achievable by a Bell real model instance
since every Bell local instance is also Bell real.

Figure 16: Red lines indicate correlations that are simultaneously achievable
by QM and Bell local model instances (cases for $w=-1$ and $w=0$,
respectively, are shown). Table 48: Two specific examples of QM and Bell local
model instance correlation equivalence, one for $w=-1$ and one for $w=0$.

A specific example point is shown on a red line in each plot (purple dots) .
On the left ($w=-1$ case), the point $(\frac{2}{3},-1,\frac{2}{3})$ is shown
and on the right ($w=0$ case), the point $(0,-\frac{1}{2},\frac{1}{2})$ is
shown. The parameters for each model instance that give rise to this
correlation equivalence are shown in Table 48.

###  13.3 QM and Bell local model equivalence

Despite the fact that there are an infinite number of correlation equivalent
QM and Bell local model instances (see Sec 13.2), _equivalence_ (Def. 35) is
an entirely different matter. The only QM model instance equivalent to a Bell
local model instance is the trivial (minimal) one. This can be easily seen as
follows.

Consider Table 2 in Sec 2.1, columns 6 and 8 for the QM and Bell local models,
respectively. After setting these two conditional probability vectors equal to
each other, identities such as the following emerge:

$\frac{1}{2}=\frac{1}{2}\cos^{2}\theta_{1}+\frac{1}{2}\sin^{2}\theta_{1}=\alpha_{1}\beta_{1}+\alpha_{1}\beta_{3}=\alpha_{1}(\beta_{1}+\beta_{3})=\alpha_{1}$

Similarly, $\alpha_{k}=\beta_{k}=\frac{1}{2}$ for _all_ $k=1,2,3,4$. In this
case, all of the Bell local conditional probabilities $\alpha_{j}\beta_{k}$
are equal to $\frac{1}{4}$, and all of the correlations are zero. The QM
parameter settings which achieve this same set of conditional probabilities
(and correlations, of course) are $\theta_{1}=135^{\circ}\text{ and
}\theta_{k}=45^{\circ}$ for $k=2,3,4$.

So what about the fact that there are non-trivial examples of QM and Bell
local model instances that achieve the same correlations (an infinite number
of them, in fact), as shown in Sec. 13.2? Again, the mapping from conditional
probability parameters to correlations is many-to-one! Consider the two
specific examples shown in Table 48, and despite the fact that in each case
the correlations are the same, the generic parameters can be quite different,
as shown in Table 49.

Table 49: QM and Bell local instances that achieve the correlations
$(w,x,y,z)=(-1,\frac{2}{3},-1,\frac{2}{3})$ and
$(w,x,y,z)=(0,0,-\frac{1}{2},\frac{1}{2})$, respectively

###  13.4 Example 2: QM and Bell real and not Bell local

Table 50 shows the parameter assignments for the QM and Bell real models that
are consistent with the correlations $(w,x,y,z)=(0,1,-1,0)$. The reason that
there cannot be any Bell local model consistent with these correlations is
given in Sec. 6.2.

Table 50: Parameter assignments for $(w,x,y,z)=(0,1,-1,0)$.

Note that just because a Bell real model instance has the same correlations as
a given QM model (“correlation equivalent”), it does not mean that it is
“equivalent” in the sense of having the same conditional probabilities. See
Table 51. Both of the Bell real model instances (columns 3 and 4) reproduce
the QM correlations of $(0,1,-1,0)$, but only the first one (column 3) has
exactly the same conditional probabilities.

Table 51: Example of QM model instance and two distinct Bell real model
instances that are consistent with the same set of correlations
$(w,x,y,z)=(0,1,-1,0)$.

###  13.5 Example 3: QM and not Bell real and not Bell local

Pick the notorious set of angles for the QM model that produces the maximum
violation of a bound in at least one of the CHSH inequalities (Table 52).
There is no Bell real model instance consistent with these correlations
because it must satisfy all 8 CHSH inequalities, and since any Bell local
model instance is also Bell real, there can be no Bell local model instance
consistent with them either.

Table 52: Parameter assignment for $(w,x,y,z)=1/2\sqrt{2}(-1,1,1,1)$.

###  13.6 Example 4: Not QM and Bell real and Bell local

Table 53 shows the Bell real and Bell local parameter assignments that achieve
the correlations $(w,x,y,z)=(0,0,0,1)$.

Table 53: Parameter assignments for $(w,x,y,z)=(0,0,0,1)$.

These correlations cannot be achieved by any QM model instance because it is
necessary that, for some integers $k_{1},k_{2},k_{3},k_{4}$,
$\theta_{1}=(2k_{1}+1)\frac{\pi}{4}$, $\theta_{2}=(2k_{2}+1)\frac{\pi}{4}$,
$\theta_{3}=(2k_{3}+1)\frac{\pi}{4}$, and $\theta_{4}=k_{4}\pi$. Then
$\theta_{1}=\theta_{2}+\theta_{3}+\theta_{4}$ reduces to
$2\left(k_{1}-k_{2}-k_{3}-2k_{4}\right)=1$, a contradiction. QED. Fig. 17
illustrates what has just been proved.

Figure 17: Correlations $(w,x,y,z)=(0,0,0,1)$ achievable by Bell real and Bell
local models but not by any QM model (purple dot in middle of top square).

###  13.7 Example 5: Not QM and Bell real and not Bell local

Table 54 shows a Bell real parameter assignment that achieves the correlations
$(w,x,y,z)=(-1,-\frac{1}{3},-\frac{1}{3},\frac{1}{3})$.

Table 54: Parameter assignment for
$(w,x,y,z)=(-1,-\frac{1}{3},-\frac{1}{3},\frac{1}{3})$.

However, $(-1,-\frac{1}{3},-\frac{1}{3},\frac{1}{3})$ _cannot_ be achieved by
any assignment of parameters to a Bell local model. Consider the equations
that must be solved:

$\left(\begin{array}[]{l}(\alpha_{1}-\alpha_{3})(\beta_{1}-\beta_{3})\\\
(\alpha_{1}-\alpha_{3})(\beta_{2}-\beta_{4})\\\
(\alpha_{2}-\alpha_{4})(\beta_{1}-\beta_{3})\\\
(\alpha_{2}-\alpha_{4})(\beta_{2}-\beta_{4})\\\
\end{array}\right)=\left(\begin{array}[]{c}-1\\\ -\frac{1}{3}\\\
-\frac{1}{3}\\\ \frac{1}{3}\\\ \end{array}\right).$

To make the first term $-1$, set $\alpha_{1}=\beta_{3}=1$ and
$\alpha_{3}=\beta_{1}=0$ OR $\alpha_{1}=\beta_{3}=0$ and
$\alpha_{3}=\beta_{1}=1$. Suppose the first choice is made. Then to make the
second and third terms equal to $-\frac{1}{3}$, it is necessary to set
$\alpha_{4}=\beta_{2}=\frac{1}{3}$ and $\alpha_{2}=\beta_{4}=\frac{2}{3}$. But
then the last term will be $-\frac{1}{9}$ instead of $\frac{1}{3}$, as
required. A similar contradiction results from the other choice
$\alpha_{1}=\beta_{3}=0$ and $\alpha_{3}=\beta_{1}=1$.
This correlation vector also cannot be achieved by any QM model instance. For
let $x=\frac{1}{2}\arccos{(-\frac{1}{3})}$. Then it is necessary that, for
some integers $k_{1},k_{2},k_{3},k_{4}$,
$\theta_{1}=\left(2k_{1}+1\right)\frac{\pi}{2}$, $\theta_{2}=x+k_{2}\pi$,
$\theta_{3}=x+k_{3}\pi$, and $\theta_{4}=-x+(2k_{4}+1)\frac{\pi}{2}$, so
$\theta_{1}=\theta_{2}+\theta_{3}+\theta_{4}$ reduces to
$2\left(k_{1}-k_{2}-k_{3}-k_{4}\right)=1+\frac{2x}{\pi}$, which equates an
integer to a non-integer, a contradiction. QED. Fig. 18 illustrates what has
just been proved.

Figure 18: Correlations $(w,x,y,z)=(-1,-\frac{1}{3},-\frac{1}{3},\frac{1}{3})$
for not QM, Bell real, not Bell local (blue dot in middle of triangular face).

###  13.8 Example 6: Not QM and not Bell real and not Bell local

See Fig. 17 in Sec. 13.6, and notice the point $(1,-1,-1)$ (black dot at the
bottom front) corresponding to the correlations $(w,x,y,z)=(0,1,-1,-1)$ . It
is not in the Bell region because not all of the CHSH inequalities are
satisfied; the second $s$-function has value $s_{2}=-3<-2$. Since it is not in
the Bell region, it also cannot be on the Bell local contour either.

This correlation vector also cannot be achieved by any QM model since
$\theta_{1}$ would have to be of the form $(2k_{1}+1)\frac{\pi}{4}$,
$\theta_{2}$ of the form $k_{2}\pi$, $\theta_{3}$ of the form
$(2k_{3}+1)\frac{\pi}{2}$, and $\theta_{4}$ of the form
$(2k_{4}+1)\frac{\pi}{2}$, so $\theta_{1}=\theta_{2}+\theta_{3}+\theta_{4}$
reduces to $2(k_{1}-2k_{2}-2k_{3}-2k_{4})=3$, a contradiction. QED

##  14 Summary of results

The following list summarizes the main results proved in this paper, together
with pointers to the relevant section, definition, or theorem. In most cases,
these results are also reflected in one or more of Fig.’s 2, 3, 4, 5, and 6.

  1. 1.

If a model instance is Bell real, then its correlations satisfy all 8 CHSH
inequalities. See Thm. 18 in Sec. 9.

  2. 2.

If a quadruple of correlations satisfies all 8 CHSH inequalities, then _there
exists_ a Bell real model instance with these correlations (Fine’s Theorem
[21]). See Thm. 19 in Sec. 9.2.

  3. 3.

If a quadruple of correlations satisfies all 8 CHSH inequalities, there may be
_non-Bell real_ model instances possessing this same set of correlations. For
example, deterministic type 2 instances that are not Type 1. See Sec. 9.3 for
a specific example. This fact is probably not well-appreciated, namely that
there are model instances _not_ derived from local hidden variables
assumptions whose correlations satisfy all 8 CHSH inequalities, and therefore
are incapable of replicating some QM predictions.

  4. 4.

If a model instance is Bell local, then it is also Bell real. In the usual
terminology in the literature, this translates to the statement “if the
factorization condition holds in a theory, then it is also a local, hidden
variables theory”. See Thm. 16 in Sec. 6. Also see Appendix A for terminology.

  5. 5.

The set of Bell local model instances forms a proper subset of the set of Bell
real model instances. That is, there are Bell real model instances that are
NOT Bell local. See Sec. 6.2 for an example.

  6. 6.

The set of QM model instances and the set of Bell real model instances have a
non-empty intersection. But neither is a subset of the other. See Table 51 in
Sec. 13.4, and also Sec. 13.5. Also see row 2 of Fig. 8.

  7. 7.

There is exactly one QM model instance that is also Bell local, one with all
correlations equal to zero (what is called the “Minimal” or “Trivial” model in
this paper). See Sec.’s 7 and 13.3.

  8. 8.

All QM model instances satisfy the remote context independence condition, but
only one satisfies the remote outcome independence condition. See Tables 37
and 38 in Sec. 11.2.

  9. 9.

Likewise, all Bell real model instances satisfy the remote context
independence condition, but not all satisfy the remote outcome independence
condition. See Tables 39, 40, 41, and 42 in Sec. 12.2. For a specific example,
see Table 44 in Sec. 12.3.

  10. 10.

A model instance satisfies local causality (LC) iff it satisfies _both_ the
remote context independent (RCI) and remote outcome independent (ROI)
conditions (Thm. 21). Note that Shimony [33] and Jarrett [27] equate the
conjunction of RCI and ROI to the factorization condition (FC). The reason for
the difference is that, under the stricter requirements of this paper, a model
instance cannot be called locally causal (LC) unless _all relevant conditional
probabilities are well-defined_. However, it is also shown in this paper that
LC $\Rightarrow$ FC (Thm. 22). In other words, this paper agrees with
Shimony’s [33] and Jarrett’s [27] conclusion for all FC model instances that
are also LC. See Sec. 10.3 and 10.4.

  11. 11.

There are a finite number (256) of deterministic model instances. All of them
either satisfy all 8 CHSH inequalities or violate at least one Tsirelson
bound. In other words, every deterministic model instance either fails to
produce at least some correlations achievable by some QM model instances, or
it produces correlations that no QM model instance can produce, even though
only 16 of the 256 model instances are actually Bell real or Bell local. See
Sec. 3.

  12. 12.

Although there are an infinite number of outcome predictable model instances
and an infinite number of measurement predictable instances, only two QM model
instances are also outcome predictable and there are _no_ QM model instances
that are measurement predictable. This latter fact is a statement of the no-
communication theorem for QM (Thm. 15). See Sec. 4.

  13. 13.

Based on the correlations of the QM model instances (see Table 19), it is
clear that, if not for the constraint on the measurement difference angles
($\theta_{1}=\theta_{2}+\theta_{3}+\theta_{4}$ – see Fig. 11), the QM model
could achieve $s$-function values as low as -4 and as high as +4, thus
violating the Tsirelson bounds, just like the generic model. See Sec. 8.2.2.

######  Note 19.

This is not a deep statement about fundamental quantum mechanics principles
that imply the Tsirelson bounds, only an observation of a simple geometric
fact (namely, that the four relevant _differences_ of Alice’s and Bob’s
measurement angles must satisfy a linear constraint), which is enough to
prevent the QM $s$-functions from going all the way to $\pm 4$. See also page
12 of Aspect [1] where this relationship is noted.

##  15 Highlights

The following list highlights a few results from this paper that either
address certain misconceptions about Bell’s Theorem and/or may not be well
known or appreciated. For a complete summary of the results, see Sec. 14.

  * •

QM correlations just look different. Revisit Fig.’s 7 and 8 in Sec.’s 5.1 and
5.2. Note how different the QM correlations look compared to the correlations
of any other model type. This shows more than a simple inequality, or set of
inequalities, how difficult it is to reproduce certain features of QM model
instances using only assumptions of reality, locality, and/or determinism.

  * •

However, QM and Bell real model instances have something in common.
They share the properties of generally satisfying RCI, but not generally
satisfying ROI. One often reads that quantum mechanics is “non-local”, but not
so when it comes to RCI. In the context of an EPRB-like experiment, QM’s “non-
localness” is tied up more with the outcomes than with the detector settings.

  * •

“Local realism” is tricky. It is often stated in the literature that _local
realism_ is the basis of Bell’s inequality, seeming to imply that locality and
realism are separate conditions and their _conjunction_ is required to derive
the CHSH inequalities. However, it is a little more nuanced than that.

    * –

First of all, the proof of Thm. 18 (Sec. 9.1) shows that it is enough to
assume a model instance to be Bell real in order to get all 8 CHSH
inequalities. “Locality”, in the form of remote context independence (RCI),
comes along for the ride according to Thm. 23 in Sec. 12.2. On the other hand,
one could take the position that RCI is already “built into” the definition of
Bell real via the assumptions on the hidden variables that lead to its form
(see Appendix A). If so, the interpretation of conjoined “local” and “real”
characteristics makes sense.

    * –

Second of all, if the “local” in “local realism” refers to “Bell local” ,
meaning a model instance satisfies the factorization condition (FC), than this
assumption _alone_ is sufficient to derive the CHSH inequalities, since every
Bell local instance is also Bell real (Thm. 16 in Sec. 6). Again one could
adopt the viewpoint that the hidden variables approach to defining “Bell real”
and “Bell local” types already has reality and locality built into the Bell
local model type since it is just a special case of the Bell real model type.

  * •

Fine’s Theorem: Handle with care. It is worth emphasizing what Fine’s Theorem
(Thm. 19) does and does not say. First, it says that if the CHSH inequalities
hold for the correlations of some generic model instance, then there _exists_
a Bell real model instance that achieves these correlations. But it does _not_
say that any given generic model instance that satisfies all 8 CHSH
inequalities _is_ Bell real. A counterexample is given in Sec. 9.3. Put
another way, one cannot say that the CHSH inequalities being satisfied by some
generic model instance is _sufficient evidence_ to declare the model instance
to be Bell real, i.e., to be worthy of the name “real”.

  * •

Determinism vs. predictability. This paper makes a clear distinction between
determinism and predictability. See Sec.’s 3 and 4 and also Fig. 2.

    * –

(See Thm.’s 1 and 2) Deterministic model instances are interesting because
they can fail to mimic some of the behaviors of QM in two distinct ways,
namely, given a deterministic model instance, it either:

      * *

Satisfies the CHSH inequalities (underachieves) as in Types 1 and 2, or

      * *

Exceeds the Tsirelson bounds (overachieves) as in Type 3 (but not 1 or 2). See
Fig. 4.

  * •

On the other hand, predictable model instances are interesting because they
are related to faster-than-light (FTL) signaling.

    * –

There are two QM model instances that are outcome predictable: Alice can
predict Bob’s outcome under QM rules, but only in two specific instances. See
Thm. 9 and Table 9.

    * –

There are _no_ QM model instances that are measurement predictable: Bob
_cannot_ send messages to Alice under QM rules. See Thm. 15.

    * –

However, there are an infinite number of _non-QM_ model instances that are
measurement predictable: Bob _could_ send messages to Alice if the rules
governing the EPRB experimental world were different. See Table 10 and Thm.
12.

##  Appendix A Hidden variables and operational variables

The purpose of this appendix is to make the connection between the
_operational r.v._ modeling approach and the _hidden r.v._ modeling approach.
The definitions and results in the main body of the paper live entirely within
the framework of operational r.v.s, as exemplified by Table 1 or 2, for
example. However, the historical tradition is to start by assuming (or
deriving) hidden variables. Here is the connection.

Given a pmf on the hidden r.v.’s $\Lambda$, _assume_ there exists a joint pmf
on the _combined_ operational and hidden r.v.’s $(A,B,D_{A},D_{B},\Lambda)$
such that the marginal pmf on the hidden r.v.’s matches the original given
pmf. In particular, this means that, after computing the marginal pmf on the
_operational_ r.v.’s, further mention of the _hidden_ r.v.’s can be
suppressed. The most general form of such a (marginalized) model based on the
operational r.v.’s only is shown in Table 1 (hence the name “generic”). Put
another way, the hidden r.v.’s are introduced to mathematically characterize
certain concepts, like “reality” or “locality”, but once the marginal pmf on
$(A,B,D_{A},D_{B})$ is computed based on the full joint pmf on
$(A,B,D_{A},D_{B},\Lambda)$, all subsequent results are based solely on the
operational r.v. pmf, as shown in Table 1.

As a specific example, see Table 55, where $\Lambda=(A_{1},A_{2},B_{1},$
$B_{2})$. The rationale for the pmf names “Bell real” and “Bell local” will be
explained in Appendices B.1 and B.2

Table 55: Hidden variable Bell real and Bell local model pmfs.

The four r.v.’s $(A_{1},A_{2},B_{1},B_{2})$ represent _prepared definite
outcomes_ , awaiting only Alice’s and Bob’s measurement setting choices. If
Alice chooses her first detector setting, $D_{A}=-1$, she gets the result
$A=A_{1}$. If she chooses her second detector setting, $D_{A}=1$, she gets the
result $A=A_{2}$. Similarly for Bob with respect to $B_{1},B_{2}$. The full
joint pmf’s for the 64 possible outcomes of both operational and hidden r.v.’s
$(A,B,D_{A},D_{B},A_{1},A_{2},B_{1},B_{2})$ are shown in Tables 56 and 57,
split over two pages.

Table 56: The combined model (first half). Table 57: The combined model
(second half).

To see how this full joint pmf is connected to the corresponding (hidden r.v.)
marginal pmf’s in Table 55, consider row 50 in Table 57, shown in red for easy
identification. Note that $D_{A}=-1,D_{B}=+1$, which means that Alice uses her
_first_ measurement setting and Bob uses his _second_. Therefore, Alice gets
the measurement outcome $A=A_{1}=1$ and Bob gets the measurement outcome
$B=B_{2}=-1$. Hence their joint measurement outcome is $(A,B)=(1,-1)$, so
finally the operational r.v.’s are $\left(A,B,D_{A},D_{B}\right)=(1,-1,-1,1)$
and the full row 50 is
$(A,B,D_{A},D_{B},A_{1},A_{2},B_{1},B_{2})=(1,-1,-1,1,1,1,-1,-1)$.

The probabilities in the “Bell real” and “Bell local” columns of row number
50, namely $\rho_{13}\delta_{ab^{\prime}}$ and
$\alpha_{3}\alpha_{4}\beta_{1}\beta_{2}\delta_{ab^{\prime}}$, resepectively,
come from the fact that $\left(A_{1},A_{2},B_{1},B_{2}\right)=(1,1,-1,-1)$ is
in the 13th row of Table 55, hence has probability $\rho_{13}$ in column 5 and
$\alpha_{3}\alpha_{4}\beta_{1}\beta_{2}$ in column 6. When combined with the
probability of Alice choosing her _first_ measurement setting and Bob choosing
his _second_ measurement setting, which is $\delta_{ab^{\prime}}$, this yields
overall probabilities of $\rho_{13}\delta_{ab^{\prime}}$ and
$\alpha_{3}\alpha_{4}\beta_{1}\beta_{2}\delta_{ab^{\prime}}$ in row 50 of the
last two columns of Table 57, respectively. Similarly for the other 63 rows
(exercise for the reader to check!).

The resulting _marginal_ pmf’s of the _operational_ r.v.’s for both the Bell
real and Bell local models are shown in Table 58.

Table 58: Operational r.v. Bell real and Bell local model pmfs. Obtained as
the marginal pmfs on $(A,B,D_{A},D_{B})$ relative to the complete pmfs on
$(A,B,D_{A},D_{B},\Lambda)$ in Tables 56 and 57.

The constraints in the last row of Table 58 guarantee that entries in both the
“Bell real” and “Bell local” columns form a pmf.

##  Appendix B Bell reality and Bell locality

The purpose of this appendix is to give rationales for the names “Bell real”
and “Bell local”.

###  B.1 Rationale for the name Bell real

As mentioned previously, the four numbers $(A_{1},A_{2},B_{1},B_{2})$ in Table
55 represent prepared definite, i.e. _real_ , outcomes, awaiting only Alice’s
and Bob’s measurement setting choices. That is, the photon sent to Alice is
“encoded” with the definite outcomes $(A_{1},A_{2})$ and similarly the one
sent to Bob is “encoded” with definite outcomes $(B_{1},B_{2})$.

It turns out that all instances of the “Bell real” model type also satisfy the
remote context independence (RCI) condition, which is a (weak) form of
locality (see Sec. 2.2 and Thm. 23 in Sec. 12.2). This characterization is
similar to the description of a “local hidden variables theory” in the
textbook by Schumacher and Westmoreland [32], which in turn has been
chacterized as a fair representation of Bell’s original intentions by Wiseman
[37].

###  B.2 Rationale for the name Bell local

Though the notation is different, the following explanation is roughly
equivalent to Fine’s discussion of a stochastic hidden variables model being
_factorizable_ in [21]. Both Shimony [33] and Wiseman [37] use the term “Bell
locality” to indicate satisfaction of the factorization condition (Def. 8).
Furthermore Wiseman [37] argues that this is Bell’s concept of locality as
expressed in one of his later papers [4].

Define non-negative real numbers $\alpha_{1},\alpha_{2},\alpha_{3},\alpha_{4}$
and $\beta_{1},\beta_{2},\beta_{3},\beta_{4}$ in two different ways. The first
is based on the hidden r.v.’s, Table 55, last column. The second is based on
the operational r.v.’s, Table 58, last column. First, in terms of the _hidden_
r.v.’s $(A_{1},A_{2},B_{1},B_{2})$, define

$\displaystyle\alpha_{1}=P(A_{1}=-1),\;\beta_{1}=P(B_{1}=-1),$
$\displaystyle\alpha_{3}=P(A_{1}=+1),\;\beta_{3}=P(B_{1}=+1),$ (32)
$\displaystyle\alpha_{2}=P(A_{2}=-1),\;\beta_{2}=P(B_{2}=-1),$
$\displaystyle\alpha_{4}=P(A_{2}=+1),\;\beta_{4}=P(B_{2}=+1).$

In terms of the _operational_ r.v.’s, define

$\displaystyle\alpha_{1}=P(A=-1|D_{A}=-1),\;\beta_{1}=P(B=-1|D_{B}=-1),$
$\displaystyle\alpha_{3}=P(A=+1|D_{A}=-1),\;\beta_{3}=P(B=+1|D_{B}=-1),$ (33)
$\displaystyle\alpha_{2}=P(A=-1|D_{A}=+1),\;\beta_{2}=P(B=-1|D_{B}=+1),$
$\displaystyle\alpha_{4}=P(A=+1|D_{A}=+1),\;\beta_{4}=P(B=+1|D_{B}=+1).$

Claim that these two definitions are equivalent, for example,

$\alpha_{1}=P(A=-1|D_{A}=-1)=P(A_{1}=-1),$

and similarly for the other $\alpha$’s and $\beta$’s. Recall that, by
definition, $A_{1}$ is one of the two prepared definite outcomes for Alice,
such that if Alice chooses her first detector setting ($D_{A}=-1$), then she
gets the outcome $A=A_{1}$. So by _definition_ , if $D_{A}=-1$ and $A_{1}=-1$,
then $A=-1$ also. In other words, $P(A=-1|D_{A}=-1)=P(A_{1}=-1)$. Similarly
for the other 7 equalities.

Consider the last column of Table 58. Based on this pmf, Table 59 shows the
conditional probabilities $P(A|D_{A})$ and $P(B|D_{B})$ in terms of the
$\alpha$’s and $\beta$’s (see columns 5 and 6). The last column imposes the
factorization condition (FC – see Def. 8) by making every entry in column 7
equal to the product of the entries in columns 5 and 6 in the same row.
Finally, note that these match the conditional probabilities for the Bell
local model as defined in Table 2 in Sec 2.1.

Table 59: Factorization condition defines the Bell local model.

As an additional check, the Bell local parameter constraints are easily
derived from from either Eq. B.2 or Eq. B.2:

$\displaystyle\alpha_{1}+\alpha_{3}=\alpha_{2}+\alpha_{4}=1,\;\beta_{1}+\beta_{3}=\beta_{2}+\beta_{4}=1.$
(34)

##  Appendix C Counterfactual definiteness and other criticisms

As mentioned in the outline (Sec. 1.4), there are ongoing controversies
surrounding Bell’s Theoerem. There are authors who reject a formulation such
as the one in this paper altogether. They assert that, since it assumes a
joint pmf on measured and unmeasured outcomes, it is irrelevant to any EPRB-
like experiment and also to Einstein’s original concerns. See for example,
Hess, De Raedt, and Michielsen in [25]. There are also objections based on on
the assertion that Bell’s Theorem is purely a mathematical construct with no
physical relevance. See Hess and Philipp [26]. These authors have other
objections as well, but a more in-depth discussion will have to wait, as this
paper is already very long. Since these two criticisms seem to be the most
important ones, a short response is given here.

According to Wikipedia [18], _counterfactual definiteness_ refers to “…the
ability to speak ’meaningfully’ of the definiteness of the results of
measurements that have not been performed (i.e., the ability to assume the
existence of objects, and properties of objects, even when they have not been
measured)”. Specifically, one of the objections to the approach in this paper
would be that a common probability distribution defined on a collection of
r.v.’s related to an EPRB-like experiment implicitly assumes that both
measured and unmeasured (but presumed) outcomes can be combined in a common
statistical framework. This violates the Kolmogorovian precept of having a
direct logical connection between identifiable outcomes in a sample space and
the probabilities assigned to them. In answer to the objection of invoking
counterfactual definiteness, two points are made. Keep in mind Tables 55 and
58.

  * •

The hidden r.v.’s – refer to Table 55. This is indeed a (pair of) joint
probability distribution(s) on measured and unmeasured outcomes. It is the
very essence of counterfactual definiteness since the outcomes are a list of
pairs of _both possible outcomes_ for both Alice and Bob, in advance of being
measured (or not). But this is exactly what Bell intended when he turned the
EPR argument on its head. Namely, he _assumed_ a classical world that we all
knew and believed in, namely, that quantities exist independently of
measurement. They are _real_. This is a _hypothesis_ , meant only to be an
alternative to quantum mechanics, testable by experiment, via a simple
inequality. This is expressed more eloquently in Gill’s paper [23], where
counterfactual definiteness is embraced, not shunned.

  * •

The operational r.v.’s – refer to Table 58. This is also a (pair of) joint
probability distribution(s), but it does not involve the hidden variables.
That is, in a single iteration of the experiment, no simultaneous measured and
unmeasured outcomes are involved. Each one of the 16 atomic events consists of
a quadruple of Alice’s and Bob’s outcomes, together with their freely chosen
detector settings. There is only one measurement (observation) per iteration
for both Alice and Bob. This idea is illustrated in Fig. 1 of Gill [23]. In
fact, if one is squeamish about starting with the probability space(s) of
Table 55, one can go directly to assuming the probability space(s) of Table
58, and avoid the counterfactual definiteness issue altogether. In which case,
the only issue left is one of interpretation. Is it meaningful to label the
two pmf’s “Bell real” and “Bell local”? Of course, that is what the deductive
trail between Table 55 and Table 58 is all about (Appendix A).

Finally, there is one more possible objection to address. One may suggest that
the assumption of a joint probability distribution (on either the hidden
r.v.’s or the operational r.v.’s) is _by itself_ sufficient to derive the CHSH
inequalities. See for example Hess and Philipp [26]. The implication being
that Bell’s Theorem is strictly the result of a mathematical construct with no
connection to the physical situation.

However this is not true for the operational r.v. modeling paradigm in this
paper – see Table 2 in Sec. 2.1. Note that the QM model type is included; some
instances of this model type have correlations that violate some of the CHSH
inequalities. See Sec. 8.2.1. However, correlations of _all_ instances of the
Bell real and Bell local types satisfy all 8 CHSH inequalities. See Sec. 9.1.
The distinguishing characteristic is not whether a joint probability
distribution is assigned (or not), but _the symbolic form of the parameters of
the pmf_ , i.e. the conditional probabilities $P(A,B|D_{A},D_{B})$. And these
parameters are based upon different assumptions concerning the underlying
physical reality.

## References

  * [1] Alain Aspect. _Bell’s Theorem: The Naive View of an Experimentalist_ , “Quantum [Un]speakables $--$ From Bell to Quantum information”, edited by R. A. Bertlmann and A. Zeilinger, Springer, 2002.
https://dx.doi.org/10.1007/978-3-662-05032-3_9

  * [2] John S. Bell. _On the Einstein, Podolsky, Rosen Paradox_ , Physics Vol. 1, No. 3, pp. 195-290, 1964. (Reproduced in [11].)
https://dx.doi.org/10.1103/PhysicsPhysiqueFizika.1.195

  * [3] John S. Bell. _On the Problem of Hidden Variables in Quantum Mechanics_ Review of Modern Physics 38, 1976 (Reproduced in [11].)
https://dx.doi.org/10.1103/RevModPhys.38.447

  * [4] John S. Bell. _The Theory of Local Beables_ , Epistemological Letters 9, 1976; Dialectia 39 1985. (Reproduced in [11].)
https://doi.org/10.1142/9789812386540_0008

  * [5] John S. Bell. _Bertlmann’s Socks and the Nature of Reality_ , Journal de Physique Colloques C2 Supplement 3, 1981. (Reproduced in [11].)
https://doi.org/10.1142/9789812795854_0085

  * [6] John S. Bell, _EPR correlations and EPW distributions_ , New Techniques and Ideas in Quantum Measurement Theory, D. M. Greenberger,ed., Ann. New York Acad. Sci vol 480, 1986. (Reproduced in [11].)
https://doi.org/10.1111/j.1749-6632.1986.tb12429.x

  * [7] John S. Bell. _Introduction to the Hidden Variable Question_ , Proceedings of the International School of Physics ’Enrico Fermi’, course II: Foundations of Quantum Mechanics, Academic 171-81. New York, 1971.
https://doi.org/10.1142/9789812795854_0074

  * [8] John S. Bell. _Speakable and Unspeakable in Quantum Mechanics: Collected Papers on Quantum Philosophy_ , Cambridge University Press, 1987.
https://doi.org/10.1017/CBO9780511815676

  * [9] John S. Bell. _La nouvelle cuisine_ , Between Science and Technology , A Sarmeljin, P. Kroes, ed., Elsevier/North-Holland 1990. (Reproduced in [11].)
https://doi.org/10.1142/9789812386540_0022

  * [10] John S. Bell and M. Nauenberg, _The moral aspects of quantum mechanics_ , Preludes in Theoretical Physics – In Honor of V.F. Weisskopf, de Shalit A, Feshbach H and van Hove L eds. Amsterdam: North Holland, 1966. (Reproduced in [11].)
https://doi.org/10.1142/9789812386540_0003

  * [11] John S. Bell. _John S. Bell on the Foundations of Quantum Mechanics_ , M. Bell, K. Gottfried, M. Veltman, eds., World Scientific, Singapore, 2001.
https://doi.org/10.1142/4757

  * [12] Mary Bell and Shan Gao, ed.’s, _Quantum Nonlocality and Reality: 50 Years of Bell’s Theorem_ , Cambridge University Press, 2016.
https://doi.org/10.1017/CBO9781316219393

  * [13] John S. Bell Google Scholar citations. https://scholar.google.com/citations?user=Bd9KX0oAAAAJ&hl=en.
  * [14] D. Bohm. _Quantum theory_ New York: Prentice-Hall, 1951. (also New York: Dover, 1989).
  * [15] Jean Bricmont. _What did Bell really prove?_ Quantum Non-Locality and Reality, M. Bell and S. Gao, ed., Cambridge University Press, 2016 – p. 49
https://doi.org/10.1017/CBO9781316219393.006

  * [16] Harvey R Brown, Christopher G Timpson. _Bell on Bell’s Theorem: The Changing Face of Non-Locality_ , Quantum Non-Locality and Reality, M. Bell and S. Gao, ed., Cambridge University Press, 2016 – p.91.
https://doi.org/10.1017/CBO9781316219393.008

  * [17] Eric G. Cavalcanti and Howard M. Wiseman. _Bell nonlocality, signal locality and upredictability (or What Bohr could have told Einstein at Solvay had he known about Bell experiments)_ , arXiv:0911.2504v2 [quant-ph] 13 Jun 2012.
https://doi.org/10.1007/s10701-012-9669-1

  * [18] _Counterfactual definiteness_ , Wikipedia.
https://en.wikipedia.org/wiki/Counterfactual_definiteness

  * [19] J.F. Clauser, M.A. Horne, A. Shimony, R.A. Holt. _Proposed experiment to test local hidden-variable theories_ , Phys. Rev. Lett., 23 (15): 880$--$4, Bibcode:1969PhRvL..23..880C, doi:10.1103/PhysRevLett.23.880), 1969.
https://doi.org/10.1103/PhysRevLett.23.880

  * [20] A. Einstein, B. Podolsky, N. Rosen. _Can Quantum-Mechanical Description of Physical Reality Be Considered Complete?_ , Phys. Rev. Lett. 47, 777, May 1935.
https://doi.org/10.1103/PhysRev.47.777

  * [21] Arthur Fine. _Hidden Variables, Joint Probability, and the Bell Inequalities_ , Phys. Rev. Lett. 48, 291, February 1982.
https://doi.org/10.1103/PhysRevLett.48.291

  * [22] Arthur Fine. _The Einstein-Podolsky-Rosen Argument in Quantum Theory_ , The Stanford Encyclopedia of Philosophy, https://plato.stanford.edu/entries/qt-epr/#SpinBohmVers, First published Mon May 10, 2004; substantive revision Tue Oct 31, 2017.
https://plato.stanford.edu/entries/qt-epr/

  * [23] R. Gill. _Statistics, Causality and Bell’s Theorem_ , Statistical Science, Vol. 29, No. 4, pp 512-528, 2014.
https://doi.org/10.1214/14-STS490

  * [24] J.J.Halliwell. _Two Proofs of Fine’s Theorem_ , Physics Letters A, Vol. 378, Issue 40, Aug 14 2014, pp. 2945-2950.
https://doi.org/10.1016/j.physleta.2014.08.012

  * [25] Karl Hess, Hans De Raedt, Kristel Michielsen. _Counterfactual Definiteness and Bell’s Inequality_. Journal of Modern Physics, 7, 2016, pp 1651-1660.
https://doi.org/10.4236/jmp.2016.713150

  * [26] Karl Hess, Walter Philipp. _The Bell Theorem as a Special Case of a Theorem of Bass_ , Foundatiions of Physics, 35, October 2005, pp. 1749-1767.
https://doi.org/10.1007/s10701-005-6520-y

  * [27] J. P. Jarrett _On the physical significance of the locality conditions in the Bell arguments_ , Nous, 18: 569–589, 1984.
https://doi.org/10.2307/2214878

  * [28] Tim Maudlin. _What Bell Did_ , J. Phys. A: Math. Theor. 47, 424010 (24pp).
https://doi.org/10.1088/1751-8113/47/42/424010

  * [29] Tim Maudlin. _What Bell Did_ , YouTube, 2014.
https://www.youtube.com/watch?v=Vg5z_zeZP60

  * [30] I. Pitowski. _Quantum Mechanics as a Theory of Probability_ , Oct 2005.
https://arxiv.org/abs/quant-ph/0510095v1

  * [31] E. Rosinger, _George Boole and the Bell Inequalities_. Jun 2004.
https://arxiv.org/abs/quant-ph/0406004

  * [32] Benjamin Schumacher and Michael Westmoreland. _Quantum Processes and Information_ , Cambridge University Press, 2010.
https://doi.org/10.1017/CBO9780511814006

  * [33] Abner Shimony, Wayne Myrvold, and Marco Genovese. _Bell’s Theorem_ , The Stanford Encyclopedia of Philosophy, First published Wed Jul 21, 2004; substantive revision Wed Mar 13, 2019.
https://plato.stanford.edu/entries/bell-theorem/

  * [34] Henry P. Stapp. _Strengthening Bell’s Theorem: Removing the Hidden-Variable Assumption_ , Quantum Non-Locality and Reality, M. Bell and S. Gao, ed., Cambridge University Press, 2016 – p.151.
https://doi.org/10.1017/CBO9781316219393.011

  * [35] Roderich Tumulka. _The Assumptions of Bell’s Proof_ , Quantum Non-Locality and Reality, M. Bell and S. Gao, ed., Cambridge University Press, 2016 – p. 79.
https://doi.org/10.1017/CBO9781316219393.007

  * [36] N. N. Vorobev. _Consistent Families of Measures_ , “Theory of Probabilities and its Applications”, Volume VII, Number 2 1962.
https://doi.org/10.1137/1107014

  * [37] Howard Wiseman. _The Two Bell’s Theorems of John Bell_ , Journal of Physics A: Mathematical and Theoretical, Volume 47, Number 42, Oct 8, 2014.
https://doi.org/10.1088/1751-8113/47/42/424001


# Beyond Tradition: Evaluating Agile feasibility in DO-178C for Aerospace
Software Development

J. Eduardo Ferreira Ribeiro
Department of Informatics Engineering
Faculty of Engineering, University of Porto
Porto, Portugal
<EMAIL_ADDRESS>
João Gabriel Silva
CISUC, Department of Informatics Engineering
University of Coimbra
Coimbra, Portugal
<EMAIL_ADDRESS>
Ademar Aguiar
Department of Informatics Engineering
Faculty of Engineering, University of Porto
Porto, Portugal
<EMAIL_ADDRESS>

###### Abstract

Domain-specific standards and guidelines play a crucial role in regulating
safety-critical systems, with one notable example being the _DO-178C_ document
for the aerospace industry. This document provides guidelines for
organisations seeking to ensure the safety and certification of their software
systems. This paper analyses the _DO-178C_ document within the context of
software development for safety-critical aerospace systems focusing on Agile
software development, aiming to assess its feasibility. Unlike restricting
specific development methods, _DO-178C_ offers indispensable support that
upholds confidence in safety, aligning seamlessly with the objectives of
aerospace industries. Our analysis reveals that there are no limitations or
restrictions within the _DO-178C_ that inhibit the adoption of Agile and
provides guidelines and objectives for achieving suitable evidence, allowing
for various working methods, including Agile methods, contrary to the overall
opinion in the industry that the traditional waterfall method is mandatory.
Additionally, we emphasise that the guidelines explanation is explicitly
tailored to software professionals using Agile methods, giving it a much more
specific focus than publications that only provide a generic overview of the
standard.

_Keywords_ Safety-critical systems $\cdot$ Aerospace $\cdot$ DO-178C $\cdot$
Software development $\cdot$ Agile

##  1 Introduction

The intrinsic link between safety and risk, as highlighted by Bowen et al.
[1], serves as the foundation for the concept of safety-critical systems.
These systems, as defined by Cullyer [2], encompass those whose functional
failure could result in dire consequences such as loss of life, injury,
environmental damage, or property loss. Within the aerospace domain, where the
role of software is pivotal, ensuring a high degree of reliability becomes
paramount. Embedded software, a vital component of safety-critical systems,
collaborates with hardware to manage overall equipment safety. System and
software development processes are deeply intertwined in this intricate
landscape, accentuating the need for robust safety assurance. Examples of
safety-critical systems abound, encompassing aircraft flight control, medical
devices, rail control, satellites, and more [3]. The horizon of safety-
critical systems broadens further as innovations like Tesla’s self-driving
technology take centre stage [2, 4]. As such, the software development
methodologies underpinning these systems require meticulous consideration.
Traditionally, the waterfall method has favoured the safety-critical systems
engineering domain.

Additionally, the Verification & Validation Model (V-Model), an evolved
version of the waterfall method, has gained traction due to its incorporation
of Verification and Validation (V&V) phases [5]. Proposed by Paul Rook in the
late 1980s, the V-Model continues to influence safety-critical systems
engineering [5, 6]. However, standards and documents like _DO-178C_ [7] do not
prescribe a specific development model and provide guidelines and objectives
for achieving suitable evidence, allowing for various working methods,
including Agile methods [7, 8, 9]. This paper establishes the groundwork by
providing essential background information on safety-critical systems and
introduces a pivotal document in aerospace software development, known as
_DO-178C_ [7]. In the safety-critical domain, including the aerospace domain,
the systems must adhere to stringent regulatory requirements and guidelines to
ensure reliability and safety. The _DO-178C_ document serves as a cornerstone,
offering comprehensive guidance for organisations involved in software
development and certification for aerospace applications. Within the scope of
this paper, we embark on an analysis of _DO-178C_ within the context of
software development for safety-critical aerospace systems, with a specific
emphasis on Agile software development. Our primary goal is to evaluate its
feasibility. It is worth noting that the influence of _DO-178C_ extends beyond
its prescribed methods as an indispensable supporter in investing confidence
in safety measures across the aerospace domain.

Furthermore, this paper conducts a comprehensive synthesis of _DO-178C_
tailored for software professionals who employ Agile methods within the
context of Agile software development. We assess its feasibility in this
context. This approach provides a significantly sharper focus compared to
existing publications, often providing only a generic overview of the
document.

Section 2 offers an overview of the interrelationships among various aerospace
standards and documents within the aerospace domain. This section places
particular emphasis on the _DO-178C_ document. Moving on to Section 3, we
delve into a series of subsections that commence with insights into the
evolution of _DO-178_ , from its initial publication to its most recent
version, _DO-178C_ , issued in 2011. Subsection 3.1 introduces and explores
the distinct Failure Condition Category Levels outlined in _DO-178C_. This
subsection succinctly summarizes the requisite objectives and verification
objectives for each level, as stipulated by the _DO-178C_ document.
Subsequently, Subsection 3.2 highlights the central _DO-178C_ document and
explains its connections to relevant supplementary documents. Within
Subsection 3.3, the _DO-178C_ document structure is introduced and explored.
Moving on to Subsection 3.4, we investigate the five essential plans mandated
by _DO-178C_ for all levels. In Subsection 3.5, we delve into the correlations
linking plans, processes, standards, and outputs that collectively facilitate
adherence to _DO-178C_ ’s document and for project-specific needs. Subsection
3.6 subsequently navigates the software development process, outlining the
essential steps from initial planning to attaining certification-ready status.
The outcome of this exploration is a visual representation depicting the
interplay between these processes, the designated plans, and the objectives of
safety certification. Within Subsection 3.7, we underscore the pivotal role of
traceability, independence, and change control in successfully pursuing
certification. Finally, in the same subsection, we offer a condensed insight
into the objectives and activities of each process, as delineated across
different levels of criticality. In Subsection 3.8, we provide a comprehensive
overview of the processes associated with the tables listed in Annex A of the
_DO-178C_ document pointing to the location where these tables are situated
within the _DO-178C_ document. We conclude with Section 4, reflecting on the
_DO-178C_ document’s influence on aviation software safety, and we address the
question of whether _DO-178C_ actually imposes a particular development model
or only provides guidelines and objectives for acquiring sufficient evidence,
thus enabling a variety of working methods, including Agile approaches.
Additionally, we identify future research areas, explicitly evaluating
established methods and exploring novel approaches to optimise efficiency,
safety, and compliance within aerospace software practices.

##  2 Aerospace Standards and Documents

Figure 1 outlines the relationships of primary standards and documents in the
aerospace domain. It highlights the relationships among various aerospace
standards and documents, with _DO-178C_ and _DO-254_ [10] being the most
widely recognised. Figure 1 also provides a comprehensive structure that
includes additional standards and documents at the system level, addressing
various aspects of system development and certification.

Figure 1: Safety-critical standards for aerospace relationships, adapted from
[11].

By examining Figure 1, we can observe how these primary standards are linked.
It highlights their pivotal role in guiding safety assessment, electronic
hardware and software lifecycle processes, and the overall system development
process. Each of these development documents provides essential guidelines to
ensure the safety and reliability of aerospace systems.

In particular, while Figure 1 shows the broader landscape of standards and
documents in the aerospace domain, this specific analysis focuses mainly on
the _DO-178C_ document. This document, also known as "Software Considerations
in Airborne Systems and Equipment Certification," is of utmost importance in
studying avionics system development and certification. It sets forth the
guidelines and requirements that developers must adhere to when designing and
implementing software for airborne systems.

Turning our attention back to Figure 1, we can see how it presents a concise
overview of the interrelationships between key standards governing avionics
systems. The diagram explicitly highlights the connections among the following
standards:

  * •

_ARP4761_ focusses on the assessment of system safety, providing guidelines to
identify and mitigate potential hazards in avionic systems [12].

  * •

_ARP4754A_ deals with system development, addressing the activities and
processes involved in the design, development, and validation of aircraft and
systems [11].

  * •

_DO-297_ , known as the "Integrated Modular Avionics (IMA) Development
Guidance and Certification Considerations," offers guidance for developing
integrated modular avionics systems [13].

  * •

_DO-254_ , or "Design Assurance Guidance for Airborne Electronic Hardware,"
specifies the objectives and activities necessary for designing and verifying
electronic hardware used in airborne systems [10].

  * •

_DO-178C_ , as mentioned above, sets the standards for software development
assurance, ensuring that software for airborne systems is developed and tested
to meet strict safety and reliability requirements [7].

  * •

_ARP5150A/5151A_ focusses on electromagnetic environmental effects, guiding
the management and mitigation of the impact of electromagnetic interference on
avionic systems [14, 15].

By adhering to these standards and documents, aerospace developers and
certification authorities can work together to create robust and reliable
avionics systems that meet the industry’s strict requirements.

##  3 DO-178 and its Evolution

In the past, software held a more straightforward role, primarily enhancing
the functions of mechanical and analogue electrical systems. However, an
important realization surfaced early on: this approach could not ensure the
reliability and safety required for intricate safety systems. This epiphany
catalysed the release of the inaugural _DO-178_ certification document in
1980, as cited by Singh [16].

During this era, _DO-178_ established a form of software certification
grounded in "best practices," although its content remained abstract. The
regulations were gradually refined through trial and error. _DO-178_
introduced the concept of software verification requirements, with its
specifics contingent upon the software’s safety criticality. This document
also categorized software applications into critical, essential, and
nonessential sectors. Additionally, it intertwined the software certification
process with relevant Federal Aviation Regulations (FARs), such as Type
Certification Approval, Technical Standard Order (TSO) Authorization, and
Supplemental Type Certification [16].

The maiden version of _DO-178_ laid the foundation for software certification.
However, practical application swiftly necessitated revisions. As new needs
emerged, more frequent updates ensued to enhance the guidelines. Table 1
visually illustrates the progression from _DO-178_ to its latest incarnation,
_DO-178C_.

Table 1: _DO-178_ evolution, adapted from [7, 9, 17].

Document Basis Year Themes _DO-178_ _498 & 2167A_ 1980 Artefacts, documents,
traceability, management and testing. _DO-178A_ _DO-178_ 1985 Process,
testing, components, four critical levels, reviewers, waterfall method.
_DO-178B_ _DO-178A_ 1992 Integration, development methods, data (not
documents), tools COTS. _DO-178C_ _DO-178B_ 2011 Reducing subjectivity,
address modeling and reverse engineering.

The 1982 publication of _DO-178_ established a "prescriptive set of design
assurance processes for airborne software that focuses on documentation and
testing" [16]. This standard underwent numerous refinements, each aimed at
clarifying and advancing concepts. Iterations introduced novel ideas when
necessary, exemplified by the supplements in _DO-178C_. _DO-178_ ’s 1985
update, version A, introduced the concept of varied activities based on
software component criticality (Subsection 3.1). The subsequent version, B,
introduced the concept of activities and associated objectives, leading to a
comprehensive overhaul and fostering development method flexibility in 1992.
This iteration also delineated essential attributes a design assurance process
must possess [16].

The most recent version, _DO-178C_ , emerged in 2011, retaining much of its
predecessor’s content while striving to clarify application nuances and
eliminate inconsistencies. _DO-178C_ also introduced the notion of
supplements, supplemental documents addressing cutting-edge technology’s
application without altering the core standard (Subsection 3.2). The _DO-178_
family of standards has long been viewed as a cornerstone of aviation safety.
Literature affirms that its utilization has not been linked to significant
aviation accidents [16].

In summary, the journey from the early days of software’s role in mechanical
enhancement to the intricate certification processes of _DO-178C_ showcases
the evolution of software’s integration into safety-critical systems within
the aerospace domain.

###  3.1 Failure Condition Category Level

When developing an aerospace system, it is essential to identify the specific
category of associated failure conditions. This initial comprehension holds
enormous importance in ensuring strict adherence to the mandated standards,
documents and levels the certifying authority sets during the validation
process; otherwise, our systems will not be certified.

The _DO-178C_ document demonstrates confidence in a software component in
proportion to its designated failure condition category level, often called
its criticality. To achieve this, the _DO-178C_ categorizes the criticality of
components into five distinct Design Assurance Levels (DAL), as shown in
Figure 2. This classification system acts as the foundation for determining
the level assigned to a software component, considering its contribution to
the potential failure conditions of the overarching system [7].

Figure 2: DAL pyramid, adapted from [9].

Below we have detailed each DAL level caused by software’s anomalous behaviour
determining or contributing to a failure of a system function [7, 9].

  * •

Level A: Catastrophic is a failure condition resulting in multiple fatalities
and loss of the aeroplane.

  * •

Level B: Hazardous/Severe is a failure condition that reduces the aeroplane or
flight crew’s capability to cope with adverse operating conditions. These
effects can manifest as a large reduction of functional capabilities and
safety margins, as fatal or serious injury to a small number of passenger
besides the crew and can create physical distress or excessive workload of the
flight crew that can no longer accurately or completely do their tasks.

  * •

Level C: Major is a failure condition that reduces the aeroplane or flight
crew’s capability to cope with adverse operating conditions. These failures
can create a significant reduction of functional capabilities, safety margins,
discomfort or distress of the flight crew and passengers possibly including
injuries or can significant increase in the crews workload impairing their
efficiency.

  * •

Level D: Minor failure condition would not cause significant effect on the
aeroplane safety, all crew members being in the possession of knowledge needed
to manage such incidents. These conditions may refer to slight reduction of
safety margins and functional capabilities, slight increase in the crew
workload as well as some physical discomfort to passengers and cabin crew.

  * •

Level E: has no effect his a criticality level that does not impact the safety
margins and would not affect on the operational capabilities of the aircraft.
While this error does not affect the functioning of the aircraft,
justifications about this error (issue) need to be provided to the Federal
Aviation Administration (FAA).

The _DO-178C_ categorizes the DAL levels based on the required objectives, the
impact of anomalies in the software component, and the failure rate of that
component. These objectives encompass process requirements outlined in the
document, showcasing adherence to _DO-178C_ when interacting with
certification authorities. Table 2 summarises these levels’ overview, from the
utmost criticality (level A) to the least (level E). As depicted in Figure 2
and Table 2, level A is the highest criticality level according to the
document. It requires a comprehensive set of objectives and verification
objectives to ensure the safety and reliability of the software. Notably,
level E, positioned as the least critical, is the only level excused from
requiring verification activities. We might still need to follow certain
development practices if our software falls under level E. However, the
scrutiny and verification level is generally lower than the other levels.

Table 2: Number of Objectives and Verification Objectives required by
_DO-178C_ for every DAL level [7].

DAL No. of Objectives No. of Verification Objectives A 71 43 B 69 41 C 62 34 D
26 9 E 0 0

Presenting all objectives and verification objectives for each DAL summarised
in Table 2 is not feasible due to the extensive and complex information
involved. For a thorough compilation of these objectives and verification
objectives, referring directly to the _DO-178C_ document is recommended. This
document provides comprehensive guidance on the requirements for each level,
spanning from level A to the final level E. In Subsection 3.8, we provide a
comprehensive overview of the processes associated with the tables listed in
Annex A of the _DO-178C_ document. This section precisely points to the
location where these tables are situated within the _DO-178C_ document. These
tables thoroughly explain the objectives, verification objectives, activities,
and outcomes linked to distinct software levels.

The _DO-178C_ document expands beyond failure conditions and outlines
additional software-related considerations within the system lifecycle process
[7]. These considerations encompass various aspects:

  * •

Parameter Data Items \- Consists of executable object code and/or data that
can compromise one or more configuration items or data that can influence the
software behaviour without modifying the executable.

  * •

User-Modifiable Software \- Consists of software or part that may be changed
by the user within modifications constraints without certification authority
review.

  * •

Commercial-Off-The-Shelf Software \- Software already included in the airborne
systems.

  * •

Option-Selectable Software \- Consists of functions from some airborne systems
and equipment that may be selected by other software instead of hardware
connector pins.

  * •

Field-Loadable Software \- Refers to software that can be loaded without
removing the system or equipment from its installation.

In essence, the _DO-178C_ document goes beyond just failure conditions,
encompassing these diverse aspects of software considerations within the
context of the system lifecycle process.

###  3.2 DO-178C and related Supplements

The _DO-178C_ standard guides the aerospace community in developing with an
acceptable level of confidence the software parts of airborne systems and
equipment that must comply with the requirements of the standards and
documents. It describes the complete systems lifecycle process, including the
safety assessment and validation processes; however, it does not intend to
describe the certification process for which we must refer to applicable
regulations and guidance material issued by the certification authorities [7].
Figure 3 shows the relationship between the _DO-178C_ and the related
supplements. As we can observe, the _DO-178C_ is what we can call the core
document.

Figure 3: _DO-178C_ and related documents, adapted from [8].

Each one of the _DO-178C_ supplements provides additional information on key
topics, namely [7, 8]:

  * •

_DO-248C_ (Supporting Information for _DO-178C_ and _DO-278A_) – Collection of
Frequently Asked Questions (FAQs) and Discussion Papers (DPs) with
applications of _DO-178C_ and _DO-278A_ in the safety assurance of software
for aircraft [18].

  * •

_DO-330_ (Software Tool Qualification Considerations) – Standalone document
referenced by the _DO-178C_ that provides guidance on tools qualification
[19].

  * •

_DO-331_ (Model-Based Development and Verification Supplement to _DO-178C_ and
_DO-278A_) – Provides guidance for model-based development and verification
used as part of the software lifecycle. Furthermore, it includes the outputs
that would be using models and the verification evidence that could be derived
from them. Therefore, this supplement also applies to the models developed in
the system process that define software requirements or software architecture
[20].

  * •

_DO-332_ (Object-Oriented Technology and Related Techniques to _DO-178C_ and
_DO-278A_) – Provides guidance when object-oriented technology or related
techniques are used as part of the software development lifecycle (development
and verification) [21].

  * •

_DO-333_ (Formal Methods Supplement to _DO-178C_ and _DO-278A_) – Provides
guidance when formal methods are used as part of a software lifecycle [22].

The current focus of this study is the _DO-178C_ ; however, these other
documents might be considered in the future. _DO-178C_ itself comprises twelve
sections, two annexes and two appendixes briefly described in Subsection3.3
[7, 8].

The main purpose of the _DO-178C_ standard is not to explain "how to develop"
but rather to "support the development" of software for airborne systems and
equipment to ensure a level of confidence in safety that complies with
specific airworthiness requirements/objectives [7]. This demonstrates that
there are no inherent constraints or restrictions within the document that
forbid the adoption of Agile methods, contrary to the prevailing industry
opinion that the traditional waterfall method is mandatory.

###  3.3 DO-178C Document Structure

Having a better understanding of how the _DO-178C_ relates to the other
documents and supplements (Section 2 and Subsection 3.2), we believe it is the
right moment to advance and understand the _DO-178C_ structure.

The document is composed of 12 sections, briefly described below [7, 8]:

  * •

Section 1 – document overview. Explains the purpose and scope of the document,
its relationship to other documents and how to use it.

  * •

Section 2 – provides details about the system framework related to software
development (such as: information flow between systems and software lifecycle
process, system and software assessment process, among others); it is aligned
with _ARP4745A_.

  * •

Section 3 – software lifecycle process overview of planning, development
(requirements, design, code and integration), verification, software
configuration management, software quality assurance and certification
liaison.

  * •

Section 4 – explains the planning process, objectives and activities. One
example of a planning process is the software lifecycle environment from
development to testing.

  * •

Section 5 – provides the necessary details for the software development
process objectives and activities that include requirements, design, coding,
integration and traceability phases.

  * •

Section 6 – verification is not just testing but a technical assessment of the
outputs. Verification is vital in software development assurance since over
half of the _DO-178C_ objectives are verification objectives. The process
begins with the verification of the plans, and it goes until reporting and
review of verification results.

  * •

Section 7 – explains the change configuration management process. The process
includes objectives and activities like traceability reporting, control and
review.

  * •

Section 8 – provides guidance for the software quality assurance process, what
are the objectives and activities.

  * •

Section 9 and 10 – summarize the certification liaison and the certification
process.

  * •

Section 11 – identifies the software lifecycle outputs (data) generated while
planning and verifying the software.

  * •

Section 12 – includes guidance for some additional considerations, including
modifications to previously developed software, tool qualification,
alternative methods, software reliability models and product service history.

The _DO-178C_ document also contains annexes A and B, and appendixes A and B
covering [7, 8]:

  * •

Annex A – contains tables for each process with the 71 formal objectives and
outputs by software level (e.g., independence requirements for the objective,
output to be generated for safety, the objective and the amount of
configuration control required on the output).

  * •

Annex B – includes the acronyms and glossary of terms used in the _DO-178C_
standard.

  * •

Appendix A – provides the background of the _DO-178_ documents and highlights
the differences between the previous (_DO-178B_) and the current (_DO-178C_)
standards.

  * •

Appendix B – contains committee membership.

Once more, the purpose of the _DO-178C_ standard is not to explain the "how",
instead and quoting [7] is to:

> The purpose of this document is to provide guidance for the production of
> software for airborne systems and equipment that performs its intended
> function with a level of confidence in safety that complies with
> airworthiness requirements.

This conclusion emphasizes the absence of intrinsic limitations or
restrictions within the document that would deny the adoption of Agile
methods, challenging the general industry opinion that the traditional
waterfall method is mandatory.

###  3.4 DO-178C Five Plans

Subsection 3.3 provided valuable insights into the _DO-178C_ structure,
clarifying the significance of each of its twelve sections. Turning our focus
to section eleven within the _DO-178C_ document, it strongly recommends
creating five plans with specific information for any DAL level, which is
referred to as the "Software level" in the _DO-178C_ (last version published
in 2011). These plans can be summarized as follows [7, 8]:

  * •

Plan for Software Aspects of Certification (PSAC) – This is the preliminary
plan submitted to the certification authority. It is used to document the
agreements with the certification authority and to determine if the proposed
software lifecycle corresponds with the rigour required for the software’s DAL
being developed by the applicant.

  * •

Software Development Plan (SDP) – It describes the software development
procedures and lifecycle to satisfy the process objectives to guide the
development team and ensure compliance. Furthermore, it describes the
development environment and the standards to be used (requirements, design and
coding). The SDP provides the necessary details to ensure proper
implementation of the software lifecycle process, while the PSAC only contains
a summary.

  * •

Software Verification Plan (SVP) – It describes the software development
procedures to be used and guides the verifiers through the verification
process, ensuring compliance with the _DO-178C_ objectives. Some examples are
organisational responsibilities, independence, verification methods and
environment.

  * •

Software Quality Assurance Plan (SQAP) – Establishes the plan and methods to
achieve the _DO-178C_ document objectives, plans, and software quality
assurance standards.

  * •

Software Configuration Management Plan (SCMP) – Establishes the software
configuration management procedures, activities, and environment to be used
throughout the software development and verification. The plan includes
configuration identification, baselines and traceability, problem reporting,
change control, and change review.

Each of the five plans (PSAC, SDP, SVP, SQAP, and SCMP) outlines the processes
that must be implemented and applied to the project’s outputs [7, 8]. These
processes are meticulously defined within these plans right at the inception
of any aerospace project, even before the specification of requirements,
encompassing both system and software aspects within the aerospace system and
software development context. It is crucial to emphasize that the _DO-178C_
document deliberately refrains from imposing or constraining the selection of
methods to be employed and detailed in these plans. This flexibility empowers
project stakeholders to opt for the method that best aligns with their
requirements, including Agile methods. The pivotal factor to consider when
choosing a method lies in ensuring that it instils a level of safety
confidence that meets the specific airworthiness requirements and objectives
tailored to the particular DAL, as elaborated in Section 3.1.

In summary, the _DO-178C_ outlines a structured and rigorous approach to
software development for safety-critical aerospace systems. While the text
does not explicitly state that _DO-178C_ restricts the usage of Agile software
development, the _DO-178C_ places significant emphasis on documentation, as
outlined in the five plans considering the various aspects of the software
development and verification process. _DO-178C_ mandates rigorous verification
and quality assurance processes, which include maintaining independence
between development and verification activities. While Agile practices often
promote continuous integration and delivery, alternative approaches are
available to ensure role independence while still adhering to verification and
quality assurance requirements. These approaches may include practices like
Test-Driven Development (TDD) and Pair Programming (PP)111Test-Driven
Development (TDD) and Pair Programming (PP) are two of the twelve practices
that make up the Agile method known as Extreme Programming (XP), introduced by
Kent Beck [24, 25]. [23]. _DO-178C_ requires adherence to specific predefined
standards for requirements, design, and coding. While Agile teams typically
enjoy flexibility in selecting their own, including the tools to be used, it
is essential to note that when defining the standards within the plans, an
agreement can be achieved with the teams to adhere to the specified
guidelines. Lastly, _DO-178C_ requires tailoring its processes according to
the DAL of the software being developed, indicating different levels of rigour
for different DALs. In this context, an Agile method that aligns with the
specific DAL may be selected. However, it is essential to acknowledge that
customizations might be necessary to address the particular DAL requirements
while ensuring compliance with _DO-178C_. Considering these factors, we
conclude that _DO-178C_ ’s emphasis on detailed planning, documentation, and
adherence to specific standards makes it challenging to adopt Agile and
implement a particular Agile method without significant modifications. While
it is not impossible to use Agile in a _DO-178C_ -compliant project, it would
likely require tailoring the Agile method selected and respective practices to
meet the rigorous safety and certification requirements of _DO-178C_.
Ultimately, the choice of development, including an Agile method, should be
made carefully, considering the specific needs and constraints of the project
and the regulatory requirements of _DO-178C_.

###  3.5 Software Development Standards and Plans Outputs

Along with the five plans described in the previous subsection (Subsection
3.4), _DO-178C_ also requires adherence to three additional standards [7, 8]:
Software Requirement Standard (SRS), Software Design Standard (SDS), and
Software Coding Standard (SCS). While these standards can draw inspiration
from industry-wide standards, they must be defined individually and customized
for project-specific needs. These documents establish a set of rules and
constraints for the project team, facilitating control over functionality and
safety features.

While it is essential to recognize that _DO-178C_ mandates compliance with
specific predefined standards for requirements, design, and coding, and Agile
teams generally have the flexibility to select their own standards and tools,
it is equally crucial to emphasize that no inherent limitation exists within
Agile methods that prevents alignment with the specified guidelines when
defining standards within the plans. Moreover, there are no inherent
constraints that prevent Agile teams from adhering to these guidelines, as
agreements can be reached with the teams to ensure compliance with those
requirements.

Returning our attention to the outputs of the five plans, there is a strong
correlation between the plans, processes, standards, and outputs, all
collectively contributing to achieving compliance with _DO-178C_ objectives
[7, 8], as illustrated in Figure 4 and described below.

Figure 4: Plans and processes correlation with their corresponding outputs.

  * •

Software Accomplishment Summary (SAS) – summarises the actual versus planned
(as specified in PSAC) activities and results for the project. The
certification authority uses it to overview the software aspects of
certification.

  * •

Software Configuration Index (SCI) – identifies the software configuration and
can contain a set of configuration items.

  * •

Software Requirements Data (SRD) – defines the high-level requirements (HLR),
including the derived requirements.

  * •

Trace Data – establishes the associations between lifecycle data items and
contents. Trace Data demonstrates bi-directional associations between:

    * –

System requirements allocated to software and HLR;

    * –

HLR and low-level requirements (LLR);

    * –

LLR and source code;

    * –

Software requirements and test cases;

    * –

Test cases and test procedures;

    * –

Test procedures and test results.

  * •

Software Design Description (SDD) – defines the software architecture and the
LLR that will satisfy the HLR.

  * •

Source Code – consists of written code in the source language.

  * •

Executable Object Code (EOC) – consists of code usable by the target computer
processing unit and is, therefore, software loadable into the hardware or
system.

  * •

Parameter Data Item File (PDIF) – consists of usable data by the target
computer processing unit.

  * •

Software Verification Results (SVR) – results produced by the software
verification activities. It is used as evidence to support the system
processes assessment.

  * •

Software Configuration Management Records (SCMR) – results of the software
configuration management process’s activities. Examples are configuration
identification lists, baselines, change history reports, and release records.

  * •

Problem Reports (PR) – are a means to identify and record software product
anomalous behaviour resolution, process non-compliances with software plans
and standards, and deficiencies in software lifecycle data.

  * •

Software lifecycle Environment Configuration Index (SECI) – identifies the
software lifecycle environment’s configuration. This index is written to
reproduce the hardware and software lifecycle environment for software
regeneration, re-verification, or modification.

  * •

Software Quality Assurance Records (SQAR) – SQA records results from audit
reports, meeting minutes, authorized process deviation, software conformity
review records, and others.

In summary, as illustrated in Figure 4, the production of these outputs occurs
at different stages throughout the software development lifecycle, as outlined
in the project plans. These outputs ensure adherence to _DO-178C_ objectives.
The timing of output generation can vary depending on the selected software
development method, the project’s lifecycle, and the development phase in
progress. The exact timing also depends on project-specific considerations,
the chosen development method, and the DAL assigned to the software under
development. Achieving _DO-178C_ compliance requires a rigorous approach
encompassing comprehensive planning, meticulous documentation, and
verification activities at each phase, guaranteeing that safety-critical
aerospace software aligns with its intended objectives. Considering that the
_DO-178C_ does not restrict the use of specific development methods, including
Agile methodologies.

Furthermore, Agile, as per the Agile Manifesto, is characterized by an
iterative and incremental approach focusing on continuous delivery and client
satisfaction [26]. Transitioning to Agile in this context is feasible without
harsh changes to existing processes [23, 27]. Instead, it can be accomplished
by defining a software development process in the plans (Subsection 3.4) that
is tailored and incorporates some Agile practices, aligning them with the
specific DAL requirements to ensure compliance with _DO-178C_. This results in
a more streamlined process and the potential to reuse outputs generated during
different lifecycle phases, including documentation, iteratively and
incrementally.

###  3.6 Software Development Process

As mentioned earlier, both the PSAC and the SDP must provide a comprehensive
description of the software development process to be used. It is important to
remark that _DO-178C_ does not prescribe specific methods, neither does it
restrict Agile methods. Nevertheless, following DO-178C guidelines, the
software development process consists of four subprocesses [7, 8]: the
Software Requirements Process, Software Design Process, Software Coding
Process, and Integration Process. In this publication, we do not aim to define
or describe the detailed methods, including an Agile method tailoring for each
process. They are individually defined and customized to address project-
specific requirements within the PSAC and SDP plans, which are established
before starting any development. Our future work may explore the incorporation
of Agile methods with the implementation of the required tailoring into these
processes and always maintaining compliance with the _DO-178C_ objectives.

Nonetheless, it is worth noting that certain aerospace companies have achieved
a high level of maturity by relying on predefined plans and software
development processes (traditional waterfall method), necessitating only minor
tailoring to adapt to the specific needs of new projects. To provide a
comprehensive understanding of the relationship between plans, processes, and
V&V activities and how they interconnect, we have drawn upon the insights
gained from our analysis of _DO-178C_. Figure 5 illustrates the outcome of
this exercise. Our primary objective has been to identify and describe the
essential steps from the planning phase to what we consider as certifiable or
certification-ready. Furthermore, to ensure successful certification, it is
crucial to grasp the significance of the State of Involvement (SOI) within the
process. The certification authority outlines SOI assessments/audit events at
various project stages [8].

Figure 5: _DO-178C_ Software Development Process, adapted from [7].

The _DO-178C_ standard does not define or indicate the certification authority
involvement level in a certification process. However, the author in [8]
states that the International Certification Authorities Software Team (CAST)
identified a software compliance assessment approach indicating four
intervention points throughout the project: planning, development, test and
final [7, 8].

As stated by [8]:

  * •

SOI 1 – audit that happens after the plans and standards have been reviewed
and baselined.

  * •

SOI 2 – audit that happens after at least half of the code has been developed
and reviewed.

  * •

SOI 3 – audit usually happens after at least half of the test cases and
procedures are developed and reviewed.

  * •

SOI 4 – audit happens after any issues from the other SOI audits are closed,
and the verification results, SCI and SAS are reviewed and baselined.

Figure 5 shows how the software requirements process uses the system lifecycle
processes’ outputs to develop HLR; the software design process uses the HLR to
redefine and develop the software architecture and the LLR that can be used to
implement the source code. The mapping also shows how integration and V&V
relate with HLR, Design, LLR and source code. Furthermore, Figure 5 shows when
each SOI event should achieve successful V&V and certification-ready status.
However, the _DO-178C_ does not specify any software development method such
as Waterfall, or any other method to be used by any process; it only requires
that what is described in the plans is followed and the production of the
needed evidence to achieve certification [7, 8, 9].

###  3.7 Traceability, Independence and Change Control

The _DO-178C_ standard identifies traceability, independence and change
control activities as highly important to achieving successful certification.

Following the _DO-178C_ standard, traceability, independence and change
control can be summarised as [7]:

  * •

Traceability – is the mapping between process outputs, an output and its
originating process, or between a requirement and its implementation.

  * •

Independence – separation of responsibilities to guarantee an objective
evaluation. They are usually achieved by having the verification activity
performed by person(s) or tools independent from the developer of the item
being verified.

  * •

Change control – managing and controlling changes to configuration items and
baselines after their formal establishment.

In summary, an Agile method can be customized by integrating specific Agile
practices when defining the software development process in the PSAC and SDP.
This method should be defined and implemented in alignment with the
requirements and objectives of _DO-178C_ to ensure compliance, specifically
when addressing traceability, independence, and change control requirements.
For traceability, Product Backlog Items (PBIs)222 PBI is a smaller requirement
increment of work that can be completed during a specific established
timeframe [28]. can establish clear links between user requirements and
development tasks or features. Each PBI can comprehensively outline the
requirement and its corresponding implementation, ensuring a transparent
connection between requirements and their successful implementation.
Acceptance criteria, specifying the conditions for requirement fulfilment,
further enhance traceability. To achieve independence, Agile practices like
cross-functional teams promote collaboration among members with diverse roles,
ensuring independence. This structure inherently fosters objective
evaluations, particularly during verification, where team members not involved
in initial development can provide impartial assessments. Code reviews within
the Agile method also ensure independent evaluations of code quality and
alignment with requirements.

Regarding change control, Agile teams effectively manage changes through
continuous refinement and prioritization of PBIs. This approach allows teams
to accommodate new requirements while maintaining traceability. In addition,
Agile teams usually employ version control systems to track and manage changes
to configuration items systematically, ensuring comprehensive documentation
and management. By integrating these practices, the process can successfully
address traceability, independence, and change control requirements while
upholding the requirements and objectives outlined in _DO-178C_.

###  3.8 DO-178C Objectives and Activities

In Subsection 3.1, Table 2 provides a summary of the distinct DAL levels,
going from the highest level of criticality (level A) to the lowest (level E).
The table also presents the number of objectives and verification objectives
that must be adhered to according to the _DO-178C_ document for each level.
Moving forward, Subsection 3.4 outlines the essential five plans mandated by
the _DO-178C_ document. This subsection delves into the intricate
relationships between these plans, elucidates their individual processes, and
delineates the resultant outputs they yield. Moreover, Subsection 3.6
introduces Figure 5, which visually elucidates the fundamental stages spanning
from the initial planning phase to the attainment of a state that qualifies as
either certifiable or ready for certification.

As previously discussed in Subsection 3.3, Annex A of the _DO-178C_ document
contains tables that elaborate on the objectives, verification objectives
activities, and outputs for various software levels [7]. These tables pertain
to the following processes:

  * •

Software Planning Process (Table-1, Page 96, [7]);

  * •

Software Development Processes (Table-2, Page 97, [7]);

  * •

Verification of Outputs of Software Requirements Process (Table-3, Page 98,
[7]);

  * •

Verification of Outputs of Software Design Process (Table-4, Page 99, [7]);

  * •

Verification of Outputs of Software Coding & Integration Processes (Table-5,
Page 100, [7]);

  * •

Testing of Outputs of Integration Process (Table-6, Page 101, [7]);

  * •

Verification of Verification Process Results (Table-7, Page 102, [7]);

  * •

Software Configuration Management Process (Table-8, Page 103, [7]);

  * •

Software Quality Assurance Process (Table-9, Page 104, [7]);

  * •

Certification Liaison Process (Table-10, Page 105, [7]).

Furthermore, It is important to note that the _DO-178C_ document emphasizes
that these tables, elucidating objectives, activities, and outputs, should not
be regarded as checklists, as they do not encompass the entirety of compliance
aspects stipulated by the standard [7]. Due to the above reason, we intend not
to detail each activity mandated by the _DO-178C_ document exhaustively, but
rather to indicate the locations where these details can be sourced in the
future for each respective process.

Moreover, listing all objectives and verification objectives by each DAL is
impractical due to the extensive and complex nature of the information. For
the complete list of objectives and verification objectives, it is recommended
to refer to the _DO-178C_ document itself, which provides comprehensive
guidance on the requirements for each level. The document is extensive and
complex, designed to ensure the highest levels of safety and reliability in
airborne software systems.

##  4 Conclusions

In conclusion, the _DO-178C_ document and its supplements represent a
commitment to aerospace software safety. As aerospace systems rely heavily on
software to enhance efficiency and functionality, the guidelines outlined in
the _DO-178C_ document have emerged as a critical influence in shaping
aerospace domain software development. At its core, the _DO-178C_ document is
not intended to be a rigid and prescriptive rulebook for software development.
Instead, its primary purpose is to provide comprehensive guidance for software
production within the aerospace domain. This approach acknowledges the dynamic
nature of software development nowadays while setting a clear path toward
ensuring safety and reliability. By avoiding a one-size-fits-all method, the
_DO-178C_ document encourages adaptability and innovation in the pursuit of
robust software solutions. In other words, it does not impose restrictions on
the adoption of Agile methods, a finding that we present in this paper that
challenges the prevailing industry notion that the traditional waterfall
method is mandatory. Central to the _DO-178C_ are the five plans: the PSAC,
SDP, SVP, SQAP, and SCMP. These plans collectively lay the groundwork for the
software development process, delineating a course to prioritise traceability,
independence, and change control. This holistic approach ensures that software
development is not merely a technical endeavour but a rigorously documented
and audited journey that leaves no room for ambiguity. Under the _DO-178C_ ,
the software development process encompasses four integral subprocesses:
Software Requirements Process, Software Design Process, Software Coding
Process, and Integration Process.

Figure 5 shows the relationship between these subprocesses, plans, and safety
certification objectives. The SOI audits, dispersed throughout the development
lifecycle, underscore the incremental nature of verification and the critical
role of continuous assessment in achieving the highest airworthiness
standards. The _DO-178C_ document being a reference for industry
collaboration, it embodies the collective dedication to safety within the
aerospace domain. Offering guidance rather than a strict software development
method encourages an environment where developers, engineers, and stakeholders
can tailor their software development practices to address unique challenges
and objectives, leaving space for future adaptations resulting from an ever-
evolving industry landscape. While _DO-178C_ does not explicitly restrict
Agile methods, its rigorous framework places significant emphasis on
documentation, independence between development and verification activities,
and adherence to predefined standards, aspects that are not generally taken
into account in Agile methods. By incorporating in Agile development practices
such as traceability through Product PBIs, cross-functional teams for
independence, and change control, it is possible to use Agile methods within
the _DO-178C_ compliance context. Agile can offer benefits like continuous
integration and delivery while maintaining compliance, but it must align with
_DO-178C_ ’s requirements and objectives. Achieving a successful integration
of Agile practices into _DO-178C_ involves tailoring the selected Agile method
and practices, ensuring that they address the specific needs and safety
certification requirements of the project. Ultimately, the choice of
development approach, including Agile, should be made thoughtfully,
considering project specifics and the regulatory requirements of _DO-178C_.

Given the adaptable nature of the _DO-178C_ document regarding software
development methods, future research could focus on two main areas:

  * •

Evaluating Established Methods: A comprehensive analysis of overall methods,
including a critical examination of the Waterfall method, considering
scientific research and industry experiences.

  * •

Exploring New Approaches: Investigating emerging software development methods
from the Agile field that can accommodate the dynamic demands of the aerospace
domain. The goal is to identify methods that optimize efficiency, safety, and
compliance within the _DO-178C_ document.

Both research lines could contribute to increasing the domain knowledge and
refining aerospace software practices, fostering a balance between innovation
and safety in this rapidly evolving industry.

## References

  * [1] Bowen, J. & Stavridou, V. Safety-critical systems, formal methods and standards. Software Engineering Journal. 8, 189 (1993)
  * [2] Cullyer, J. Safety critical systems. Microprocessors And Microsystems. 17, 2 (1993)
  * [3] Knight, J. Safety critical systems: Challenges and directions. Proceedings - International Conference On Software Engineering. pp. 547-550 (2002)
  * [4] Myklebust, T. & Stålhane, T. The agile safety case. The Agile Safety Case. pp. 1-235 (2018,1)
  * [5] Mathur, S. & Malik, S. Advancements in the V-Model. ©2010 International Journal Of Computer Applications. 1 pp. 975-8887 (2010)
  * [6] Russo, S. & Scippacercola, F. Model-Based Software Engineering and Certification: Some Open Issues. Proceedings - 2016 IEEE 27th International Symposium On Software Reliability Engineering Workshops, ISSREW 2016. pp. 237-240 (2016,12)
  * [7] DO-178C, Software Considerations in Airborne Systems and Equipment Certification. RTCA. (2011)
  * [8] Rierson, L. Developing Safety-Critical Software: A Practical Guide for Aviation Software and DO-178C Compliance. (CRC Press,2013)
  * [9] Vance Hilderman and Tony Baghai Avionics Certification: A Complete Guide to DO-178 (Software), DO-254 (Hardware). (2007)
  * [10] DO-254, Design Assurance Guidance for Airborne Electronic Hardware. RTCA. (2000)
  * [11] ARP4754A, Guidelines for Development of Civil Aircraft and Systems. SAE International, December. (2010)
  * [12] ARP4761, Guidelines and methods for conducting the safety assessment process on civil airborne systems and equipment. SAE International, December. (1996)
  * [13] DO-297, Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations. RTCA. (2005)
  * [14] ARP5150A, Safety Assessment of Transport Airplanes in Commercial Service. SAE International. (2013)
  * [15] ARP5151A, Safety Assessment of General Aviation Airplanes and Rotorcraft in Commercial Service. SAE International. (2013)
  * [16] Singh, A. RTCA DO-178B (EUROCAE ED-12B). (2011), https://www.researchgate.net/publication/315023556
  * [17] McHale, J. Real-time operating system vendors rush to comply with DO-178B | Military & Aerospace Electronics. (2001), https://www.militaryaerospace.com/computers/article/16710702/realtime-operating-system-vendors-rush-to-comply-with-do178b
  * [18] DO-248C, Supporting Information for DO-178C and DO-278A. RTCA. (2011)
  * [19] DO-330, Software Tool Qualification Considerations. RTCA. (2011)
  * [20] DO-331, Model-Based Development and Verification Supplement to DO-178C and DO-278A. RTCA. (2011)
  * [21] DO-332, Object-Oriented Technology and Related Techniques to DO-178C and DO-278A. RTCA. (2011)
  * [22] DO-333, Formal Methods Supplement to DO-178C and DO-278A. RTCA. (2011)
  * [23] VanderLeest, S. & Buter, A. Escape the waterfall: agile for aerospace. 2009 IEEE/AIAA 28th Digital Avionics Systems Conference. DASC 2009. (2009)
  * [24] Beck, K. Extreme Programming Explained: Embrace Change. (Addison-Wesley Longman Publishing Co., Inc.,1999)
  * [25] Beck, K. & Andres, C. Extreme Programming Explained: Embrace Change (2nd Edition). (Addison-Wesley Professional,2004)
  * [26] Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., C. Martin, R., Mellor, S., Schwaber, K., Sutherland, J. & Thomas, D. Manifesto for Agile Software Development, (URL http://agilemanifesto.org/). (2001)
  * [27] Silva Cardoso Rodrigues, J., Ferreira Ribeiro, J. & Aguiar, A. Improving Documentation Agility in Safety-Critical Software Systems Development For Aerospace. 2022 IEEE International Symposium On Software Reliability Engineering Workshops (ISSREW). pp. 222-229 (2022)
  * [28] Schwaber, K. & Sutherland, J. Scrum Guide V7. (2020)