Parameter Data Items (PDI’s) are digital data external to a software executable which are used by that executable during normal execution. Remember that software executables are binaries comprised of instructions and data which reside together in one or more executable formats. PDI’s are outside of but read by these executables as a way of customizing an executable’s operation and thus influence the execution of that executable.
PDI’s typically reside in non-volatile memory (e.g. “flash”) which are read upon power-up. Therefore a hardware/software interface is used by the executable to access the PDI. Since DO-178C requires hardware/software interfaces to be covered by High-Level Requirements (HLRs), PDI’s must be described via HLR’s.
While PDI’s influence an executable’s behavior, they do not modify the executable; instead, the PDI’s are managed as a separate configuration item which means PDI’s can be updated without updating a certified executable.
PDIs may have numerous individual elements and are typically stored as arrays or discrete addressable memory elements within the non-volatile memory. Typically, each PDI element has a unique value and each element has attributes including data type, min/max range, and potential relationships to other PDI elements. Commonly, PDI’s are used to:
- Initialize constants which are variable within a system such as calibration data;
- Activate/deactivate software components;
- Used to establish partitioning boundaries;
- Used to customize Reusable Software Components (RSC’s per AC 20-148)
- Customize the software for a particular aircraft configuration
- Differentiate military versus civil functionality
- Store data which is more frequently updated than the executable itself but which are outside the scope of “Aeronautical Data” governed by DO-200C.
Parameter Data Items are commonly used to allow flexibility in design and use-cases without re-certifying the avionics software. Remember, if you change the binary itself you incur at a minimum a “Minor” re-certification which is still tedious and expensive. But software which is certified to use PDI’s may avoid re-certification by only updating PDI’s within the update constraints specified for that PDI set.
PDI versus DAL
PDI’s can influence software of all DALs so full DO-178C objectives of the highest DAL using that PDI apply. As DAL A has 71 formal DO-178C Objectives, all 71 potentially apply. The use of PDI’s should be covered within all five DO-178C plans and all three DO-178C standards – it’s best to use professional DO-178C Templates and Checklists to ensure complete coverage of DO-178C PDI aspects.
In short, DO-178C PDIs must have full high-level requirements, full robustness and relationship properties (possibly stated as Low-Level Requirements (LLRs) but HLRs are normally sufficient), bi-directional traceability to full tests of all PDI requirements, and full CM and evidence-based (checklists) reviews. The more reusable your software is, the more likely it will use PDIs to enhance that reusability and reduce certification costs/risks.
