PDI’s: Using Parameter Data Items per DO-178C

Using Parameter Data Items (PDI) in DO-178C

Software success depends upon reliability, reusability, and efficiency. But evolving software in aviation means DO-178C and DO-278A re-certification. The answer? Apply DO-178C’s Parameter Data Item (PDI) Objectives to minimize re-certification while maximizing reusability and safety. Thus, the new PDI objectives of DO-278A and DO-178C for configurable software: specifically new objectives outlined in DO-178C’s Table A-5, which pertains to the Verification of Outputs of Software Coding and Integration Process.

One such objective is Objective #8, “Parameter Data Item (PDI) File is correct and complete.” Then Objective #9 affirms verification of those PDI’s. But what are PDI’s?

Parameter Data Items are configurable elements outside the executable that influence or alter airborne software behavior. They offer operational flexibility, enhance reusability, and minimize re-certification but PDI’s also introduce potential vulnerabilities. Therefore, aviation elevates PDIs to similar verification rigor as executable object code — yet many projects overlook the need for software requirements, verification, and traceability of PDIs. Possibly even worse, many projects avoid PDI’s because of seeming mysteries regarding these aviation certification aspects and thus lose the opportunity for improved reusability, flexibility, and reduced future certification.

To begin, WHAT is a parameter? 

To understand “Parameters”, first, consider: “What is “Software”?

“A collection of executable programs, associated libraries, and documentation …

… Essentially, software is the set of instructions and data that allows a computer to perform a specific task.” (IEEE)

So, DO-178B focused upon a narrower definition of software which did not include data or instructions outside the executable, thus DO-178B had no provisions for PDIs whereas DO-178C and DO-278A do.

However — aviation software increasingly uses additional data external to the executable to INFLUENCE software.

So, what is a “Parameter Data Item?”

DO-178C defines a Parameter Data Item (PDI) as:

“A data set that influences the behavior of the software without modifying the executable object code (EOC) and is managed as a separate configuration item. Not part of the EOC.”

PDIs are external data used by airborne software to configure operational parameters, e.g., calibration values, flight envelope limits, navigation constraints, partitioning time budgets, and communication or encryption settings.

Note:

1. PDIs are comprised of individual element(s) – each element assigned a single value. 
2. Each element has attributes such as type, range, range of allowable values, etc.
3. These values and attributes are all defined within corresponding High-Level Requirements, unique to each element.

Overview of PDI’s within Avionics System & Certification Guidelines

Why Use Parameters?

The utilization of PDIs offers several key advantages in the development and certification of airborne systems:

⇔ Importantly, PDIs are the drivers of Flexibility!

PDIs are the silent drivers of flexibility in certified software, yet they bring unique risks. While they spare us from recompiling binaries for minor adjustments, they also create potential performance vulnerabilities. Remember, DO-178C attempts to fully define a framework of “determinism” whereby planning, development, verification, and configuration management together force developers to consider all foreseeable operating conditions of the software and ensure determinism is defined, achieved, and verified. But PDIs can alter data flow or control flow, thus subjugate the very determinism DO-178C implies.

What are examples of PDI use cases?

How do PDIs exert influence?

We know that a PDI influences software behavior without modifying the executable object code. Thus, it is managed as a distinct configuration item: logically separated from the executable, yet capable of influencing its execution flow. Each PDI comprises multiple elements, each assigned a single value and possessing defined attributes such as type, range, and permissible value sets. PDIs may exert influence through various mechanisms, including:

Control Flow Modification:	Influencing execution paths within the Executable Object Code.
Component Activation/Deactivation:	Enabling or disabling software functions and components.
System Configuration Adaptation:	Tailoring software computations to specific system configurations.
Computational Data Provision:	Serving as input data for software computations.
Resource Allocation:	Defining time and memory partitioning.
Initialization:	Providing initial values to software components.

Now that we see the rationale for using PDIs, it’s critical to recognize the opportunities and risks that accompany the data. PDIs have the power to influence execution without changing Binary & Recertification. However, they can also introduce latent safety failures, bypass system constraints, become attack vectors, and invalidate certification. In short: PDIs are a double-edged sword.

DO-178C recognizes this—and demands PDI management on par with executable software.

PDI Planning Details & Risks – See full AFuzion PDI Whitepaper for Details.

Free: Download Remaining 10+ Page Paper Here