Acronym

22.1 Introduction

Many safety-critical systems are designed to be configurable. Configuration data provide a flexible, yet controlled, way to configure and reconfigure a system. The data used to configure the system are referred to as configuration data in this chapter. DO-178C and the certification authorities’ policy and guidance use a variety of other terms to describe these configuration data, including configuration files, databases, airborne system databases, parameter data items, adaptation data items, etc.

This chapter explains some of the terminology, guidance, and recommendations related to configuration data. This chapter does not discuss aeronautical databases (e.g., navigational or terrain databases). They are discussed in Chapter 23.

22.2 Terminology and Examples

The European Aviation Safety Agency (EASA) Certification Memorandum CM-SWCEH-002 refers to configuration data as configuration files and defines them as:

Files embedding parameters used by an operational software program as computational data, or to activate/deactivate software components (such as, to adapt the software to one of several aircraft/engine configurations). The terms “registry” or “definition file” are sometimes used for a configuration file. Configuration files such as symbology data, bus specifications or aircraft/engine configuration files are segregated from the rest of the embedded software for modularity and portability purposes [1].

Section 15.2 of Federal Aviation Administration (FAA) Order 8110.49 (Change 1) refers to configuration data as airborne system databases. The Order explains that airborne system databases are:

Used by an airborne system and approved as part of the type design of the aircraft or engine. These databases may influence paths executed through the executable object code, be used to activate or deactivate software components and functions, adapt the software computations to the aircraft configuration, or be used as computational data. Airborne system databases may consist of script files, interpretive languages, data structures, or configuration files (including registries, software options, operating program configuration, aircraft configuration modules, and option-selectable software) [2].

DO-178C builds upon the certification authority guidance by introducing the concept of parameter data item and parameter data item file, defined as follows [3]:

• Parameter data item—A set of data that, when in the form of a Parameter Data Item File, influence the behavior of the software without modifying the Executable Object Code and that is managed as a separate configuration item. Examples include databases and configuration tables.

• Parameter Data Item File—The representation of the parameter data item that is directly usable by the processing unit of the target computer. A Parameter Data Item File is an instantiation of the parameter data item containing defined values for each data element.

Configuration data are separate from the executable object code. Sometimes the configuration data are included as part of the airborne software part number and therefore are included in the DO-178C software life cycle data (i.e., they are called out in the Software Accomplishment Summary and Software Configuration Index of the airborne software). Other configuration data may have a separate part number than the airborne software in order to configure the software for the specific aircraft needs. In this situation, the configuration data may have their own life cycle data (including a separate Software Accomplishment Summary and Software Configuration Index) and a separate part number. Configuration data may also be field loadable or user modifiable.

Configuration data come in many formats, including text files, binary data, XML (eXtensible Markup Language) data, lookup tables, databases, etc. Some examples of configuration data include data used to do the following:

• Define symbology for a display system.

• Specify databus parameters.

• Enable or disable preprogrammed functions (e.g., option-selectable software).

• Configure a data network.

• Program integrated modular avionics (IMA) platform resource allocation (such as memory, time, and shared resources).

• Identify aircraft-specific options (such as a personality module).

• Calibrate sensors or actuators.

• Configure a real-time operating system.

DO-178C section 2.5.1 explains the following [3]:

Parameter data items may contain data that can:

1. Influence paths executed through the Executable Object Code.

2. Activate or deactivate software components and functions.

3. Adapt the software computations to the system configuration.

4. Be used as computational data.

5. Establish time and memory partitioning allotments.

6. Provide initial values to the software component.

Configuration data are normally developed and controlled by one of the following entities:

• Equipment/avionics manufacturer’s systems or systems integration team. The configuration of the system may be established by the systems or systems integration team. For example, when determining the systems communications requirements, the systems team may identify the network connections, and the integration team may develop the configuration data to implement the connections.

• Equipment/avionics manufacturer’s software team. The software team may package configuration data as part of the equipment’s software or as a separate configuration item. An example of configuration data that is part of the software package is a lookup table to set gains. An example of configuration data that is packaged separately is a resource allocation file for an application.

• Equipment/avionics manufacturer’s production process. In some situations, the configuration data are established as part of the production process rather than the engineering and software development process. For example, the hardware configuration data such as processor serial number and equipment serial number may be entered as part of the production process. Another example is calibration data that are entered prior to acceptance testing and shipping to the customer.

• Aircraft manufacturer’s installation process. Sometimes, the aircraft manufacturer is responsible for some configuration data. For example, the aircraft manufacturer may use a configurable aircraft personality module to configure the aircraft to meet customer’s specific needs.

• User’s modification process. Some configuration data may be user modifiable. For example, an airline may use configuration data to identify which parameters they will collect for maintenance purposes.

22.3 Summary of DO-178C Guidance on Parameter Data

DO-178B did not provide unique guidance for configuration data. However, as noted earlier, DO-178C uses the terms parameter data item and parameter data item file to describe configuration data. DO-248C explains that a parameter data item is a software component that contains only data (and no executable object code). A parameter data item is also a configuration item. Airborne software may consist of one or more executable object code configuration items and one or more parameter data configuration items. A parameter data item file is an instantiation of the parameter data item containing defined values for each data element [4].

Parameter data items are assigned the same software level as the software component that uses the parameter data. Parameter data item files are treated very similar to executable object code in DO-178C; they are driven by the requirements and must be verified, either separately or as part of the airborne software. DO-178C sections 7 and 8 explain that parameter data item files need to be under configuration management and assessed during software quality assurance activities, just as the executable object code is. Likewise, DO-178C section 9 identifies parameter data item files as type design data along with the executable object code.

The following DO-178C objectives, explicitly reference parameter data item files [3]:

• DO-178C Table A-3 objective 7: “Executable Object Code and Parameter Data Item Files, if any, are produced and loaded in the target computer.” This objective was expanded from DO-178B to DO-178C to address the integration of the parameter data into the target computer.

• DO-178C Table A-5 objective 8: “Parameter Data Item File is correct and complete.” This objective is new to DO-178C. It ensures that each element in a parameter data item file satisfies its requirements, has correct values, and is consistent with other data elements.

• DO-178C Table A-5 objective 9: “Verification of Parameter Data Item File is achieved.” This ensures that all elements of each parameter data item file were covered during verification.

22.4 Recommendations

Configuration data cover a wide variety of scenarios. Each scenario has its own unique needs to be addressed on the specific project. However, this section provides some general recommendations to keep in mind. Many of these recommendations are based on DO-178C and/or certification authorities’ policy and guidance.

Recommendation 1: Determine how the configuration data will be used and what policy and/or guidance applies. Depending on how the configuration data are used, guidance on field-loadable software (see Chapter 18), user-modifiable software (see Chapter 19), or deactivated code or option-selectable software (see Chapter 17) may apply. The DO-178C guidance on parameter data items and any special guidance on configuration data from the certification authority should be considered. At the time of this writing, the certification guidance related to configuration data is still evolving. The publication of DO-178C clarifies what is expected; however, because of the newness of the parameter data item guidance, there may be some additional clarification from the certification authorities. In general, the configuration data are treated as a special class of software; therefore, most of the guidance applicable to airborne software also applies to the configuration data—with a few adjustments here and there, as will be discussed later.

Recommendation 2: Determine the software level or development assurance level (DAL) that applies. The safety assessment considers the potential conditions that will transpire if the configuration data are erroneous or corrupted. The configuration data are normally treated like software in the safety assessment process; therefore, they are assigned a software level. However, if the configuration data are established at the system level, a DAL may apply. The configuration data are usually assigned the same software level (or DAL) as the software (or system) component that uses the configuration data, or the highest level if several levels are present, such as in an IMA system.

DO-178C explains that software level for a parameter data item is the same as the software level of software component that uses the parameter data. However, the safety assessment will take precedence. If architectural mitigation is applied, there could be a situation where the configuration data level is lower, but this would probably be quite rare.

Recommendation 3: Develop the appropriate life cycle process for the configuration data. While configuration data are similar to software and much of the guidance related to airborne software applies, there are some differences. Most projects apply the objectives of DO-178C to configuration data. However, for configuration data there will often only be one level of requirements needed (such as high-level requirements) and the structural coverage objectives are satisfied differently, since there are no conditions or decisions in configuration data. DO-178C’s guidance, objectives, and activities for parameter data items and parameter data item files explain how to apply DO-178C to configuration data.

Recommendation 4: Develop plans to document the process. The planning for the configuration data may be included as part of the software plans or it may be separate. Typically, if there is a significant amount of configuration data or if the configuration data will be regularly modified separate from the software that uses it, it makes sense to separate the configuration data and its supporting life cycle data from the executable software’s data. When the configuration data are packaged separate from the airborne software, the five plans identified in DO-178C may be compressed into one or two plans for configuration data, since the processes may not be as complex as the airborne software and the team may be significantly smaller. In more than one project, I’ve seen the plans condensed into two plans: (1) a Plan for Software Aspects of Certification which is submitted to the certification authority and (2) another plan that details the development, verification, configuration management, and quality assurance of the configuration data. Many times, the Software Configuration Management Plan and the Software Quality Assurance Plan for the airborne software may also apply to the configuration data, so those plans are merely referenced from the second plan. Regardless of how the plans are packaged, DO-178C section 4.2.j explains that the following additional information should be considered in the plans when using parameter data items [3]:

1. The way that parameter data items are used.

2. The software level of the parameter data items.

3. The processes to develop, verify, and modify parameter data items, and any associated tool qualification.

4. Software load control and compatibility.

Recommendation 5: Define requirements for configuration data. Configuration data should be requirements driven, just like any other data that impact aircraft functionality. There is often just one level of requirements needed to define the functionality of configuration data. DO-178C suggests that configuration data requirements be captured as high-level software requirements; however, there have been a few situations where system-level requirements or a configuration file design specification have been used to capture the configuration data requirements. The packaging is somewhat flexible; however, regardless of the packing scheme, it should be remembered (1) requirements to specify the configuration data are necessary, and (2) the configuration data must trace to those requirements.

Recommendation 6: Trace the configuration data to its requirements. As with source code, the configuration data must trace to its requirements. As will be discussed later, the trace data are particularly important for configuration data, since an analysis of the trace data is sometimes used to help ensure there are no unintended configuration data.

Recommendation 7: Develop standards to ensure that the configuration data are in the proper format. In order for configuration data to be readable by the executable object code, they need to be in a well-defined format. Standards defining the format of data, allowed values, data types, etc. are typically needed to guide the configuration data developer and to provide consistency and accuracy. There may be some scenarios where certain constant values are always needed, for example, some network settings for a specific device driver. Such situations may be handled by requirements or development standards. Note that standards should also be considered when verifying the configuration data (i.e., verify that the configuration data meet the development standards). When tools are used, the tools tend to enforce the data format; however, there may still be a need for data formatting standards.

Recommendation 8: Design the executable software to be configurable. The software that will interact with the configuration data should be designed to use the data. The software requirements should specify the structure, attributes, allowable ranges, etc. of configuration data to be used. Oftentimes, the executable software will perform some kind of validity check to ensure that the configuration data are within the preapproved range and have not been corrupted.

Recommendation 9: Verify the configuration data. Verification of configuration data involves several activities including the following:

1. Ensure that the requirements for the configuration data are accurate, complete, consistent, verifiable, and correct. EASA’s CM-SWCEH-002 treats this as a validation step [1]. However, whether it is called validation or verification, it needs to take place. This activity is typically accomplished by review and analysis. For complex configuration data, such as the network configuration for an aircraft, simulations are often used to verify the correctness and completeness of the data. For simpler configuration data, a review may be adequate. Some configuration data may be verified by a combination of reviews and analyses.

2. Verify that configuration data trace to the appropriate requirements. It is important to ensure that all configuration data requirements are implemented and that all configuration data are requirements driven. Accurate and complete traceability helps to ensure this. It’s important not just to make sure the trace is there, but also to make sure that it is the right trace.

3. Ensure that configuration data complies with the requirements. Requirements-based testing, as well as review and analysis, should be applied to configuration data to ensure that the requirements are satisfied. Sometimes the configuration data will be verified along with the executable object code. At other times, it may be verified separately. DO-178C section 6.6 explains that the following must apply if configuration data (DO-178C calls it parameter data item files) are verified separate from the executable object code that uses the data [3]:

   • The Executable Object Code has been developed and verified by normal range testing to correctly handle all Parameter Data Item Files that comply with their defined structure and attributes.

   • The Executable Object Code is robust with respect to Parameter Data Item Files structures and attributes.

   • All behavior of the Executable Object Code resulting from the contents of the Parameter Data Item File can be verified.

   • The structure of the life cycle data allows the parameter data item to be managed separately.

4. Ensure that all configuration data have been covered during verification. To ensure that there are no unintended configuration data, there should be an activity to ensure that all configuration data have been verified. This is similar to structural coverage analysis that is performed for software. However, since structural coverage criteria doesn’t normally apply to databases, another approach must be developed. The approach may be similar to the DO-254 concept of elemental analysis, used for electronic hardware to ensure that all elements are tied to requirements that have been verified. For our purposes, the configuration data could be treated as an element; the trace data may be used to support the analysis and to confirm that every element of the configuration data has been tested. Regardless of the approach, the goal is to ensure that all of the configuration data have been properly verified and that there is no extraneous or dead data.

5. Use a qualified verification tool to check for consistency where possible. Since configuration data can be very tedious and somewhat ineffective to verify manually (particularly if it is in bitmap format), tools can be very effective. For example, a qualified tool may be used to confirm that the system does not send messages to a sending communications port, memory segments that are not shared do not overlap, the sum of all resource requests is not greater than those provided by the system, and so on.

6. Integrate the configuration data with the executable object code into the target computer. The integration may take place during the testing, particularly if the executable object code and configuration data are verified together. However, there may be situations when the configuration data and executable object code are verified separately. If this is the case, there will need to be an additional integration step to ensure that the executable object code and configuration data work together as intended on the specific target computer.

Recommendation 10: Ensure compatibility of the executable object code and configuration data. Perform verification to ensure that the specific configuration of the executable object code and configuration data are compatible. Activities should be in place to ensure that the configuration data are not corrupted or unacceptable by the executable object code (e.g., noncompliant with the agreed upon format and ranges). Additionally, the compatibility needs to be documented in the appropriate configuration index.

Recommendation 11: Apply configuration management to the configuration data. Configuration management and configuration control apply to the configuration data, as well as their supporting life cycle data. For example, configuration files should have configuration identification, changes to configuration data requirements and files should be handled via change request or problem report, configuration data should only be changed by authorized personnel, etc. Additionally, all aspects of control category #1 or #2 (CC1 or CC2) apply to the configuration data and their supporting life cycle data—just as it does for the airborne software. See Chapter 10 for information on DO-178C’s configuration management expectations.

Recommendation 12: If the production process develops configuration data, ensure it is a controlled process. In my experience, configuration data entered during production are not as common as the configuration data developed by engineering during the development process; however, they may be needed for some systems. The production process must be well defined and repeatable. Additionally, the process should include an independent verification of the data entry (particularly for more critical data, such as level A and B). In some scenarios, the acceptance test plan (ATP) may be traced to the configuration data requirements to ensure that the ATP will identify any erroneous data. In other scenarios, an independent person may manually verify data (e.g., review the serial numbers of hardware and firmware parts) and sign the production record.

Recommendation 13: Produce the necessary documentation (life cycle data). As with airborne software, the configuration data must have the required life cycle data to support their approval. Plans, development data, verification data, configuration management data, and quality assurance data are all needed.

In general, the same life cycle data identified in DO-178C section 11 and Annex A for airborne software compliance are needed for configuration data approval. However, as noted earlier, the data may be packaged differently (e.g., plans may be merged, there may only be one level of requirements, and parameter data item guidance in DO-178C section 11 applies).

Recommendation 14: Update documentation and re-verify when modifying the configuration data. When configuration data are updated, a change impact analysis should be performed (see Chapter 10) and all impacted data updated. There may also be a need for additional verification to ensure that the updated configuration data are still compatible with the software that uses it.

Recommendation 15: If tools are used, ensure that necessary qualification is considered. Tools are often used to generate and verify configuration data, since tools can eliminate some of the trivial errors that humans may create. If the output of a tool is not verified, it will likely require qualification. See Chapter 13 for information on tool qualification.

Recommendation 16: Ensure that loading instructions are documented and approved. Since configuration data may be loaded separate from the software, it is important to ensure that the instructions for loading and updating the configuration data are well documented, repeatable, unambiguous, and approved. The loading instructions should be included in or referenced from the Software Configuration Index.