April 30, 2014

429 Views

Addressing Traceability Issues In Critical Aerospace Software

The greatest pain-points in processes and products are the result of ‘self-imposed constraints’.

For example, as per DO-178B one needs to generate Software Requirements and Design Data, but it does not state that these have to be different documents. Most teams continue to generate 2 different documents – Software Requirements Document (SRD) and Software Design Document (SDD) – because that’s what we see is being done for ages.

And the fact that managing and control of two separate documents are easier… apparently.

But this is also the reason for the greatest pain-point in the aerospace software life cycle: incomplete and/or incorrect traceability.

The pain-point becomes real when you witness an audit. The developer struggles to explain trace threads. S/he eventually explains the trace, but that involves much scrolling up and down.

The pain-point is a reality for designers, developers, and reviewers.

Model Based Development offers a way out, of course. If I double click on a model and that takes me from a top level model to a more elaborate lower-level model, then I know how the trace would be, but unfortunately, DO-178C insists that all models must be developed from textual requirements; so the issue for aerospace safety critical software remains.

Can there be a solution? Here’s one:

  1. Have one document for both SRD and SDD  
  2. Obviously the Software Requirements (the SRD part) need to be written down first
  3. The Design Data (the SDD part), instead of being developed separately, is interleaved between the SRD requirements  - using the following format

SRD#1 …. <text>

                SDD#1 … <text>
                SDD#10 … <text>
                SDD#13 … <text>

SRD#2 … <text>

                SDD#2 …<text>
                SDD#3 … <text>
                SDD#4 … <text>
                Derived Req #1 … <text>

SRD#3 …. DELETED

                SDD#5 … DELETED
                SDD#6 … DELETED

SRD#4 … <text>

                SDD#1 – refer SRD#1

SDD#7 … <text>

                SDD#8 … <text>
                SDD#9 … DELETED
                SDD#11 … DELETED
                SDD#12 … DELETED
                Derived Req #2 … <text>

  1. Maintain two sets of change history at the top of the document to trace the modifications done to SRD and SDD separately.

Advantages:

  • Traceability is built in – so a major headache is removed
  • SRD requirements would be more modular
  • SDD requirements will be better written, since they need to make sense in the context of the SRD requirements.
  • Derived Requirements now have a placeholder.
  • Maintainability is rather high. While deleting an SRD requirement, one has to evaluate if there is any impact on the corresponding SDD requirement or vice-versa.

The Challenges:

  • It is possible that the customer / DER insists on two separate documents. In that case, all that is required is write a macro to extract the relevant information and make two separate documents (or uploaded to DOORS as separate modules).
  • The process needs to be modified a little to ensure tighter handover from one phase to another (that, in any case, needs to be clearly specified in the Software Development Plan, SDP)
  • Word Documents become a little slow to manipulate if the RAM size of the PC/laptop is small. HCL Technologies has a dedicated Aerospace Software Engineering unit that specialises in aerospace safety.

References:

[1] RTCA/DO-178B – Software Considerations in Airborne Systems and Equipment Certification. Dec.1, 1992.

[2] RTCA/DO-178C - Software Considerations in Airborne Systems and Equipment Certification. Dec.13, 2011.