# DemistifyCPS: A Domain-Specific Language for Influence Modeling in Cyber-Physical Systems

Barbara da Silva Oliveira<sup>a</sup>, Nicolas Ferry<sup>b</sup> and Julien Deantoni<sup>c</sup>

Université Côte D'Azur, 13S/INRIA Kairos, Sophia Antipolis, France

(barbara.da-silva-oliveira, nicolas.ferry, julien.deantoni)@inria.fr

**Keywords:** Cyber-Physical Systems (CPS), Influence Modeling, Domain-Specific Language (DSL), Systems Engineering.

**Abstract:** Cyber-Physical Systems (CPS) are integrated systems, composed of various system parts, comprising physical and computational processes. CPS development generates multiple artifacts, including design models and implementation code developed by several stakeholders, that may interact with each other and the environment in which the CPS operates. Teams rely on Model-Based Systems Engineering (MBSE) to manage this complexity. Standard MBSE relations capture functional exchanges between artifacts and between the system and its environment. However, many couplings across artifacts and the environment remain implicit, only partially understood, or unknown at design time. The absence of explicit modeling of these couplings makes it hard to understand the effects of design or environmental changes. In this paper, we model these hidden couplings as Influences. We propose DEMISTIFYCPS, a domain-specific language for design influences as first-class relations. A mobile robot use case demonstrates the language, showing how it surfaces influences and offers actionable feedback. Overall, our work indicates that making Influences explicit helps demystify CPS behavior and supports better decision-making.

## 1 INTRODUCTION

Engineering cyber-physical systems (CPS) is a socio-technical effort, where multiple teams cooperate to define requirements, build models, and implement different parts of the system (Carreira et al., 2020). Decisions in one part of the system, together with environmental factors beyond the control of system developers, often form implicit interactions. Such couplings *influence* System Response Properties (i.e., observable outcomes such as the braking distance of a car), which are often not accounted for during design time (da Silva Oliveira et al., 2024). These *influences* may threaten the proper operation and correctness of the system. This risk is critical in systems, particularly in CPS that rely on closed loops between sensors and actuators. For stakeholders to make sound decisions, they need a structured way to *express* these influences, to *analyze* their effects on the system's behavior, and to *coordinate* actions across teams.

Model-Based Systems Engineering (MBSE) has largely been adopted as a means of managing the

complexity of developing systems such as CPS (Madni and Sievers, 2018). Current MBSE practices incorporate various forms of explicit relationships between artifacts, such as dependencies, interactions, or traceability links. These help identify how artifacts are connected and how changes may propagate. However, relations that connect system response properties that emerge during system operation due to their interaction with the physical environment are typically not captured by explicit and analyzable relations in MBSE approaches.

To address this concern, this paper introduces the *Influence* relation as a first-class modeling concept. In particular, we present the DEMISTIFYCPS domain-specific modeling language as a means to explicitly specify *Influences* (i.e., relating Design Artifacts and Environmental Factors to System Response Properties, and Requirements) during CPS development. We also detail how the concept of *Influence* can be used to provide support for stakeholders in decision-making. We demonstrate the use of DEMISTIFYCPS in a mobile robot use case.

The remainder of the paper is organized as follows. Section 2 presents the background of our work and reviews related studies. Section 3 introduces the metamodel and textual syntax of DEMISTIFYCPS.

<footnote>a https://orcid.org/0009-0007-8455-9627</footnote>

<footnote>b https://orcid.org/0000-0003-2036-0508</footnote>

<footnote>c https://orcid.org/0000-0001-6962-7846</footnote>
In Section 4, we detail the analysis enabled by the language. Section 5 demonstrates the approach on a robot use case. Section 6 concludes our work.

## 2 BACKGROUND AND RELATED WORK

Current MBSE practices capture CPS design and development through the usage of models of structure and behavior (Hoffmann, 2006). In most tools, the system under study (SUS) and its interfaces with the environment are represented, reflecting the separation of the SUS from its physical surroundings (Carreira et al., 2020). Based on such interfaces with the environment, existing mechanisms, such as context diagrams (Daun and Tenbergen, 2023), facilitate analysis of relations between the SUS and its environment.

While these practices explicitly capture some interactions and functional dependencies with environmental factors, they are primarily used for a priori known interactions. Moreover, environmental aspects are intermingled with the system design and do not offer dedicated or flexible concepts to specify how design artifacts, System Response Properties (SRPs), and requirements are linked to environmental factors. SRPs emerge not only from the internal behavior of the SUS, but also from interactions between the system and its environment. They are evaluated against requirements, which aligns with measures of system performance (Roedler and Jones, 2005).

Complementary work on cross-consistency modeling focuses on keeping different models and views synchronized (Klare et al., 2021). Such approaches reason over correspondences, relations, and constraints to preserve consistency across views, typically by checking explicit ports, interfaces, or contracts. Similar to context diagrams, environmental factors are usually included only when they are a priori declared in models through well-defined interfaces. Our work, in contrast, focuses on modeling environment-mediated couplings that are not intended to be explicitly represented in the SUS interface, but are instead used as explanatory elements relating design choices, SRPs, and requirement violation or satisfaction.

Other related approaches, such as orthogonal uncertainty modeling, consider the impact of environmental factors at runtime in order to manage runtime adaptations (Bandyszak et al., 2020). In contrast, our approach focuses on modeling such couplings at design time.

Finally, studies on Critical Infrastructures provide a complementary perspective on cross-cutting

effects in systems-of-systems (Akbarzadeh and Katsikas, 2021), which inspires our work on exploring chains of relationships and understanding their impact. Similarly, changeability approaches (Koh et al., 2013) improve transparency regarding change propagation and, while not aligned with our objectives, were inspirational.

To address these limitations, we introduce the notion of *Influence* as a first-class modeling concept. By modeling relationships between design artifacts, environmental factors, and SRPs, we aim to enable more comprehensive analysis and support socio-technical coordination in CPS development.

## 3 INFLUENCE CONCEPT

In this section, we define the notion of Influence and introduce DEMISTIFYCPS, our domain-specific modeling language for specifying Influences.

### 3.1 Influence Definition

As introduced in the previous section, the objective behind the concept of *Influence* is to make explicit the interactions between Design Artifacts, Environmental Factors, System Response Properties, and Requirements. More precisely, we define an *Influence* as a relation that explicitly connects one or more participants, such as design artifacts or environmental factors, to a system response property. Variations in this property can affect the satisfaction of requirements. In this work, we aim to model *Influence* as a first-class relation capturing these interactions.

Figure 1 summarizes the key elements of an Influence: participants (circles on the left) are inputs of a single influence node (middle) that *influences* one SRP (right), which is *constrained* by requirements (top right) and is *affected* by participants.

<figure><img src="image_1.png" /><figcaption>Figure 1: Illustration of the concept of Influence.</figcaption></figure>

Given a set of participants including Design Artifacts *D*<sub>I</sub>, Environmental Factors Φ<sub>I</sub>, and (optionally) System Response Properties SRP<sub>I</sub><sup>in</sup>, an Influence *I* re-
sults in one output SRP, srp<sub>I</sub>:

$$f_I : D_I \times \Phi_I \times SRP_I^{\text{in}} \rightarrow \text{Val}(\text{srp}_I).$$

The function $f_I$ describes how multiple inputs affect a System Response Property (e.g., BrakingDistance) that may be constrained by requirements. This mapping is intentionally single output, aiming to keep granularity clear and enable more precise traceability explanations.

As opposed to standard dependency or interaction modeling, an Influence *I* involves at least one design artifact and its participants do not comprise only design artifacts. At least one non-artifact participant (i.e., an environmental factor and/or an upstream SRP) captures the integration of the CPS with its environment.

We require the tooling to satisfy the following:

* **R1: First-class relation:** Influence must be an explicit modeling element that links design artifacts, environmental factors, or upstream SRPs to a single output SRP.

* **R2: Support chains of influences:** An SRP produced by an Influence shall be usable as an input to other influences, enabling a chain of influences. It shall enable explanations from participants through intermediate SRPs to related requirements.

* **R3: Flexible expression of Influences:** The language must admit multiple levels of precision for expressing an Influence. Developers must be able to use different precision levels, such as quantitative formulations or qualitative assertions.

* **R4: Decision-making support:** Depending on the precision available, the tooling must provide structural insights, and, when possible, requirement-aware evaluation.

* **R5: Integration in MBSE of any type of model:** The language must integrate with existing MBSE models by cross-reference. It should not modify domain models, and, when numerical analysis is required, it should be able to read numeric values from referenced elements.

In line with these requirements and faithful to the definition, we defined the DEMISTIFYCPS domain-specific language (DSL).

## 3.2 The DemistifyCPS DSL

In this section, we introduce DEMISTIFYCPS<fnref n="1" />. The key concepts of its metamodel are presented and examples are provided using the associated concrete

syntax. The DEMISTIFYCPS metamodel is depicted in Figure 2 using EMF Ecore.

An Influence model embeds a set of Influences. An Influence owns participants (i.e., ArtifactParticipant, EnvironmentalFactorParticipant, SRPInputParticipant), one output SRP, and an owned InfluenceFunction.

For model consistency, each Influence must include at least one design artifact among its participants and at least one non-artifact participant that can be either an environmental factor or an input SRP. These constraints were implemented at the Meta-model level by the use of OCL constraints, and in the DSL validator class, so as to be automatically checked by the Eclipse validator, issuing an error marker if the rule is violated.

DesignArtifacts represent design elements (e.g., SysML parts, items, and attributes) that developers create and modify throughout the system development life cycle. Each artifact may reference an external model element and record a changeability in [0, 1]. Changeability is the expected ease of modifying an artifact, according to different aspects. It can be defined as how rapidly the artifact can be changed, how the system adapts itself after changing that artifact, or how costly it is to change. Listing 1 provides an example of a DesignArtifact instance definition.

<caption>Listing 1: Design Artifact instance.</caption>

```
DesignArtifact motorSpeed ->
    "ActivityDiagWheelControl.activityWheelControl.speedWheel"
    changeability 0.6,
```

EnvironmentalFactors capture the elements from the physical environment that affect SRPs (e.g., friction, slope, temperature). Developers provide a configuration description, documenting assumptions or the operational context. Optionally, they may record a value and a unit, which may be a fixed constant, or baseline values. As future work, we plan to support interval values ([$v_{min}$, $v_{max}$]). This would enable validity-frame exploration, i.e., identifying regions in the operating space in which a requirement is satisfied. Each environmental factor may include a flexibility score that quantifies the extent to which the operating environment can be adjusted, for example, the practical ability to select or schedule the operational context (e.g., selecting an operating window), or availability of alternatives. Listing 2 exemplifies the EnvironmentalFactor definition.

<caption>Listing 2: EnvironmentalFactor instance.</caption>

```
EnvironmentalFactor temperature
description "Outdoor temperature"
```

<footnote n="1">¹Available at https://github.com/barbara-da-silva-oliveira/DemistifyCPS</footnote>
<figure><img src="image_2.png" /><figcaption>Figure 2: DEMISTIFYCPS Metamodel defined in EMF, capturing Design Artifacts, Environmental Factors, Requirements, and System Response Properties.</figcaption></figure>

flexibility 0.0 value 40 unit "deg",

A SystemResponseProperty is the output of an Influence. A SystemResponseProperty models observable outcomes or behaviors that may be extracted from simulation traces or operational logs. It has a description and, optionally, declares which requirement(s) it is constrainedBy. In Listing 3, the SRP MarginCollision may impact the satisfaction of ObstacleAvoidance.

<caption>Listing 3: SystemResponseProperty instance.</caption>

SystemResponseProperty MarginCollision
description "Collision margin for clearance
according to the detection threshold"
constrainedBy ObstacleAvoidance,

Participant is an abstract class for all links between an Influence and its inputs, with specializations ArtifactParticipant, EnvironmentalFactorParticipant, SRPInputParticipant. All specializations inherit the optional annotations to characterize their contribution to an Influence: weight, likelihood, and confidence. The weight represents the relative contribution of that participant within the Influence, likelihood expresses how often the participant is expected to be relevant to the Influence, and confidence expresses how certain the developer is about the definition of that participant. These annotations are important especially when full equations

are unavailable to quantify the contribution of each of the participants in the Influence definition.

The participant is separated from the definitions themselves, since each participant may be part of multiple influences. For example, each time a DesignArtifact is used in different influences, a new ArtifactParticipant is created, owned by that Influence, referring to the same artifact.

Listing 4 shows an instance of ArtifactParticipant referring to DesignArtifact named motorSpeed.

<caption>Listing 4: ArtifactParticipant instance.</caption>

ArtifactParticipant motorSpeed
weight 0.6 likelihood 0.8 confidence 0.9,

Listing 5 shows an example of EnvironmentalFactorParticipant referring to the EnvironmentalFactor named temperature.

<caption>Listing 5: EnvironmentalFactorParticipant instance.</caption>

EnvironmentalFactorParticipant temperature
weight 0.4 likelihood 0.7 confidence 0.8

Listing 6 represents an instance of SRPInputParticipant, DistanceToStop that refers to output SRP of another Influence.

<caption>Listing 6: SRPInputParticipant instance.</caption>

SRPInputParticipant DistanceToStop
weight 0.8 likelihood 0.7 confidence 0.8

The requirements that constrain SRPs can be de-
fined in structured text using Requirements. Listing
7 depicts the requirement ObstacleAvoidance.

<caption>Listing 7: Requirement instance.</caption>

Requirement ObstacleAvoidance
satisfied when "MarginCollision - 5 > 0" ,

An Influence combines participants (artifacts, environmental factors, input SRPs) via an InfluenceFunction to determine a single output SRP. The InfluenceFunction can be used to specify how the participants affect the SystemResponseProperty of an Influence. It carries a definition and return type. It can be specialized according to the needs and maturity of knowledge of developers. For instance, a function may be defined as a closed-form expression, rule-based description, or an informal text. In listing 8, it is depicted an influence with a function that captures a physics-based expression directly as ASCII math.

<caption>Listing 8: Influence instance.</caption>

Influence i1 #** "Braking distance model" #**
participants:
  ArtifactParticipant motorSpeed,
  ...
  EnvironmentalFactorParticipant dragCoefficient,
  influenceFunction "f1":
    definition "mass*motorSpeed^2 / ...
    *dragCoefficient*(motorSpeed)^2"
  returnType Real
  affects DistanceToStop,

The language and its metamodel are designed for
incremental knowledge description. Stakeholders can
declare what they know about the system influences,
and attach lightweight semantics if they have access
to them. Modelers may start with natural language ra-
tionales and progressively refine them with metadata
such as likelihood and changeability.

The models constructed with DEMISTIFYCPS be-
come actionable through Static Analysis. As we de-
tail in the next section, we compile influences into
a directed graph via a star-encoding, and exploit it
to realize structural and, when available, quantitative
analysis. These analyses inform developers, who can
improve their understanding of system behavior and
make better decisions in the following iterations dur-
ing the system design.

4 DEMISTIFYCPS-ENABLED
STATIC ANALYSIS

In this section, we detail how an Influence Model can
be exploited to perform static analysis that supports
decision-making. Our goal is to provide developers
with a systematic way to reason about influences. The
static analysis operates on the structure and metadata
of the Influence Model, assuming a well-formed and
minimal influence definition.

To perform our static analysis, we first transform
the Influence Model into a directed graph. Using this
representation, we can conduct structural analyses
that expose the paths linking participants to require-
ments, revealing how changes may propagate through
the system. Furthermore, when the influence function
is defined as mathematical equations, we assess how
changes in the participants may be prejudicial or ben-
eficial to requirement satisfaction.

4.1 Graph Transformation

Conceptually, an Influence connects a set of partic-
ipants (Design Artifacts *D*<sub>*I*</sub>, Environmental factors
*Φ*<sub>*I*</sub>, and, optionally, input SRPs) to a single output
SRP *srp*<sub>*I*</sub>. Our tooling compiles every model into a
graph using a *star-encoding*, which represents every
Influence instance as a central node connected to its
participants. For every influence *I* with participants
*D*<sub>*I*</sub> ∪ *Φ*<sub>*I*</sub> ∪ *S*<sub>*R*</sub>*P*<sub>*I*</sub><sup>in</sup>, the tooling produces one arc from
each participant to the central node *I*. From each node
*I*, a single arc is connected to *srp*<sub>*I*</sub>. System Response
Property is linked to Requirements, according to each
association *constrainedBy* in the model.

The transformation runs over the EMF Resource
that stores the Influence Model. The graph is avail-
able in Eclipse based on the KIELER Lightweight Di-
agrams (Schneider et al., 2013), and can be exported
in DOT format.

4.2 Traceability and Impact Analyses

The goal of traceability and impact analyses is to pro-
vide explanations by following the graph representa-
tion. From each participant, traceability is realized by
traversing the arcs from the participant through an In-
fluence central node to its produced SRP (*p* → *I* →
*srp*<sub>*I*</sub>), and possibly continues from the SRP through
the influences it participates in (S<sub>*R*</sub>*P*<sub>*I*</sub><sup>in</sup> ∈ *p* → *I*). Re-
quirements that may be affected by the change are ob-
tained by the link recorded in the graph (*srp*<sub>*I*</sub> → *R*).
The traversal keeps a map so that the tool can report
*p* → *I* → *srp*<sub>*I*</sub> → *R* explanations.
To quantify impact, we first report a direct measure. For each participant $p \in D_I \cup \Phi_I \cup SRP$, we analyze its direct impact as a single adjacency lookup, providing the number of influence instances that directly list $p$ as a participant. We then report the propagation of the impact, obtained by a multi-hop breadth-first search using the number of outEdges[u] (i.e., all nodes v such that $u \to v$) reachable by each participant $p$, counting the distinct influences it encounters in the path.

When the model provides participants metadata, the tool can be extended to include the calculation of the weighted impact, according to the developer's definition (i.e., likelihood, confidence, weight).

High impact metrics indicate that participants need to be carefully analyzed, since their change may need different tuning according to each influence, or it may provoke trade-offs (i.e., the change of a design artifact may be beneficial to a requirement satisfaction, and prejudicial to another).

A high impact of Environmental Factors indicates that they require particular attention, as they often represent environmental conditions that systematically challenge requirement satisfaction. Moreover, it could also mean that the requirements need to be redesigned to accommodate the conditions of system operation more accurately.

## 4.3 Analysis of Participants on Requirement Satisfaction

We conduct requirement analysis to determine which participants can affect each requirement and whether changing a participant would be beneficial or prejudicial to its satisfaction. The tooling supports two complementary analyses, adapting according to the Influence definition.

When an Influence is specified with only textual descriptions, we perform a **structural requirement analysis**. Given a Requirement *R*, the tool collects the set of SRPs that it constrains, traverses upstream chained influences until it reaches all participants that ultimately impact *R*. Optionally, the returned set of participants can be ranked according to *changeability* and *flexibility*. *Changeability* reflects configuration agility, cost or time, and the expected risk, according to the domain. *Flexibility* expresses the feasibility of change and how adjustable the environmental factor is. The objective is to provide developers with a list of possible design changes (on the participants) ranked based on these two metadata attributes.

When the influence definition comes with an evaluable Influence Function, it is possible to real-

ize a **quantifiable requirement analysis**, quantifying requirement satisfaction and effects of participant changes.

Considering an Influence that exposes an Influence Function:

$$ srp_I = f_I(\mathbf{z}) \quad \text{with} \quad \mathbf{z} = (z_1, \dots, z_n), \quad (1) $$

where $z$ are the values of the participants (artifacts, environmental factors, and input SRPs) and $srp_I$ is the influence's output System Response Property (SRP).

Participants' values $z$ are provided by the concrete assignment of numeric values to the participants required to evaluate $f_I$. These values come from the system models and environment settings. A scenario serves as the baseline $\mathbf{z}$ for analysis.

Each Requirement *R* constraining this SRP is represented by a satisfaction margin $M_R: \mathbb{R} \to \mathbb{R}$ s.t. $M_R(s) \ge 0$ means “*R* satisfied at *s*” and $M_R(s) < 0$ means “violated”. For a “$\le$” threshold $\tau$ we use $M_R(s) = \tau - s$; for a “$\ge$” threshold $\tau$ we use $M_R(s) = s - \tau$.

The local effect of varying a participant $z_k$ on *R* at the operating point $\mathbf{z}^*$ is given by partial derivative:

$$ S_k := \left. \frac{\partial \mathcal{M}_R}{\partial z_k} \right|_{\mathbf{z}^*} = \underbrace{M'_R(f_I(\mathbf{z}^*))}_{\text{req. slope at srp}_I} \cdot \underbrace{\frac{\partial f_I}{\partial z_k}}_{\text{sensitivity of SRP}} \cdot \left. \frac{\partial f_I}{\partial z_k} \right|_{\mathbf{z}^*} \quad (2) $$

For the common “$\le \tau$” case ($M_R(s) = \tau - s$) we have $M'_R(s) = -1$, hence

$$ S_k = - \left. \frac{\partial f_I}{\partial z_k} \right|_{\mathbf{z}^*} \quad (3) $$

We evaluate whether the sign of the partial derivative is positive or negative with respect to the variable of interest. We classify each participant value $z_k$ according to the sign of $S_k$: if $S_k < 0$, it prejudices; $S_k > 0$ it benefits requirement satisfaction.

In the tooling, an evaluator compiles the expression defined in $f_I$. It resolves the numeric values for the external design EObjects and for environmental factors directly stored in the Influence Model.

Next, the tool extracts the attribute “satisfied when” into a margin expression. Inequalities are parsed as a satisfaction margin (e.g., $s \le \tau$ becomes $M(\cdot) = \tau - s$, $s \ge \tau$ becomes $M(\cdot) = s - \tau$). The tooling evaluates *M* by composing any SRP symbols that appear and substituting scalar values of participants, as extracted from the system models and Influence Model. This procedure produces an SRP value, a margin *M*, and a map of sensitivities $\nabla M$, labels for the change actions (e.g., when increasing participant's numeric values, “prejudices / benefits” satisfaction of requirement); and a textual trace of the computation for explainability.
<figure><img src="image_3.png" /><figcaption>Figure 3: Graph presenting two influences identified in CPS development using KIELER Lightweight Diagrams.</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>Figure 4: Feedback in the influence model editor.</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>Figure 5: Feedback on referenced SysML artifact.</figcaption></figure>

As future work, when ranges or multiple scenarios are provided for participants, the evaluator could sweep those ranges and provide the validity region {$z | M_R(z) \ge 0$}, i.e., where requirement *R* remains satisfied. In the current implementation, we evaluate for single point values.

Together, these analyses provide the developers with structural insight, indicating who can impact a requirement and how feasible it is to change it; and quantitative evidence, how a change in the participants' values would move the requirement closer or away from satisfaction.

## 4.4 Design Coordination Feedback

Our solution also issues design-time coordination notifications (e.g., Info/Warning/Error). This provides feedback to developers directly within their editing environment, helping them understand change impacts and make informed decisions as they edit their models. This includes: (i) the number of Influences the same design artifact participates in (information markers both on the Influence and on the external artifact); and (ii) the number of Influences an SRP participates in a trace to its linked requirements.

# 5 CASE STUDY: MOBILE ROBOT

In this section, we demonstrate the usage of both DEMISTIFYCPS and our static analysis support on a case study. We introduce a small, yet sufficiently representative, example of a Cherokee 4WD Arduino mobile robot<fnref n="2" />.

The system must satisfy the following requirements: (i) RQ1: Efficient exploration, the robot should explore the environment avoiding unnecessary maneuvers; (ii) RQ2: Obstacle avoidance, the robot should detect obstacles and avoid them within a detection threshold.

It is equipped with two gearbox-equipped DC motors via a RoMeo V1 board, and an ultrasonic sensor with a rotary servo that scans the environment to detect obstacles. It operates two types of scanning: (i) Dynamic Detection, while the robot is moving, and (ii) Static Detection, when the robot is fully stopped to obtain more accurate distance estimates to select avoidance maneuvers.

We have developed SysML v2 models specifying the behavior and structure of the robot, using activity models and part definitions. We detail the influences we have found during the development of the use case in the repository³. We proceed by detailing how they are transformed and exploited using DEMISTIFYCPS.

As a first step, the transformation of the model towards a graph was executed. A partial graph representation is depicted in Figure 3, showing two of the influences detailed in this section, while the others were omitted for space reasons.

The results of the **impact** analysis show that artifacts such as mass and motorSpeed appear in two influences directly, but indirectly, they appear in eight influences. This reveals cascading effects, and high-

<footnote n="2">²Available at https://wiki.dfrobot.com
³https://github.com/barbara-da-silva-oliveira/DemistifyCPS/tree/main/Examples</footnote>
lights the importance of understanding how partici-
pants' changes propagate across influences, and of
evaluating the impacts on satisfaction of the associ-
ated requirements.

Among environmental factors, temperature ap-
pears most often as a participant, appearing di-
rectly in three influences, followed by others such as
friction, and indirectly, each appears in eight in-
fluences. This suggests that the system design must
explicitly account for these operating conditions, or it
may be necessary to revise the operational context.

From the quantifiable requirement analysis of ObstacleAvoidance, we computed the effects of changing the participants’ values. According to the results, increasing motorSpeed results in S<sub>motorSpeed</sub> < 0, therefore it prejudices the satisfaction of the requirement, while increasing friction results in S<sub>μ</sub> > 0 and it is beneficial to the satisfaction of the requirement. Complementing these results with structural requirement analysis, we rank the feasible changes by their declared ease of change. It indicates that detectionThreshold (changeability 0.90) and the environmental factor friction μ (flexibility 0.70) are among the most actionable participants. Together, these results suggest that developers prioritize raising detectionThreshold and, where feasible, friction μ.

In addition to these analysis results, actionable
feedback was provided to developers. Figure 4 de-
picts feedback appearing directly in the influence
model editor, while in Figure 5, the feedback ap-
pears directly in the SysML model the developers are
working on. The developer immediately sees which
changes could propagate, and under which condi-
tions.

The case study demonstrates how developers ben-
efit from the expression and analysis of Influences us-
ing DEMISTIFYCPS. These results support decision-
making by revealing where coordination risks con-
centrate, identifying the most influential participants,
and indicating which participants require attention
when they are updated.

6 CONCLUSIONS

In this paper, we have introduced the modeling of
Influences using DEMISTIFYCPS, a domain-specific
language that makes *Influence* a first-class relation.
The concept turns environment-mediated couplings
among CPS artifacts into explicit models with de-
fined participants, affected system response proper-
ties, and related requirements. We have provided an
early prototype of the analysis tooling, transforming

these models into encoded graphs for structural analy-
sis, and, when available, also performing quantitative
analysis on requirement satisfaction. We have used
DEMISTIFYCPS in a case study, which demonstrated
how Influence can be applied to improve decision-
making in CPS development. Future work will ex-
pand the evaluation of our work, providing larger use
cases for validation, and enrich and exploit Influence
semantics for deeper analysis.

REFERENCES

Akbarzadeh, A. and Katsikas, S. (2021). Identifying and Analyzing Dependencies in and among Complex Cyber Physical Systems. *Sensors*, 21(5):1685. Number: 5 Publisher: Multidisciplinary Digital Publishing Institute.

Bandyszak, T., Daun, M., Tenbergen, B., Kuhs, P., Wolf, S., and Weyer, T. (2020). Orthogonal uncertainty modeling in the engineering of cyber-physical systems. *IEEE Transactions on Automation Science and Engineering*, 17(3):1250–1265.

Carreira, P., Amaral, V., and Vangheluwe, H. (2020). Multi-paradigm modelling for cyber-physical systems: foundations. In *Foundations of multi-paradigm modelling for cyber-physical systems*, pages 1–14. Springer.

da Silva Oliveira, B., Ferry, N., and Deantoni, J. (2024). Towards leveraging the concept of influence to enhance collaborative cyber-physical systems development. In *Proceedings of the ACM/IEEE 27th International Conference on Model Driven Engineering Languages and Systems*, pages 935–944.

Daun, M. and Tenbergen, B. (2023). Context modeling for cyber-physical systems. *Journal of Software: Evolution and Process*, 35(7):e2451.

Hoffmann, H. (2006). Sysml-based systems engineering us-
ing a model-driven development approach. *INCOSE
International Symposium*, 16.

Klare, H., Kramer, M. E., Langhammer, M., Werle, D., Burger, E., and Reussner, R. (2021). Enabling consistency in view-based system development—the vitruvius approach. *Journal of Systems and Software*, 171:110815.

Koh, E. C., Caldwell, N. H., and Clarkson, P. J. (2013). A technique to assess the changeability of complex engineering systems. *Journal of Engineering Design*, 24(7):477–498.

Madni, A. and Sievers, M. (2018). Model-based systems engineering: Motivation, current status, and research opportunities. *Systems Engineering*, 21:172 – 190.

Roedler, G. J. and Jones, C. (2005). Technical Measurement. A Collaborative Project of PSM, INCOSE, and Industry. Technical report, Defense Technical Information Center, Fort Belvoir, VA.

Schneider, C., Spönemann, M., and von Hanxleden, R. (2013). Just model! - putting automatic synthesis of node-link-diagrams into practice. In *2013 IEEE Symposium on Visual Languages and Human Centric Computing*, pages 75–82.