LLFSMs to TLA+: A Model-to-Text Transformation of Executable

Models Enabling Speciﬁcation and Veriﬁcation of Multi-Threaded and

Concurrent Systems

Vladimir Estivill-Castro

1 a

, Miguel Carrillo

2 b

and David A. Rosenblueth

2 c

Department of Engineering, Pompeu Fabra University, Roc Boronat 138, Barcelona 08018, Spain

Instituto de Investigaciones en Matem

aaticas Aplicadas y en Sistemas, Universidad Nacional Aut

onoma de M

exico,

Apdo. 20-126, Ciudad de Mexico 01000, Mexico

Keywords:

Reasoning About Models, Model Transformation, Executable Models, Formal Veriﬁcation.

Abstract:

As complexity of software systems increases, ensuring reliability becomes ever more crucial. Despite ad-

vances, behaviour-modelling techniques still face challenges due to semantic gaps. This work focuses on

translating Logic-Labelled Finite-State Machines (LLFSMs) to the Temporal Logic of Actions (TLA), bridg-

ing the gap between a time-triggered formalism and common temporal logic for model checking. The transla-

tion is innovative as multi-threaded and distributed systems can now be designed using LLFSMs. We illustrate

the translation with Fischer’s protocol (for multi-threaded systems), and release tools with examples for dis-

tributed systems. The approach addresses semantic gaps from three sources: differing ﬁnite-state machine

semantics, variations in translating to executable models versus models for checking, and discrepancies be-

tween abstract and executable model translations.

1 INTRODUCTION

Achieving dependable and trustworthy behaviour in

software for autonomous, cyber-physical and real-

time systems, poses signiﬁcant challenges. While

progress has been made in Model-Driven Software

Development (MDSD), there are indications that tools

and techniques still need to incorporate executable

and veriﬁable modelling fully. We introduce a model-

to-text translation of arrangements of Logic-Labelled

Finite State Machines (LLFSMs) to the Temporal

Logic of Actions (TLA).

The industry’s current adoption of model trans-

formation techniques seems marginal because of se-

mantic issues (Bucchiarone et al., 2020). Our trans-

lation facilitates the development of software models

for multi-threaded and distributed systems based on

the ubiquitous and well-known concept of ﬁnite-state

machines. It enables the simulation and execution of

the models under a transparent and clear semantics.

Without becoming familiar with the target language

of model checkers, developers can verify their mod-

https://orcid.org/0000-0001-7775-0780

https://orcid.org/0000-0003-2105-3075

https://orcid.org/0000-0001-8933-8267

els without semantic gaps.

Our translation enables, for the ﬁrst time, the

use of LLFSMs to model multi-threaded and dis-

tributed systems. Our prototype implementation is

based on the Eclipse Modelling Framework (EMF)

but, as opposed to our previous translation of LLF-

SMs to SMV (Carrillo et al., 2020), we do not use ATL.

Thus, our implementation prototype executes outside

Eclipse and includes demonstrations of two promi-

nent examples in the literature of distributed systems:

the classical two phase commit and the well-studied

elevator example of the IEC 61499 standard. With

this paper, we release Docker containers that enable

the full reproduction of all examples

. Moreover,

we also implement and include a parallel translation

to SMV. Each example includes veriﬁcation of safety

properties, liveness properties, and real-time proper-

ties without semantic gaps. Moreover, our models are

also translated to three executable formats without se-

mantic gaps (see Fig. 1).

Sec. 2 argues why model translation to TLA+ is

relevant and is followed by a discussion on seman-

A “How To” document (Estivill-Castro

et al., 2024) assists using the Docker containers

hub.docker.com/r/vladestivillcastro/llfsms-examples.

Estivill-Castro, V., Carrillo, M. and Rosenblueth, D. A.

LLFSMs to TLA+: A Model-to-Text Transformation of Executable Models Enabling Speciﬁcation and Veriﬁcation of Multi-Threaded and Concurrent Systems.

DOI: 10.5220/0013094700003896

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 13th International Conference on Model-Based Software and Systems Engineering (MODELSWARD 2025), pages 15-26

ISBN: 978-989-758-729-0; ISSN: 2184-4348

.xmi

Model

Meta-model (Modelling Framework)

.ecore

conforms

.dot

dot script

.pdf

.lisp

.nusmv

SMV

file

LISP interpreter

source

C scheduler

MIPS

source

.asm

MIPS scheduler

NuSMV/NuXMV

model checker

.tla

TLA+

file

TLC

model checker

Executable

Verifiable

Visual

LISP

source

Figure 1: Our translator (in java) takes models (.xmi) and produces executable and veriﬁable models.

tic gaps. We present the advantages of LLFSMs as

behaviour models and we summarise related work.

Sec. 4 presents the translation using Fischer’s Proto-

col as a running illustration. This protocol is central

to multi-threaded systems, particularly to TLA+. Fis-

cher’s Protocol is correct for mutual exclusion but not

necessarily for avoiding starvation. We discuss mod-

els of schedulers in Sec. 5. This is also a ﬁrst for LLF-

SMs: on one hand, the scheduler for the arrangement

is an LLFSM itself, and on the other, formal veriﬁca-

tion of the scheduler is enabled by our model-to-text

translation. Sec. 6 illustrates further advantages be-

fore we conclude in Sec. 7.

2 JUSTIFICATION

TLA has been central to the speciﬁcation and formal

veriﬁcation of distributed systems (Merz, 2019). For-

mal veriﬁcation with TLA+ of multi-threaded systems

and concurrent systems is regularly used by suppli-

ers of cloud services such as Amazon (Newcombe

et al., 2015) and Microsoft (Kuppe, 2023). The au-

thors of the IronFleet methodology highlight TLA+ as

one of the central tools for formal veriﬁcation (Haw-

blitzel et al., 2015). Others agree: “For our work,

TLA perfectly meets our requirements” (Niyogi and

Nath, 2024).

Building a speciﬁcation with TLA+ is equivalent

to deﬁning “the system’s spec” where a spec is “a

succinct description of every allowable behaviour of

the system” (Hawblitzel et al., 2015) or the Kripke

structure (a large non-deterministic state machine).

A Kripke state v is a valuation of all system vari-

ables. There is a Kripke transition from one Kripke

state v

to another v

if the system can reach v

from

in a single execution step. In TLA+ and SMV, the

Kripke structures is deﬁned implicitly, usually com-

posing modules deﬁned with speciﬁc notation from

mathematics and logic (Konnov et al., 2022).

We enable the construction of specs using mod-

els of behaviour. We aim to address requests such as

“Although TLA+ speciﬁcations are purely declara-

tive, they are meant to be used to describe algorithmic

behaviour, and that should be simulatable, executable

and testable” (Moreira et al., 2022).

Requests for tools that generate executable code

from formal speciﬁcations often lead to discussions

about technical differences between formalisms, with

little support for bridging the gap between executable

and veriﬁable models (Carvalho, 2019). We pos-

tulate that speciﬁcations can be created using LLF-

SMs, which can be simulated, translated into high-

level programming languages, and used as input for

model checkers. For developers, working with exe-

cutable models and simulating the speciﬁcation is a

more intuitive approach (Mart

ınez et al., 2012). Our

translation facilitates the development of specs as ex-

ecutable models.

Developers prefer using executable models over

mathematical notation from speciﬁcation languages

such as Z and TLA, as evidenced by “programmers

do not enjoy reading white papers full of mathemati-

cal notation” (Bellotti, 2019).

Translating these speciﬁcations into executable

systems is still largely a manual process: “The adop-

tion of formal methods in industry is challenged by

the cost and complexity involved in the formal speciﬁ-

cation of the system” (Nicol

as and Toval, 2009). The

essence of this paper is that LLFSMs are just as for-

mal (as they can be automatically translated into SMV

or TLA+) and just as executable (as they can be trans-

lated into MIPS and C).

IronFleet stresses the importance of eradicating

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

Abstract

model

Executable

model

Executable

model

Validity of behavioural

properties differ

Verifiable

model

Verifiable

model

Translation for

analysis

Translation for

analysis

(a) What is valid of the executable

models?

Abstract

Model

Ver ifiable

Model

Executable

Model

Generate

The behaviour of the executable model differs from the

behaviour of the verifiable model on model-checker

simulator

(b) What is valid of the executable

model M

Abstract

Model

Executable

Model

Executable

Model

Generate

The behaviour of what should be the same executable

model differs from each other

Papyrus UML Modelling Tool

Editing order of the

single model

differs from each other

have different behaviours?

Figure 2: Known semantic gaps.

semantic gaps (Hawblitzel et al., 2015). (Kurshan,

2018) attributes the lesser penetration in the industry

of formal veriﬁcation to wide semantic gaps.

We are concerned with three types of semantic

gaps (Fig. 2). First, Fig. 2a shows executable mod-

els generated from UML models for analysis with a

model checker. Despite numerous attempts to address

this translation, however, this process may yield in-

consistent formal veriﬁcation outcomes due to multi-

ple semantic variants within UML. Under one seman-

tic variant, the properties may be valid but invalid un-

der another (Besnard et al., 2018). The IEC 61499

also suffers from semantic variants (Cengic and

Akesson, 2010). Moreover, UML has several exten-

sions (fUML, krtUML, SysML, UML-RT) which not

only have their extended semantics but offer seman-

tic variants among them. (Posse and Dingel, 2016)

report on six attempts for formalising semantics and

their Table 1 contrasts at least four.

A second gap involves scenarios where a model

M is constructed and subsequently translated into

both an executable model M

and a model M

for the

model checker (Fig. 2b). Discrepancies may arise be-

tween the observed behaviour of the executable model

and the simulation of M

on the model checker.

For instance, consider a scenario where a Papyrus-RT

model M comprises multiple communicating ﬁnite-

state machines. Papyrus-RT commonly produces an

executable model M

designed for Linux that em-

ploys multitasking services for communication pur-

poses. These intricacies rarely appear in the idealised

model M

. Consequently, during simulation by the

model checker, M

may exhibit traces not present in

(Sahu et al., 2020).

A ﬁnal gap arises when the semantics of a model

depends on the sequence in which components of the

model are edited within an MDSD tool (Pham et al.,

2017) (Fig. 2c). This is a signiﬁcant risk because

visually identical models ought to possess identical

semantics; (Guermazi et al., 2015) report extensive

evaluation of executions, but even with the reference

implementation, identical models can be created that

behave differently (Estivill-Castro, 2021).

LLFSMs are designed with precise semantics

for their execution and with familiar visual nota-

tion. LLFSMs were ﬁrst used for robotic sys-

tems (Brooks, 1990) but have been applied in em-

bedded systems (McColl et al., 2022; Carrillo et al.,

2020), micro-controllers, and FPGAs.

In LLFSMs, predicates (as opposed to events) la-

bel the transitions between states 1) facilitating sim-

ple semantics, e.g., using polling instead of inter-

ruptions, and 2) enabling scheduling the machines

as time-triggered systems, which are easier to ver-

ify than event-triggered machines (Furrer, 2019). By

using LLFSMs, we eliminate the second type of se-

mantic gap (Fig. 2b) to the point that, as suggested by

(Besnard et al., 2018), although inefﬁcient, the model

checker could act as the interpreter for execution.

3 RELATED WORK

There have been efforts to translate UML statecharts

into PROMELA for the SPIN model checker (Latella

et al., 1999). There have also been efforts to translate

to timed automata or some form of Petri nets (Andr

et al., 2023). Many others translate or generate SMV,

the input language of NuSMV, started by (Kwon, 2000).

Other formalisms have been the target of the transla-

tion, such as process algebras, i.e., Hoare’s Commu-

nicating Sequential Processes (CSP), or the Language

Of Temporal Ordering Speciﬁcation (LOTOS) as well

as PVS, KIV, B and Z (Andr

e et al., 2023). None of

these translate to TLA+.

Three types of research are closest to our work.

First is the translation using ATL to SMV by (Carrillo

LLFSMs to TLA+: A Model-to-Text Transformation of Executable Models Enabling Speciﬁcation and Veriﬁcation of Multi-Threaded and

Concurrent Systems

Bool sensor: T1 Non C Sec Delay, T1 C Sec Delay, T2 Non C Sec Delay, T2 C

Sec Delay

Int blackboard: Shared:0..2

ArrangementofLLFSMs||**FischerDelaysByBooleanSensors**||.Thellfsms=(STARTER,THREAD_1,THREAD_2)

BooleanSensor=[(T1_Non_C_Sec_Delay:boolean),(T1_C_Sec_Delay:boolean),(T2_Non_C_Sec_Delay:boolean),(T2_C_Sec_Delay:boolean)]

IntegerWhiteboard=[(Shared:0..2)]

Constants=[Not_A_Thread=0]

STARTER(ID:0)turn(0)

WhiteboardVariablesinLHS=[Shared]

WBinLHSShared=[Shared]

THREAD_1(ID:1)turn(1)

WhiteboardVariablesinLHS=[Shared]

WBinLHSShared=[Shared]

LocalInteger=[(I_am_thread_T1:0..2)]

THREAD_2(ID:2)turn(2)

WhiteboardVariablesinLHS=[Shared]

WBinLHSShared=[Shared]

LocalInteger=[(I_am_thread_T2:0..2)]

dInitSTARTER(0)

START(1)

write"Initialisesharedvariable"

Shared::=Not_A_Thread

1:[true](Tid:00)

dInitTHREAD_1(0)

T1_NON_C_SEC(1)

write"T1noncriticalsection"

I_am_thread_T1::=1

1:[true](Tid:10)

T1_WAIT(2)

1:[T1_Non_C_Sec_Delay](Tid:11)

T1_ASSIGN(3)

Shared::=I_am_thread_T1

1:[(Not_A_Thread==Shared)](Tid:12) 1:[(NOT(I_am_thread_T1==Shared))](Tid:13)

T1_C_SEC(4)

write"T1criticalsection"

2:[true](Tid:14)

T1_LET_GO(5)

Shared::=Not_A_Thread

1:[T1_C_Sec_Delay](Tid:15)

1:[true](Tid:16)

dInitTHREAD_2(0)

T2_NON_C_SEC(1)

write"T2noncriticalsection"

I_am_thread_T2::=2

1:[true](Tid:20)

T2_WAIT(2)

1:[T2_Non_C_Sec_Delay](Tid:21)

T2_ASSIGN(3)

Shared::=I_am_thread_T2

1:[(Not_A_Thread==Shared)](Tid:22) 1:[(NOT(I_am_thread_T2==Shared))](Tid:23)

T2_C_SEC(4)

write"T2criticalsection"

2:[true](Tid:24)

T2_LET_GO(5)

Shared::=Not_A_Thread

1:[T2_C_Sec_Delay](Tid:25)

1:[true](Tid:26)

Figure 3: Initialisation for Fischer’s protocol.

et al., 2020) since the source is also an LLFSM model.

Second is a translation to SMV from models built with

Function Blocks of the IEC 61499 (Patil et al., 2015)

since, the machines inside function blocks have no

events, only guards (thus, these are LLFSM), and

events are handled outside the block on the interface

and by priority schemes (using timers). Third, some

degree of parallelism is achieved by (McColl et al.,

2022) by scheduling LLFSMs in groups of indepen-

dent, not communicating LLFSMs and inside groups

using a predeﬁned round-robin schedule.

4 TRANSLATION

4.1 Example

Fischer’s protocol is a software-based approach re-

quiring no hardware support to ensure mutual exclu-

sion among multiple threads (Lamport, 1987; Lam-

port, 2005a; Lamport, 2005b; Lamport, 2024). Its

correctness has been validated multiple times. The

variable Shared identiﬁes the thread in the critical

section and initially holds the predeﬁned constant

NotAThread (see the STARTER machine in Fig. 3,

with index 0 in the arrangement).

Each thread (Fig. 4) can spend an arbitrarily long

time both in its non-critical section and in its critical

section.

The protocol coordinates several copies of the

LLFSM in Fig. 4. For illustration, we use one LLFSM

modelling the Fischer’s protocol thread (Fig. 4) with

index 1 in the arrangement but with two copies (how-

ever, our tools allow to set the number k of threads).

In the translation, the threads are named ThreadID

with an ID ∈ {1, 2}

. Fischer’s protocol is a suit-

able example of multi-threaded system because each

thread gets a turn by a non-deterministic scheduler (at

any time any thread can be the next thread).

The transitions of LLFSM are identiﬁed with names

of the form Tid<machine index><transition index>. Thus,

the Tid00 in the name of the only transition in Fig. 3, but

Tid10, Tid11, Tid12, Tid13, Tid14, Tid15, and Tid16,

are the names of the transitions in Fig. 4.

1:[true](Tid:16)

Figure 4: The LLFSM corresponding to a thread.

4.2 Brief Introduction to LLFSMs

A system is comprised of an arrangement (i.e., a se-

quence of instances) of LLFSMs. Each LLFSM con-

sists of states and transitions. Time progresses as

the system executes code within a state; a transition

moves the execution from one state to another.

LLFSMs are extended machines, where exe-

cutable code can also be associated with a state in-

volving Boolean and integer variables. In line with

the principles of MDSD, we abstract the action lan-

guage for this executable code in a meta-model. The

LLFSMs presented here will not include sections

(or equivalently, they only have an OnEntry sec-

tion and its code is the code of the state). LLF-

SMs featuring states with sections (OnEntry, OnExit,

and Internal) can be model-to-model translated into

LLFSMs without sections and yet maintain equivalent

semantics (Carrillo et al., 2020).

A critical aspect of LLFSMs’ semantics is that

the execution of code statements within a state is

atomic: once execution reaches a state, the entire code

of the state is executed without interruption. This

atomicity is crucial for bridging the semantic gap be-

tween model checkers and executable implementa-

tions. However, it is possible to build non-atomic ver-

sions if the modeller desires to do so.

A state can serve as the source for multiple tran-

sitions, ordered in sequence ⟨l

, . . . , l

⟩. A transition

= (B

, t

) (where B

is the Boolean label and t

the target state) updates the machine current state to t

if B

evaluates to true and all labels in preceding tran-

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

sitions l

, . . . , l

i−1

evaluate to false. Therefore, at most

one transition can be activated at a time. A machine

updates its current state only when such LLFSM has

its turn and a transition has a Boolean expression that

evaluates to true. When it has its turn, the machine M

executes a ringlet atomically, that is:

1. M copies the current valuation v (the assignment

of all variables to their values),

2. it evaluates the Boolean expression of all transi-

tions leaving the current state in that ﬁxed valua-

tion v,

3. it executes the code of the target state of the tran-

sition that ﬁred and updates its current state to the

target state (or does nothing if no transition ﬁres).

4.3 The Translation and Its Illustration

We present a model-to-text transformation enabling

the creation of a formal speciﬁcation for TLA+ from

executable models of sequential, distributed, or multi-

threaded systems. (Carrillo et al., 2020) provided a

formal sequential semantics for an arrangement A of

LLFSMs.

Each machine must have a single initial state. The

case where a model requires a machine M with mul-

tiple initial states I

chosen non-deterministically can

be modelled with a simple transformation.

All machines begin in a pseudo-state (preﬁxed

with dInit) as their current state. The initial pseudo-

state contains only one transition, labelled “true”.

For each machine M , the ﬁrst turn of M updates M ’s

current state (from the pseudo-state dInitM ) to M ’s

initial state. In our running example, STARTER will

execute ﬁrst, initialising variable Shared that initially

has no value.

A TLA+ speciﬁcation is the conjunction of three

formulas: Init, Next, and Liveness (Lamport, 2002).

Init ∧ □[Next]

vars

∧ Liveness.

Each formula serves the following purpose.

1. Speciﬁcation of Initial States (Init): This for-

mula deﬁnes the initial Kripke states. Since

Kripke states are valuations, only those valuations

that make Init true are initial Kripke states.

2. Safety Speciﬁcations (Next): This second for-

mula deﬁnes which actions the system can per-

form and is a disjunction (∨) of formulas in the

form ψ

=⇒ φ

. Each formula ψ

=⇒ φ

indi-

cates there is a possible transition from any Kripke

state satisfying ψ

to any target Kripke state sat-

isfying φ

. Thus, ψ

=⇒ φ

describes possible

edges within the Kripke structure.

3. Liveness Speciﬁcations (Liveness): A third for-

mula speciﬁes when a Kripke transition must be

taken.

We now describe the model-to-text transformation re-

sponsible for constructing these three components.

4.3.1 Constructing the Formula Init

A TLA+ speciﬁcation starts with a declaration of the

variables. As each LLFSM maintains its current state,

we declare variables in TLA+ that serve as program

counters. For each machine M NAME, we declare a

variable M NAMEState.

Using the running example from Fig. 3 and Fig. 4,

we show the declaration of variables generated by our

tools. The TLA+ speciﬁcations and mathematical no-

tation we show next are the output of the coded trans-

lation (and text in grey are comments). For the Fis-

cher’s protocol arrangement, that has three machines

(a STARTER and two threads) we have three variables

that keep track of the current state of each machine.

The variables that represent the current state of a machine

VARIABLES STARTERState, THREAD 1State, THREAD 2State

LLFSMs have two primary types of variables. Lo-

cal variables (which are only visible to one machine)

and shared variables (with scope across the arrange-

ment). Shared variables are of four types: those

named blackboard variables (which can be both read

and written), those named sensor variables (that are

read only, but the environment can modify in an open

model), and effector variables (that are write only, and

the environment observes).

We show the deﬁnition of the variables of our run-

ning example. In TLA+, variable names cannot be du-

plicated, and we declare them so all variables are part

of the subscript of the weak fairness condition for the

Liveness formula (see Sec. 4.3.3). The user variables

are followed by the declaration of the variable turn.

Boolean sensor variables

, T1 Non C Sec Delay, T1 C Sec Delay

, T2 Non C Sec Delay, T2 C Sec Delay

Integer whiteboard variables

, Shared

The integer local variables of all machines

The integer local variables of machine THREAD 1

, THREAD 1 I am thread T1

The integer local variables of machine THREAD 2

, THREAD 2 I am thread T2

Which machine takes a turn

, turn

In TLA+, it is necessary to explicitly specify the

types of all variables as an invariant, represented by

LLFSMs to TLA+: A Model-to-Text Transformation of Executable Models Enabling Speciﬁcation and Veriﬁcation of Multi-Threaded and

Concurrent Systems

formulas in the form of Gϕ, where G is the LTL oper-

ator globally/always. This is achieved for the variable

that keeps the current state of the LLFSM by deﬁning

that the potential values of the current state consist of

the states of the LLFSM, for each LLFSM.

For the example, we show only a few invariants,

but the translation includes one for each variable.

The type-correctness invariants

TypesTHREAD 1 I am thread T1OK

∆

THREAD 1 I am thread T1 ∈ {n ∈ Int : n ≥ 0 ∧ n ≤ 2}

TypesT1 Non C Sec DelayOK

∆

T1 Non C Sec Delay ∈ BOOLEAN

TypesSharedOK

∆

= Shared ∈ {n ∈ Int : n ≥ 0 ∧n ≤ 2}

Among the invariants is the constraint that the

scheduler keeps the value of turn to be the index of

one of the LLFSMs in the arrangement.

We now provide the predicate that deﬁnes the ini-

tial states of the Kripke structure. The formula is

named Arrangement NameInit and is a conjunction

of what is possible at the start of the system. Each ma-

chine Nachine Name will have its counter initialised

to the pseudo-state:

Nachine NameState = “dinitNachine Name”.

We express each variable as initially undeﬁned but

holds some value in its domain. Consequently, there

exist numerous initial states in the Kripke structure,

encoding that execution can start with any combina-

tion of valuations for the variables. In our example,

before STARTER runs, the variable Shared can ini-

tially hold any value in its domain. The sensor vari-

ables with postﬁx Delay are controlled by the envi-

ronment, enabling each thread to stay in its critical or

non-critical sections for an undeﬁned long time.

The variable turn is set to the ﬁrst machine (with

index 0) in our example, but in general it could be

another value. Also, if we intended to implement an

arrangement of LLFSM where the arrangement could

start from any LLFSM, we would simply alter the

turn=0 statement to turn ∈ {0, 1, . . . , n}. This ad-

justment shows the ﬁrst step towards furnishing the

multi-threaded or distributed semantics.

The initial predicate. Each machine starts in its initial state.

FischerInit

∆

= ∧ turn = 0

∧ STARTERState = “dInitSTARTER” ∧THREAD 1State = “dInitTHREAD 1”

∧ THREAD 2State = “dInitTHREAD 2”

∧ T1 Non C Sec Delay ∈ BOOLEAN

∧ T1 C Sec Delay ∈ BOOLEAN

∧ T2 Non C Sec Delay ∈ BOOLEAN

∧ T2 C Sec Delay ∈ BOOLEAN

∧ Shared ∈ {0, 1, 2}∧ THREAD 1 I am thread T1 ∈ {0, 1, 2}

∧ THREAD 2 I am thread T2 ∈ {0, 1, 2}

4.3.2 Constructing the Formula Next

In general, for every state s of every machine M in

the arrangement, we proceed to deﬁne the transitions

out of s. We write these transitions as a disjunction

because a machine M with a current state s and a se-

quence of transitions ⟨(e

, s

), (e

, s

), . . . , (e

, s

)⟩

(where s represents the current and source state,

, s

, . . . , s

are the target states, and e

, e

, . . . , e

are Boolean expressions) moves to a new Kripke state

if and only if {(e

, s

) ﬁres} ⊕ {(e

, s

) ﬁres} ⊕

··· ⊕ {(e

, s

) ﬁres} ⊕ {no transition ﬁres}, where ⊕

stands for exclusive or. Hence, a Kripke transition

occurs if and only if an LLFSM M has its turn, and

either: (a) the current state of M has a transition that

ﬁres and no preceding transition with the current state

as the source state ﬁres or (b) no transition ﬁres (but

not both). If no transition ﬁres, the system will still

progress as another LLFSM in the arrangement has

its turn.

Therefore, for every instance of a transition

, s

) out of the current state s

for the machine

with turn t , we write a formula incorporating the fol-

lowing components.

t,j

∆

= ( turn = t ) ∧ (current State Variable = s

)

∧(∀v < j , ¬e

) ∧e

We illustrate this part of the translation with the

transition out of the state T1 WAIT to the state T1

ASSIGN:

T 12

∆

= turn = 1 ∧ THREAD 1State = “T1 WAIT”

∧ (Not A Thread = Shared)

This formula is the conjunction of three condi-

tions: the turn matches the machine number, the cur-

rent state is T1 WAIT, and the transition is labelled by

a test for equality (a Boolean formula) involving the

shared variable Shared.

A formula for the effect of a transition must be

speciﬁed for each transition in the system. In TLA+

we must continue the description of a step in the sys-

tem by specifying the new Kripke state (the new valu-

ation). The ﬁrst effect of a ﬁring transition from s

is the update of the state. The program counter for

the state must be updated to the target state. Thus, the

deﬁnition of the transition continues with a conjunc-

tion with the following equality

∧ Machine NAMEState

′

= s

In TLA+, the value of a variable in the next Kripke

state is primed.

For the example of transition T

of the second

thread in Fischer’s protocol, this means

∧ THREAD 1State

′

= “T1 ASSIGN”

The second effect is the atomic execution of the

OnEntry in the target state. This depends on the as-

signment statements in the target state. For the ﬁrst

thread, arrival to the state T1 ASSIGN implies evalua-

tion of only one assignment.

∧ Shared

′

= THREAD 1 I am thread T1

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

There is a third part for each transition. For-

malisms like SMV and TLA+ must specify what hap-

pens with everything else. Crucially, everything else

remains unchanged, except for the sensor variables,

since the environment could modify such variables.

In TLA+, we specify this aspect of sensor variables,

indicating that their new value is some value in their

domain.

For the running example of THREAD 1, transition

continues as follows.

∧ UNCHANGED ⟨STARTERState, THREAD 2State⟩

∧ UNCHANGED ⟨THREAD 1 I am thread T1⟩

∧ UNCHANGED ⟨THREAD 2 I am thread T2⟩

∧ T1 Non C Sec Delay

′

∈ BOOLEAN

∧ T1 C Sec Delay

′

∈ BOOLEAN

∧ T2 Non C Sec Delay

′

∈ BOOLEAN

∧ T2 C Sec Delay

′

∈ BOOLEAN

LLFSMs can model open and closed models. An

open model can characterise the environment through

sensor variables. In this case, the potential successor

Kripke states are as many as the possible combina-

tions of assignments to the sensor variables. Closed

models, by contrast, are simpler because the environ-

ment can be modelled as an additional LLFSM and

sensor variables as blackboard (shared) variables. The

additional LLFSM provides values to those black-

board (shared) variables while other LLFSMs in the

arrangement read them.

For each transition, the next value of the variable

turn must be deﬁned. However, how turn is updated

determines the difference between sequential execu-

tion, or multi-threaded or distributed system. Since

the update appears in all deﬁnitions of all transitions,

it can be factored out in the formula deﬁning Next.

There is a possibility that no transition ﬁres, in

which case every action-language variable remains

unchanged. This also must be speciﬁed for each ma-

chine M . We deﬁne a default formula indicating ev-

erything remains the same guarded by a conjunction

that all other transitions must evaluate to false.

We exemplify the default transition for the ma-

chine that corresponds to the ﬁrst thread in Fischer’s

protocol.

T1condDefault

∆

= ∧ turn = 1

∧ (¬THREAD 1State = “dInitTHREAD 1”

∧ ¬(THREAD 1State = “T1 NON C SEC”

∧T1 Non C Sec Delay)

∧ ¬(THREAD 1State = “T1 WAIT” ∧ (Not A Thread = Shared))

∧ ¬(THREAD 1State = “T1 ASSIGN” ∧

(¬(THREAD 1 I am thread T1 = Shared)))

∧ ¬(THREAD 1State = “T1 ASSIGN” ∧ TRUE)

∧ ¬(THREAD 1State = “T1 C SEC”

∧ T1 C Sec Delay)

∧ ¬(THREAD 1State = “T1 LET GO” ∧ TRUE)

)

∧ UNCHANGED ⟨THREAD 1State⟩

∧ UNCHANGED ⟨STARTERState, THREAD 2State⟩

∧ UNCHANGED ⟨THREAD 1 I am thread T1⟩

∧ UNCHANGED ⟨THREAD 2 I am thread T2⟩

∧ UNCHANGED ⟨Shared⟩

∧ T1 Non C Sec Delay

′

∈ BOOLEAN

∧ T1 C Sec Delay

′

∈ BOOLEAN

∧ T2 Non C Sec Delay

′

∈ BOOLEAN

∧ T2 C Sec Delay

′

∈ BOOLEAN

Thus, the formula for the Next predicate is the dis-

junction because one of the machines is awarded the

turn, and that machine executes a transition, or if no

other transition ﬁres, it ﬁres its default transition. The

previous transitions must be false for each transition

to ﬁre, and this pattern is also for the default transi-

tion, placed last. As the turn update happens in every

disjunct, as we anticipated, we can factor it out.

In the sequential execution of an arrangement with

n LLFSMs, the variable turn (not accessible to the

modeller) is assigned values in a round-robin fash-

ion: turn ← (turn + 1) mod n, typically starting

from turn ← 0. However, after factoring out the up-

date of the turn, it becomes clear that we can achieve

a multi-threaded (or distributed system) by adjusting

how the turn is updated. When modelling a multi-

threaded system, where the CPU can allocate the next

ringlet to any of the LLFSMs, the update of the turn

is non-deterministic:

turn

′

∈ {0, 1, 2}.

Therefore the generated Next formula for Fis-

cher’s example is as follows.

Move to a successor state in the Kripe Structure

FischerNext

∆

A non-deterministic scheduler advances some transition

turn

′

∈ {1, 2} ∧

The transitions of machine STARTER

∨ T 00 ∨ T 0condDefault

The transitions of machine THREAD 1

∨ T10 ∨ T11 ∨ T12 ∨ T 13 ∨ T 14 ∨ T 15 ∨ T 16 ∨ T 1condDefault

The transitions of machine THREAD 2

∨ T20 ∨ T21 ∨ T22 ∨ T 23 ∨ T 24 ∨ T 25 ∨ T 26 ∨ T 2condDefault

4.3.3 Constructing the Liveness Formula

The formula for Liveness should be a conjunction of

weak and/or strong fairness formulas for subactions

of Next since this guarantees that the speciﬁcation is

machine closed (Lamport, 2002). We will not deﬁne

subactions or machine closedness. Arrangements of

LLFSMs always progress, even if the machine hold-

ing the turn lacks a transition that ﬁres, the execu-

tion proceeds to the next machine. This implies the

absence of stuttering behaviours, where there are no

behaviours that continuously enable a step but do not

execute the step. Thus, we eliminate all potential stut-

tering behaviours using TLA’s construct for weak fair-

LLFSMs to TLA+: A Model-to-Text Transformation of Executable Models Enabling Speciﬁcation and Veriﬁcation of Multi-Threaded and

Concurrent Systems

Table 1: Fischer’s mutual exclusion veriﬁcation (sec).

k TLC NuSMV

5 3 ±0.5 1 ±0.05

6 27 ±1.1 5 ±0.11

7 166 ±1.4 25 ±0.32

8 1,085 ±5.1 95 ±0.43

ness WF. Adhering to the convention that vars repre-

sents the tuple of all variables,

Liveness

∆

= WF

vars

(Next),

where the formula WF

vars

(A) in TLA+ is deﬁned

as (Lamport, 2002)

□(□ENABLED⟨A⟩

vars

⇒< A >

vars

)

and it states that, if A ever becomes forever enabled,

then an A step must eventually occur.

4.3.4 Using the Translation

Our translation enables the veriﬁcation of the central

property of mutual exclusion expressed in TLA+ ex-

actly as discussed by Lamport (Lamport, 2005a) by

choosing TLC as our target model checker.

[](˜((THREAD_1State="T1_C_SEC")

/\(THREAD_2State="T2_C_SEC")))

Using our parallel translation, we can also for-

mally verify the mutual exclusion of any two threads

translating to SMV.

LTLSPEC G( !(THREAD_1.At_T1_C_SEC

& THREAD_2.At_T2_C_SEC))

Other properties checked on Fischer’s algorithm

are deadlock freedom and a progress property (Lam-

port, 2005b; Lamport, 2005a) that we can verify with

both model checkers. For instance, the following

Progress (Lamport, 2005a) property.

Progress ≜ (∃t ∈ Thread : pc[t] ∈ {WAIT , ASSIGN })

=⇒ (∃t ∈ Thread : pc = C SEC ).

This condition expresses that, “if some thread is

waiting to enter its critical section, then some thread

(not necessarily the same one) will eventually en-

ter” (Lamport, 2005a).

Different model checkers use different computa-

tional resources for verifying a property. At least for

Fischer’s algorithm, NuSMV is computationally faster

than TLC. We compared TLC with NuSMV repeating the

veriﬁcation ﬁve times for each model checker on the

same computer. Table 1 shows average times (with

95% conﬁdence intervals) verifying mutual exclusion

for ﬁve to eight threads with a unrestricted scheduler.

These results show that the coded translations are ef-

ﬁcient.

initial

proxy turn ∈ {1, . . . , m}

Figure 5: A nondeterministic scheduler encoded as an

LLFSM.

4.3.5 The Translation’s Structure

There are two ways by which a sequential arrange-

ment of LLFSMs simulates the non-deterministic exe-

cution of a multi-threaded arrangement. The ﬁrst ver-

sion adds a scheduler to the arrangement.

Deﬁnition 1. The LLFSM-scheduler version to

simulate multi-threaded execution of an arrange-

ment A = ⟨M

, M

, . . . , M

⟩ (where each M

an LLFSM) is a new sequential arrangement

′

= ⟨S , M

, M

, . . . , M

⟩ with a new variable

turn proxy, where A

′

is forced to start with its

ﬁrst LLFSM S , the original variable turn in A is re-

placed by turn proxy, and S is a scheduler which

non-deterministically assigns the turn proxy of a

machine in A.

The second version adds a Boolean sensor vari-

able as conjunction with the existing Boolean expres-

sion of every transition.

Deﬁnition 2. The LLFSM-variable version to simu-

late multi-threaded execution of an arrangement A =

⟨M

, M

, . . . , M

⟩ (where each M

is an LLFSM) is a

new sequential arrangement A

′

= ⟨M

′

, M

′

, . . . , M

′

⟩

with a new Boolean sensor variable grant CPU, all

machines M

′

are copies of the corresponding ma-

chine M

except that all transitions T

= (e

, s

) of

the machines M

have been replaced by T

′

= (e

∧

grant CPU, s

) for machine M

′

, and

1. the environment cannot set grant CPU always

to false from any point forwards, (that is, in LTL:

G F grant CPU), and

2. if the environment sets grant CPU to true on ma-

chine M

’s turn, then it must sustain grant CPU

to true while M

evaluates all transitions out of its

current state.

The following proposition establishes that the seman-

tics of multi-threaded LLFSMs, can be used to obtain

faithful translations in two equivalent ways.

Proposition 1. The LLFSM-scheduler multi-threaded

execution and the LLFSM-variable multi-threaded ex-

ecution are equivalent.

Proof. First, we show that any sequence N =

⟨t

, t

, . . .⟩ (whether ﬁnite or inﬁnite) of turns with

∈ {1, . . . , m} for the multi-threaded execution of

A is simulated by the round-robin execution of the

LLFSM-scheduler A

′

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

Let N = ⟨t

, t

, . . .⟩ be an arbitrary sequence of

non-deterministic turns of a multi-threaded execution

of A. The scheduler S is depicted in Fig. 5. It runs

once for every round-robin cycle, and thus, it can hap-

pen that when the scheduler is granted a turn for the

i-th time, it sets turn proxy to t

. Although the vari-

able turn is updated in a round-robin fashion by the

sequential execution, a machine M

in the arrange-

ment only reacts if turn proxy equals i. Otherwise,

does nothing. Thus, for each scan across the ar-

rangement, only one of the machines M

executes its

ringlet, precisely M

, when turn proxy equals t

Thus, the sequential execution of A

′

grants turns to

machines M

in the arrangement in exactly the se-

quence N of the multi-threaded execution of A.

We now proceed to the converse. We show that

any round-robin execution R of the simulator ar-

rangement A

′

corresponds to a multi-threaded exe-

cution of A. But let N = ⟨t

, t

, . . .⟩ the sequence

of values granted by the schedulers S to the vari-

able turn proxy on sequential execution R of A

′

The sequential execution only enacts machine M

each round-robin scan over arrangement A. Thus,

the multi-threaded execution with sequence of turns

N = ⟨t

, t

, . . .⟩ enacts the execution R.

Now we show that any sequence N = ⟨t

, t

, . . .⟩

(whether ﬁnite or inﬁnite) of turns with

∈ {1, . . . , m} for the multi-threaded execution

of A is simulated by the round-robin execution of the

LLFSM-variable A

′

The idea is simple. In the round-robin execution

of A

′

, when turn equals t

(at the i-th sequential

scan), the environment sets grant CPU to false for

all machines in the scanning of the arrangement but

grant CPU is set to true for machine M

. Thus, all

transitions are guaranteed not to ﬁre for all other ma-

chines. Machine M

evaluates its transitions with

grant CPU set to true, which is logically equivalent

as evaluating (true ∧ a)e = e for every Boolean ex-

pression e labelling its transitions. Thus, the only ac-

tions that happen in the round-robin execution of A

′

are those in the multi-threaded execution of A

′

For the converse, since the environment cannot

keep grant CPU set to false forever, some machine

will get a turn. Since the environment must keep

grant CPU true for all outgoing transitions of the cur-

rent state of M

this is equivalent to granting a turn in

a non-deterministic schedule to M

We have two immediate corollaries, one for TLA+

and the following which is the NuSMV version.

Corollary 1. Let P be a property. Using the NuSMV

translation of the LLFSM-scheduler version of an ar-

rangement A (modelling a multi-threaded system) to

verify P is equivalent to using the NuSMV translation

of the LLFSM-variable version of an arrangement A

(modelling a multi-threaded system) to verify P.

Since the LLFSM-variable version requires a deli-

cate interaction of when grant CPU is true, we prefer

the translation using the LLFSM-scheduler version.

Fischer’s protocol shows the case when there are

several copies of the same LLFSM. There are two

possible ways to perform the model-to-text transla-

tion of an arrangement when an LLFSM has several

instances. The ﬁrst option uses facilities in speciﬁca-

tions for NuSMV or for TLC to create several instances

of a module.

Deﬁnition 3. The LLFSM-module version to trans-

late a machine M with c copies in an arrangement

of LLFSMs consists in using the module facility of

the language L

to create speciﬁcations of a model

checker C, and to translate M to a module M

and

indicate that the L

-speciﬁcation has c instances of

The second option is to use that SMV-speciﬁcations

and TLA+-speciﬁcations allow arrays.

Deﬁnition 4. The LLFSM-array version to translate

a machine M with c copies in an arrangement of

LLFSMs consists in using the array facility of the lan-

guage L

to create speciﬁcations of a model checker

C, and to translate M to a module M

, but for each

element a of M , create an array a:[1..c] in M

Proposition 2. At least for SMV and TLA+, the

LLFSM-module translation of an arrangement and

the LLFSM-array translation can be made equivalent.

We elected to use the LLFSM-module translation

for our implementations of the translation.

5 SCHEDULERS

In Fischer’s protocol, the unrestricted scheduler of

Fig. 5 may cause starvation. LLFSMs can be used

to deﬁne, and analyse properties of alternative sched-

ulers. We can verify the scheduler on its own or verify

an arrangement with a speciﬁc scheduler.

The scheduler of Fig. 5 is automatically translated

to SMV, and we can verify

Property 1 at any time, any thread in the future can

have a turn, and

Property 2 With two or more threads, at any point, for

any thread t, there is a path that starves t forever.

Because the scheduler of Fig. 5 allows a thread to mo-

nopolise the CPU, we formulate a new scheduler in

Fig. 6 controlling t LLFSMs. The arrangement can

include one starter LLFSM for set up. Here, for each

LLFSMs to TLA+: A Model-to-Text Transformation of Executable Models Enabling Speciﬁcation and Veriﬁcation of Multi-Threaded and

Concurrent Systems

thread i, we have a variable waiting

that counts how

long i has been waiting for the CPU. For this new

model, we also apply our model-to-text transforma-

tions. We conﬁrm additional properties:

LTLSPEC -- If thread i has starved to the maximum, it will

eventually have a turn (no starvation)

G(Scheduler.waiting_i=g_c.MaxConsecutive

-> F Scheduler.waiting_i=0)

CTLSPEC -- Thread i can starve for the maximum

EF (Scheduler.waiting=g_c.MaxConsecutive )

Modelling with LLFSM is agnostic to the model

checker, and designers of behaviours can apply the

translation to a model checker with which they are

most comfortable enunciating veriﬁcation properties.

LLFSMs provide abstraction from the programming

language for execution of the model. At ﬁrst sight, the

mathematical notation of TLA+ appears to be more

expressive than SMV since it supports sets and func-

tions. However, NuSMV supports interactive simula-

tion (TLA+ only supports command-line trace gener-

ation). Also, TLA+ does not have all the operators

of LTL, notably, lacking X (Next) (Kr

oger and Merz,

2008).

There are two fundamental types of properties

about real-time systems: upper bound and lower

bound (Lamport, 2005b). With t = 3 and MAX=4, we

show an example of each.

LTLSPEC G (!(w_b.the_Turn=i) -> F[0,11] w_b.the_Turn=i).

No thread, ever, waits for a turn more than 11

Kripke state transitions. Notice that this is a stronger

time-domain property as the operator F (eventually) is

replaced by a precise upper bound.

LTLSPEC G ((!(w_b.the_Turn=i)& Xw_b.the_Turn=i)

-> H[0,1]!(w_b.the_Turn=i))

Since X is missing, we have not found how to ex-

press these properties in TLA+. But the next section

illustrates an aspect feasible with SMV that seems more

comprehensive with TLA+.

6 DISCUSSION

Every time we translate to NuSMV, we run this model

checker with the option -ctt validating that the tran-

sition relation in the Kripke structure is total. Every

translation to TLA+ validates the invariants of vari-

ables within domains.

We provide further automation, offering the op-

tional generation of a series of sanity checks validated

by both model checkers. That is, for all states s in one

of the LLFSMs, the LTL

LTLSPEC (F s)

is automatically generated. Verifying such reachabil-

ity properties for all states s seems intuitively sound.

For closed models, such intuition is correct. How-

ever, the property may be false for open models be-

cause the environment never provides an input driv-

ing the behaviour to s. Nevertheless, this outcome is

informative. First, the designer can conﬁrm that, in-

deed, the interactions that avoid s are always what is

expected. Secondly, the model can be closed with an

additional LLFSM that plays the role of the environ-

ment, resulting in a closed model.

For all states s that are the source of a transition,

the following sanity check

LTLSPEC G (s -> F (!s))

can optionally be generated. Intuitively, if a state s

is not terminal, then eventually, the behaviour must

leave s. Although this sanity check may be false in

open models, it is informative because it explicitly

reveals which paths, by interacting with the environ-

ment, freeze the behaviour of the LLFSM at s.

Transitions are the dual of states. Thus if T : s

→

is a transition in one of the LLFSMs of the arrange-

ment, intuitively, T must eventually ﬁre.

LTLSPEC F (s & X t)

In TLA+, these properties must be expressed as ac-

tion properties using the globally operator and not the

eventually operator

¬¬♢(state = “s” ∧ state

′

= “t”) ≡

¬□(state ̸= “s” ∨ state

′

̸= “t”)

Then, we must use a box-action formula (Lamport,

2002).

□[state ̸= “s” ∨ state

′

̸= “t”] state

Note that we verify the negation, and we expect the

model checker to declare this formula invalid.

This offers another angle between NuSMV and TLC.

The sanity checks with properties with an eventually

form could be vacuously true. Thus, they should be

complemented by ensuring that the negation is false

and the model checker provides the trace. Although

TLC does this, the output of false properties is lengthy

and TLC (in command-line mode) halts when a prop-

erty is found to be false.

A signiﬁcant added value is that users can request

the generation of sanity checks about the scheduling.

For the round-robin deterministic scheduler, with n

LLFSMs in the arrangement

Note that LTL’s G (globally/always) is □ in TLA+,

while LTL’s F (eventually) is ♢, & is ∧, and ! is ¬ in TLA+.

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

initial

∀i waiting

← 0

starter’s turn

theTurn ← 0

keep CPU ∈ {1, . . ., t}

i ← keep CPU

thread i’s turn

theTurn ← i

waiting

← 0

∀j ̸= i waiting

←

(waiting

+ +) mod (MAX + t)

true

T1:(waiting

≥ MAX) ∨ ((keep CPU == 1)

j ̸=1

(waiting

< MAX))

true

T2:(waiting

≥ MAX) ∨ ((keep CPU == 2)

j ̸=2

(waiting

< MAX))

Tt:(waiting

≥ MAX)

∨((keep CPU == t)

j ̸=t

(waiting

< MAX))

Figure 6: A fair scheduler encoded as an LLFSM.

LTLSPEC

G ( (turn=0 & X turn=1)

...

| turn=t-2 & X turn=t-1)

| turn=t-1 & X turn=0)

)

is the sanity-check.

7 CONCLUSION

Time-triggered architectures require careful tuning

of time step frequencies. In event-driven software,

such as web or GUI applications with simple user

inputs, assumptions about time gaps between events

typically hold. However, in cyber-physical systems,

the large number of connected sensors drastically in-

creases event frequency. UML statecharts have sev-

eral features that reduce their understandability for

developers, while LLFSMs present different but com-

parable issues (Estivill-Castro and Hexel, 2019).

By analysing schedulers for arrangements of LLF-

SMs we can now handle multi-threaded systems and

distributed systems. We eliminated semantic gaps by

ensuring that veriﬁcation traces are consistent with

executions in C or MIPS. There is a possibility that

the translation implementation is faulty. However,

regular comparison of the executable models (Lisp,

MIPS, C) and using two model checkers reduces this

risk. The next step is to formally verify the translation

tool, which we consider feasible because each meta-

model element follows a rule, similar to the recursive

rules used in ATL transformations that can be veriﬁed

by induction.

We keep a single representation and provide trans-

lations of such a representation to both programming

and model-checker languages, thus, experts in one

language need not become experts in others. Re-

call that programming languages differ signiﬁcantly

from the languages used by model checkers. “As

TLA+ is math-based, it comes with a difﬁcult learn-

ing curve and might appear intimidating to software

engineers” (Caballar, 2023). Thus, a top priority is

to “translate a high-level TLA+ design directly into

code” (Caballar, 2023). We believe our approach

contributes to the simultaneous development of exe-

cutable code and simultaneous veriﬁcation.

More translations beyond C, LISP, MIPS, TLA+,

and SMV would be desirable, but such efforts can be

performed with current translations as translations of

reference. Such validation against all previous trans-

lations aids signiﬁcantly in eradicating semantic gaps

and errors from implementing new translations.

REFERENCES

Andr

e, E., Liu, S., Liu, Y., Choppy, C., Sun, J., and Dong,

J. S. (2023). Formalizing UML state machines for au-

tomated veriﬁcation – a survey. ACM Comput. Surv.,

55(13s).

Bellotti, M. (2019). Introduction to TLA+ model

checking in the command line. Software Safety

medium.com/software-safety. [Online; accessed 29-

05-24].

Besnard, V., Brun, M., Jouault, F., Teodorov, C., and

Dhaussy, P. (2018). Uniﬁed LTL veriﬁcation and em-

bedded execution of UML models. 21th ACM/IEEE,

MODELS, p. 112–122, NY, USA. ACM.

Brooks, R. (1990). The behavior language; user’s guide.

TR AIM-1227, MIT, Dep. Elec. CS.

Bucchiarone, A., Cabot, J., Paige, R. F., and Pierantonio, A.

(2020). Grand challenges in model-driven engineer-

ing: an analysis of the state of the research. Software

and Systems Modeling, 19(1):5–13.

Caballar, R. D. (2023). TLA+ helps programmers squash

bugs before coding. IEEE Spectrum.

Carrillo, M., Estivill-Castro, V., and Rosenblueth, D. A.

(2020b). Veriﬁcation and simulation of time-domain

properties for models of behaviour. Revised papers

Int. Conf., MODELSWARD, vol. 1361 CCIS, p. 225–

249. Springer.

LLFSMs to TLA+: A Model-to-Text Transformation of Executable Models Enabling Speciﬁcation and Veriﬁcation of Multi-Threaded and

Concurrent Systems

Carvalho, A. (2019). TLA+, Event B comparison. [Online;

accessed 1-12-23].

Cengic, G. and Akesson, K. (2010). On formal analysis

of IEC 61499 applications, part A: Modeling. IEEE

Trans. Industrial Informatics, 6(2):136–144.

Estivill-Castro, V. (2021). Tutorial activity diagrams with

Moka and unsafe race conditions. https://www.

youtube.com/watch?v=P1KX2dBjmO8.

Estivill-Castro, V., Carrillo Barajas, M., and

Rosenblueth, D. A. (2024). How to use

javallfsmstransformation and its asso-

ciated tools. https://mipal.net.au/Downloads/

HowToUseM2T.pdf.

Estivill-Castro, V. and Hexel, R. (2019). The understand-

ability of models for behaviour. Revised papers 7th

Int. Conf., MODELSWARD, vol. 1161 CCIS, p. 50–

75. Springer.

Furrer, F. (2019). Future-Proof Software-Systems: A Sus-

tainable Evolution Strategy. Springer, Berlin.

Guermazi, S., Tatibouet, J., Cuccuru, A., Seidewitz, E.,

Dhouib, S., and G

erard, S. (2015). Executable mod-

eling with fUML and Alf in Papyrus: Tooling and ex-

periments. 1st Int. Workshop on Executable Modeling

co-located with ACM/IEEE 18th MODELS, vol. 1560

CEUR, p. 3–8.

Hawblitzel, C., Howell, J., Kapritsos, M., Lorch, J. R.,

Parno, B., Roberts, M. L., Setty, S., and Zill, B.

(2015). IronFleet: proving practical distributed sys-

tems correct. 25th Symp. on Operating Systems Prin-

ciples, SOSP, p. 1–17, NY, USA. ACM.

Konnov, I., Kuppe, M., and Merz, S. (2022). Speciﬁca-

tion and veriﬁcation with the TLA+ Trifecta: TLC,

Apalache, and TLAPS. Leveraging Applications of

Formal Methods, Veriﬁcation and Validation, p. 88–

105, Springer.

oger, F. and Merz, S. (2008). Temporal logic and state

systems. Texts in Theoretical Computer Science. An

EATCS Series. Springer.

Kuppe, M. A. (2023). Teaching TLA+ to engineers at Mi-

crosoft. Formal Methods Teaching Workshop, LNCS,

vol 13962, p. 66–81, Springer.

Kurshan, R. P. (2018). Transfer of model checking to in-

dustrial practice. Handbook of Model Checking, p.

763–793, Springer.

Kwon, G. (2000). Rewrite rules and operational semantics

for model checking UML statecharts. UML 2000 —

The Uniﬁed Modeling Language, LNCS, vol 1939, p.

528–540, Springer.

Lamport, L. (1987). A fast mutual exclusion algorithm.

ACM Trans. Comput. Syst., 5(1):1–11.

Lamport, L. (2002). Specifying Systems: The TLA+ Lan-

guage and Tools for Hardware and Software Engi-

neers. Addison-Wesley, USA.

Lamport, L. (2005a). Real time is really simple. MSR-

TR-2005-30, Microsoft Research, Dept. of Electron-

ics and Computer Science.

Lamport, L. (2005b). Real-time model checking is re-

ally simple. Correct Hardware Design and Veriﬁca-

tion Methods, 13th IFIP Advanced Research Work-

ing Conf., CHARME, vol. 3725 LNCS, p. 162–175.

Springer.

Lamport, L. (2024). A science of concurrent programs. ver-

sion 7th June. https://lamport.azurewebsites.net/tla/

science.pdf.

Latella, D., Majzik, I., and Massink, M. (1999). Automatic

veriﬁcation of a behavioural subset of UML statechart

diagrams using the SPIN model-checker. Form. Asp.

Comput., 11(6):637–664.

Mart

ınez, Y., Cachero, C., and Meli

a, S. (2012). Evaluat-

ing the impact of a model-driven web engineering ap-

proach on the productivity and the satisfaction of soft-

ware development teams. Web Engineering, ICWE,

LNCS, vol 7387, p. 223–237, Springer.

McColl, C., Estivill-Castro, V., McColl, M., and Hexel,

R. (2022a). Decomposable and executable models

for veriﬁcation of real-time systems. Revised papers

9th Int. Conf., MODELSWARD, vol. 1708 of CCIS, p.

135–156. Springer.

Merz, S. (2019). Formal speciﬁcation and veriﬁcation, p.

103–129. ACM, NY, USA.

Moreira, G., Vasconcellos, C., and Kniess, J. (2022). Fully-

tested code generation from TLA+ speciﬁcations. 7th

Brazilian Symp. Systematic and Automated Software

Testing, SAST ’22, p. 19–28, NY, USA. ACM.

Newcombe, C., Rath, T., Zhang, F., Munteanu, B., Brooker,

M., and Deardeuff, M. (2015). How Amazon web

services uses formal methods. Commun. ACM,

58(4):66–73.

Nicol

as, J. and Toval, A. (2009). On the generation of re-

quirements speciﬁcations from software engineering

models: A systematic literature review. Information

and Soft. Technology, 51(9):1291–1307.

Niyogi, R. and Nath, A. (2024). Formal speciﬁcation and

veriﬁcation of a team formation protocol using TLA+.

Soft.: Practice and Experience, 54(6):961–984.

Patil, S., Dubinin, V., and Vyatkin, V. (2015b). Formal ver-

iﬁcation of IEC61499 function blocks with abstract

state machines and SMV – modelling. IEEE Trust-

com/BigDataSE/ISPA, vol. 3, p. 313–320.

Pham, V. C., Radermacher, A., G

erard, S., and Li, S.

(2017). Complete code generation from UML state

machine. 5th Int. Conf. Model-Driven Engineering

and Software Development, MODELSWARD, p. 208–

219. SciTePress.

Posse, E. and Dingel, J. (2016). An executable formal se-

mantics for UML-RT. Softw. Syst. Model., 15(1):179–

217.

Sahu, S., Schorr, R., Medina-Bulo, I., and Wagner, M. F.

(2020). Model translation from Papyrus-RT into the

nuXmv model checker. Software Engineering and

Formal Methods. SEFM, vol. 12524 LNCS, p. 3–20.

Springer.

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering