Combining SysML V2 and BIP to Model and Verify CPS Interactions
Adel Khelifati
1 a
, Ahmed Hammad
2 b
and Malika Boukala-Ioualalen
1 c
1
Faculty of Computer Science, USTHB University, Algiers, Algeria
2
FEMTO-ST Institute, UMR CNRS 6174, Besanc¸on, France
Keywords:
SysML v2, BIP, Interaction Modeling.
Abstract:
Cyber-physical systems (CPS) require precise interaction modeling and rigorous verification to guarantee
reliability and correctness, particularly in safety-critical systems, where interaction errors such as deadlocks
may lead to critical failures. Although SysML v2 provides expressive modeling capabilities, it lacks explicit
execution semantics for structured interactions. To address this limitation, we propose a structured subset of
SysML v2 to specify interactions at the structural level. These interactions are then mapped to the Behavior,
Interaction, Priority (BIP) framework, which defines their execution semantics and enables formal analysis.
Specifically, we introduce Rendez-vous and Broadcast connectors to enforce synchronization and one-to-many
communication, respectively, ensuring that interactions are explicitly represented and amenable to formal
analysis. BIP provides precise execution semantics, facilitating rigorous verification and streamlining the
process by eliminating the need for external verification models. We validate our approach through a case
study on swarm drone coordination, demonstrating structured execution, the ability to detect and resolve
critical deadlocks, and the correctness and robustness of interactions.
1 INTRODUCTION
Cyber-physical systems (CPS) integrate computa-
tional and physical processes, requiring precise mod-
eling and rigorous verification to ensure reliability
and correctness. These systems consist of multiple
interacting components that must coordinate execu-
tion through synchronous and asynchronous interac-
tions. Failures in coordination can lead to dead-
locks or unexpected behaviors, especially in safety-
critical applications such as autonomous vehicles,
aerospace, and industrial automation. Ensuring inter-
action correctness demands formal verification tech-
niques that guarantee safety, liveness, and deadlock
freedom (Graja et al., 2020).
The Systems Modeling Language (SysML) (Object
Management Group (OMG), 2012) provides a struc-
tured framework for CPS modeling across different
abstraction levels. The recent evolution of SysML
into SysML v2 (Object Management Group (OMG),
2024) introduces significant enhancements in terms of
precision, expressiveness, modularity, and the flexi-
bility of its graphical and textual representations, aim-
a
https://orcid.org/0009-0006-4522-8123
b
https://orcid.org/0000-0003-3739-1650
c
https://orcid.org/0000-0002-8713-4997
ing to address the growing complexity of modern
CPS design (Friedenthal, 2023). However, SysML
v2 lacks the execution semantics necessary to specify
and analyze structured interactions formally. In par-
ticular, it does not natively support synchronization
and communication mechanisms, which are essential
for modeling the coordinated execution of CPS com-
ponents.
Among the formal languages specialized in inter-
action verification, the Behavior, Interaction, Priority
(BIP) framework (Basu et al., 2006) provides a strong
semantic foundation for modeling, composing, and
analyzing component interactions. However, BIP is
not designed as a system-level modeling language and
lacks support for high-level features such as multi-
view modeling, requirement traceability, standardized
graphical notation, and MBSE tool integration.
Conversely, SysML v2 excels in these areas, offer-
ing a rich modeling environment for system structure,
requirements, and multi-view architecture, but it does
not define execution semantics for interactions.
To bridge this gap, we propose a combined
approach that leverages both strengths. Our method
uses a dedicated subset of constructs to define
the interactions structurally within SysML v2. It
transforms the resulting model into BIP, where the
400
Khelifati, A., Hammad, A. and Boukala-Ioualalen, M.
Combining SysML V2 and BIP to Model and Verify CPS Interactions.
DOI: 10.5220/0013645700003964
In Proceedings of the 20th International Conference on Software Technologies (ICSOFT 2025), pages 400-409
ISBN: 978-989-758-757-3; ISSN: 2184-2833
Copyright © 2025 by Paper published under CC license (CC BY-NC-ND 4.0)

execution semantics of these interactions are formally
defined. This enables the generation of executable
models, facilitating rigorous verification while main-
taining compatibility with MBSE practices.
In summary, this paper makes the following con-
tributions:
• We define a structured subset of SysML v2
constructs, including explicit interaction mecha-
nisms, to precisely model synchronous and asyn-
chronous interactions in CPS.
• We introduce a systematic transformation process
to map SysML v2 models to the Behavior, Inter-
action, Priority (BIP) framework, ensuring pre-
cise execution semantics and enabling verification
without intermediate steps.
• We validate the effectiveness and applicability
of our proposed approach through a detailed
case study involving swarm drone coordination,
demonstrating the detection and resolution of ex-
ecution issues such as potential deadlocks.
The remainder of this paper is structured as fol-
lows. Section 2 reviews related work and highlights
the limitations of existing methods. Section 3 presents
the necessary background on SysML v2 and BIP. Sec-
tion 4 describes our structured interaction modeling
approach. Section 5 elaborates on the systematic
transformation process from SysML v2 to BIP, high-
lighting its verification capabilities. Section 6 illus-
trates our approach through a case study on swarm
drone coordination. Finally, Section 7 summarizes
our contributions and outlines future research direc-
tions.
2 RELATED WORK
Ensuring the correctness of the SysML model has
been a long-standing challenge. Given that SysML
does not provide execution semantics, several studies
have investigated integrating SysML with formal ver-
ification tools to enable rigorous system analysis. The
work of (Moln
´
ar et al., 2024) explores the feasibility
of linking SysML v2 models with verification tech-
niques. However, while these approaches improve the
validation of system properties, they lack support for
explicit execution semantics of interactions, particu-
larly mechanisms such as multi-component synchro-
nization and prioritized communication.
One significant effort in integrating SysML with
BIP was the work of (Nussbaumer and Kieliger,
2017), which developed a bidirectional transforma-
tion between SysML v1 and BIP for visualization and
editing. This method allowed BIP models to be repre-
sented within SysML using custom UML profiles and
stereotypes. However, this work primarily focused
on structural mappings rather than execution seman-
tics, meaning that key interaction mechanisms such as
broadcast or rendez-vous were not explicitly modeled
within SysML. Additionally, this approach was based
on SysML v1, which lacks the enhanced expressive-
ness and formal semantics introduced in SysML v2.
Although transformation efforts aim to enable for-
mal execution semantics, other research has focused
on verifying the structural consistency of interactions
in SysML models. The work of (Khelifati et al., ) ver-
ifies the static semantic of SysML interactions within
Internal Block Diagrams (IBDs). This approach en-
sures that SysML models conform to well-defined
structural constraints, preventing issues such as mis-
connected ports or inconsistent interfaces. However,
static verification alone does not analyze how interac-
tions dynamically evolve during execution. Our ap-
proach bridges this gap by mapping SysML v2 mod-
els to a formally executable framework like BIP.
Another line of research has explored constraint-
based verification to specify and analyze interactions
in SysML. The work of (Tannoury et al., 2022a) intro-
duces SysReo, which combines SysML with Reo and
OCL to define and verify system interactions using
constraint automata. An extension of this approach is
presented by (Tannoury et al., 2022b), where SysM-
L/MARTE is used to model real-time constraints,
making it particularly suitable for automotive CPS. In
contrast to Reo, BIP offers a more comprehensive for-
mal framework that supports compositional modeling
and direct execution semantics, eliminating the need
for automata-based translations and external formal
encodings.
Beyond SysML-based approaches, research has
also explored the relationship between BIP and Reo
as coordination models for system interactions. The
work of (Dokter et al., 2015) establishes a formal
mapping from BIP (without priority) to Reo, demon-
strating how constraint-based verification techniques
can be applied to BIP models. This transformation
allows for reasoning about BIP interactions within
Reo’s formal framework. However, this approach
does not leverage system-level modeling languages
such as SysML.
In contrast to these approaches, we propose a
method that defines a structured subset of SysML v2
constructs to model structured interactions explicitly.
By mapping these models into BIP, execution seman-
tics are introduced, enabling both formal execution
and verification. This integration ensures a seamless
transition from system-level modeling to executable
Combining SysML V2 and BIP to Model and Verify CPS Interactions
401

analysis without requiring additional transformation
steps or external model-checking frameworks.
3 BACKGROUND
This section introduces the fundamental elements of
SysML v2 and BIP relevant to our approach. We fo-
cus only on the constructs required to define struc-
tured interactions and facilitate their transformation
into a formal verification framework.
3.1 SysML v2: Essential Constructs for
Interaction Modeling
SysML v2 provides a structured framework for mod-
eling Cyber-Physical Systems, offering improved
modularity, richer semantics, and textual representa-
tions. It defines key constructs for specifying system
components, their interactions, and behaviors, includ-
ing:
Port Definition (port def). Define interaction
points between system components, specifying data
flow and communication constraints. Listing 1 de-
fines a SysML v2 port as an interaction point between
system components.
Listing 1: Example of a Port Definition in SysML v2.
port def C om man dP or t {
in r ec eiv ed Com ma nd : S tr in g ;}
Part Definition (part def). Represent a system
component, encapsulating ports and internal behavior.
Listing 2 represents a reusable component type that
exposes interaction ports.
Listing 2: Example of a Part Definition in SysML v2.
part def C on troll er {
port comma nd In : C om ma ndP or t ;}
State Definition (state def). Capture the dif-
ferent operational modes of a component. They in-
clude a set of states and transitions that describe how
the component evolves over time, as illustrated in
Listing 3.
Listing 3: Example of a State Definition in SysML v2.
state def C ont ro l le rSt at es {
state Idl e ; state A ct iv e ;
transition I dl e_ t o_ Ac t iv e
first Idl e
accept r ec eiv ed Com ma nd via co mm andIn
then Ac ti ve ;}
Connections (connection def). Define inter-
actions between components. Listing 4 presents an
example of a connection def in SysML v2
Listing 4: Example of a Connection in SysML v2.
connection def S ync hr oni za t io n {
end con tr ol le r : Co mma nd Po rt ;
end ac tuator : C omm an dP ort ;
flow con tr ol le r . r ec eiv ed Com ma nd
to ac tuator . re ce i ve dC o mm and ;}
3.2 BIP: A Framework for Interaction
and Formal Verification
The Behavior, Interaction, Priority (BIP) framework
provides a rigorous component-based approach to
model and verify CPS. It introduces three main lay-
ers: Behavior, Interaction, and Priority, each serving
a distinct role in defining system execution semantics.
Behavior (Atomic Components). The Behavior
layer encapsulates the state-based dynamics of the
components using atomic components, or atoms.
Each atom defines internal states and transitions be-
tween them. Listing 5 illustrates an example of a BIP
atomic component that models a simple Controller
with two states, Idle and Active, and a transition trig-
gered by receiving a command.
Listing 5: Example of an Atomic Component in BIP.
atom type C on troll er () {
export port C omm an dP o rt _t comm an dI n ;
place Idle , A ct iv e ;
initial to Id le ;
on comma nd In from Idle to A ctive do {
printf(" Co ntr ol le r a ct iv at ed .\ n " ) ;}}
Interaction (Connectors) Connectors define syn-
chronization and communication between multiple
components. In BIP, connectors specify how com-
ponents interact by enabling or enforcing simultane-
ous execution of multiple ports. Listing 6 shows a
Rendez-vous connector, which ensures that two com-
ponents (c and a) are executed synchronously
Listing 6: Example of a Rendez-vous Connector in BIP.
connector type S ync hr oni za t io n (
Com ma nd Por t_ t c , Co mm a nd Po rt_ t a ) {
define c a ;}
ICSOFT 2025 - 20th International Conference on Software Technologies
402

In contrast, a Broadcast connector allows one
component to communicate with multiple receivers
without requiring them to be available simultane-
ously. In BIP, an apostrophe ( ’ ) after a port name
in the ‘define‘ statement specifies that the port is a
trigger, meaning that its activation initiates the inter-
action. Listing 7 illustrates an example of a Broadcast
connector.
Listing 7: Example of a Broadcast Connector in BIP.
connector type B ro ad cast (
Bro ad cas tP ort _t s ender ,
Com ma nd Por t_ t rec1 , Com ma nd P or t_ t
rec2 , C om man dP ort _t r ec3 ) {
define send er ’ re c1 re c2 rec3 ;
on se nd er re c1 re c2 rec3 down {
rec1 . co mma nd Sig na l = se nd er .
com ma nd Sig na l ;
rec2 . co mma nd Sig na l = se nd er .
com ma nd Sig na l ;
rec3 . co mma nd Sig na l = se nd er .
com ma nd Sig na l ;}
on se nd er r ec ei ver1 down {
rec1 . co mma nd Sig na l = se nd er .
com ma nd Sig na l ;}}
In this example, the apostrophe ( ’ ) after ‘sender‘
in the ‘define‘ statement indicates that ‘sender‘ is the
trigger, meaning that its activation initiates the in-
teraction. The ‘down‘ statement ensures that when
‘sender‘ is activated, its command signal is propa-
gated to all receivers, allowing them to receive the
message simultaneously.
Priority. The Priority layer allows specifying ex-
ecution order between interactions when multiple
are possible, ensuring deterministic system behavior.
However, this paper does not focus on priority mech-
anisms.
The next section presents our approach for defin-
ing structured interactions in SysML v2 and mapping
them to BIP.
4 PROPOSED APPROACH
SysML v2 models the structural architecture of
Cyber-Physical Systems (CPS) using components,
ports, and their connections. Interactions are spec-
ified via connection definitions, with semantics in-
ferred from structure. However, it lacks execution se-
mantics, limiting its ability to analyze dynamic be-
haviors like synchronization or asynchronous com-
munication.
To address this, we define a subset of SysML
v2 constructs—port, part, state, and connection
definitions—for modeling structured interactions.
These models are then transformed into BIP, where
connectors define formal execution semantics. This
enables verification while preserving SysML model-
ing conventions.
We focus on two interaction types: Rendez-vous
for strict synchronization, and Broadcast for one-to-
many communication.
Rendez-vous interactions model strict synchro-
nization between multiple components, requiring all
participants to reach a common execution point be-
fore proceeding. In our approach, this type of interac-
tion is first specified structurally in SysML v2 using
a connection definition that links multiple ports, as
shown in Listing 8.
Listing 8: Rendez-vous Interaction in SysML v2.
connection def R en dezVo us {
end p1 : SyncPo rt ;
end p2 : SyncPo rt ;
end p3 : SyncPo rt ;}
This structural specification is then mapped to a
BIP connector that enforces the same synchronization
semantics at execution time. The equivalent BIP def-
inition is shown in Listing 9, where all involved ports
must participate for the interaction to be executed.
Listing 9: Rendez-vous Connector in BIP.
connector type R en dezVo us ( S yn cPo rt _t
p1 , Sy nc Por t_ t p2 , S yn cP or t_t p3 )
{
define p1 p2 p3; }
Broadcast interactions represent asynchronous
one-to-many communication, where a sender trans-
mits information to multiple receivers, not all of
which are required to participate simultaneously. In
our approach, such interactions are first modeled
structurally in SysML v2 using a connection defini-
tion with optional constraints on participant readiness.
A basic example is shown in Listing 10.
Listing 10: Broadcast Interaction in SysML v2.
connection def B ro ad cast {
end se nd er : Bro ad cas tP ort ;
end recei ve r1 : C om ma ndP or t ;
end recei ve r2 : C om ma ndP or t ;
end recei ve r3 : C om ma ndP or t ;
constraint { sen de r . is Re ady }
flow se nd er . Si gn al to r ec eiver 1 .
Si gn al ;
flow se nd er . Si gn al to r ec eiver 2 .
Si gn al ;
flow se nd er . Si gn al to r ec eiver 3 .
Si gn al ;}
This specification is mapped into a BIP connector
Combining SysML V2 and BIP to Model and Verify CPS Interactions
403

where the sender acts as a trigger, initiating the inter-
action. The BIP equivalent is presented in Listing 11,
where all receivers participate when available.
Listing 11: Broadcast Connector in BIP.
connector type B ro ad cast (
Bro ad cas tP ort _t s ender ,
Com ma nd Por t_ t re ceive r1 ,
Com ma nd Por t_ t re ceive r2 ,
Com ma nd Por t_ t r ec ei ve r3 ) {
define send er ’ r ec ei ve r1 re ce iv er2
re ceiver3 ;
on se nd er r ec ei ver1 re ce iver2
re ceiver3 down {
re ceiver1 . Sign al = send er .
Si gn al ;
re ceiver2 . Sign al = send er .
Si gn al ;
re ceiver3 . Sign al = send er .
Si gn al ;}}
In more complex scenarios, broadcast interactions
in SysML v2 may include multiple constraints, each
specifying a valid subset of receivers based on readi-
ness conditions. Listing 12 illustrates this case.
Listing 12: Broadcast Interaction with multiple Constraints
in SysML v2.
connection def B ro ad cast {
end se nd er : Bro ad cas tP ort ;
end recei ve r1 : C om ma ndP or t ;
end recei ve r2 : C om ma ndP or t ;
constraint { sen de r . is Re ady and
re ceiver1 . isReady and
re ceiver2 . isReady }
flow se nd er . Si gn al to r ec eiver 1 .
Si gn al ;
flow se nd er . Si gn al to r ec eiver 2 .
Si gn al ;
constraint { sen de r . is Re ady and
re ceiver1 . isReady }
flow se nd er . Si gn al to r ec eiver 1 .
Si gn al ;
constraint { sen de r . is Re ady and
re ceiver2 . isReady }
flow se nd er . Si gn al to r ec eiver 2 .
Si gn al ;
}
These alternative conditions are translated into
BIP as conditional interaction patterns using on state-
ments, ensuring structured execution based on dy-
namic availability, as shown in Listing 13.
Listing 13: Broadcast Connector with Multiple Constraints
in BIP.
connector type B ro ad cast (
Bro ad cas tP ort _t s ender ,
Com ma nd Por t_ t re ceive r1 ,
Com ma nd Por t_ t r ec ei ve r2 ) {
define send er ’ r ec ei ve r1 re ce iv er2 ;
on se nd er r ec ei ver1 re ce iver2 down {
re ceiver1 . Sign al = send er . Signal ;
re ceiver2 . Sign al = send er . Signal ;}
on se nd er r ec ei ver1 down {
re ceiver1 . Sign al = send er . Signal ;}
on se nd er r ec ei ver2 down {
re ceiver2 . Sign al = send er . Signal
;}}
This mapping from structural constraints in
SysML v2 to conditional interactions in BIP pre-
serves the intended communication flexibility while
enabling formal execution semantics. The next sec-
tion elaborates the transformation workflow that sup-
ports this mapping.
5 MODEL TRANSFORMATION
FROM SysML v2 TO BIP
We map structured SysML v2 constructs to their
BIP equivalents to enable formal verification. This
transformation connects system-level modeling to ex-
ecutable semantics while preserving the structure and
behavior of interactions. It supports both synchronous
and asynchronous patterns and provides a foundation
for rigorous analysis.
The transformation consists of three stages: ex-
tracting SysML v2 elements (ports, parts, states, con-
nections), applying rule-based mappings, and gener-
ating an executable BIP model. Algorithm 1 summa-
rizes the structural, behavioral, and interaction map-
pings.
Ports are translated into BIP port types, while
components with internal states become BIP atoms
composed of places and transitions. If multiple tran-
sitions share the same source and target states, they
are merged using conditional guards to preserve be-
havioral distinctions.
Connections are mapped to BIP connectors, with
the trigger port identified by an apostrophe (’). Con-
straints are converted into on conditions, and flow
statements into down blocks to manage data propa-
gation and enforce synchronization semantics.
Though currently manual, the transformation pro-
cess lays a foundation for automation, thanks to the
structured and semantically precise nature of SysML
v2. The SysML v2 API enables systematic extrac-
tion of model elements (parts, ports, states), allowing
transformation rules to be applied programmatically.
Integrated with BIP toolchains, this would support the
automatic generation of executable BIP models.
Such automation enhances scalability and reduces
modeling effort while preserving correctness and
traceability. It also strengthens the link between high-
ICSOFT 2025 - 20th International Conference on Software Technologies
404

Algorithm 1: Transformation from SysML v2 to BIP.
Require: SysML v2 model M
SysML
Ensure: Equivalent BIP model M
BIP
1: Parse M
SysML
to extract essential elements:
2: Identify all port def, part def, state def, and
connection def
3: Extract transitions from state def
4: Identify constraints and their associated flow state-
ments
5: Initialize an empty BIP model M
BIP
6: for each port def in M
SysML
do
7: Map to a BIP port type with corresponding at-
tributes
8: Add the mapped BIP port type to M
BIP
9: end for
10: for each part def containing a state def do
11: Create a BIP atom type corresponding to the
SysML part
12: for each state def in the part do
13: for each state in the state def do
14: Create a BIP place representing the state
15: end for
16: Convert transitions into BIP transitions
17: end for
18: Add the BIP atom type to M
BIP
19: end for
20: for each connection def in M
SysML
do
21: Create a BIP connector type with the corre-
sponding ports
22: Identify the port that appears in all constraints and
designate it as the trigger port (apostrophe (’))
23: for each constraint in the connection do
24: Extract the constraint and translate it into a BIP
on condition
25: Identify the corresponding flow statements
26: Group the flow statements under the corre-
sponding on condition in the down section
27: end for
28: Add each constructed BIP connector type to
M
BIP
29: end for
30: Transform the System Composition
31: Identify the top-level part that contains other parts
32: Map it to a BIP compound type
33: Add each BIP compound type to M
BIP
34: for each contained part instance do
35: Add the corresponding BIP atom type to M
BIP
36: end for
37: for each connection def inside the system composi-
tion do
38: Add the corresponding BIP connector type to
M
BIP
39: end for
40: return M
BIP
level SysML v2 modeling and the formal execution
and verification capabilities of the BIP framework.
6 CASE STUDY: SWARM DRONE
COORDINATION WITH SysML
v2 AND BIP
Swarm drone coordination is an essential challenge
in autonomous flight systems, where multiple drones
must execute synchronized maneuvers while main-
taining strict communication and interaction con-
straints. This case study focuses on the formal mod-
eling and verification of a swarm drone system using
SysML v2 and BIP, ensuring correct coordination and
synchronization of drones.
The system consists of a command station that is-
sues flight commands and a swarm of three drones
that receive and execute the commands. Two inter-
action mechanisms govern communication: a broad-
cast mechanism, where the command station sends
commands to all drones simultaneously, and a rendez-
vous synchronization, where all drones synchronize
before resetting to their initial state.
6.1 SysML v2 Model
The swarm drone coordination system is modeled
in SysML v2, capturing the structure, behavior, and
interactions between the command station and the
drones. The model includes port definitions for com-
mand transmission and synchronization, part defini-
tions representing system components, state machines
defining operational states and transitions, connec-
tion definitions establishing interactions, and a sys-
tem composition assembling all components into the
Drone Swarm system. The complete textual speci-
fication of this SysML v2 model is presented in the
Listing 14.
Listing 14: Complete SysML v2 Model for Swarm Drone
Coordination.
package Dro ne Sw ar m {
private import S cal ar Va lue s ::*;
port def C om man dP or t {
in attribute c omm an dS i gn al :
St ri ng ;
attribute is Re ad y = t rue ;}
port def B roa dc as t Po rt {
out attribute c omm an dS i gn al :
St ri ng ;
attribute is Re ad y = t rue ;}
port def R end ez Vou sP ort { }
part def Dron e {
port comma nd In : C om ma ndP or t ;
port ren de zV ou s : Ren de zVo us Por t ;
attribute c om ma ndS ig nal : St ri ng ;
state def D ro neS ta te s {
en try ; then Id le ;
state Idl e ; state R eady ;
state Fl yi ng ; state Fo rmati on ;
Combining SysML V2 and BIP to Model and Verify CPS Interactions
405

transition ’ Idle - Ready ’
first Idl e accept si gn al :
St ri ng via c om ma nd In
then Re ady { com ma ndS ig na l = "
Re ady " ;}
transition ’ Ready - Fly ing ’
first Re ady
accept si gn al : St ri ng via
co mmandIn
then Fl yi ng { c om ma n dS ig nal = "
In Air " ;}
transition ’ Flying - For mat ion ’
first Fl yi ng
accept si gn al : St ri ng via
co mmandIn
then Forma ti on { c om m an dS ign al
= " In Fo rma ti on " ;}
transition ’ F ormat ion - Idle ’
first Forma ti on
accept si gn al : St ri ng via
re nde zV ou s
then Idl e ;} }
part def S tat io n De Com ma n de {
port s ta ti o nC om m an d :
Bro ad ca stP or t ;
state def S tat io nS t at es {
attribute ph ase : In te ge r = 0;
attribute co mpteur : I nt eg er =
0;
attribute maxCy cl es : Integer =
10;
state Ac ti ve ; state Sto p ;
en try ; then A ctive ;
transition ’ Active - Start ’
first Ac ti ve
accept Si gn al : St ri ng via
sta ti on C om ma n d
if ph ase == 0 and c ompteur <
ma xCycles
then Ac ti ve {
ph ase = 1;
co mp te ur = c om pt eu r + 1 ;}
transition ’ Active - T ake off ’
first Ac ti ve
accept Si gn al : St ri ng via
sta ti on C om ma n d
if ph ase == 1 and c ompteur <
ma xCycles
then Ac ti ve {
ph ase = 2;
co mp te ur = c om pt eu r + 1 ;}
transition ’ Active - For mat ion ’
first Ac ti ve
accept Si gn al : St ri ng via
sta ti on C om ma n d
if ph ase == 2 and c ompteur <
ma xCycles
then Ac ti ve {
ph ase = 0;
co mp te ur = c om pt eu r + 1; }
transition ’ Active - Stop ’
first Ac ti ve
if co mpteur >= m ax Cy cl es
then Sto p ; }}
connection def B ro ad cast {
end se nd er : Bro ad cas tP ort ;
end recei ve r1 : C om ma ndP or t ;
end recei ve r2 : C om ma ndP or t ;
end recei ve r3 : C om ma ndP or t ;
constraint{ send er . i sR ea dy and
re ceiver1 . isReady and
re ceiver2 . isReady and
re ceiver3 . isReady }
flow se nd er . c om man dS ig n al to
re ceiver1 . c om man dS ign al ;
flow se nd er . c om man dS ig n al to
re ceiver2 . c om man dS ign al ;
flow se nd er . c om man dS ig n al to
re ceiver3 . c om man dS ign al ;
constraint{ send er . i sR ea dy and
re ceiver1 . isReady }
flow se nd er . c om man dS ig n al to
re ceiver1 . c om man dS ign al ; }
connection def R en dezVo us {
end d1 : Re nd e zV ou s Po rt ;
end d2 : Re nd e zV ou s Po rt ;
end d3 : Re nd e zV ou s Po rt ; }
part Dro ne Sw ar m {
part st at io n : St a ti onD eC omm an d e ;
part d1 : D ro ne ;
part d2 : D ro ne ;
part d3 : D ro ne ;
connection l ea de rCo mm and :
Br oadcast c on ne ct ( station .
st at io nC om ma nd , d1 . c omman dIn ,
d2 . c omman dIn , d3 . comm an dI n ) ;
connection r en de z vo us S yn c :
Re nde zV ou s connect ( d1 .
re ndezV ous , d2 . re ndezV ous , d3.
re nde zV ou s ) ;} }
Figure 1 provides the complete assembly of the
swarm drone system components.
Figure 1: Swarm System Composition in SysML v2.
6.2 BIP Model
The BIP model for swarm drone coordination was
generated following the algorithm proposed in Sec-
tion 5. This transformation systematically maps
SysML v2 constructs into their BIP equivalents, en-
suring structural and behavioral consistency while
preserving interaction semantics. To enhance the
analysis of execution processes, additional trace mes-
sages were incorporated into the BIP model. These
messages allow us to observe the evolution of system
ICSOFT 2025 - 20th International Conference on Software Technologies
406

states. The complete BIP model representation of the
system is shown in Listing 15.
Listing 15: Complete BIP Model for Swarm Drone Coordi-
nation.
@cpp ( in cl ude = " stdi o . h")
package Dr on e1 1
ex te rn function printf(string, int)
port type C omm an dP o rt _t (string
com ma nd Sig na l )
port type B roa dc ast Po r t_ t (string
com ma nd Sig na l )
port type R end ez V ou sPo rt _t ()
atom type Dron e (int id)
data string c omm an dS i gn al
export port C omm an dP o rt _t
co mmandIn ( c om man dS ign al )
export port R end ez V ou sPo rt _t
re nde zV ou s ()
place Idle , Rea dy , Flying ,
Fo rmation
initial to Id le do {
com ma nd Sig na l = " " ;}
on comma nd In from Idle to Read y do
{
com ma nd Sig na l = " R ea dy " ;
printf(" Drone %d is Read y \ n", id
) ;}
on comma nd In from R eady to Fl yi ng
do {
com ma nd Sig na l = " I nA ir " ;
printf(" Drone %d is F lying \n" ,
id ) ;}
on comma nd In from F ly in g to
Fo rmation do {
com ma nd Sig na l = " In Fo rmati on ";
printf(" Drone %d is in F or ma tion
\n" , id ) ;}
on ren de zV ou s from F or ma ti on to
Idle do {
printf(" Drone %d re se ts fr om
Fo rmation to Idl e \ n" , id ) ;}
end
atom type S tat io n De Com ma n de ()
data string c omm an dS i gn al
data int phas e
data int c om pt eu r
data int m ax Cy cles
export port B roa dc ast Po r t_ t
bro ad cas tC o mm an d ( c om man dS ign al
)
place Acti ve , St op
initial to A ctive do {
ph ase = 0; c om pt eu r = 0;
ma xCycles = 4;
com ma nd Sig na l = " " ;}
on b ro adc as tCo mm a nd from A ct iv e to
Ac ti ve provided ( co mp te ur <
ma xCycles ) do {
if ( p ha se == 0) then
com ma nd Sig na l = " S ta rt " ; pha se
= 1;
else if ( phas e == 1) then
com ma nd Sig na l = " Takeoff " ;
ph ase = 2;
else if ( phas e == 2) then
com ma nd Sig na l = " Fo rm at io n
";
ph ase = 0;
fi fi fi
co mp te ur = c om pt eu r + 1;
printf(" St at io n : Sending % s
Co mm an d \ n " , com ma nd S ig na l );
}
internal from A ctive to Sto p
provided ( comp te ur >=
ma xCycles ) do {
printf(" St at io n : Max cycles
re ac he d . St op pi ng .\ n " , 0) ; }
end
connector type B ro ad cast (
Bro ad cas tP ort _t s ender ,
Com ma nd Por t_ t re ceive r1 ,
Com ma nd Por t_ t re ceive r2 ,
Com ma nd Por t_ t r ec ei ve r3 )
define send er ’ r ec ei ve r1 re ce iv er2
re ceiver3
on se nd er r ec ei ver1 re ce iver2
re ceiver3 down { recei ve r1 .
com ma nd Sig na l = se nder .
com ma nd Sig na l ;
re ceiver2 . c om man dS ign al = sender
. c omm an dSi gn al ;
re ceiver3 . c om man dS ign al = sender
. c omm an dSi gn al ; }
on se nd er r ec ei ver1 down {
re ceiver1 . c om man dS ign al = sender .
com ma nd Sig na l ;}
end
connector type R en dezVo us (
Ren de zVo us P or t_ t d1 ,
Ren de zVo us P or t_ t d2 ,
Ren de zVo us P or t_ t d3 )
define d1 d2 d3
end
compound type D ro neSwa rm ()
component S ta tio nD e Co mma nd e s ta ti on
()
component Dr one d1 (1)
component Dr one d2 (2)
component Dr one d3 (3)
connector Broad ca st lead er Com ma nd (
st at io n . br oa dc as tC om ma nd , d1 .
co mma ndIn , d2 . com man dIn , d3.
co mmandIn )
connector Ren de zV ou s r end ez vo u sS yn c
( d1 . r en dez Vo us , d2 . re nde zV ous ,
d3 . re nd ez Vo us )
end
end
Combining SysML V2 and BIP to Model and Verify CPS Interactions
407

6.3 Execution and Results
The BIP model was executed to validate the correct
operation of the swarm drone coordination system.
The execution trace, illustrated in Figure 2, demon-
strates interactions between the command station and
the drones, confirming structured command dissemi-
nation and synchronized execution. Initially, the com-
mand station successfully broadcasts a Start com-
mand, causing all drones to transition from Idle to
Ready. Subsequent commands systematically move
them through the Flying and Formation states, as
defined by the initial SysML v2 specification (List-
ing 14). When the drones reach the Formation state,
they synchronize through the rendez-vous connec-
tor, ensuring coordinated execution before resetting
to Idle. The broadcast connector facilitates simul-
taneous dissemination of commands, thus maintain-
ing synchronization and consistent transitions among
drones.
Figure 2: Execution trace of the BIP model showing drone
state transitions.
Despite these structured transitions, the initial ex-
ecution results indicated that after completing a pre-
defined number of cycles, the system entered an un-
intended deadlock state. Specifically, the deadlock
emerged in state #5, where the station reached its
stopping condition. Due to the absence of additional
valid transitions, the system reached a state in which
no further interactions were possible, resulting in a
deadlock.
To address and illustrate the potential resolution
of this deadlock, we modified the SysML model of
the command station by removing the stopping condi-
tion, thus enabling continuous cyclic operations. The
revised StationDeCommande SysML v2 specification
is presented in Listing 16. The BIP model generated
from this modified SysML v2 specification is corre-
spondingly presented in Listing 17.
Listing 16: Modified Command Station Definition in
SysML v2 (without stopping condition).
part def S tat io n De Com ma n de {
port s ta ti o nC om m an d : Bro ad cas tP or t ;
state def S tat io nS t at es {
attribute ph ase : In te ge r = 0;
state Ac ti ve ; en try ; then Active ;
transition ’ Active - Start ’
first Ac ti ve
accept Si gn al : St ri ng via
sta ti on C om ma n d
then Ac ti ve { ph ase = 1; }
transition ’ Active - T ake off ’
first Ac ti ve
accept Si gn al : St ri ng via
sta ti on C om ma n d
then Ac ti ve { ph ase = 2; }
transition ’ Active - For mat ion ’
first Ac ti ve
accept Si gn al : St ri ng via
sta ti on C om ma n d
then Ac ti ve { ph ase = 0;}}}
The resulting BIP model, presented in Listing 17,
eliminates the stopping condition of the command sta-
tion and ensures continuous operation, thus removing
the conditions that previously led to the deadlock.
Listing 17: Modified BIP Model for Continuous Execution.
atom type S tat io n De Com ma n de ()
data string c omm an dS i gn al
data int phas e
export port B roa dc ast Po r t_ t
bro ad cas tC o mm an d ( c om man dS ign al )
place Ac ti ve
initial to A ctive do { p hase = 0;
com ma nd Sig na l = " "; }
on b ro adc as tCo mm a nd from A ct iv e to
Ac ti ve do {
if ( p ha se == 0) then
com ma nd Sig na l = " S ta rt " ;
ICSOFT 2025 - 20th International Conference on Software Technologies
408

ph ase = 1;
else if ( phase == 1) then
com ma nd Sig na l = " Takeoff " ;
ph ase = 2;
else if ( phas e == 2) then
com ma nd Sig na l = " Fo rm at io n " ;
ph ase = 0; fi fi fi
printf(" St at io n : Sending % s
Co mm an d \ n " , com ma nd Sig na l );}
end
After executing this modified model, the deadlock
situation no longer arises. Instead, the system con-
tinuously cycles through the predefined states (Idle,
Ready, Flying, and Formation) without interrup-
tion, demonstrating the correctness and robustness
of the structured interactions modeled. This modifi-
cation highlights the flexibility and effectiveness of
our structured approach in diagnosing and resolving
interaction-related issues such as deadlocks.
7 CONCLUSION
This paper presented an approach for modeling struc-
tured interactions in Cyber-Physical Systems (CPS)
by defining a structured subset of SysML v2. This
subset introduces Rendez-vous and Broadcast con-
nectors to explicitly capture synchronous and asyn-
chronous interactions, enabling their transformation
into the Behavior, Interaction, Priority (BIP) frame-
work for formal execution and analysis.
The transformation process systematically maps
SysML v2 models into BIP while preserving struc-
tural integrity and interaction semantics. A case study
on swarm drone coordination validated the approach,
demonstrating its ability to model multi-agent inter-
actions and verify synchronization properties through
BIP-based execution. The results confirmed that the
method supports structured execution, enables the de-
tection and resolution of deadlocks, and ensures inter-
action correctness.
While effective, the current approach has certain
limitations. The transformation does not yet sup-
port all BIP constructs, such as hierarchical priori-
ties and composite connectors, and remains a manual
process that requires user intervention. Future work
will extend the transformation to support these ad-
vanced constructs, integrate time-aware interactions,
and automate the mapping through model-to-model
transformations. Furthermore, incorporating an incre-
mental verification strategy using tools like D-Finder
2 (Bensalem et al., 2011) could enable early detection
of inconsistencies. Enhancing automation, scalability,
and coverage will further consolidate the integration
of SysML v2 and BIP for robust CPS modeling and
formal verification.
REFERENCES
Basu, A., Bozga, M., and Sifakis, J. (2006). Modeling het-
erogeneous real-time components in bip. In Fourth
IEEE International Conference on Software Engineer-
ing and Formal Methods (SEFM’06), pages 3–12.
Ieee.
Bensalem, S., Griesmayer, A., Legay, A., Nguyen, T.-H.,
Sifakis, J., and Yan, R. (2011). D-finder 2: To-
wards efficient correctness of incremental design. In
Nasa Formal Methods Symposium, pages 453–458.
Springer.
Dokter, K., Jongmans, S.-S., Arbab, F., and Bliudze,
S. (2015). Relating bip and reo. arXiv preprint
arXiv:1508.04848.
Friedenthal, S. (2023). Future directions for mbse with
sysml v2. In MODELSWARD, pages 5–9.
Graja, I., Kallel, S., Guermouche, N., Cheikhrouhou, S.,
and Hadj Kacem, A. (2020). A comprehensive sur-
vey on modeling of cyber-physical systems. Con-
currency and Computation: Practice and Experience,
32(15):e4850.
Khelifati, A., Boukala-Ioualalen, M., and Hammad, A.
Construction of consistent sysml models applied to
the cps. ACM Journal on Emerging Technologies in
Computing Systems.
Moln
´
ar, V., Graics, B., V
¨
or
¨
os, A., Tonetta, S., Cristoforetti,
L., Kimberly, G., Dyer, P., Giammarco, K., Koethe,
M., Hester, J., et al. (2024). Towards the formal ver-
ification of sysml v2 models. In Proceedings of the
ACM/IEEE 27th International Conference on Model
Driven Engineering Languages and Systems, pages
1086–1095.
Nussbaumer, C. J. M. and Kieliger, L. (2017). Bidirectional
transformation between bip and sysml for visualisa-
tion and editing.
Object Management Group (OMG) (2012). OMG Systems
Modeling Language SysML. Technical report.
Object Management Group (OMG) (2024). Systems
Modeling Language (SysML) v2 Beta 2 Specifica-
tion: Language. https://www.omg.org/spec/SysML/2.
0/Beta2/Language/PDF. Accessed Mars 2025.
Tannoury, P., Chouali, S., and Hammad, A. (2022a). An
incremental model-based design methodology to de-
velop cps with sysml/ocl/reo. In Journ
´
ees du GDR
GPL, Jun 2022, Vannes.
Tannoury, P., Chouali, S., and Hammad, A. (2022b). Model
driven approach to design an automotive cps with sys-
reo language. In Proceedings of the 20th ACM In-
ternational Symposium on Mobility Management and
Wireless Access, pages 97–104.
Combining SysML V2 and BIP to Model and Verify CPS Interactions
409