Developing software for modern aerospace systems means balancing strict certification requirements, tight hardware constraints, and rapidly increasing functional complexity. As avionics architectures evolve toward more integrated, reconfigurable, and autonomous platforms, engineering teams are seeking development flows that can keep pace with both innovation and compliance.

MathWorks, DLR, and SYSGO have joined forces to demonstrate how model-based systems engineering (MBSE) and a single-source-of-truth workflow can accelerate development for certifiable, safety-critical avionics. By combining high-level architecture modeling, certified real-time operating system technology, and automated code and configuration generation, the partners show a seamless path from Simulink models all the way to PikeOS-based embedded targets—including support for dynamic partition reconfiguration.

A Modern Challenge: Integrated Modular Avionics (IMA) and Dynamic Reconfiguration

Traditional avionics architectures rely on federated subsystems—one computer, one function. As aircraft became more capable and interconnected, this model proved costly, rigid, and difficult to scale. Integrated Modular Avionics (IMA) introduced a new paradigm: Multiple applications executing on shared computing modules, isolated through time and space partitioning.

This approach increases flexibility and resource efficiency, but it also introduces new challenges:

• How do we ensure fault tolerance and resilience when functions share computational resources?
• How do we support autonomous algorithms that may behave unpredictably?
• How can the system reconfigure itself safely at runtime?

Enter dynamic reconfiguration: the capability to activate, deactivate, or replace partitions during operation. Whether responding to a detected fault, containing a misbehaving AI component, or reallocating resources, dynamic reconfiguration becomes a cornerstone of future autonomous avionics systems.

SYSGO’s PikeOS—our certified separation kernel RTOS and hypervisor—provides native mechanisms to support this through ARINC 653 APIs, health monitoring partitions, configurable schedules, and partition mode changes.

But enabling reconfiguration requires a consistent, traceable, and certifiable model of the system architecture. That is where MathWorks tools and DLR workflows fit in.

System Composer: Architectural Modeling as the Single Source of Truth

MathWorks’ System Composer sits at the top of the workflow, capturing high-level system and software architectures in a structured, analyzable form.

With System Composer, engineers can:

• Model hierarchical architectures, interfaces, behaviors, and physical or functional views
• Use activity and sequence diagrams to express interactions
• Apply stereotypes and metadata that describe timing, partitioning, or deployment properties
• Maintain multiple fidelity levels—from abstract behavior to detailed Simulink algorithms
• Integrate third-party models, legacy code, hardware-in-the-loop systems, and FMUs

Crucially, architectural metadata becomes the basis for downstream code generation and PikeOS configuration, ensuring that the architecture model remains the single source of truth for the entire development pipeline.

Simulink and the ARINC 653 Blockset: Turning Architecture into Executables

Once the architecture is defined, it can be translated into a deployable design using:

• The ARINC 653 Blockset for defining partitions, processes, ports, and communication channels
• Behavioral models built directly in Simulink
• Automated C code generation via Embedded Coder

The generated code conforms to the ARINC 653 APEX interfaces implemented by PikeOS. This allows each partition defined in System Composer to be directly translated into a certifiable PikeOS partition application, reducing manual coding effort and minimizing integration mismatches.

For added flexibility, SYSGO is developing a native PikeOS API compatibility layer for non-avionics domains, removing the dependency on ARINC 653 when desired.

Bridging the Gap: Automatic PikeOS Configuration through XML Generation

One of the most powerful elements of the workflow is that System Composer and Simulink metadata can be automatically translated into a PikeOS system configuration (XML).

This generated configuration specifies:

• Partition definitions
• Application associations
• Inter-partition communication channels
• Time scheduling information

SYSGO’s Eclipse-based IDE, CODEO, can import this XML directly, populating the PikeOS system setup with predefined partitions, ports, and scheduling parameters. Because the configuration is auto-generated from the model, developers avoid manual re-entry and maintain full traceability from architecture to target image.

CODEO: Integrating, Monitoring, and Deploying on PikeOS

Once imported into CODEO, the software engineer can:

• Map binaries to partitions
• Modify scheduling parameters or routing details when needed
• Configure board-specific aspects through the Platform Support Package (PSP)
• Build a final PikeOS system image
• Debug at the instruction level and monitor real-time execution behavior

PikeOS’s modular certification strategy—separating certifiable core components from project-specific BSP or API elements—ensures that the resulting system can be certified to stringent standards such as DO-178C (avionics), ISO 26262 (automotive), and Common Criteria.

Demonstration: Reconfigurable Flight Control Partitions on a PowerPC Board

The webcast includes a complete end-to-end demonstration:

1. Architecting two flight control partitions and their sampling-port interface in System Composer
2. Generating an XML configuration and automatically creating matching Simulink models
3. Implementing partition logic (e.g., simple counters for illustration)
4. Generating C code and ELF binaries via Simulink Embedded Coder using the PikeOS toolchain
5. Importing configuration and binaries into CODEO and generating the PikeOS system image
6. Deploying the image to a PowerPC VPX platform via TFTP
7. Booting the system and monitoring the output from the two partitions running in isolation

The full process—from modeling to deployment—can be completed in minutes, even with room for scaling to industrial-sized systems. This demonstrates not only workflow efficiency but also the robustness of a model-driven, architecture-first approach.

Key Benefits of the Integrated Workflow

• Faster Development Through Automation: Architectures, code, and OS configurations are generated from a single model—reducing manual integration and minimizing human error
• Early Validation and Shift-Left Testing: Developers can simulate, analyze, and refine architecture, scheduling, and reconfiguration logic long before hardware is available
• Strong Traceability for Certification: End-to-end linkage from architectural model to deployable target image supports DO-178C and ARP 4754A processes
• Support for Mixed-Criticality Systems: PikeOS enables safe coexistence of high-criticality control logic and rich guest OSes, enabling modern intelligent avionics architectures
• Ready-to-Use Building Blocks and References: DLR and SYSGO provide real demonstrators, examples, and whitepapers that teams can build upon

Conclusion

Future aerospace systems demand architectures that are modular, adaptive, reliable, and certifiable. The collaborative workflow between MathWorks, DLR, and SYSGO provides a blueprint for meeting these challenges head-on.

By treating the system architecture as the single source of truth and letting tools automate downstream software generation and real-time OS configuration, teams can dramatically reduce integration time, increase development agility, and maintain the rigorous certification compliance required for avionics.

Whether you are developing autonomous flight control, mission management software, or modular payload systems, this integrated model-to-mission pipeline offers a proven, scalable approach to building the next generation of safety-critical aerospace software.