Source-linked AI summary
From Architecture to Binary: Ensuring Cross-Domain Consistency in Model-Based Airborne Software Development
Nils Schlautmann, Viktor Sinitsyn, Benjamin Engelhard, Florian Holzapfel
TL;DR
The paper targets cross-domain inconsistencies that arise when airborne system, functional-model, and embedded artifacts evolve without continuous enforcement. It implements a repository-centered approach with dBricks, cross-repository references, and CI pipelines, reporting promising early qualitative feedback while broader validation remains necessary.
Problem
Cross-domain inconsistencies persist despite defined processes and machine-readable artifacts because transitions among system, functional, and embedded domains lack continuous enforcement.
Method
The approach assigns each domain a primary repository and uses GitLab CI/CD pipelines and Docker-based runners to generate, reference, notify, and validate exchanged artifacts.
Results
Initial qualitative feedback indicates reduced interface-update inconsistencies and improved productivity, including less manual change identification and automated ICD export.
Takeaways & Limitations
Lightweight repository enforcement lets domains work independently while keeping artifacts traceable and consistent with minimal manual effort.
Takeaways & Limitations
The approach’s suitability and reliability still require broader application in real development projects.
Abstract
from arXiv · showhide
This paper presents an airborne software development approach for manned and unmanned aerial vehicles aimed at reducing inconsistencies across system, model-based functional, and embedded software domains. In environments influenced by standards such as ARP-4754B and DO-178C, these inconsistencies typically stem from insufficient enforcement across domain boundaries rather than missing process definitions. Building on a previously proposed toolchain centered on a relational interface database, we identify recurring failure modes and propose a repository-centered implementation to address them, tailored to small, resource-constrained teams operating without heavyweight process overhead. Each domain is assigned a primary repository with cross-repository references and dedicated CI pipelines that generate, update, and validate the exchanged artifacts. Automated interface updates, differential change notifications, and consistency checks propagate changes with minimal manual effort and surface inconsistencies before the time-consuming code-generation and compilation steps. An initial implementation in an ongoing experimental project is described, with qualitative feedback from its early use.
I. INTRODUCTION
The paper addresses cross-domain inconsistencies in airborne software development by implementing lightweight repository and CI enforcement for small teams pursuing certification-oriented practices.
- Model-based functional development separates specialized teams, but changes can diverge across system, functional, and embedded artifacts.The paper links this challenge to increasing time-to-market and scalability demands in resource-constrained aerospace teams.
- These inconsistencies arise mainly from weak cross-artifact enforcement rather than missing process definitions and often surface only during late integration or testing.Late discovery makes root-cause identification and correction time-consuming and costly.
- The proposed implementation assigns three domain repositories with defined interfaces and dedicated CI pipelines around dBricks.The approach emphasizes lightweight consistency enforcement rather than heavyweight process gates, while supporting ARP-4754B and DO-178C-oriented teams.
- The implementation supports certification-oriented practices but is not intended to replace formal certification activities.Its stated benefits are improved traceability and consistency across development domains.
- Prior work established processes, a Single Source of Truth, and CI checks, but had not presented an implementation enforcing the cross-domain process in practice.Earlier contributions addressed functional-domain automation, system-level scope, interface databases, and adjacent validation or documentation problems.
A. Domains and Responsibilities
The process divides responsibilities among system, functional, and embedded domains, with artifacts exchanged through defined development activities and feedback loops.
- System Domain: The system domain derives requirements, allocates aircraft functions, develops the physical architecture, and transfers it into dBricks.dBricks then serves as the Single Source of Truth for downstream artifacts.
- System Domain: The system domain verifies compiled binaries against system-level requirements during integration testing.
- Functional Domain: The functional domain develops application-layer functionality in Simulink® with Polarion® requirements and modular mrails-supported model development.An integration repository assembles functional submodels with system-defined interfaces before release to the embedded domain.
- Embedded Domain: The embedded domain develops low-level software, including drivers, BSP, middleware, initialization, and automatically generated transport-layer code.Its software typically targets bare-metal systems or an RTOS.
- Embedded Domain: The embedded team generates source code from the released functional model, integrates it with low-level and transport-layer code, and compiles the binary.System-level integration testing feeds findings back iteratively across all three domains.
B. Artifacts Affected by Inconsistencies
The affected artifacts span the interface definition, generated and integrated functional models, and embedded software outputs, whose cross-domain links are insufficiently explicit.
- ICD XML: The ICD XML is the machine-readable interface description exported from dBricks for each device.It defines physical ports, transport-layer information, assigned functions, and their logical inputs and outputs.
- Simulink® Dummy Model: The generated Simulink® dummy model and data dictionaries provide the structural skeleton for functional-model development.They are generated automatically from the ICD XML and contain integrated-function inputs and outputs.
- Simulink® Integration Model: The Simulink® integration model combines functional submodels with the dummy model but lacks an explicit ICD XML revision link.Its internal GitLab traceability therefore does not detect when the interface definition has changed.
- Embedded Outputs: Embedded outputs include transport-layer code generated from the ICD and functional source code produced from the integrated model.The embedded software is also reused across projects and hardware platforms, making consistent templates and components important.
- The common gap is that design outputs lack an explicit reference to the ICD XML revision against which they were built.This missing linkage makes consistency between artifacts brittle.
C. Failure Modes Observed in Practice
Observed failures concentrate at transitions between independently evolving artifacts, where changes are manually compared, inconsistently propagated, or discovered only during builds and testing.
- Interface Changes: Regenerated dummy models provide no structured change history, so functional teams manually compare renamed parameters, changed data types, and added or removed signals.This comparison is described as error-prone and inefficient.
- Revision Desynchronization: Functional and embedded domains may intentionally use different XML revisions, but this desynchronization creates compatibility risks across their iteration cycles.Transport-layer-only changes can move faster on the embedded side than functional updates.
- Build-Time Discovery: Failed builds can follow a 20–60 min Simulink® build phase when interface changes require functional-model updates.Incompatibilities become visible only when transport-layer code is linked with generated functional source code.
- Units and Scaling: Inconsistent units, scaling factors, and data-type conversions between transport-layer code and functional models were historically reconciled case by case.Actuator command resolutions could differ, such as 0.1° versus integer-degree expectations.
- Data Types: Manual updates to integration models can introduce latent data-type inconsistencies that surface during code generation or compilation.The functional team may then be unavailable to diagnose the root cause immediately.
- Unpropagated Changes: Direct ICD XML fixes stored beside embedded software can be lost when regeneration overwrites the locally edited file.Undocumented functional parameters likewise require later manual consolidation and rework.
- Toolchain Environments: Different workstation toolchains and configurations cause difficult-to-diagnose compilation errors and bottleneck integration around a few known-good environments.This reduces responsiveness during integration and flight testing.
III. PROPOSED REPOSITORY-CENTERED APPROACH
The approach assigns each domain a primary repository and uses CI pipelines plus cross-repository references to enforce artifact consistency. Coarse repository boundaries preserve domain independence while limiting unnecessary propagation of changes.
- Each domain receives a primary repository and CI pipelines that continuously detect inconsistencies across repository transitions.The implementation uses GitLab CI/CD with custom Docker-based runners.
- Repositories are granulated coarsely so changes propagate only to affected repositories.System and embedded domains maintain one repository per device because their outputs are device-level atomic artifacts.
- Functional-domain Simulink® dummy models are jointly managed when multiple integrated functions on a device require matching interfaces.
- Git submodules anchor consuming repositories to specific upstream revisions, so downstream changes require explicit reference updates.
- The repository structure, pipelines, and submodule references collectively address the identified cross-domain failure modes.
A. Interface Repository (System Domain)
The interface repository controls released system-level interface artifacts and their propagation to functional and embedded domains. Branches, differential notifications, and automated generation support staged review and role-specific updates.
- Interface Repository: The interface repository is the sole bridge from dBricks and automatically produces ICD XML and mrails-compliant Simulink® dummy models.The system domain controls which dBricks revisions are released downstream and when.
- Branching and release control: The dBricks, dev, and master branches separate proposed changes, development consumption, and flight-testing releases.Merging dev into master is the system domain’s formal “ready for flight” statement for the interface definition.
- Notifications: Notifications classify interface changes by affected artifact categories and filter low-impact modifications for role-specific recipients.Categories include physical ports, functions, function parameters, data types, and the transport layer.
- Notifications: Email notifications include pipeline links, change status, previous and current values, and direct dBricks links for modified or added elements.
- Notifications: The same structured change information updates merge-request descriptions, making reviews traceable while reducing manual reviewer effort.
- Failure-mode mitigation: The mechanisms address four identified failure modes through differential change summaries, version-controlled releases, generated artifacts, and consistency-enforcing release controls.The repository structure does not directly address FM3; SI-unit conventions and generated transport-layer code are used instead.
B. Function Integration Repository (Functional Domain)
The function integration repository extends the existing mrails-based integration process with consistency checks against interface-repository artifacts. Branch workflows and staged code-generation checks support independent iteration while blocking inconsistent releases.
- Repository role: The repository’s contribution is extending mrails integration pipelines to enforce consistency with Simulink® dummy models published by the interface repository.
- Branch workflow: Feature branches support functional development and interface updates at a cadence different from interface evolution.
- Consistency checks: An automated check compares Simulink® integration-model inports and outports against ICD XML for matching names, directions, and data types.
- Code generation: Merge-request pipelines run code generation after consistency checks and block merges until generation succeeds.
- Code generation: Feature-branch commits use non-blocking dry-run code generation, allowing reported failures without preventing commits.This tradeoff supports continued development before embedded-side binary rebuilding.
- Review and change proposals: The checks and generation outcomes are attached to automated merge requests, while reverse-direction requests provide a standardized channel for interface changes.
C. Software Integration Repository (Embedded Domain)
The software integration repository is the final pre-compilation integration point, combining referenced interfaces, function repositories, hardware support, and embedded source code. Its blocking CI pipeline checks compatibility, generates code, compiles the binary, and records reproducibility metadata.
- C. Software Integration Repository (Embedded Domain): The software integration repository combines interface and function-integration repositories with hardware support and manually authored embedded source code.It generates binaries from the latest functional models and interface definitions.
- C. Software Integration Repository (Embedded Domain): The pipeline is the sole route to testing and flight-ready binaries and blocks on failure because input inconsistencies could have safety implications.It runs on feature-branch commits and merge requests into dev or master in a shared Docker environment.
- C. Software Integration Repository (Embedded Domain): Compatibility checks validate shared tool versions and interface revisions before functional source-code generation and compilation.Feature and development integration can accept compatible revisions, while master merges require exact matches.
- C. Software Integration Repository (Embedded Domain): The pipeline produces functional source code, integrates it with low-level software and transport-layer code, and compiles the binary.These mechanisms address three identified failure modes, including detecting interface incompatibility before a 20–60 min Simulink build phase.
- C. Software Integration Repository (Embedded Domain): A build report records tool versions, referenced-submodule Git hashes, and input-artifact checksums alongside the compiled binary for subsequent target-hardware testing.The binary and report are exposed as pipeline artifacts.
- C. Software Integration Repository (Embedded Domain): Referencing the interface repository prevents local ad-hoc ICD XML edits, while Docker and version checks remove dependence on individually maintained toolchains.Corrections must propagate through dBricks and the interface repository’s release process.
D. Supporting Repositories
Supporting repositories provide reusable tools and hardware-specific artifacts while participating in the same submodule-based consistency checks as the primary repositories.
- D. Supporting Repositories: Supporting repositories are reused across projects and referenced as submodules by primary repositories, bringing them into the consistency-checking machinery.They add no independent consistency mechanisms.
- D. Supporting Repositories: Tool repositories contain in-house tools such as mrails and tlcodegen, whose matching versions support reproducible code generation across releases.Both tools remain under active development.
- D. Supporting Repositories: Hardware support repositories isolate platform-specific compilation toolchains and tlcodegen templates from primary pipelines.They may also reference vendor board-support packages or compilation tooling.
IV. APPLICATION IN PRACTICE
The approach is being implemented in a manned light sport aircraft project, with interface infrastructure and selected validation stages already operational. Early qualitative feedback reports fewer interface-update inconsistencies and improved productivity, while broader evaluation remains pending.
- IV. APPLICATION IN PRACTICE: Implementation and validation are underway in a manned light sport aircraft project, with the mechanisms intended to apply where three-domain separation exists.The interface repository is fully implemented, while other pipeline stages remain in progress.
- IV. APPLICATION IN PRACTICE: The interface repository and interface-validation stages of the function-integration and software-integration pipelines have been implemented.The full architecture is not yet in production use.
- IV. APPLICATION IN PRACTICE: Initial qualitative feedback indicates reduced inconsistencies from interface updates and improved productivity.Functional-domain users report less manual work, and automated ICD export removes a recurring delay source on the system side.
- IV. APPLICATION IN PRACTICE: Quantitative efficiency evaluation is deferred until broader adoption provides a sufficient sample.Current evidence is qualitative rather than a measured efficiency study.
V. CONCLUSIONS AND FUTURE WORK
The paper addresses cross-domain inconsistencies through repository-centered, lightweight enforcement that assigns responsibilities and makes repositories active process components. Initial feedback is promising, but broader application is still needed, and future work includes more automation and architecture-model integration.
- V. CONCLUSIONS AND FUTURE WORK: Repository-centered responsibilities and lightweight consistency checks address inconsistencies between system, functional, and embedded domains.The approach elevates repositories from passive storage to components enforcing domain interactions.
- V. CONCLUSIONS AND FUTURE WORK: Lightweight enforcement is intended to give resource-constrained teams cross-domain consistency without sacrificing development agility.The paper contrasts this approach with heavyweight process gates.
- V. CONCLUSIONS AND FUTURE WORK: Broader application in real development projects is still required to establish the approach’s suitability and reliability.The authors expect vulnerabilities and weaknesses to emerge during broader use and subsequent revisions.
- V. CONCLUSIONS AND FUTURE WORK: Future improvements include automatically triggering integration runs after function-repository commits and baselining matching interface versions for flight testing.These changes target shorter integration-testing round trips and controlled interface states.
- V. CONCLUSIONS AND FUTURE WORK: Closer integration of architecture models could eliminate manual transfer into dBricks and derive simulation models directly from architectural descriptions.This is presented as a more far-reaching future possibility.