Tech Juice 2512. The Rafale Aircraft Avionics Source Code – What is it and why are we asking for it?

Introduction. 

There are numerous reports of the Indian Air Force attempting to obtain the source code of the Rafale aircraft, the lead fighter aircraft in the IAF’s inventory.  The purported reasons are to bolster technological sovereignty, defence autonomy, and integration of indigenous weapons and avionics.

For good reasons, when a software-intensive system is bought off the shelf, it is not normal for the contract to involve the supply of the ‘source code’ with the intent of technology transfer.  When the software-intensive system is part of a weapon delivery platform,  the ‘source code’ goes through a rigorous process, before it is allowed to function in the real world and deliver weapons.  The ratio of source code lines to certification documentation is potentially three to 10 times the volume.  DO-178C certification at the highest level of integrity demanded for weapon delivery systems would normally demand over 10x the size of the source code, which could potentially run into 1-10 million lines of code.  The documentation would typically involve Requirements documents, Design specifications, Traceability matrices, Test plans, procedures, and results, Verification & validation reports, Safety analysis, Configuration & change control logs and Certification artefacts.

Will Just Getting Source Code Suffice?

Sometimes, the supply of source code is embedded into the contract to give a feeling of technology transfer to the recipient nation.  Getting the source code alone is not the same as getting the technological autonomy to upgrade and integrate independently.  Today, source code is generated by high-level design tools, and the entire tool chain will be necessary.  The common joke is that even pressing Enter and a backspace in any code segment is enough to generate the requirement for the software to go through its certification process all over again.  DO-178C is the gold standard for avionics software certification.  The rigour of certification is progressively tightened based on the severity of failures of the overall system.  For an avionics system that delivers weapons or provides key inputs for safe flight, the rigour is very high.  Typically, the standard will require robust requirements for code traceability, verification and test evidence and robust structural coverage analysis for recertification of modified code before flight.

Code is the bottom-most part of the food chain!

Software licensing and the procurement of the entire software development environment (requirement management interfaces, compilers, configuration files, software engineering artefacts, detailed documentation, test facilities, cyber security assessment tools, other certification artefacts, traceability matrices etc.), with the OEM, will need to be done in the capital contract stage or as a separate technology transfer contract.  There will also be a need for custom hardware and firmware interfaces that avionics typically use, which may be undocumented/encrypted in the software tool development process.  For safety-critical software that will be delivering weapons, reverse engineering of source code is not an option.  Sometimes, it is possible to reverse engineer using similar stores where the avionics thinks that it is handling a particular store when in reality it is a similar store held in inventory.  Beyond this, it is unthinkable unless complete technology transfer and sustainment is negotiated with the OEM in the capital contract.  

The following are mandatory, along with the source code, if we are really going to have technological independence.

• Technical Data Deliverables
• Full source code for all software components (including third-party, where possible).
• Build tools and environment details (compilers, linkers, version info).
• Detailed interface control documents (ICDs).
• System architecture diagrams.
• Firmware and FPGA source, if applicable.
• Certification Data
• Software Requirements Specification (SRS)
• High- and low-level design documents
• Test cases, procedures, and results
• Traceability matrix (requirements ↔ code ↔ test)
• Tool qualification documentation (per DO-330, if used)
• Conformance to DO-178C, including Level declaration
• Licensing and Support
• Confirm that the Government (or integrator) can modify, maintain, and upgrade the software without OEM permission.
• Ask for in-person technical training or technology transfer workshops.
• Define sustainment support terms (optional but helpful).

Contract Language  

  It is important to be aware of the contracting options available for technology transfer.  Defence contract clauses can be tailored for unlimited rights to modify software.  This gives full independence to use, modify, reproduce, release, or disclose the data in any manner and for any purpose.  Alternatively, contract clauses can facilitate Government General Purpose Rights (GPR), which allow use, modification, and sharing within the Government or contractors supporting Government work.  Usually, the GPR lasts for 5 years, and the contract converts into unlimited rights.

Both the above are expensive and typically need significant human resource investments for extended periods by both the OEM and the procuring government.  Therefore, most contracts severely restrict the ability to modify onboard software without OEMs' involvement through separate commercial contracts.  The OEM, in any case, is maintaining a small standing army which works on enhancing, upgrading, obsolescence management and maintenance of the onboard avionics systems.  Clearly, just obtaining source code is usually useless and mostly unreadable and should not be considered a technology transfer, even if offered.  

Guidance for contract language for unlimited rights are contained in the Defence Fedaral Acquisition Regulations of the US DoD.  Some pointers are DFARS 252.227-7013: Included and interpreted to secure Unlimited Rights (or Government Purpose Rights with transition) and DFARS 252.227-7014: For software-specific rights — confirm non-commercial software to apply favourable clauses.  These can be used to model the support contract for technology transfer.

Conclusion

700 × 465

Maintenance, upgrade, enhancement and obsolescence management of military avionics software is no simple task.  It generally requires extended expert resourcing over the lifetime of the system and software.  It is a great idea to part with treasure and go through the pain of a properly structured technology transfer for an existing avionics system and then use the team to build the upgrade for the Rafale systems to truly become technologically independent.