Generative Systems Engineering in CATIA Magic (CUSE 2026)

Hi MBSE (& AI) enthusiasts,

In this post, I would like to share some of our current solutions in the context of AI applications in CATIA Magic.

This content was presented and demonstrated live at our recent CATIA User Symposium Europe (CUSE) 2026 in Darmstadt.

Enjoy reading the post, and feel free to reach out if you have any questions.

 

The next section starts with a short introduction and some information regarding the availability and prerequisites for AI-related features in CATIA Magic. If you are mainly interested in the demo videos, feel free to jump directly to the demo section. You will find the video for each step in the last column.

Intro

The current AI-augmented solutions in CATIA Magic can be grouped into three main categories: Generative Requirements Extraction, Model Suggestions, and Virtual Companions, meaning AURA and LEO Systems Architecture competence.

Generative Requirement extraction in CATIA Magic (Step 2 in Demo)

This functionality is designed to extract requirement elements in CATIA Magic exactly as stated in the source document, while also preserving the original document structure. This means that packages are created according to the structure of the document.

The extracted requirements are first placed in an AI sandbox, where they can be reviewed by the modeler. The modeler can then decide whether to take them over into the model, decline them, or selectively pick specific requirements.

 

Model Suggestions (Step 3 in Demo) 

Model Suggestions gives the modeler the possibility to receive AI-augmented suggestions in an AI sandbox, based on the selected model elements.

For example, the modeler can select a system, defined as a Block, and receive suggestions for possible subsystems of that system. Triggering this option runs a predefined query, and the result is a list of newly generated elements in the AI sandbox.

The query behind each option is defined in a configuration file, JSON, located in the CATIA Magic installation folder.

Value: These predefined queries are customizable and can be extended to include specific rules or customer-specific methodologies. This helps ensure that the suggested model elements are aligned with user needs and modeling guidelines.

Model Suggestions are especially well suited for executing repetitive actions that do not require further input from the modeler.


Virtual Companions (AURA and LEO Systems Architecture) in CATIA Magic

3DSwym is integrated into CATIA Magic, giving the modeler access to all available Virtual Companions and competences, including AURA.

Using AURA directly from CATIA Magic allows the modeler to ask generic questions, for example about tool documentation.

However, AURA does not have access to the model itself. Therefore, it cannot answer questions in the context of the current model or generate model elements directly.

 

          

                             

LEO | Systems Architecture (Step 1 & 4-7 in Demo) 

LEO Systems Architecture mainly enables the modeler to:

  • Ask questions about the model and summarize it at different levels of detail.
  • Create new model elements based on a given query or an imported document, such as a picture or PDF.
  • Reference already existing model elements when creating new ones. For example, it can create a connector between an existing system and a newly generated one, even within a single call that also generates the new system.
  • Provide a detailed report, including hyperlinks to existing elements in the model tree.
  • Use a complete package as context for a prompt. In contrast to Model Suggestions, where only the selected elements are used as context, LEO can take the whole package into account if needed. This can significantly improve the quality and relevance of the results.

How does LEO work and make decisions?

LEO Systems Architecture has access to different so-called “Experts”. These are categorized as Requirements, Structure, Behavior, and Methodology Experts.

Each expert has a set of predefined skills, provided as .md files. Each skill can also include examples, which are JSON files of well-designed SysML models.

 

For example, a skill for logical decomposition can include an example of a well-defined logical decomposition of a system. Each time the user asks for a logical decomposition, this example can be used as a pattern. As a result, the generated answer is better aligned with the provided modeling pattern and methodology.

Which expert is used for a specific call is decided by a central orchestrator. The orchestrator receives the user prompt together with additional context, such as user-provided documents and the chat history. It analyzes the request and routes it to the most suitable expert, for example the Structure Expert or the Behavior Expert. The selected expert then uses its dedicated skills in a ReAct (Reasoning + Acting) loop until the task is completed.


Availability and Prerequisites

All three solution categories were first introduced in CATIA Magic 2026x GA (December 2025) and on the 3DEXPERIENCE Platform 26x FD01. Nevertheless, the majority of the features shown in the following Demo will be available in CATIA Magic 2026x R1 and 3DEXPERIENCE Platform 26x FD03.

 

It is important to note that all three categories (Requirement Import, Model suggestions and LEO in CATIA Magic) are currently ONLY available in controlled availability


Required roles and plugins:

  • Server side: Generative Experience for CATIA Magic (GEM) Role
  • Client side (CATIA Magic): AI Assistant Plugin
     

 

Scenario & Demo Videos

This scenario was shaped to focus more on users who already have SysML knowledge, highlighting how LEO can benefit them by accelerating modeling activities and taking over repetitive, multi-step actions during system architecture modeling.

Beyond that, it demonstrates that LEO can support not only the creation of new models from scratch, but also the further expansion of existing models by referencing already existing model elements.
 

 Tasks executed using Model Suggestions OR LEO Systems ArchitectureDemo Video
Step 1: Create package structure (LEO)Generating packages based on given prompt

 

Step 2: Import RequirementsImporting requirements based on a requirement table documented in PDF

Step 3: Extract Use cases and systems context from requirements (Model Suggestions)

  • Deriving use cases, system contexts, and actors
  • Creating satisfy relations between use cases and selected requirements
  • Creating association links between actors and use cases
  • Setting use cases as subjects of the relating system contexts

 

Step 4: Create a new system context based on user prompt (LEO)
  • Create blocks for all participants of the system context
  • Create part properties and assign the correct blocks as their types
  • Create an IBD to visualize the system context and its participants

 

 

Step 5: Create interactions between participants of existing system context (LEO)
  • Create exchange items as signals
  • Create connectors between existing part properties
  • Create item flows between existing blocks
  • Assign the appropriate signal as the conveyed element of each item flow
  • Set the correct direction for each item flow
  • Set the corresponding connector as the realizing connector of each created item flow

 

 

 

Step 6: Create the System Structure of robotic Arm based on imported picture (LEO)

  • Analyzing the imported picture
  • Create the related blocks for the identified subsystems
  • Reference the already existing SoI, Robotic Arm, and set the newly created subsystems as its children

 

 

Step 7: Create the conceptual system architecture (LEO)

  • Create interface blocks
  • Create appropriate flow properties for each interface block
  • Set the correct signal as the type of each flow property
  • If no suitable signal exists in model, create a new signal and set it as the type of the corresponding flow property
  • Set the correct direction for the flow properties
  • Create proxy ports for the subsystems
  • Set the appropriate interface block as the type of each proxy port
  • Conjugate the direction of proxy ports where needed, based on the signal direction defined by the user