Certification Authorities Software Team (CAST)

Position Paper

CAST-22

***Reuse of Software Tool Qualification Data Across Company Boundaries
(Applying the Reusable Software Component Concept to Tools)***

***COMPLETED March 2005***

***(Rev 1)***

##### Reuse of Software Tool Qualification Data Across Company Boundaries (Applying the Reusable Software Component Concept to Tools)

1.  **Introduction and Background**

    1.  Software verification and development tools are often packaged
        in such a way that their qualification data may be reusable on
        multiple projects. Chapter 9 of FAA Order 8110.49 and Section
        12.2 of DO-178B/ED-12B address the tool qualification process.
        Chapter 12 of Order 8110.49 addresses reuse of tool
        qualification data within a company, when used in the same way
        as a previous project. FAA Advisory Circular (AC) 20-148,
        "Reusable Software Components," addresses reuse of software
        components across company boundaries, when all stakeholders
        agree on the reuse approach. However, none of the policy or
        guidance to date addresses the reuse of tool qualification data
        across company boundaries. A note is included in Section 2 of AC
        20-148 to allow some tool qualification reuse consideration. The
        note states: *"The reuse concept in this AC may apply to
        verification and development tools. Applicants and tool
        developers must discuss with the FAA the details of each
        reusable tool qualification project. Because tools differ from
        airborne software, there are other concerns to address when
        trying to reuse tool qualification data. The FAA plans to
        address tool reuse in future guidance."* However, at the time of
        completing the AC, the approach for addressing tool
        qualification reuse was not yet documented.

    2.  The purpose of this paper is to document the process for reusing
        tool qualification data across company boundaries (i.e., to
        approach tools as a kind of reusable component that may be
        reused with minimal certification authority involvement on the
        subsequent projects). This paper builds upon the guidance of AC
        20-148 with specific focus on tool-unique aspects.

> Note: If the tool is not used across company boundaries, this approach
> may not be desirable (i.e., Chapter 12 of Order 8110.49 should be
> consulted instead).

3.  This position paper will likely become the basis for additional
    guidance or an update to AC 20-148 to specifically address the reuse
    of tool qualification data across company boundaries. It must be
    noted that if this position paper progresses to be implemented into
    an AC, the AC contents will take precedence over this paper.

```{=html}
<!-- -->
```
2.  **Overview of AC 20-148**

> AC 20-148 is summarized below:

-   Sections 1 through 3 explain the purpose of the AC, discuss the
    motivation for the guidance, and outline factors for getting
    certification authority to accept a reusable software component
    (RSC).

-   Section 4 provides general guidelines for RSC acceptance.

-   Sections 5 through 7 provide guidance for RSC developers,
    integrators, and applicants on developing or using an RSC.

-   Sections 8 through 10 provide typical activities the RSC developers,
    integrators, and applicants can expect from the certification
    authorities for the first acceptance of an RSC and its subsequent
    use.

-   Section 11 discusses common issues that should be addressed when
    developing and using an RSC. These issues may affect multiple
    DO-178B/ED-12B objectives. Section 11 is not an exhaustive list of
    issues that may arise, since each project will have its own specific
    issues.

-   Section 12 addresses changes to an RSC.

-   Section 13 provides guidance for concurrent uses of an RSC.

-   Section 14 lists related documents to assist with RSC compliance.

-   Appendices 1 through 3 provide definitions of key terms, list of
    acronyms, and a sample format for an RSC developer to document
    DO-178B/ED-12B credit.

> Note: As discussed in AC 20-148, the AC has been coordinated with
> international certification authorities and their comments have been
> addressed. However, it is not certain if international authorities
> will adopt the AC. International certification projects should be
> coordinated with the appropriate authorities to determine the
> applicability of the AC.
>
> Figure 1 below illustrates the approach outlined in AC 20-148.

![](media/image1.wmf)

Figure 1 -- AC 20-148 Approach

3.  **General Guidelines for Reusable Tool Qualification**

#### 

1.  Proposed reusable software development and verification tools should
    be packaged and qualified in such a way that some of the tool
    qualification data may be reused on other projects. The boundaries
    and limitations of what is reusable and what will be
    project-specific should be established during the first acceptance
    of the reusable tool qualification package.

2.  Projects that desire to obtain "credit" for a reusable tool should
    follow the guidelines of AC 20-148 and this paper, as applied to
    tools. The majority of the AC's guidelines may be applied to tools,
    as well as embedded airborne software components. Specific reusable
    tool guidelines are discussed below for both development tools and
    verification tools.

3.  The acceptance letter for the reusable tool qualification will be
    similar to that described in Section 9 of AC 20-148. The letter will
    likely reference the Reusable Tool Qualification Plan (RTQP),
    Reusable Tool Accomplishment Summary (RTAS), Reusable Tool
    Configuration Index (RTCI), and Reusable Tool Data Sheet (RTDS). The
    identification, revision, and dates of these referenced documents
    must be included in the acceptance letter to ensure that the proper
    configuration is considered in subsequent projects. Other data
    associated with the initial tool qualification should be available
    for review by the certification authority, as requested.

```{=html}
<!-- -->
```
4.  **Development Tool Guidelines**

####  

1.  Reusable development tools should follow the guidance in AC 20-148
    for reusable software components, and the guidance of this paper as
    applied to tools. Where an RSC Plan for Software Aspects of
    Certification (PSAC), Software Configuration Index (SCI), Software
    Accomplishment Summary (SAS), Data Sheet, etc. are described in AC
    20-148, an RTQP, RTCI, RTAS, RTDS, etc. should be used instead
    (i.e., the appropriate tool qualification data should be substituted
    for the RSC data).

2.  As with an RSC, the initial reusable tool qualification must be done
    in the context of an actual certification project and must have the
    documented agreement of all the stakeholders (i.e., the applicant,
    the system developer, the reusable tool developer, the tool user,
    and the certification authority must agree on the plan for tool
    reuse). (Note: The stakeholders may vary depending on the nature of
    the project.)

3.  The concept of defining credit and roles for each DO-178B/ED-12B
    objective will still apply for the development tool, as described in
    Section 5 of AC 20-148. For each objective, the following should be
    described in the RTQP and RTAS: amount of credit being sought (full,
    partial, or no credit), assumptions, means of compliance, and
    remaining activities to be completed by the applicant, system
    developer and/or tool user.

4.  The credit being claimed for the tool (i.e., the DO-178B/ED-12B
    objective(s) that it automates, replaces, or supplements) should
    also be described in detail in the RTQP and RTAS with appropriate
    justification of the tool's development assurance level. For each
    objective that the tool automates, replaces, or supplements, the
    following should be described in the RTQP and RTAS: amount of credit
    being sought (full, partial, or no credit), assumptions, means of
    compliance, tool limitations, and remaining activities to be
    completed by the tool user, system developer, and/or applicant.

5.  Any assumptions and limitations that affect proper tool operation
    should also be identified in the RTAS and RTDS (as well as in the
    tool user's guide).

6.  Additionally, the guidance of DO-178B/ED-12B Section 12.2 should be
    addressed in the RTQP, RTAS, and other reusable tool qualification
    data.

7.  The reusable tool data to be supplied to the tool user, system
    developer, and/or applicant is comparable to the data listed in
    Section 6 of AC 20-148. That is, the tool user, system developer,
    and/or applicant will need all data to support software compliance
    substantiation and aircraft type certification and continued
    airworthiness.

8.  A RTDS and acceptance letter for the development tool will be
    similar to an airborne RSC data sheet and acceptance letter (see
    Sections 6.i and 9 of AC 20-148). That is, the RTDS and acceptance
    letter should include the same types of information as described in
    AC 20-148.

```{=html}
<!-- -->
```
5.  **Reusable Verification Tool Qualification Guidelines**

> Defining reuse criteria for verification tool qualification is
> slightly more challenging than development tool qualification, because
> objectives for verification tools are not directly listed in Annex A
> of DO-178B/ED-12B and Chapter 9 of Order 8110.49 addresses only the
> tool qualification process itself and not reuse of the tool
> qualification data. The concept of AC 20-148 applies for verification
> tools; however, the following guidelines should also be considered:

1.  The initial reusable tool qualification must be done in the context
    of an actual certification effort and must have the documented
    agreement of all the stakeholders (i.e., the applicant, the system
    developer, the tool developer, the tool user(s), and the
    certification authority must all agree on the plan for tool reuse).
    (Note: The stakeholders may vary depending on the nature of the
    project.)

2.  The reusable tool developer should package the verification tool
    data separately from the project documents. This is not typically
    required for a verification tool, but if reuse credit is sought, it
    should be separately packaged. (It may be necessary also to protect
    company proprietary information, since the data needs to cross
    company boundaries.) That is, the verification tool should have a
    RTQP, RTCI, RTAS, RTDS, and supporting reusable tool qualification
    data.

3.  AC 20-148 relies on the concept of full, partial, or no credit for
    DO-178B/ED-12B objectives. That is, the objectives serve as the
    mechanism for determining responsibilities of the RSC developer, and
    the integrator or applicant. Prior to the end of the project, all
    applicable objectives must be satisfied. Since objectives for
    verification tool objectives are not listed in Annex A of
    DO-178B/ED-12B, Table 1 was generated to describe the objectives for
    reusable verification tool qualification.

4.  The verification tool objectives in Table 1 should be described in
    detail in the RTQP and RTAS. In generating these objectives, the
    objectives for airborne software and development tools were
    considered for their relevance to reusable verification tools.
    Additionally, Section 12.2 of DO-178B/ED-12B and Chapter 9 of FAA
    Order 8110.49 were considered. A set of 15 verification tool
    qualification objectives was generated and is shown in Table 1. Note
    that, since Table 1 was generated specifically for qualification of
    reusable verification tools, its objectives may go beyond existing
    guidance, e.g., Chapter 9 of Order 8110.49. The first two columns
    provide the reusable verification tool qualification objective
    number and description (the objective number is unique to this
    position paper and has no relevance or tie to DO-178B/ED-12B
    objective numbering). The third column describes the output of the
    objective and DO-178B/ED-12B references. The fourth column provides
    additional description of each objective and the applicability to
    reusable verification tools. The fourth column also describes the
    similarity of the reusable verification tool objective to the
    objectives for airborne software and development tools. The last
    column describes if the output needs to be CC1 or CC2 (control
    category 1 or 2), using Table 7-1 in DO-178B/ED-12B to define CC1
    and CC2. The goal of Table 1 is to provide a set of reusable
    verification tool qualification objectives that can then be used to
    communicate full, partial, or no qualification credit in a
    verification tool reuse project.

###### Table 1 -- Reusable Verification Tool Qualification Objectives

+---+-------------+---------------+----------------------------+-----+
| * | **De        | **Output      | **How the Objective        | **C |
| * | scription** | Description   | Applies for Reusable       | C** |
| O |             | and           | Verification Tools (*and   |     |
| b |             | D             | similarity to              |     |
| j |             | O-178B/ED-12B | DO-178B/ED-12B Annex A     |     |
| * |             | Reference**   | objectives*)**             |     |
| * |             |               |                            |     |
+===+=============+===============+============================+=====+
| 1 | Define the  | Reusable Tool | While there is no          | 1   |
|   | intended    | Qualification | requirement for a RTQP for |     |
|   | use of the  | Plan (RTQP)   | a verification tool under  |     |
|   | tool, its   | (12.2.3.1 a,  | DO-178B/ED-12B, a RTQP     |     |
|   | a           | b, e, and f   | should be provided to      |     |
|   | rchitecture | only)         | obtain reusable credit.    |     |
|   | and         |               | The RTQP includes a        |     |
|   | e           |               | description of the         |     |
|   | nvironment, |               | intended use of the tool,  |     |
|   | the         |               | its architecture and       |     |
|   | qu          |               | environment, the           |     |
|   | alification |               | qualification approach, a  |     |
|   | approach,   |               | description of credit      |     |
|   | and a       |               | claimed, and other         |     |
|   | description |               | information as described   |     |
|   | of credit   |               | in Section 12.2.3.1 of     |     |
|   | claimed.    |               | DO-178B/ED-12B. For        |     |
|   |             |               | additional guidance, see   |     |
|   |             |               | FAA Order 8110.49, Chapter |     |
|   |             |               | 9-5.b(4).                  |     |
|   |             |               |                            |     |
|   |             |               | *This is similar to        |     |
|   |             |               | objective A1-1, Software   |     |
|   |             |               | development and integral   |     |
|   |             |               | processes activities are   |     |
|   |             |               | defined.*                  |     |
+---+-------------+---------------+----------------------------+-----+
| 2 | Define and  | RTQP 12.2.3.1 | This section of the RTQP   | 1   |
|   | document    | b             | should identify which      |     |
|   | the use of  |               | DO-178B/ED-12B objectives  |     |
|   | the         |               | the tool will automate,    |     |
|   | v           |               | replace, or supplement.    |     |
|   | erification |               | Justification for the      |     |
|   | tool, when  |               | tool's adequacy for        |     |
|   | qu          |               | claiming such credit       |     |
|   | alification |               | should also be documented. |     |
|   | is required |               | Additionally, it should be |     |
|   | (i.e., when |               | clear what the applicant,  |     |
|   | DO-         |               | system developer, and/or   |     |
|   | 178B/ED-12B |               | tool user will need to do  |     |
|   | objectives  |               | to properly claim credit   |     |
|   | are         |               | for this objective in      |     |
|   | eliminated, |               | their project.             |     |
|   | reduced, or |               |                            |     |
|   | automated   |               | *This is related to        |     |
|   | by the use  |               | objective A1-4, Additional |     |
|   | of a        |               | considerations are         |     |
|   | software    |               | addressed.*                |     |
|   | tool        |               |                            |     |
|   | without its |               |                            |     |
|   | output      |               |                            |     |
|   | being       |               |                            |     |
|   | verified).  |               |                            |     |
+---+-------------+---------------+----------------------------+-----+
| 3 | Reusable    | Reusable Tool | For additional guidance,   | 1   |
|   | tool        | Operational   | see FAA Order 8110.49,     |     |
|   | operational | Requirements  | Chapter 9-6.a.             |     |
|   | r           | (RTOR)        |                            |     |
|   | equirements | 12.2.3.2 (a,  | *This is similar to        |     |
|   | are         | b, and c      | objective A2-2, High-level |     |
|   | developed.  | only),        | requirements are           |     |
|   |             |               | developed.*                |     |
+---+-------------+---------------+----------------------------+-----+
| 4 | Tool        | Reusable Tool | The tool qualification     | 2   |
|   | complies    | Qualification | data should include tool   |     |
|   | with        | Data          | verification cases,        |     |
|   | reusable    | (12.2.2),     | procedures, and results    |     |
|   | tool        |               | demonstrating that each    |     |
|   | operational |               | operational requirement is |     |
|   | re          |               | tested over its normal     |     |
|   | quirements. |               | range. For additional      |     |
|   |             |               | guidance, see FAA Order    |     |
|   |             |               | 8110.49, Chapter 9-5.b(3)  |     |
|   |             |               | and DO-178B/ED-12B,        |     |
|   |             |               | Sections 11.13 and 11.14.  |     |
|   |             |               |                            |     |
|   |             |               | *This is similar to        |     |
|   |             |               | objective A6-1, Executable |     |
|   |             |               | Object Code complies with  |     |
|   |             |               | high-level requirements.*  |     |
+---+-------------+---------------+----------------------------+-----+
| 5 | Test        | Reusable Tool | As part of the             | 2   |
|   | coverage of | Qualification | verification results, a    |     |
|   | reusable    | Data (12.2.2) | coverage analysis should   |     |
|   | tool        |               | be performed to            |     |
|   | operational |               | demonstrate that all of    |     |
|   | r           |               | the tool operational       |     |
|   | equirements |               | requirements have been     |     |
|   | is          |               | tested (or otherwise       |     |
|   | achieved.   |               | verified). For additional  |     |
|   |             |               | guidance, see FAA Order    |     |
|   |             |               | 8110.49, Chapter 9-5.b(3)  |     |
|   |             |               | and DO-178B/ED-12B,        |     |
|   |             |               | Sections 11.13 and 11.14.  |     |
|   |             |               |                            |     |
|   |             |               | *This is similar to        |     |
|   |             |               | objective A7-3, Test       |     |
|   |             |               | coverage of high-level     |     |
|   |             |               | requirements is achieved.* |     |
+---+-------------+---------------+----------------------------+-----+
| 6 | Tool        | Reusable Tool | A means should be provided | 2   |
|   | co          | SCM Records   | to uniquely identify all   |     |
|   | nfiguration | (12.2.3.b)    | components of the          |     |
|   | items are   |               | qualified tool and its     |     |
|   | identified. |               | reusable tool              |     |
|   |             |               | qualification data and     |     |
|   |             |               | their associated           |     |
|   |             |               | configuration. For         |     |
|   |             |               | additional guidance, see   |     |
|   |             |               | FAA Order 8110.49, Chapter |     |
|   |             |               | 9-6.f and DO-178B/ED-12B,  |     |
|   |             |               | Section 11.18.             |     |
|   |             |               |                            |     |
|   |             |               | *This is similar to        |     |
|   |             |               | objective A8-1,            |     |
|   |             |               | Configuration items are    |     |
|   |             |               | identified*                |     |
+---+-------------+---------------+----------------------------+-----+
| 7 | Baselines   | Reusable Tool | While there is no          | 1   |
|   | and         | Configuration | requirement for a separate | (T  |
|   | t           | Index (RTCI), | configuration index for a  | CI) |
|   | raceability |               | tool under DO-178B/ED-12B, |     |
|   | are         | Resuable Tool | a RTCI should be provided  | 2   |
|   | e           | SCM Records   | to obtain reusable credit. | (   |
|   | stablished. | (12.2.3.b)    | DO-178B/ED-12B Section     | SCM |
|   |             |               | 11.16 can be used to       | re  |
|   |             |               | provide guidance for the   | cor |
|   |             |               | structure of an RTCI . For | ds) |
|   |             |               | additional guidance, see   |     |
|   |             |               | FAA Order 8110.49, Chapter |     |
|   |             |               | 9-6.f and DO-178B/ED-12B,  |     |
|   |             |               | Section 11.18.             |     |
|   |             |               |                            |     |
|   |             |               | *This is similar to        |     |
|   |             |               | objective A8-2, Baselines  |     |
|   |             |               | and traceability are       |     |
|   |             |               | established.*              |     |
+---+-------------+---------------+----------------------------+-----+
| 8 | Problem     | Reusable Tool | In addition to any open    | 2   |
|   | reporting   | Problem       | problem reports at time of |     |
|   | is          | Reports,      | qualification, the tool    |     |
|   | e           | Reusable Tool | developer should track and |     |
|   | stablished. | SCM records   | analyze all problems found |     |
|   |             | (12.2.3.b)    | after release and notify   |     |
|   |             |               | the tool user, system      |     |
|   |             |               | developer, and applicant.  |     |
|   |             |               | Problem reports should be  |     |
|   |             |               | addressed by users,        |     |
|   |             |               | developers, and applicants |     |
|   |             |               | in subsequent reuse of the |     |
|   |             |               | tool, and in continuing    |     |
|   |             |               | airworthiness. For         |     |
|   |             |               | additional guidance, see   |     |
|   |             |               | FAA Order 8110.49, Chapter |     |
|   |             |               | 9-6.f and DO-178B/ED-12B,  |     |
|   |             |               | Section 11.18.             |     |
|   |             |               |                            |     |
|   |             |               | *This is similar to        |     |
|   |             |               | objective A8-3, Problem    |     |
|   |             |               | reporting, change control, |     |
|   |             |               | change review, and         |     |
|   |             |               | configuration status       |     |
|   |             |               | accounting are             |     |
|   |             |               | established. However, only |     |
|   |             |               | the problem report         |     |
|   |             |               | (section 7.2.3) is         |     |
|   |             |               | applicable to tools.*      |     |
+---+-------------+---------------+----------------------------+-----+
| 9 | Tool life   | Resuable Tool | For additional guidance,   | 2   |
|   | cycle data  | SCM Records   | see FAA Order 8110.49,     |     |
|   | should be   | (12.2.3.b)    | Chapter 9-6.f and          |     |
|   | retrievable |               | DO-178B/ED-12B, Section    |     |
|   | (7.2.7a),   |               | 11.18.                     |     |
|   | stored to   |               |                            |     |
|   | ensure that |               | *This is related to        |     |
|   | no          |               | objective A8-4, Archive,   |     |
|   | u           |               | retrieval, and release are |     |
|   | nauthorized |               | established. However, only |     |
|   | changes can |               | the portions of the        |     |
|   | be made     |               | objective applicable to    |     |
|   | (7          |               | CC2 are addressed, plus    |     |
|   | .2.7.b(1)), |               | the addition of data       |     |
|   | released    |               | release prior to use       |     |
|   | prior to    |               | (7.2.7.d).*                |     |
|   | use for     |               |                            |     |
|   | software    |               |                            |     |
|   | manufacture |               |                            |     |
|   | (7.2.7.d),  |               |                            |     |
|   | and         |               |                            |     |
|   | retained to |               |                            |     |
|   | satisfy     |               |                            |     |
|   | ai          |               |                            |     |
|   | rworthiness |               |                            |     |
|   | r           |               |                            |     |
|   | equirements |               |                            |     |
|   | and enable  |               |                            |     |
|   | software    |               |                            |     |
|   | mo          |               |                            |     |
|   | difications |               |                            |     |
|   | (7.2.7.e).  |               |                            |     |
+---+-------------+---------------+----------------------------+-----+
| 1 | Reusable    | Reusable Tool | The reusable tool should   | 2   |
| 0 | tool        | SCM Records   | be properly installed      | (   |
|   | operational | (12.2.3.b),   | within the its qualified   | SCM |
|   | environment |               | operational environment.   | re  |
|   | and         | Resuable TOR  | The credit given for the   | cor |
|   | limitations | (12.2.3.2.b,  | reusable tool developer,   | ds) |
|   | are         | c)            | and the associated tool    |     |
|   | defined.    |               | user and applicant         | 1   |
|   |             |               | responsibilities will be   | (RT |
|   |             |               | dependent on the           | OR) |
|   |             |               | installation constraints.  |     |
|   |             |               |                            |     |
|   |             |               | *This is similar to        |     |
|   |             |               | objecive A8-5, Software    |     |
|   |             |               | load control is            |     |
|   |             |               | established.*              |     |
+---+-------------+---------------+----------------------------+-----+
| 1 | Assurance   | Reusable Tool | SQA should monitor the     | 2   |
| 1 | is obtained | Software      | reusable tool              |     |
|   | that        | Quality       | qualification proccess and |     |
|   | reusable    | Assurance     | products, as with any      |     |
|   | tool        | (SQA) Records | other software development |     |
|   | qu          | (11.19)       | or qualification effort.   |     |
|   | alification |               |                            |     |
|   | process     |               | *This is similar to        |     |
|   | complies    |               | objective A9-1, Assurance  |     |
|   | with        |               | is obtained that software  |     |
|   | approved    |               | development and integral   |     |
|   | RTQP.       |               | processes comply with      |     |
|   |             |               | approved software plans    |     |
|   |             |               | and standards.*            |     |
+---+-------------+---------------+----------------------------+-----+
| 1 | Software    | Resuable Tool | The conformity review      | 2   |
| 2 | conformity  | SQA Records   | applies to RTQP, RTAS,     |     |
|   | review is   | (11.19)       | RTCI, and other Reusable   |     |
|   | conducted.  |               | Tool Qualification Data.   |     |
|   |             |               | See Section 8.3 of         |     |
|   |             |               | DO-178B/ED-12B for         |     |
|   |             |               | conformity review          |     |
|   |             |               | guidance.                  |     |
|   |             |               |                            |     |
|   |             |               | *This is similar to        |     |
|   |             |               | objective A9-3, Software   |     |
|   |             |               | conformity review is       |     |
|   |             |               | conducted.*                |     |
+---+-------------+---------------+----------------------------+-----+
| 1 | Co          | RTQP          | While there is no          | 1   |
| 3 | mmunication | (12.2.3.1 a,  | requirement for a RTQP for |     |
|   | and         | b, e, and f   | a verification tool under  |     |
|   | un          | only)         | DO-178B/ED-12B, a RTQP     |     |
|   | derstanding |               | should be provided to      |     |
|   | between the |               | obtain reusable tool       |     |
|   | applicant   |               | qualification credit. For  |     |
|   | and the     |               | additional guidance, see   |     |
|   | ce          |               | FAA Order 8110.49, Chapter |     |
|   | rtification |               | 9-5.b(4). The RTQP         |     |
|   | authority   |               | provides the basis for     |     |
|   | is          |               | negotiating the degree and |     |
|   | e           |               | type of credit that will   |     |
|   | stablished. |               | be accepted.               |     |
|   |             |               |                            |     |
|   |             |               | The RTQP should address    |     |
|   |             |               | the specific items         |     |
|   |             |               | documented in AC 20-148    |     |
|   |             |               | and this position paper.   |     |
|   |             |               |                            |     |
|   |             |               | *This is similar to        |     |
|   |             |               | objective A10-1,           |     |
|   |             |               | Communication and          |     |
|   |             |               | understanding between the  |     |
|   |             |               | applicant and the          |     |
|   |             |               | certification authority is |     |
|   |             |               | established.*              |     |
+---+-------------+---------------+----------------------------+-----+
| 1 | The means   | RTQP          | While there is no          | 1   |
| 4 | of          | (12.2.3.1 a,  | requirement for a RTQP for |     |
|   | compliance  | b, e, and f   | a verification tool under  |     |
|   | is proposed | only)         | DO-178B/ED-12B, a RTQP     |     |
|   | and         |               | should be provided to      |     |
|   | agreement   |               | obtain reusable tool       |     |
|   | with the    |               | qualification credit. For  |     |
|   | RTQP is     |               | additional guidance, see   |     |
|   | obtained.   |               | FAA Order 8110.49, Chapter |     |
|   |             |               | 9-5.b(4). The RTQP         |     |
|   |             |               | provides the basis for     |     |
|   |             |               | negotiating the degree and |     |
|   |             |               | type of reusable credit    |     |
|   |             |               | that will be accepted.     |     |
|   |             |               |                            |     |
|   |             |               | *This is similar to        |     |
|   |             |               | objective A10-2, The means |     |
|   |             |               | of compliance is proposed  |     |
|   |             |               | and agreement with the     |     |
|   |             |               | Plan for Software Aspects  |     |
|   |             |               | of Certification is        |     |
|   |             |               | obtained.*                 |     |
+---+-------------+---------------+----------------------------+-----+
| 1 | Tool        | RTAS (12.2.3, | While there is no          | 1   |
| 5 | compliance  | 12.2.4),      | requirement for a separate |     |
|   | sub         | RTCI, RTDS    | RTAS, RTCI, or RTDS for a  |     |
|   | stantiation |               | verification tool under    |     |
|   | is          |               | DO-178B/ED-12B, this data  |     |
|   | provided.   |               | should be provided to      |     |
|   |             |               | obtain reusable tool       |     |
|   |             |               | qualifcation credit. This  |     |
|   |             |               | data provides the basis    |     |
|   |             |               | for acceptance of the      |     |
|   |             |               | reusable credit for a      |     |
|   |             |               | tool. For additional       |     |
|   |             |               | guidance, see FAA Order    |     |
|   |             |               | 8110.49, Chapter 9-5.b(4). |     |
|   |             |               | Note: In some cases RTAS   |     |
|   |             |               | and RTCI may be a combined |     |
|   |             |               | document.                  |     |
|   |             |               |                            |     |
|   |             |               | *This is similar to        |     |
|   |             |               | objective A10-3,           |     |
|   |             |               | Compliance substantiation  |     |
|   |             |               | is provided.*              |     |
+---+-------------+---------------+----------------------------+-----+

5.  As described in Section 5.c of AC 20-148, each of the following
    items should be detailed in the RTQP and RTAS for each objective,
    using Table 1 above for reusable verification tool qualification
    objectives:

-   Credit being sought by the reusable verification tool developer;

-   Assumptions and use limitations of the reusable verification tool or
    its data;

-   Description of how the applicant, system developer, or tool user
    should operate the tool in order to claim credit;

-   Means of compliance for each of the above Table 1 objectives and
    other applicable guidance (e.g., DO-178B/ED-12B, orders, issue
    papers, etc.);

-   Activities remaining for the user, system developer, and/or
    applicant using the tool.

    1.  The DO-178B/ED-12B objectives that the software verification
        tool is replacing, supplementing, or automating should be
        thoroughly described in the RTQP and RTAS, along with any
        assumptions about the way the tool will be used in the overall
        system and any limitations of the tool's usage. As with the
        objectives described in the table above, each objective for
        which the tool is claiming credit should document:

-   Credit (Full, partial, none) being sought by the tool developer;

-   Description of how the tool user, system developer, and/or applicant
    should operate and use the tool to maintain the credit;

-   Means of compliance for the applicable objective and justification
    for its automation;

-   Activities remaining for the tool users (i.e., tool user, software
    developer, system developer, and/or applicant).

    1.  Section 6 of AC 20-148 addresses data to be supplied by the RSC
        developer to the tool user, system developer, and applicant to
        support compliance substantiation, type design and continued
        airworthiness. That list differs for a reusable verification
        tool project. For a reusable verification tool qualification,
        the following data should be supplied to the tool users,
        developers, and applicant:

```{=html}
<!-- -->
```
-   RTQP;

-   RTCI;

-   RTAS;

-   Reusable Tool Operational Requirements (Note: In some cases, these
    requirements may be made available to the user and system developer
    and stored in a data escrow, rather than supplied to the applicant.
    However, access to this must still be available for certification
    authorities and designees for review, as requested).

-   Reusable tool qualification data to support objectives that will
    require tool user's, system developer's, or applicant's action(s);

-   Reusable tool user's guide;

-   Reusable tool data sheet that concisely describes the tool's
    functions, limitations, interface requirements, compliance concerns,
    assumptions, configuration, supporting data, open problem reports,
    tool characteristics, and other relevant information. The data sheet
    should support the user, system developer, and/or applicant's use of
    the tool and should be submitted to the cognizant certification
    authority.

6.  **Summary**

> Software development and verification tools may be considered as
> reusable software components if they have the written agreement of all
> stakeholders (i.e., the applicant, the reusable tool developer, the
> system developer, the tool user, and the certification authorities)
> and follow the guidelines of this position paper. The software tools
> must first be qualified in the context of an actual certification
> project before being proposed for reuse on other projects. There may
> be project-specific issues that are not addressed in this paper that
> must be addressed on a case-by-case basis.