How can a general-purpose SysML v2 modeling environment be adapted to address the specific engineering needs of an organization? RTE’s work on CyberGridML developed by CEA LIST provides a concrete example of how SysON can be extended with domain concepts, dedicated views, and engineering workflows, while keeping standard SysML v2 models underneath.
At the LF Energy Summit Europe 2026, a Linux Foundation event which took place in September in Berlin, Guillaume Giraud and Akli Rahmoun from RTE, France's electricity transmission system operator, presented their work on CyberGridML, a domain-specific modeling language designed to support the architecture and evaluation of power grid control systems.
The approach relies on SysML v2 and a customized version of SysON developed by CEA LIST to provide engineers with a modeling environment tailored to their domain.
Beyond the energy use case itself, this experience illustrates a broader capability of SysON: using an open-source SysML v2 environment as the foundation for specialized engineering solutions.
From a General-Purpose Language to a Domain-Specific Environment
Modern power grids increasingly combine electrical infrastructure with software, computing resources, communication networks and automated control functions. As these systems become more distributed, their digital architecture directly affects their operational performance and resilience.
For RTE, this creates a practical architecture challenge: how can different grid control architectures be modeled, compared and justified before they are deployed?
SysML v2 provides a standardized foundation for addressing this challenge. Its formal semantics, textual and graphical representations, standard API and extension mechanisms make it possible to build models that can be integrated with other engineering activities and tools. In particular, its library mechanisms allow domain-specific modeling languages to be defined on top of SysML v2.
Image: Credit RTE
RTE used these capabilities to develop CyberGridML, a domain-specific modeling language for grid control architectures.
Rather than asking engineers to work directly with generic SysML concepts, CyberGridML introduces concepts that correspond to their engineering domain.
CyberGridML: Bringing Grid Engineering Concepts into the Model
CyberGridML organizes grid control architecture around three complementary layers:
- Control Functional Architecture, describing what the grid control system must do.
- Control Resources Architecture, describing the hardware, software and networks on which these functions run, together with associated hazards.
- Allocation, mapping functions onto resources so that different deployment scenarios can be evaluated and compared.
Image: Credit RTE
This structure allows engineers to explore questions such as where control functions should be deployed, how architectures behave when communication or computing resources fail, and how different scenarios compare in terms of resilience, efficiency or cost.
The important point from a tooling perspective is that these concepts are not managed outside the system model. They become part of the modeling environment itself.
Customizing SysON Around the Engineering Domain
To put this methodology into practice, RTE used a customized build of SysON to model CyberGridML architectures.
SysON provides the underlying web-based SysML v2 modeling environment. CyberGridML extends this foundation with grid-specific concepts such as functions, resources, hazards and allocations, together with dedicated representations for manipulating them.
This changes the experience for domain engineers.
Instead of having to translate their engineering concepts into generic modeling abstractions, they can work directly with the vocabulary of grid control architecture. Domain rules can also be incorporated into the language, helping constrain how models are built and reducing modeling errors.
At the same time, the resulting models remain based on SysML v2. The specialization therefore does not require creating an isolated modeling technology or proprietary model format.
This combination is particularly interesting: the user experience can be specialized for a particular engineering domain while the underlying model remains based on an open standard.
Supporting a Complete Domain-Specific Workflow
The customization is not limited to adding new concepts to a palette.
In the workflow demonstrated by RTE, engineers can import an electrical grid model, describe control functions and their information flows, define computing and network resources, associate hazard models with components, and allocate controllers to software resources.
The resulting structured model can then be exported for evaluation and coupling with co-simulation tools. The same approach has been applied to a real distributed SCADA use case, including its functions, platforms and hazard scenarios.
SysON therefore acts as the modeling foundation for a broader engineering workflow rather than simply providing a diagram editor.
Comparing Architecture Alternatives with the Same Model
RTE applied this approach to a Zonal Control Automaton, which monitors the electrical network, detects constraints and dispatches corrective setpoints to flexible resources. One of the architecture questions was where these controllers should physically or logically run.
Image: Credit RTE
Four deployment architectures were modeled and studied: a centralized architecture, a redundant centralized architecture, a hybrid architecture combining datacenters and edge computing, and a decentralized architecture based on an edge cluster. The alternatives could then be evaluated against network failure scenarios.
Image: Credit RTE
The study made architecture trade-offs explicit. RTE reports that the decentralized approach provided higher resilience in the evaluated scenarios while retaining comparable architecture complexity. More broadly, the modeling approach enabled resilience, operational efficiency and cost to be discussed using shared, quantified evidence rather than only qualitative architecture descriptions.
The models also remain useful beyond the initial comparison. According to RTE, the same SysML v2 models can provide a consistent foundation for simulation and future digital-twin initiatives.
SysON as a Foundation for Specialized Modeling Solutions
The RTE experience illustrates an important aspect of SysON.
Adopting SysML v2 does not mean that every engineer has to work with a generic SysML v2 environment.
An organization can use SysON as a foundation and extend it around its own engineering context. Domain concepts can become first-class modeling elements. Dedicated representations can support specific activities. Domain rules can guide modeling. Models can also be connected to downstream analysis, simulation or digital-twin workflows.
At the same time, the underlying models remain aligned with SysML v2 and its standard APIs.
For organizations with established engineering methods or highly specialized domains, this opens an interesting path: combine the interoperability of a standard modeling language with a modeling environment adapted to the way their engineers actually work.
RTE’s CyberGridML implementation shows what this approach can look like in practice. A general-purpose, open-source SysML v2 environment becomes the foundation for a domain-specific engineering solution, without losing the benefits of the standard underneath.