Formal Verification of Autonomous Vehicle Group Control Systems via Specification Translation of Multitask Hybrid Observational Transition Systems

Abstract

In multitasking systems, concurrent execution leads to an exponential growth of the state space, posing significant challenges for formal verification. This complexity is further exacerbated in hybrid systems that integrate discrete and continuous dynamics. To address these challenges, we propose to model multitasking hybrid systems and systematically verify system properties through formal verification methods, using synergistic formal verification of model checking and theorem proving to ensure rigorous correctness analysis. We, therefore, introduce a transformation framework that converts behavioral specifications into rewrite specifications, enabling the integration of verification techniques from both approaches. To demonstrate the effectiveness of our approach, we model self-driving car group control systems as Multitask Hybrid Observational Transition Systems (MHOTS), a framework extending Observational Transition Systems (OTS) to support hybrid and multitask behaviors, specify their safety properties in theorem proving via CafeOBJ, in model checking via real-time Maude, and verify that the system remains safe regardless of the number of processes involved. The approach leverages specification translation between CafeOBJ and Real-Time Maude to exploit the complementary strengths of theorem proving and model checking. CafeOBJ is an algebraic specification language that provides a rigorous mathematical foundation for theorem proving, enabling the verification of system properties through logical deductions, while Real-Time Maude facilitates model checking, thereby enhancing the safety and reliability of autonomous vehicle systems. This methodology not only confirms the safety properties of the control system but also establishes a robust framework for the future development and validation of autonomous driving technologies. The integration of these formal verification techniques provides a rigorous and systematic approach to ensuring the desired properties of Multitask Hybrid Observational Transition systems, contributing to the advancement of safe and reliable autonomous driving solutions.

1. Introduction

In multitasking systems, ensuring safety and correctness is a crucial challenge, particularly when hybrid systems involve both discrete and continuous dynamics. The complexity of formal verification in such systems grows exponentially with the number of concurrent processes, making traditional verification techniques inefficient.

To address this issue, we propose a specification translation approach that systematically integrates theorem proving with CafeOBJ, an algebraic specification language designed for formal verification, and model checking with Real-Time Maude, a tool for executable specification and formal analysis of real-time systems, leveraging their complementary strengths (Figure 1). By transforming behavioral specifications into rewrite specifications, we enable rigorous safety verification of multitask hybrid systems.

Figure 1 shows the complementary strengths of CafeOBJ and Real-Time Maude in specification transformation. CafeOBJ on the upper side features interactive theorem proving, provides rigorous logical reasoning, and is suitable for infinite state space verification, but it requires a lot of manual interaction, which limits automation. Real-Time Maude on the lower side represents fully automatic model checking, providing efficient finite state space exploration, but may encounter scalability challenges due to state explosion. The middle arrow symbolizes the specification transformation mechanism that connects these two methods, effectively combining the rigorous accuracy of theorem proving with the automation and efficiency of model checking. This integration enhances the comprehensiveness, efficiency, scalability, and robustness of verification, thereby effectively addressing errors or oversights that may occur when verifying complex multitask hybrid systems.

As a case study, we apply this method to autonomous vehicle group control systems, where safety properties are critical. Autonomous vehicle group control systems are considered multitask systems. These autonomous vehicles exhibit both continuous behaviors (such as speed and position) and discrete behaviors (such as pedal action). Hybrid systems combine continuous and discrete dynamic behaviors, making them suitable for accurately representing autonomous vehicle control systems. We verify that the vehicles maintain a safe distance under the defined constraints, preventing collisions. Furthermore, we also provide a counterexample to verify our theoretical analysis.

Traditional testing and simulation tools, such as CarMaker (https://www.ipg-automotive.com/en/products-solutions/software/carmaker/) (accessed on 2 April 2025) [1], and SUMO (https://eclipse.dev/sumo/) (accessed on 2 April 2025) [2], offer valuable insights but are insufficient for ensuring comprehensive safety due to their reliance on limited and predetermined scenarios. Formal methods, encompassing various theories, tools, and techniques, are extensively utilized in the development of software and hardware systems. These methods describe, design, analyze, and verify computational systems using mathematical and logical foundations, thus providing precise and unambiguous definitions of system behaviors and properties. Formal specifications reduce ambiguity and errors, enhancing system reliability and correctness. Formal verification, which includes techniques like theorem proving and model checking, ensures that systems conform to their specifications.

There have been several important case studies in the domain of transportation systems verification using formal methods. For instance, KeYmaeraX (https://keymaerax.org/publications.html) (accessed on 2 April 2025) [3] has been effectively utilized to formally verify the collision avoidance protocols in airborne systems, demonstrating its strength in handling hybrid systems with complex continuous dynamics and rigorous safety requirements. CafeOBJ (https://cafeobj.org/) (accessed on 2 April 2025) [4] has been applied to formally model and verify autonomous vehicle systems, highlighting its capability in interactive theorem proving and specification of multitasking systems. Similarly, UPPAAL (https://uppaal.org/) (accessed on 2 April 2025) [5] has been successfully employed to verify railway timetable correctness and scheduling constraints, benefiting from its real-time model checking abilities to verify timing properties systematically. Real-time Maude (https://olveczky.se/RealTimeMaude/index.html) (accessed on 2 April 2025) [6] has also demonstrated significant advantages in the railway domain, particularly in verifying the European Rail Traffic Management System (ERTMS), showcasing its effectiveness in specifying and verifying complex real-time constraints and behaviors.

These studies collectively emphasize the complementary strengths of theorem proving (e.g., CafeOBJ and KeYmaeraX) and model checking (e.g., UPPAAL and Real-Time Maude). Inspired by these works, our research specifically leverages the synergy between CafeOBJ’s interactive theorem proving and Real-Time Maude’s automated model checking, providing a robust and rigorous verification methodology tailored explicitly for autonomous vehicle group control systems.

Theorem proving involves the generation of mathematical proofs through the collaboration between humans and computers. This semi-automated method is applicable to systems with infinite state spaces and supports continuous variables. Conversely, model checking is a fully automated approach for formal verification but is limited by the state space constraints. By the specification translation between the theorem proving and model checking, we can take advantage of both approaches to ensure the safety property of the system as

Table 1. Characteristics of Model checking and Theorem proving.

Formal Verification	Theorem Proving	Model Checking
Example	CafeOBJ	Real-Time Maude
Advantage	infinite state spaces	fully-automated
Disadvantage	semi-automated	finite state spaces

. The necessity of our specification translation method stems from the integration of the respective advantages of theorem proving and model checking in a multitask hybrid system. By converting specifications between CafeOBJ and Real-Time Maude, our approach effectively combines the advantages of both verification approaches, making formal verification more efficient and reliable.

Although existing verification tools such as KeYmaeraX and UPPAAL have demonstrated their advantages in specific domains, they still face certain challenges in efficiency and scalability when applied to multi-task hybrid systems with rapidly growing state spaces. Although KeYmaeraX provides powerful formal proofs, its reliance on manual theorem proving may limit its scalability and automation in practice. Despite its advantages in automatic verification, UPPAAL may face significant challenges due to the state explosion problem as the system complexity increases.

Our approach achieves a balanced trade-off by explicitly integrating theorem proving and model checking via specification transformation between CafeOBJ and Real-Time Maude. This integration leverages the ability of theorem proving to rigorously handle infinite state spaces and the ability of model checking to automatically explore state spaces and quickly detect errors. As a result, it improves verification efficiency and system scalability, especially for scenarios involving control systems of large-scale autonomous vehicle groups.

Table 1 intentionally presents a qualitative rather than quantitative comparison between theorem proving (CafeOBJ) and model checking (Real-Time Maude). The main reason is that these methods differ fundamentally in their operational paradigms. Interactive theorem proving heavily depends on human guidance and thus exhibits high variability in metrics like execution time and memory usage, primarily influenced by user interaction patterns. In contrast, model checking is fully automated and produces explicit quantitative measures (such as time and memory consumption), which are highly dependent on specific state-space characteristics and computational resources. Therefore, a direct, meaningful quantitative comparison (e.g., execution times or memory consumption) could mislead or fail to capture the true complementary nature of these methods. Instead, Table 1 emphasizes intrinsic methodological differences, clearly highlighting their relative strengths and limitations to illustrate why integrating both techniques provides significant verification advantages.

In our previous work, we proposed a way to describe and verify an autonomous vehicle control system (single vehicle) by the CafeOBJ method [7], and explored specification translation from CafeOBJ to Maude for a single vehicle [8]. Then, we investigated a method to describe the formal specification of a control system for groups of autonomous vehicles based on the CafeOBJ method [4].

In comparison to Maude [9,10], Real-Time Maude introduces an explicit time concept, allowing for the direct modeling and analysis of systems with time constraints [11]. This extension provides a variety of time patterns and timers capable of describing diverse time-related behaviors and events within a system [12]. Furthermore, Real-Time Maude supports temporal logic, facilitating the description and verification of the temporal properties inherent in real-time systems [13]. Consequently, Real-Time Maude enhances the functionalities of Maude by enabling it to handle systems with time constraints more effectively.

The contributions of this work include: 1. Based on the framework of formal specification of multitask hybrid systems, we propose a novel specification transformation method that systematically integrates interactive theorem proving and fully automated model checking. Compared to existing methodologies that typically rely solely on theorem proving (e.g., CafeOBJ) or exclusively on model checking (e.g., Real-Time Maude), our method benefits from their complementary strengths: theorem proving’s capability in rigorously handling infinite-state spaces and complex hybrid dynamics, and model checking’s efficiency in automatically exploring state spaces and detecting potential errors rapidly. 2. By applying our proposed integrated method, we successfully verified the safety characteristics of autonomous vehicle group control systems. Compared with other formal verification studies in transportation (such as airborne collision avoidance verification by KeYmaeraX, railway scheduling verification by UPPAAL, and ERTMS verification by Real-Time Maude), our methodology not only achieves comprehensive verification results with rigorous proof scores but also demonstrates enhanced robustness, specifically due to the ability to identify critical counterexamples via automated model checking, ensuring the early detection and correction of potential specification errors.

The structure of this thesis is as follows: Section 1 provides an overview of the research problem, highlights the challenges in the formal verification of multitask hybrid systems, and introduces the proposed approach. Section 2 shows the definition of the Multitask Hybrid Observational Transition Systems(MHOTS) framework, explaining its components and mathematical foundations. Section 3 describes how MHOTS is formally specified using the CafeOBJ language. Section 4 presents the verification methodology of theorem proving using the proof score to ensure system correctness. Section 5 details the translation of CafeOBJ specifications into Real-Time Maude for model checking. Section 6 conducts simulations and model checking to verify safety properties and provides a counterexample demonstrating system failure under reduced safety constraints. Section 7 summarizes the contributions of this research and outlines potential directions for future work.

2. The Multitask Hybrid Observational Transition Systems

An Observational Transition System (OTS) consists of a set of observers, a set of initial states and a set of transitions. There are some researches on timed OTS (TOTS) [14], hybrid OTS (HOTS) [15], multitask timed OTS (MTOTS) [16]. OTS is a formal framework used for specifying and verifying system behaviors based on a set of observations, transitions, and states. To extend the concept of OTS to multitask and hybrid systems, we introduce MHOTS, which incorporate both discrete and continuous state transitions, as well as multiple interacting processes.

2.1. Definition of MHOTS

Let $Time$ be a densely ordered set of clock values. We assume a universal state space Y, a set $Pid$ of process identifiers, and sets D of values indexed by observers. In OTSs, a system state, an element of Y, is not explicitly represented. States and transitions are identified through observers in OTSs. In MHOTSs, we distinguish global, local, discrete and continuous observers and transitions explicitly, where global ones are given for the whole system’s behavior and local ones are given for processes.

Definition 1.

An MHOTS $\mathcal{S}=(\mathcal{O},\mathcal{I},\mathcal{T}$) consists of the following:

• $\mathcal{O}$: A set of observers.
  The set $\mathcal{O}$ = ${\mathcal{O}}_{GD}\cup {\mathcal{O}}_{LD}\cup {\mathcal{O}}_{GC}\cup {\mathcal{O}}_{LC}$ is classified into a set ${\mathcal{O}}_{GD}$ of global discrete observers; ${\mathcal{O}}_{LD}$, local discrete observers; ${\mathcal{O}}_{GC}$, global continuous observers and ${\mathcal{O}}_{LC}$, local continuous observers.
  Each global observer $o\in {\mathcal{O}}_{GD}\cup {\mathcal{O}}_{GC}$ is a function $o:\mathsf{{\rm Y}}\to D_o$, where $D_o$ is a data type. Similarly, each local observer $o\in {\mathcal{O}}_{LD}\cup {\mathcal{O}}_{LC}$ is a function $o:Pid\times \mathsf{{\rm Y}}\to D_o$. We write $o_i\left(s\right)$ instead of $o(s,i)$, and we denote $o_i$ as an element of $\mathcal{O}$ and $o_i:\mathsf{{\rm Y}}\to D_{o_i}$ for $o\in {\mathcal{O}}_{LD}\cup {\mathcal{O}}_{LC}$ and $i\in Pid$ if no confusion occurs. The equivalence relation ${=}_{\mathcal{S}}\subset \mathsf{{\rm Y}}\times \mathsf{{\rm Y}}$ between two states is defined as the observational equivalence, i.e., $s_1$ ${=}_S{s}_2$ if and only if $\forall o\in \mathcal{O}$. $o\left(s_1\right)=o\left(s_2\right)$. ${\mathcal{O}}_{GC}$ has a special master clock $now$ that observes the elapsed time since the execution of $\mathcal{S}$ began.
• $\mathcal{I}$: A set of initial states such that $\mathcal{I}\subset \mathsf{{\rm Y}}$.
• $\mathcal{T}$: A set of transitions.
  $\mathcal{T}={\mathcal{T}}_{GD}\cup {\mathcal{T}}_{LD}\cup {\mathcal{T}}_C$ is divided into a set ${\mathcal{T}}_{GD}$ of global discrete transitions, a set ${\mathcal{T}}_{LD}$ of local discrete transitions, and a set ${\mathcal{T}}_C$ of continuous transitions. Each $\tau \in {\mathcal{T}}_{GD}$ (or $\tau \in {\mathcal{T}}_{LD}$) is a function $\tau :\mathsf{{\rm Y}}\to \mathsf{{\rm Y}}$ (or $\tau :\mathsf{{\rm Y}}\times Pid\to \mathsf{{\rm Y}}$). For $i\in Pid$ and $d\in Time$, we may write ${\tau }_i\in \mathcal{T}$ and $tic{k}_d\in \mathcal{T}$, respectively, if no confusion occurs. All transitions $\tau \in \mathcal{T}$ preserve ${=}_{\mathcal{S}}$, that is, $\tau \left(s_1\right){=}_{\mathcal{S}}\tau \left(s_2\right)$ whenever $s_1{=}_{\mathcal{S}}{s}_2$. Every transition τ has an effective condition defined as $c-\tau$. For $\tau \in \mathcal{T}$, its effective condition is given as a function $c-\tau :\mathsf{{\rm Y}}\to Bool$ (or $c-\tau :Pid\times \mathsf{{\rm Y}}\to Bool$). If $c-\tau \left(s\right)$ (or $c-\tau (i,s)$) is false then $\tau \left(s\right)=s$ (or $\tau (i,s)=s$). ${\mathcal{T}}_{\mathcal{C}}$ has only one special continuous transition $tick:Time\times \mathsf{{\rm Y}}\to \mathsf{{\rm Y}}$, that is, ${\mathcal{T}}_C=\left\{tick\right\}$, called a time advancing transition. If $s^{\prime }=tick(t,s)$ and it is effective, then $now\left(s^{\prime }\right)$ = $now\left(s\right)+t$ for each $t\in Time$ and $s\in \mathsf{{\rm Y}}$.

where the time advancing transition $tick$ satisfies the following condition:

• For each continuous observer $o\in {\mathcal{O}}_{GC}\cup {\mathcal{O}}_{LC}$, we define a flow constraint $nex{t}_o:Time\times \mathsf{{\rm Y}}\to D_o$ for global ones, or  $nex{t}_o:Pid\times Time\times \mathsf{{\rm Y}}\to D_o$ for local ones, which constrains the evolution of the values of o, that is, $nex{t}_o(t,s)$ (or $nex{t}_o(i,t,s)$) returns the value observed by o (or $o_i$) after time t from state s.
• For discrete observers ${\mathcal{O}}_{GD}\cup {\mathcal{O}}_{LD}$, we call a tuple of all their observed values a location. The set $Loc$ of locations is defined as

  $$Loc={\displaystyle \prod _{o\in {\mathcal{O}}_{GD}\cup {\mathcal{O}}_{LD}}{D}_o}.$$
• For each observer $o\in {\mathcal{O}}_{GC}\cup {\mathcal{O}}_{GD}$ (or $o_i\in {\mathcal{O}}_{LC}\cup {\mathcal{O}}_{LD}$), we assume there is a corresponding symbol $x_o$ (or $x_{o_i}$), which is called a variable in ordinary hybrid automata. We denote the set of all such variables by X.
• We define an invariant for each location, where the hybrid system can stay at the location as long as the invariant is true. An invariant function $inv:Loc\to PConstr\left(X\right)$ gives the evolution domain restriction $inv\left(l\right)$, called an invariant condition of location $l\in Loc$, where $PConstr\left(X\right)$ is the class of polynomial constraints over the set of continuous variables X. For example, $p=(x+{\displaystyle \frac{1}{2}}y>z)\in PConstr\left(X\right)$ is a polynomial constraint over $\{x,y,z\}$. For $p\in PConstr\left(X\right)$ and a valuation v : $X\to D$ where D is the union of all $D_o$, a boolean value ${⟦p⟧}_v$ is the result of replacing x with $v\left(x\right)$. For example, for a valuation υ such that $\upsilon \left(x\right)=1,\upsilon \left(y\right)=2,\upsilon \left(z\right)=3$, the boolean value ${⟦p⟧}_{\upsilon }=1+{\displaystyle \frac{1}{2}}·2>3$ is false.
  We assume $inv\left(l\right)$ is a conjunction of $in{v}_o\left(d\right)$ for all $o\in {\mathcal{O}}_{GD}\cup {\mathcal{O}}_{LD}$ and $d\in D_o$, that is, $inv\left((d_1,\dots ,d_n)\right)$ = $in{v}_{o_1}\left(d_1\right)\wedge \cdots \wedge in{v}_{o_n}\left(d_n\right)$, where $in{v}_o:D_o\to PConstr\left(X\right)$.
• The time advancing transition $tick$ should satisfy the following conditions: for $s^{\prime }=tick(t,s)$, $o\left(s^{\prime }\right)=nex{t}_o(t,s)$ for $o\in {\mathcal{O}}_{GC}$ and $o(i,s^{\prime })=nex{t}_o(i,t,s)$ for $o\in {\mathcal{O}}_{LC}$ whenever $c-tick(t,s)$ is true.
• The effective condition $c-tick:Time\times \mathsf{{\rm Y}}\to Bool$ is defined as follows: $c-tick(t,s)=true$ if and only if
  $\forall o_d\in {\mathcal{O}}_{GD}$. $\forall o_c\in {\mathcal{O}}_{GC}\cup {\mathcal{O}}_{LC}$. $d=o_d\left(s\right)$ ∧ $v\left(x_{o_c}\right)=nex{t}_{o_c}(t,s)$ ∧ $v\left(x_{o_d}\right)=o_d\left(s\right)$ ⇒ ${⟦in{v}_{o_d}\left(d\right)⟧}_v$, and
  $\forall o_d\in {\mathcal{O}}_{LD}$. $\forall o_c\in {\mathcal{O}}_{GC}\cup {\mathcal{O}}_{LC}$. $d=o_d(i,s)$ ∧ $v\left(x_{o_c}\right)=nex{t}_{o_c}(t,s)$ ∧ $v\left(x_{o_d}\right)=o_d\left(s\right)$ ⇒ ${⟦in{v}_{o_d}\left(d\right)⟧}_v$
  Roughly speaking, $tick(t,s)$ is effective when all of the invariant conditions hold with the values of the continuous observers after time t, that is, $nex{t}_o(t,s)$.

Definition 2.

An execution of an MHOTS S = ($\mathcal{O},\mathcal{I},\mathcal{T}$) is a (finite or infinite) sequence $s_i\in \mathsf{{\rm Y}}$ ($i\in \{0,1,\dots ,n\}$ or $i\in \mathbb{N}$) of states satisfying $s_0\in \mathcal{I}$, and for each $s_i$, there exists $\tau \in \mathcal{T}$ such that $s_{i+1}$ = $\tau \left(s_i\right)$. A state s is called reachable if it is included in an execution of S. A state predicate $p:\mathsf{{\rm Y}}\to Bool$ is called invariant if $p\left(s\right)$ is true for all reachable states s. We denote the set of the reachable states by $RS$.

The explicit distinction among global, local, discrete, and continuous observers in MHOTS significantly improves verification accuracy by structuring system modeling and verification processes more systematically and precisely: Global observers capture system-wide state properties (e.g., system time, shared environmental conditions), enabling global invariants and conditions to be rigorously defined and verified at a high level of abstraction. This ensures correctness across the entire system state space. Local observers allow for the accurate and scalable verification of properties specific to individual processes or components (e.g., each vehicle’s velocity, position, or operational state). By isolating local behaviors, verification can more accurately pinpoint specific sources of errors or violations of system properties. Discrete observers clearly specify distinct modes or states of the system or individual components, facilitating precise reasoning about mode transitions and state-dependent properties. They provide clarity and accuracy in modeling state-dependent constraints and invariants, reducing ambiguity and errors during formal verification. Continuous observers explicitly describe dynamic variables that evolve continuously over time (such as velocity and position). Clearly defining continuous behaviors separately from discrete behaviors allows for an accurate and robust analysis of system dynamics under real-world physical constraints. This systematic classification of observers not only clarifies the semantics of the system being verified but also allows verification techniques (theorem proving and model checking) to be tailored specifically to different aspects of the system. Consequently, it enhances the verification’s precision, reduces the likelihood of oversights or ambiguities, and improves the accuracy and reliability of verification outcomes, especially when dealing with complex multitasking hybrid systems.

2.2. Illustrative Example of MHOTS: A Two-Tank Water Flow System

To intuitively illustrate the core principles of MHOTS, consider a simple yet illustrative toy example—a hybrid control system involving two interconnected water tanks with a controllable valve. Suppose we have two vertically aligned water tanks (Tank A at the top, Tank B at the bottom) connected by a valve-controlled pipe. The system exhibits hybrid behaviors due to both discrete control actions (opening/closing a valve) and continuous dynamic changes (water flow between tanks). The objectives of this simplified system are to maintain the water level in Tank B within safe limits and avoid overflow and underflow scenarios by controlling the valve discretely based on continuous water level observations. This scenario can be naturally modeled as an MHOTS as follows:

• $\mathcal{O}$: Observers
  Discrete Observers (${\mathcal{O}}_D$): valve state ∈ $\{open,closed\}$ indicating the status of the valve connecting two tanks.
  Continuous Observers (${\mathcal{O}}_C$): level A ∈ $\mathbb{R}$ ≥ 0: Water level in Tank A; level B ∈ $\mathbb{R}$ ≥ 0: Water level in Tank B; now ∈ $\mathbb{R}$ ≥ 0: Global system time.
• $\mathcal{I}$: The initial conditions of the state.
  The initial valve state is closed: valve(init) = closed
  Tank A and Tank B initial water levels: levelA(init) = 10, levelB(init) = 2.
  Initial system time: now(init) = 0.
• $\mathcal{T}$: Transitions
  Continuous transitions are governed by the following set of differential equations: When the valve is open:

  $${\displaystyle \frac{d\left(levelA\right)}{dt}}=-k;{\displaystyle \frac{d\left(levelB\right)}{dt}}=k,$$
  When the valve is closed:

  $${\displaystyle \frac{d\left(levelA\right)}{dt}}=0;{\displaystyle \frac{d\left(levelB\right)}{dt}}=0.$$
  Here, the constant k represents the water flow velocity (assumed to be $k=1$ unit/s). So the next function can be defined following
  When the valve is open:

  $$nex{t}_{levelA}(t,s)=levelA\left(s\right)-k·t;nex{t}_{levelB}(t,s)=levelB\left(s\right)+k·t$$
  When the valve is closed:

  $$nex{t}_{levelA}(t,s)=levelA\left(s\right);nex{t}_{levelB}(t,s)=levelB\left(s\right)$$
  Time Observer:

  $$nex{t}_{now}(t,s)=now\left(s\right)+t$$
  The position invariant constraint is that the water levels of Tank A and Tank B must always satisfy:

  $$levelA\ge 0;0\le levelB\le 10$$
  Therefore, the effective condition for continuous migration is as follows:

  $$c_{t}ick(t,s)=(nex{t}_{levelA}(t,s)\ge 0)\wedge (0\le nex{t}_{levelB(t,s)}\le 10)$$
  Define the following valve state transition rules (discrete transitions):
  Open valve:
  Transition condition: Tank B water level is lower than the lower threshold (e.g., levelB ≤ 3).

  $$c_{open}\left(s\right)=(value\left(s\right)=closed)\wedge (levelB\le 3)$$
  Behavior: The valve changes from closed to open.

  $$value\left(s\right)=openif{c}_{open}\left(s\right).$$
  Close valve:
  Transition condition: The water level of Tank B reaches the upper threshold (for example, levelB ≥ 8).

  $$c_{closed}\left(s\right)=(value\left(s\right)=open)\wedge (levelB\ge 8)$$
  Behavior: The valve changes from open to closed.

  $$value\left(s\right)=closedif{c}_{closed}\left(s\right).$$
  At this time, the water level (levelA, levelB) and time (now) do not change.

2.3. Fundamental Assumptions of MHOTS

Before specifying MHOTS in CafeOBJ, one may encounter the challenge of an almost infinite process. For instance, when defining the effective tick ($c-tick$), it is necessary to verify invariants at non-initial location. However, due to the near-infinite property of this process, verifying the invariants of the effective tick, such as $in{v}_o(p,d)(\overrightarrow{nex{t}_o(s,t)}$), becomes significantly challenging.

To solve this problem, we introduce the specification $PSet$ which is the sequence of processes. We define the $ps$ as the observation that observes the sort $PSet$, where we assume the $ps\left(s\right)$ is the arbitrary set of finite processes exist in non-initial location.

There are only infinite processes that exist in the initial location when ${⟦in{v}_{o_D\left(label\right)}⟧}_{\upsilon }$ is true. We assume $O_{LC}=\{o_1,\dots ,o_m\}$, $O_{GC}=\{o_1^{\prime },\dots ,o_n^{\prime }\},X=\{x_{o_1},\dots ,x_{o_m},x_{o_1^{\prime }},\dots ,x_{o_n^{\prime }}\}$, then

$$\upsilon \left(x_{o_i}\right)=o_i\left(init\right)$$

$$\upsilon (x_{o_j^{\prime }})=o_j^{\prime }(p,init)$$

After applying the transition tick, the initial condition

$$o_i\left(tick(t,s)\right)=o_i\left(init\right)$$

$$o_j^{\prime }(p,tick(t,s))=o_j^{\prime }(p,init)$$

Finite processes in non-initial location satisfy invariant. And ${⟦inv\left(d\right)⟧}_{\upsilon }$ is PConstr(X) which indicate

$$\upsilon (x_{o_i})=nex{t}_{o_i}(t,s)$$

$$\upsilon (x_{o_j^{\prime }})=nex{t}_{o_j^{\prime }}(p,t,s)$$

for all $x\in X$.

These define the continuous evolution of system variables over time, governed by constraints such as follows:

• Velocity update: $v^{\prime }\left(i\right)=v\left(i\right)+a\left(i\right)\times \Delta t$.
• Position update: $x^{\prime }\left(i\right)=x\left(i\right)+v\left(i\right)\times \Delta t+{\displaystyle \frac{1}{2}}a\left(i\right)\times \Delta t^2$.

3. Multitask Hybrid OTS/CafeOBJ Specifications

In this section, we propose a way to describe a CafeOBJ specification whose model is an MHOTS that we have defined.

3.1. Specification of Sets of Processes

One of the advantages of MHOTS is that it allows us to model a system with an arbitrary number of processes, whereas an ordinary automaton approach cannot represent a state with infinitely many processes in a finite-length tuple of variables. However, when we describe an MHOTS specification, we need to give definitions of invariants for all processes. It may make the size of the specification infinite. To avoid this problem, we assume that almost all processes are in a certain location, such as the initial location, whose invariant condition holds in any reachable state. Then, in any reachable state, it is sufficient to check a finite number of processes that are not in the location. In our example, the initial locations of all, possibly infinite, vehicles are $start$, and only finite vehicles are located at $accel$, $brake$ or $nothing$. The observed set $ps\left(s\right)$ is introduced to gather all but finitely many vehicles that have entered by the transition $enter$.

mod* PID{
  [Pid]
  pred _=_ : Pid Pid {comm}
  var P : Pid
  eq (P = P) = true .
}
		

First, we define a module named PID in CafeOBJ language (mod* PID{}). A data type Pid ([Pid]) is defined as a data type that represents the identifier of the vehicle process ID. A predicate ( _=_ : Pid Pid ) is defined to determine whether two Pids are equal. {comm} indicates that the predicate satisfies the commutative law. A variable P (var P : Pid) is defined as a universal variable that represents an element of Pid type. An equation (axiom) is defined as (eq (P = P) = true). This equation indicates that any Pid is equal to itself (reflexive). That is, for any P, the value of the equation P = P is always true.

Then, we define PSET, a module for sets of processes of PID, as follows:

mod! PSET{
  pr(PID)
  [Pid < PSet]
  op nil : -> PSet
  op _ _ : PSet PSet -> PSet {assoc idr: nil}
  op dummy : -> Pid
  pred _in_ : Pid PSet
  pred empty : PSet
  op first : PSet -> Pid
  op last : PSet -> Pid
  op _sub_ : PSet PSet -> Bool
  op ps : -> PSet
  …
}
		

Module PSET imports PID. Sort PSet is declared as a super sort of Pid, which means a single process of Pid is also an element PSet. Constant $\mathtt{nil}$ denotes the empty set, and operator $\text{\_}\text{\_}$ defines a sequence of terms of sort $\mathtt{Pid}$ as a term of sort $\mathtt{PSet}$. Constant dummy of Pid is declared as a dummy element when taking an element from the empty set. Some ordinary functions on sets are declared. For a given set, elements are lined up in order, thus, it can be regarded as a list, a queue, or a sequence of processes. For example, operator $\mathtt{last}$ takes the last element of a given set. The term last(p4 p3 p2 p1) is equivalent to p4 by applying the equation last(P PS) = P with $\mathtt{P}=\mathtt{p}\mathtt{4}$ and $\mathtt{PS}=\mathtt{p}\mathtt{3}\mathtt{p}\mathtt{2}\mathtt{p}\mathtt{1}$.

3.2. System Description of MHOTSs in CafeOBJ

In this section, we give a way to describe a system module $\mathcal{M}$ of an MHOTS $\mathcal{S}$ in CafeOBJ. Module $\mathcal{M}$ imports data modules, including PSET, which was defined above. For sort $Time$, we choose a built-in arithmetic module of CafeOBJ, for example, the built-in module RAT of rational numbers. The universal state space $\mathsf{{\rm Y}}$ is represented by a hidden sort, denoted as H. We assume that the data types $D_o$ for $o\in \mathcal{O}$ are described in imported data modules and that there are visible sorts $V_o$ corresponding to the data types, and that variables used in the following equations are declared. For example, variable S of sort H, T of sort $Time$, P, Q of sort Pid, and PS, QS of sort PSet are declared.

Definition 3.

An MHOTS/CafeOBJ specification has the following syntax:

• $OTS$ :: = $\overrightarrow{SubModule}$ $MainModule$
• $SubModul{e}_i$ :: = mod(!|*) $S{M}_i$$\left\{...\right\}$
• $MainModule$ :: = mod* M {
• pr(S $M_1$)… pr(S $M_l$)
• *[H]*
• $Signature::=Init$$\overrightarrow{Obs}$$\overrightarrow{Trans}$
• $Axiom$ ::= $Vars$ $A_{init}$ $A_{{\tau }_1}$ … $A_{{\tau }_m}$
• $Init$ ::= op init : $\to H$.
• $A_{init}$ ::= $A_{init}^{o_{G_1}}$ … $A_{init}^{o_{G_m}}$ $A_{init}^{o_{L_1}}$ … $A_{init}^{o_{L_m}}$
• $A_{init}^{o_G}$ ::= eq $o_G$(init) = $t_{ini{t}_{o_G}}$.
• $A_{init}^{o_L}$ ::= eq $o_L$(init,$X_i$) = $t_{ini{t}_{o_L}}$.
• $Ob{s}_G$ ::= bop $o_G$ : H $\to V_{o_G}$
• $Ob{s}_L$ ::= bop $o_L$ : H $X_i$ $\to V_{o_L}$
• $Tran{s}_i$ ::= $B{T}_i$ $C{T}_i$
• $B{T}_i$ ::= bop ${\tau }_i$ : H $X_i$ $\to H$
• $C{T}_i$ ::= bop $c-{\tau }_i$ : H $X_i$ → Bool
• $A_{{\tau }_i}^{\perp }$ ::= bceq ${\tau }_i$ (S,$Y_i$) = S if not (c-${\tau }_i$(S,$Y_i$)).
• $A_{{\tau }_i}^{o_G}$ ::= ceq $o_G$(${\tau }_i$(S,$Y_i$)) = $t_{{\tau }_{o_G}}$’ if c-${\tau }_i$(S,$Y_i$).
• $A_{{\tau }_i}^{o_L}$ ::= ceq $o_L$(${\tau }_i$(S,$Y_i$), $X_i$) = $t_{{\tau }_{o_L}}$’ if c-${\tau }_i$(S,$Y_i$).
• $Vars$ ::= $VH$ $\overrightarrow{V{O}_1}$ … $\overrightarrow{V{O}_m}$ $\overrightarrow{V{T}_1}$ … $\overrightarrow{V{T}_n}$
• $VH$ ::= vars S: H
• $V{O}_i$ ::= vars $X_i$: $V_{o_i}$
• $V{T}_i$ ::= vars$Y_i$: $V_{{\tau }_i}$
• }

where each $SubModul{e}_i$ is a module specifying data type, explained in the previous section. $S{M}_i$ is the name of the module $SubModul{e}_i$. H is a hidden sort. Each initial state in the set $\mathcal{I}$ is represented by a constant, conventionally denoted as $init$. $o_G$ and $o_L$ are observation symbols when the each global observer $o_G\in {\mathcal{O}}_{GD}\cup {\mathcal{O}}_{GC}$ and each local observer $o_L$∈ ${\mathcal{O}}_{LD}$∪${\mathcal{O}}_{LC}$. $t_{ini{t}_{o_G}}$ and $t_{ini{t}_{o_L}}$ are terms of visible sort $V_{o_G}$ and $V_{o_L}$, respectively. ${\tau }_i$ is a transition symbol that is defined as a behavioral operator and $c-{\tau }_i$ is an effective condition of transition described as a boolean operator. When a condition of transition is effective, the transition and observed values of the state will change by the equation. The condition of an equation is a boolean term. $t_{{\tau }_{o_G}}$’ and $t_{{\tau }_{o_L}}$’ are terms of visible sorts $V_{o_G}$ and $V_{o_L}$, respectively, like $t_{ini{t}_{o_G}}$ and $t_{ini{t}_{o_L}}$. $X_i(i=1,\dots ,m)$ and $Y_i(i=1,\dots ,m)$ are CafeOBJ variables for $V_{o_i}$ and $V_{{\tau }_i}$. Hereafter, all definitions and proofs are built on the notation of Definition 3.

3.3. A Case Study of the MHOTS/CafeOBJ Method

In this section, we present an MHOTS/CafeOBJ specification $\mathcal{MS}$ and verify the safety property, ensuring that vehicles do not collide with each other in any reachable state, using the proof score method.

The purpose of this model and specification is to verify that the vehicle can maintain a safe distance between any two vehicles in its initial state when performing any operation (such as braking or acceleration) (Figure 2). Regardless of how many vehicles are moving in the lane, when the distance between two vehicles is too close ($▵x>8$), it must switch to braking mode and fix the pedal state to braking to avoid a collision.

In the OTS/CafeOBJ specifications, a state transition system models the group control system of an autonomous vehicle, incorporating five types of observations. The continuous observations v and x capture the current values of variables v and x for each vehicle, now and ps track the elapsed time and the list of all vehicles. Meanwhile, the discrete observation loc tracks the vehicle’s present location, which is used to determine the position of the preceding vehicle.

The system provides five transition types for both discrete and continuous behaviors. The discrete transitions enter, a, b, and n represent state changes, while the continuous transition tick updates the system clock. We formalize these transitions within the OTS/CafeOBJ modules.

A CafeOBJ specification is structured by modules that contain declarations for sorts, operators, and equations. Our OTS/CafeOBJ specification includes data modules LABEL, PSET, and RAT, along with the system module MAINSYSTEM, illustrated in Figure 3.

An OTS/CafeOBJ specification consists of data modules and a system module. LABEL as the data module provides the constant operators start, accel, nothing, and brake defined as the data type Label for the vehicle.

 ops start accel nothing brake : -> Label
		

The following is the system module named MAINSYSTEM, which has the protecting modules PSET, RAT, and LABEL. The RAT module is used to define rational numbers. The velocity, position, and time all start from 0. The initial position of vehicle P is set to start. ps is empty, indicating that there may be no known previous vehicles in the system.

mod* MAINSYSTEM{
  pr(PSET + RAT + LABEL)
 …
 eq v(P,init) = 0 .   eq x(P,init) = 0 .   eq now(init) = 0 .
 eq loc(P,init) = start .  eq ps(init) = nil .
		

The transition enter, by which the vehicle enters the lane, is defined by the following equations:

eq c-enter(P,S)= (loc(P,S) = start) and (ps(S) = nil or x(last(ps(S)),S) > 0) .
ceq ps(enter(P,S))= P ps(S) if c-enter(P,S) .
ceq loc(P',enter(P,S))= (if P' = P then accel else loc(P',S) fi) if c-enter(P,S) .
eq v(P',enter(P,S))= v(P',S) . eq x(P',enter(P,S))= x(P',S) .  …
		

where the first equation specifies that enter is effective when the location is start and either the set of entered vehicles is empty or the last vehicle of the set is not at position 0. Only ps and loc are changed by enter, while the other observed values remain unchanged. The value of ps at the state after applying enter, that is, ps(enter(P,S)), is the set P ps(S) obtained by adding P at the end of the original set ps(S). Only the P’s location is updated to accel by enter(P,S). We omitted the transitions a b and n similar to enter.

Then, we specify the continuous transition tick(x,s), which represents the state obtained after advancing time by x from state s. Discrete values remain unchanged under tick, as follows:

eq loc(P,tick(T,S)) = loc(P,S) .
		

The continuous values v and x changed with tick as follows:

ceq v(P,tick(T,S)) = (if loc(P,S) = start then 0 else nextv(P,T,S) fi)
                     if c-tick(T,S) .
ceq x(P,tick(T,S)) = (if loc(P,S) = start then 0 else nextx(P,T,S) fi)
                     if c-tick(T,S) .
eq nextv(P,T,S) = v(P,S) + ac(loc(P,S)) * T .
eq nextx(P,T,S) = v(P,S) * T + 1/2 * ac(loc(P,S)) * T * T + x(P,S) .
eq ps(tick(T,S)) = ps(S) .
		

where the acceleration value of the vehicle is defined for each location by operation ac, where accel, brake, and nothing are 1, $-1$, and 0, respectively. The values of v and x after tick are defined as the next values of them when the locations are not start. Note that we specify that the values of v and x are always 0 at the location start. As the system time advances (tick(T, S)), the state of ps (which is a queue of all vehicles) remains unchanged.

The effective condition c-tick(ps(S),T,S) is recursively defined on PSet as follows:

eq c-tick(nil,T,S) = true.
 
eq c-tick(P,T,S) = ((loc(P,S) = brake or loc(P,S) = accel or loc(P,S) = nothing)
                   implies (0 <= nextv(P,T,S) and nextv(P,T,S) <= 4)) .
 
eq c-tick(P Q,T,S) = c-tick(Q,T,S) and c-tick(P,T,S) and
                    (loc(P,S) = accel implies (nextx(P,T,S) + 8 < nextx(Q,T,S)))
                    and (loc(P,S) = nothing implies (((0 < nextv(P,T,S) and
                    nextv(P,T,S) <= 4)  and (nextx(P,T,S) + 8 < nextx(Q,T,S))))
                    or nextv(P,T,S) = 0) .
 
eq c-tick(P Q PS,T,S) = c-tick(P Q,T,S) and c-tick(Q PS,T,S) .
 
eq c-tick(T,S) = c-tick(ps(S),T,S) .
		

Each vehicle obeys the speed limit between 0 and 4, as described in the second equation. In the third equation, for the two next vehicles P and Q, they obey the speed limit as well as the part of the invariant condition between the vehicles such that the distance is more than eight when the location of the behind vehicle P is accel, and  so is nothing if the velocity is not 0. By the fourth and fifth equations, all next vehicles in ps(S) satisfy the invariant condition. For example, from the recursive definition, c-tick(p3 p2 p1,T,S) is equivalent to c-tick(p3,T,S) and c-tick(p2,T,S) and c-tick(p1,T,S) and c-tick(p3 p2,T,S) and c-tick(p2 p1,T,S).

4. Verification of the Theorem Proving

A purpose of verification is to ensure no collisions in our system, that is, for each vehicle P and its next vehicle Q in ps(S) for any reachable state $S\in RS$, the position of P is always greater than that of Q, denoted by x($P,S$) < x($Q,S$). To formalize the property to be verified, we first describe a predicate safe in a module SAFE such that $\forall S\in RS.$ safe(ps(S),S) represents our goal. Next, we give a stronger property of our goal with formal verification. Finally, we give a formal proof of the stronger property based on the proof score method. In the proof score method, we describe several invariant properties inv-n to be proven in a module INV and a predicate istep-n which represents an inductive step of our proof by induction on the structure of reachable states. The structure of modules we use for verification is shown in Figure 4.

4.1. Module for the Safety Property

In the module SAFE, a predicate safe : PSet Sys -> Bool is recursively defined as follows:

  eq safe(nil,S) = true .
  eq safe(P,S) = true .
  eq safe(P Q,S) = (x(P,S) < x(Q,S)) .
  eq safe(P Q PS,S) =
  safe(P Q,S) and safe(Q PS,S) .
		

For example, safe(p4 p3 p2 p1,T,S) is reduced into x(p4,S) < x(p3,S) and x(p3,S) < x(p2,S) and x(p2,S) < x(p1,S). Thus, our goal is represented by $\forall S\in RS.$safe(ps(S),S).

To apply induction techniques, we generalize our subgoal as follows: $\forall S\in RS.\forall PS\in \mathtt{PSet}.PS\mathtt{sub}\mathtt{ps}\left(S\right)\Rightarrow \mathtt{safe}(PS,S)$, where $PS$ is a subsequence of $\mathtt{ps}\left(S\right)$.

Since $PS$ sub $PS$ holds by definition, the above property is stronger than the original goal. Thus, it suffices to show the above subgoal for our goal. We prove the subgoal by induction on $PS$. The base case $PS=\mathtt{nil}$ is trivial since $\mathtt{safe}(\mathtt{nil},\mathtt{S})=\mathtt{true}$ from the definition of safe. Consider the case of $PS=QQS$ where $Q\in \mathtt{Pid}$ and $QS\in \mathtt{PSet}$. There are two cases, such that $QS=\mathtt{nil}$ and $QS=Q^{\prime }Q{S}^{\prime }$ where $Q^{\prime }\in \mathtt{Pid}$ and $Q{S}^{\prime }\in \mathtt{PSet}$. The former is trivial since $PS=Q$ and $\mathtt{safe}(Q,S)=\mathtt{true}$ from the definition of safe. In the latter case, we have

$$\begin{array}{c}\mathtt{safe}(PS,S)\hfill \\ =\mathtt{safe}(Q{Q}^{\prime }Q{S}^{\prime },S)\hfill \\ =\mathtt{safe}(Q{Q}^{\prime },S)\mathtt{and}\mathtt{safe}(Q^{\prime }Q{S}^{\prime },S).\hfill \end{array}$$

From the definition, we have $\mathtt{safe}(Q{Q}^{\prime },S)=(x(Q,S)<x(Q^{\prime },S))$. From the induction hypothesis, we have $\mathtt{safe}(Q^{\prime }Q{S}^{\prime },S)=\mathtt{safe}(QS,S)=true$. Therefore, If $x(Q,S)<x(Q^{\prime },S)$ is proven, our goal holds. The above reasoning can be formalized and verified by the proof score method.

4.2. Induction Basis

From the above reasoning, it suffices to show $\forall S\in RS.\forall Q,Q^{\prime }\in \mathtt{Pid}.\forall Q{S}^{\prime }\in \mathtt{PSet}.Q{Q}^{\prime }Q{S}^{\prime }\mathtt{sub}\mathtt{ps}\left(S\right)\Rightarrow x(Q,S)<x(Q^{\prime },S)$ for our goal. First, we give a state predicate inv1 as follows:

eq inv1(Q,Q',QS',S) = (Q Q' QS' sub ps(S) implies (x(Q,S) < x(Q',S))) .
		

If we prove inv1(S) for all reachable states from the initial state, the safety property holds. We prove it by the induction of the structure of the reachable states. Note that a reachable state is represented by the term like ${\tau }_n(\cdots {\tau }_1\left({\tau }_0\left(\mathtt{init}\right)\right)\cdots )$, which is the result state obtained by applying transitions ${\tau }_0,{\tau }_1,\dots ,{\tau }_n$ to the initial state.

As the induction basis, we apply the reduction command to prove the initial state to satisfy inv1. In specification execution, the reduction command is applied to terms without any variable. We use fresh constant operators, like q, q’ and qs’ below, as arbitrary elements.

open INV .
    red inv1(q,q',qs',init) .
close
		

CafeOBJ interpreter returns true, which implies the induction basis holds, that is, inv1 holds at the initial state.

4.3. Induction Step

In the induction step, we prove that each transition preserves the state predicate. We first assume inv1(s) holds for a state s. Then, we prove inv1(s’) for the state s’ obtained by applying each transition to the state s. The following is a template for the induction step.

eq istep1 = inv1(s) implies inv1(s') .
		

The proposition istep1 means that inv1(s’) holds under the induction hypothesis inv1(s). The following is a part of the induction steps for the transition tick, where s’ is obtained by applying the tick with t1 to s.

open ISTEP .
    op t1 : -> Rat .
    eq s' = tick(t1,s) .
    red istep1 .
close
		

If the above reduction returns true, it guarantees that the implication inv1(S) ⇒ inv1(tick(T,S)) holds for any state S and time T. However, it returns neither true nor false for the above proof passage. To proceed with a proof, we need to give more information. A typical proof strategy is case splitting by the effective condition as follows:

open ISTEP .
    op t1 : -> Rat .
    eq c-tick(t1,s) = false .
    eq s' = tick(t1,s) .
    red istep1 .
close
		

open ISTEP .
    op t1 : -> Rat .
    eq c-tick(t1,s) = true .
    eq s' = tick(t1,s) .
    red istep1 .
close
		

If the above two proof passage return true, the original one holds. Although the first passage returns true, the second does not. In this case, we proceed to do more case-splitting for the latter passage by q = q’, qs’ = nil and so on. These candidates of cases can be found in the result term of the proof passage. When we obtain true for all cases, it guarantees that the original proof passage is satisfied.

4.4. Lemma Introduction

Repeating the process of case splitting, we may face false as a returned value of the reduction command. Such a proof passage represents either evidence that the goal does hold or that the state satisfying the conditions in the proof passage is unreachable from the initial state. For such a case, we introduce another appropriate invariant property, called a lemma, which discharges the unreachable proof passage. For example, we introduce the following lemma inv2:

eq inv2(P,S) = (loc(P,S) = start implies x(P,S) = 0) .
eq istep2 = inv2(s) implies inv2(s') .
		

We may obtain true for such a proof passage by replacing the reduction command by adding the lemma as follows:

red inv2(s) implies istep1 .
		

Proceeding with case-splitting and introducing the lemma in this case study, we obtain true for all the remaining proof passages for inv1. This means that we have verified property ∀s ∈ RS, inv2(s)⇒ inv1(s) by the proof score method. To complete a proof, we make four lemmas and 264 proof passages, all of which return true. The introduced lemmata inv2, inv3, and inv4 are defined as follows:

eq inv1(Q,Q',QS',S) = (Q Q' QS' sub ps(S) implies (x(Q,S) < x(Q',S))) .
eq inv2(P,S) = (loc(P,S) = start implies x(P,S)=0) .
eq inv3(P,S) = (P in ps(S)) implies (not loc(P,S) = start) .
eq inv4(Q,Q',QS',S) = (Q Q' QS' sub ps(S) implies (x(Q,S) < (- 1/2 * v(Q,S)
* v(Q,S)) + x(Q',S))) .
		

In addition, we need to add some lemmata that can be proved without induction on reachable states, e.g., eq lemma1(QS,T,S) = ((c-tick(T,S) and (QS sub ps(S))) implies c-tick(QS,T,S)), which we proved by induction on the structure of terms of sort PSet.

5. Specification Translation to Real-Time Maude

The purpose of the MHOTS/CafeOBJ specification is to verify its safety property by an interactive theorem proving approach with the CafeOBJ system. Interactive theorem proving is capable of dealing with large and complex systems, including those with infinitely many states; however, making a complete proof usually requires human guidance and, thus, is not fully automated. For example, Diaconescu and Futatsugi [17] introduced CafeOBJ as an algebraic specification language with powerful interactive theorem-proving capabilities, emphasizing its strength in dealing with infinite-state systems through behavioral equational logic. Ogata and Futatsugi [18] further elaborated on the interactive nature of CafeOBJ proofs by introducing the concept of proof scores, providing practical methodologies for system verification that rely significantly on user expertise. Additionally, Ogata and Futatsugi [19] provided detailed practical insights and guidelines for structuring interactive proofs in CafeOBJ effectively, highlighting typical challenges and solutions in verifying complex, multitask systems.

In contrast, our research contributes by combining the strengths of interactive theorem proving (CafeOBJ) with fully automated model checking (Real-Time Maude), addressing the inherent limitation of automation in theorem proving. By integrating these two approaches, our proposed methodology not only enhances the verification efficiency but also systematically ensures robustness by enabling the automatic detection of counterexamples.

Especially for the case that the property is not true, due to the bug of the specification, the verifier may not find the failure of the specification and the proof process may not terminate. To solve the problem, we propose a specification translation method from CafeOBJ to Real-Time Maude such that we can apply the full-automated model checking function to the translated Real-Time Maude specification to find a potential bug in the input MHOTS/CafeOBJ specification. A Real-Time Maude specification is composed of two kinds of modules: functional modules and a system module [20,21]. The functional modules correspond to data modules in CafeOBJ.

5.1. Specification Translation

We give a translation from an MHOTS/CafeOBJ specification whose submodules are tight and complete into an MHOTS/Real-Time Maude specification. Precisely, we give a function F that takes an MHOTS/CafeOBJ specification and returns an MHOTS/Real-Time Maude specification. We write $X^{\prime }$ instead of $F\left(X\right)$. For example, we write ${Signature}^{\prime }$ = $\overrightarrow{Ob{s}^{\prime }}$ $\overrightarrow{Tran{s}^{\prime }}$ instead of $F\left(Signature\right)=F\left(O{b}_{s_1}\right)F\left(O{b}_{s_2}\right)\dots F\left(Tran{s}_1\right)F\left(Tran{s}_1\right)\dots$, which means that a signature of the translated MHOTS/Real-Time Maude specification $F\left(MHOTS\right)$ = ${MHOTS}^{\prime }$ consists of symbols which are obtained by applying F to observation and transition symbols of the input $MHOTS$.

Definition 4.

For an MHOTS/CafeOBJ specification, the translated MHOTS/Real-Time Maude specification is defined as follows:

• $MHOT{S}^{\prime }$ = $\overrightarrow{SubModul{e}^{\prime }}$ $MainModul{e}^{\prime }$
• $SubModul{e}_i^{\prime }$ = (fmod  $S{M}_i$ … endfm)
• $MainModul{e}^{\prime }$ = (tmod  M is
• pr $S{M}_i$ . … pr $S{M}_l$.
• $Signatur{e}^{\prime }$ = $\overrightarrow{Ob{s}^{\prime }}$ $\overrightarrow{Tran{s}^{\prime }}$
• ${\overrightarrow{Ob{s}_G}}^{\prime }$ = op $o_G$ : $V_{o_G}$ → System.
• ${\overrightarrow{Ob{s}_L}}^{\prime }$ = op $o_L$ : $X_i$ $V_{o_L}$ → OValue.
• ${\overrightarrow{Tran{s}_i}}^{\prime }$ = op c-${\tau }_i$: $\overrightarrow{V_{{\tau }_i}}$ System → Bool.
• $Var{s}^{\prime }$ = $Var{s}_1^{\prime }$$Var{s}_2^{\prime }$$Var{s}_m^{\prime }$
• $A_{{\tau }_i}^{\prime }$ = crl [ ${\tau }_i$ ]: $t_{{\tau }_{o_G}}$ … $t_{{\tau }_{o_L}}$ … $=>$ $t_{{\tau }_{o_G}}$’ … $t_{{\tau }_{o_L}}$’ …if c-${\tau }_i$.
• $A_{init}^{\prime }$ = eq init = $t_{ini{t}_{o_G}}$ … $t_{ini{t}_{o_L}}$ …
• $Axio{m}^{\prime }=Var{s}^{\prime }\cup A_{init}^{\prime }\cup A_{{\tau }_i}^{\prime }$
• endtm)

where MHOTS’ denote the formal model of MHOTS implemented by Real-Time Maude, $\overrightarrow{SubModul{e}^{\prime }}$ is a group of submodules, $MainModul{e}^{\prime }$ is the main module. The submodule is responsible for defining the basic operators and axioms of the system, and the main module combines multiple submodules through inheritance to realize the complete system model. Submodule $SubModul{e}_i^{\prime }$ is defined using Real-Time Maude’s Functional Module (fmod) and the main module is defined using the Real-Time Module (tmod), which represents the overall behavior of the system. The main module imports the contents of the submodule through the pr $\overrightarrow{SubModul{e}^{\prime }}$ similar to cafeOBJ. The algebraic signature consists of an observer operator and a transformation rule operator and observers are divided into global observers and local observers The c-${\tau }_i$ is a conjunction of boolean expressions, equality tests, membership tests, and (in the case of rewrite rules) rewrite tests. A rewrite rule is usually equipped with a rule label [${\tau }_i$]. Each transformation rule is formally represented by a conditional rewrite rule (crl), where $t_{{\tau }_o}$ and $t_{{\tau }_o}$’ represent the observer results before and after the transformation, respectively, and c-${\tau }_i$ is the transformation condition. The initial state is defined by the equation axiom (eq), which represents the initial configuration of the system. The system axiom set consists of a set of variables, initial states, and transition rules. This formal description ensures the accessibility, determinism, and consistency of the system.

The translation process from a CafeOBJ specification to a Real-Time Maude specification is systematically carried out in the following step-by-step manner as Algorithm 1:

• Step 1: Identification and Preparation of Modules.
  CafeOBJ: Identify the main system module and all submodules, including data modules (e.g., LABEL, PID, PSET).
  Real-Time Maude: Correspondingly define a Real-Time Maude functional module (fmod) for each CafeOBJ data module and a system module (tmod) for the CafeOBJ system module.

• Step 2: Sorts and Subsorts Translation
  Translate CafeOBJ sorts to Real-Time Maude sorts.
  Declaring subsort relationships explicitly in Real-Time Maude using the subsort keyword to maintain sort hierarchies.

• Step 3: Operator Translation
  Translate CafeOBJ operators (op) to Real-Time Maude operators, preserving the arity and type signature. For example, a CafeOBJ observer is defined as follows:

  $$boploc:HPid->Label$$

  translates into Real-Time Maude as follows:

  $$oploc:PidLabel->OValue.$$

• Step 4: Initial State Translation
  Translate the CafeOBJ initial state (e.g., eq init = …) into Real-Time Maude as an equation defining the initial configuration of the system. For example, from cafeobj

  $$eqv(P,init)=0.eqloc(P,init)=start.$$
  Translate into Real-Time Maude:

  $$eqinit\left(P\right)=v(P,0)loc(P,start).$$

• Step 5: Transition Translation
  Translate CafeOBJ transitions (defined by equations and conditional equations) into Real-Time Maude rewrite rules (rl, crl).
  The effective condition of transitions (c-$\tau$) in CafeOBJ is explicitly translated into the condition part of conditional rewrite rules (if c-$\tau$) in Real-Time Maude. For example, from cafeobj

  $$ceqloc(P,enter(P,S\left)\right)=accelifc-enter(P,S).$$
  Translate into Real-Time Maude:

  $$crl\left[enter\right]:loc(P,start)=>loc(P,accel)ifc-enter(P,S).$$

• Step 6: Consistency Check and Verification
  Perform initial consistency checks by simulation using Real-Time Maude (trew command). Apply Real-Time Maude model checking (tsearch command) to verify safety properties and discover potential errors.

Algorithm 1: TranslateSpec (CafeOBJ_Spec)

Input: CafeOBJ_Spec Output: Real-Time Maude_Spec 1. Extract all submodules from CafeOBJ_Spec. 2. For each submodule:       a. Map sorts and operators to Real-Time Maude format.       b. For each transition $\tau$ with effective condition c-$\tau$:          :            Define corresponding rewrite rule in Real-Time Maude:                 crl [$\tau$] : PreState => PostState if c-$\tau$ holds. 3. For each predicate used in verification:       Map to equivalent Real-Time Maude boolean functions. 4. Assemble all mapped modules into the final Real-Time Maude_Spec. 5. Return Real-Time Maude_Spec.

By following these systematic steps, the translation ensures semantic equivalence and maintains verification integrity between CafeOBJ and Real-Time Maude specifications.

5.2. A Case Study of the MHOTS/Real-Time Maude Method

We apply the specification translation to the MHOTS/CafeOBJ specification to obtain a Real-Time Maude specification. We call the output Real-Time Maude specification an MHOTS/Maude specification. The Real-Time Maude specification consists of a few functional modules and a system module. A few functional modules define data types and operations on them by means of equational theories. A system module specifies a rewrite theory. A rewrite rule denotes a transition. We show the result of the specification translation, which consists of a functional module LABEL PID PSET and a system module MAINSYSTEM. Firstly, we show a functional module LABEL to specify the data types of our system.

(fmod LABEL is
  sort Label .   ops start accel nothing brake : -> Label . ...
endfm)
		

ops indicates the definition of multiple operators, that is, symbolic constants that can be represented. start, accel, nothing, brake are the names of labels, representing the four control states of the vehicle.

We present a system module MAINSYSTEM, which specifies the multitask hybrid observational behavior of our system. The MAINSYSTEM module imports LABEL and PSET as similar to the CafeOBJ one, and POSRAT-TIME-DOMAIN to describe time-related properties. In Real-Time Maude, a state is defined as an explicit set of observed values. To specify the states, we introduce sorts like Label < OValue < System, indicating that Label is a subsort of OValue, and OValue is a subsort of System.

(tmod MAINSYSTEM is including (LABEL + PSET) .
  protecting POSRAT-TIME-DOMAIN .
  protecting RAT .
  sort OValue .
  subsorts Label < OValue < System .
  op loc : Pid Label -> OValue .
  ops v x : Pid Rat -> OValue .
  op init : -> System .
  eq init(P) = (v(P,0)x(P,0))loc(P,start) .
  ...
 endtm)
		

loc(P, L) represents the location of process P, represented by label L. Pid represents the unique identifier of the process (Process Identifier). v(Pid, Rat) and x(Pid, Rat) represent the velocity and position coordinates of process P, respectively. init defines the initial state of the system. System represents the state type of the entire system. init(P) means that the initial velocity and initial position are 0, and the initial state label is the initial state of the system of start. The local observations $o_L:H{X}_i\to V_{o_L}$ defined in the OTS/CafeOBJ specification are translated into operations $o_L$ : $X_i$ $V_{o_L}$ → $OValue$ of Real-Time Maude. For example, loc(P, start) is a term of the sort OValue.

In the translated Real-Time Maude specification, a specification transition is translated into a rewrite rule on terms of System as follows:

 crl [a] : loc(P,L) => loc(P,accel) if not (L = start) .
 crl [b] : loc(P,L) => loc(P,brake) if not (L = start) .
 crl [n] : loc(P,L) => loc(P,nothing) if not (L = start) .
 rl [enternil] : (loc(P,start)ps(nil)) => (loc(P,accel)ps(P)) .
 crl [enterPS] : ((loc(P,start)ps(Q PS))x(Q,X)) => ((loc(P,accel)ps(P Q PS))
 x(Q,X)) if (0 < X) .
		

For example, the above first rewrite rule named by [a] takes any observed value of locations (except start) and rewrites it into the value of accel. When the vehicle is in the start state, we discuss two cases. If ps is empty (nil), P enters the accel state and becomes the only member of the queue ps; if ps is not empty and Q’s position X > 0, then P enters the accel state and joins after Q from ps(Q PS) to ps(P Q PS).

 eq update(T,((loc(P,L)v(P,V))x(P,X))OVS) =
 ((loc(P,L)v(P,nextv(L,P,T,V)))x(P,nextx(L,P,T,V,X)))update(T,OVS) .
		

The update equation updates the process state (vehicle’s position x and velocity v). The OVS serves the system’s multitasking as an object variable of other processes. The v(P,nextv(L,P,T,V)) calculates the new velocity of P after T time. The x(P,nextx(L,P,T,V,X)) calculates the new position of P after T time. The update(T,OVS) is responsible for updating the speed and position of all processes.

The tick rule allows the process state of the entire system to advance within T time units. c-tick(T, OVS) is used as a condition to ensure that the advancement within T time units is reasonable (such as whether the velocity and position constraints are met). The tick rule ensures that updates can only occur when c-tick allows, preventing unreasonable time advancement.

 crl [tick] : {OVS} => {update(T,OVS)} in time T if c-tick(T,OVS) .
 eq c-tick(nil,T,OVS) = true .
 eq c-tick(T,ps(PS)OVS) = c-tick(PS,T,ps(PS)OVS) .
		

If the process queue PS is empty, return true (allow time to advance). If PS is not empty, check the c-tick constraints one by one on PS as follows.

 eq c-tick(P,T,loc(P,L)v(P,V)x(P,X)OVS) = ((L = brake) or (L = accel) or
    (L = nothing)) implies (0 <= nextv(L,P,T,V) and nextv(L,P,T,V) <= 4) .
 
 eq c-tick(P2 P1,T,loc(P2,L2)v(P2,V2)x(P2,X2)loc(P1,L1)v(P1,V1)x(P1,X1)OVS)
    = c-tick(P2,T,loc(P2,L2)v(P2,V2)x(P2,X2)OVS) and c-tick(P1,T,loc(P1,L1)
    v(P1,V1)x(P1,X1)OVS) and (L2 = accel implies (nextx(L2,P2,T,V2,X2) + 8
    < nextx(L1,P1,T,V1,X1))) and (L2 = nothing implies (0 < nextv(L2,P2,T,V2)
    and nextv(L2,P2,T,V2) <= 4 and nextx(L2,P2,T,V2,X2) + 8 < nextx(L1,P1,T,
    V1,X1)) or nextv(L2,P2,T,V2) == 0) .
		

When a single process P is in brake, accel or nothing state, ensure that nextv(L, P, T, V) calculates a new velocity in the range [0, 4] (i.e., the velocity is not too large or too small). When two processes appear in the system, we need to ensure that P1 and P2 both comply with the c-tick rule of a single process P, but also need additional constraints. If P2 accelerates: Make sure that P2’s new position nextx(P2) is not too close to P1 (at least 8 units away). If P2’s speed remains unchanged: Make sure nextv(P2) is between [0, 4]. Make sure the minimum distance between P2 and P1 is 8. P2 can also stop when (nextv(P2) is 0). This prevents the two cars from getting too close and ensures a safe distance.

 eq c-tick(P2 P1 PS,T,loc(P2,L2)v(P2,V2)x(P2,X2)loc(P1,L1)v(P1,V1)x(P1,X1)OVS)
    = c-tick(P2 P1,T,loc(P2,L2)v(P2,V2)x(P2,X2)loc(P1,L1)v(P1,V1)x(P1,X1)OVS)
    and c-tick(P1 PS,T,...OVS) .
		

When there are multiple processes P2 P1 PS in the system. Recursively check whether P2 P1 and P1 PS meet the c-tick rule. Ensure that all processes meet the c-tick constraint.

6. Verification of the Model Checking

In this section, we show a simulation of the translated Real-Time Maude specification with the command trew and verification with model checking with the command tsearch to confirm the specification translation works well and is useful to find bugs in the original specification. In the below code, the sampling time is defined as 1 (in time 1), which means that the application of tick advances time by 1.

6.1. Simulation

The Real-Time Maude rewrite command is used to simulate one behavior of a given term t, denoted by

		trew [n] t in time < T
		

where the bracketed number n provides an upper bound for the number of rule applications and T provides an upper bound on the total duration [22,23]. We show an example of the application of the rewrite command to the module MAINSYSTEM where the first line is an input and below it is the output.

(trew [2] {loc(p1,start)ps(nil)} in time < 20 .)
Result ClockedSystem : {update(1,ps(p1)loc(p1,accel))} in time 1
		

The command trew performs time rewriting to simulate the state change in process p1 and the result shows that update(1, ps(p1) loc(p1,accel)) indicates that p1 enters the accel state at time T = 1.

This set of simulation code demonstrates time-constrained rewriting in Real-Time Maude language, simulating the behavior of process p1, focusing on the changes in velocity (v) and position (x), as well as the transition of process state (loc). The code mainly shows the process of p1 from acceleration (accel), velocity limit, and finally braking (brake).

(trew [4] {loc(p1,accel)v(p1,0)x(p1,0)ps(p1)} in time < 20 .)
Result ClockedSystem : {ps(p1)loc(p1,accel)v(p1,4)x(p1,8)} in time~4
 
(trew [1] {loc(p1,accel)v(p1,4)x(p1,8)ps(p1)} in time < 20 .)
Result ClockedSystem :
  {ps(p1)loc(p1,accel)v(p1,4)x(p1,8)} in time~0
 
(trew [2] {loc(p1,accel)v(p1,4)x(p1,8)ps(p1)} in time < 20 .)
Result ClockedSystem :
  {ps(p1)loc(p1,brake)v(p1,4)x(p1,8)} in time 0
		

At the initial state, p1 is in the acceleration (accel) state; the velocity (v) increases from 0 to 4 units; the position (x) increases from 0 to 8 units; the process state is still accel, and the simulation time advances 4 units.

After the speed reaches 4 units, try to advance 1 time unit (trew [1]). But the system state has not changed, which means that there is no applicable time advancement rule under the current conditions (because the velocity limitation constraint is not satisfied: nextv(L,P,T,V) <= 4). Therefore, time does not advance (in time 0). The state is completely unchanged, indicating that p1 is still in the accel state but cannot continue to accelerate.

Then, try to advance 2 time units (trew [2]). But the simulation does not consume time (in time 0), indicating that the discrete behavior (loc(P,L) => loc(P,brake)) directly causes p1 to enter the brake state without waiting for time to advance. The state of p1 changes from accel to brake. The velocity v(p1,4) and position x(p1,8) do not change, which means that braking has just started, and the speed has not yet decreased.

(trew [13] {loc(p1,accel)v(p1,0)x(p1,0)ps(p1)} in time < 20 .)
Result ClockedSystem : {ps(p1)loc(p1,nothing)v(p1,0)x(p1,16)} in time 10
		

We then continued the simulation a few more times and observed that the vehicle begins to decelerate until its velocity reached 0, switched to the no-operation state (nothing), and finally stopped at position 16 units as shown in Figure 5, which not only intuitively shows the forward trajectory of a single vehicle, but also indirectly proves that the system can stably and correctly perform state transitions under the set operation rules.

We not only simulated the track of a single vehicle in Real-Time Maude, but also simulated the forward track and safety verification of two and three vehicles in the CafeOBJ environment, and proved that our safety properties are safe. Next, we simulated the scenario with two vehicles; the results show the system of vehicles p1 and p2, by applying a series of transitions $ente{r}_{p1}$, $tic{k}_4$, $n_{p1}$, $ente{r}_{p2}$, $tic{k}_4$, $n_{p2}$, and $tic{k}_2$ from the initial state. By repeatedly using the reduction command, we can display the time series data of the observations the sequence of processes ($ps$) , position (x) and velocity (v) (Figure 6).

open MAINSYSTEM .
%MAINSYSTEM> red ps(tick(2,n(p2,tick(4,enter(p2,n(p1,tick(4,enter(p1,init)))
))))) .
(p1 p2):PSet
%MAINSYSTEM> red x(p1,tick(2,n(p2,tick(4,enter(p2,n(p1,tick(4,enter(p1,init)
))))))) .
(32):NzNat
%MAINSYSTEM> red v(p1,tick(2,n(p2,tick(4,enter(p2,n(p1,tick(4,enter(p1,init)
))))))) .
(4):NzNat
%MAINSYSTEM> red x(p2,tick(2,n(p2,tick(4,enter(p2,n(p1,tick(4,enter(p1,init)
))))))) .
(16):NzNat
%MAINSYSTEM> red v(p2,tick(2,n(p2,tick(4,enter(p2,n(p1,tick(4,enter(p1,init)
))))))) .
(4):NzNat
		

We also verified and proved the scenario, which demonstrates the security of the system with two vehicles. The results show that the system with vehicles p1 and p2 apply a series of transitions $ente{r}_{p1}$, $tic{k}_4$, $n_{p1}$, $tic{k}_2$, $ente{r}_{p2}$, $tic{k}_4$, $n_{p2}$, $tic{k}_1$, $b_{p1}$, $tic{k}_4$, $n_{p1}$, and $tic{k}_1$ from the initial state. By using the reduction commands repeatedly, we display the time-series data of the observed values (Figure 7). The distance after a series of transitions is 12, and if the time advances one more unit, the set of active processes of vehicles p1 and p2 have a false c-tick.

open MAINSYSTEM .
%MAINSYSTEM> red x(p1,tick(1,n(p1,tick(4,b(p1,tick(1,n(p2,tick(4,enter(p2,
tick(2,n(p1,tick(4,enter(p1,init))))))))))))) .
(44):NzNat
%MAINSYSTEM> red v(p1,tick(1,n(p1,tick(4,b(p1,tick(1,n(p2,tick(4,enter(p2,
tick(2,n(p1,tick(4,enter(p1,init))))))))))))) .
(0):Zero
%MAINSYSTEM> red x(p2,tick(1,n(p1,tick(4,b(p1,tick(1,n(p2,tick(4,enter(p2,
tick(2,n(p1,tick(4,enter(p1,init))))))))))))) .
(32):NzNat
%MAINSYSTEM> red v(p2,tick(1,n(p1,tick(4,b(p1,tick(1,n(p2,tick(4,enter(p2,
tick(2,n(p1,tick(4,enter(p1,init))))))))))))) .
(4):NzNat
 
%MAINSYSTEM> red c-tick(2,n(p1,tick(4,b(p1,tick(1,n(p2,tick(4,enter(p2,tick(2,
n(p1,tick(4,enter(p1,init)))))))))))) .
(false):Bool
%MAINSYSTEM> red c-tick(1,n(p1,tick(4,b(p1,tick(1,n(p2,tick(4,enter(p2,tick(2,
n(p1,tick(4,enter(p1,init)))))))))))) .
(true):Bool
		

We verified and proved the scenario that has three vehicles; the result showed the system of vehicles p1, p2, and p3 that apply a series of transitions $ente{r}_{p1}$, $tic{k}_4$, $n_{p1}$, $tic{k}_2$, $ente{r}_{p2}$, $tic{k}_4$, $n_{p2}$, $tic{k}_2$, $ente{r}_{p3}$, and $tic{k}_3$ from the initial state. By using the reduction commands repeatedly, we can display a time-series data of observed values (Figure 8).

open MAINSYSTEM .
%MAINSYSTEM> red ps(tick(3,n(p3,tick(4,enter(p3,n(p2,(tick(4,enter(p2,n(p1,
tick(4,enter(p1,init)))))))))))) .
(p3 (p2 p1)):PSet
%MAINSYSTEM> red x(p1,tick(3,n(p3,tick(4,enter(p3,n(p2,(tick(4,enter(p2,n(p1,
tick(4,enter(p1,init)))))))))))) .
(52):NzNat
%MAINSYSTEM> red v(p1,tick(3,n(p3,tick(4,enter(p3,n(p2,(tick(4,enter(p2,n(p1,
tick(4,enter(p1,init)))))))))))) .
(4):NzNat
%MAINSYSTEM> red x(p2,tick(3,n(p3,tick(4,enter(p3,n(p2,(tick(4,enter(p2,n(p1,
tick(4,enter(p1,init)))))))))))) .
(36):NzNat
 %MAINSYSTEM> red v(p2,tick(3,n(p3,tick(4,enter(p3,n(p2,(tick(4,enter(p2,n(p1,
 tick(4,enter(p1,init)))))))))))) .
(4):NzNat
%MAINSYSTEM> red x(p3,tick(3,n(p3,tick(4,enter(p3,n(p2,(tick(4,enter(p2,n(p1,
tick(4,enter(p1,init)))))))))))) .
(20):NzNat
%MAINSYSTEM> red v(p3,tick(3,n(p3,tick(4,enter(p3,n(p2,(tick(4,enter(p2,n(p1,
tick(4,enter(p1,init)))))))))))) .
(4):NzNat
		

In other words, the state is the result of the following processes. First, we assume that the acceleration pedal of vehicle p1 is pushed after the vehicle starts and is held for four time units, and then the pedal is released for two time units. Next, the acceleration pedal of vehicle p2 is pushed after the vehicle starts and is held for four time units; the pedal is not pushed for two time units. Next, the acceleration pedal of vehicle p3 is pushed after the vehicle starts, and it is held for three time units.

6.2. Model Checking

The Real-Time Maude rewrite command is used to search for states matched by a pattern p satisfying a given condition c from a given initial state t, denoted by

		tsearch [n] t =>* p such that c in time < T
		

where the bracketed number n provides an upper bound for the number of solutions to be searched and T provides an upper bound on the total duration [24,25].

6.2.1. Model Checking with Discrete Behavior

We use tsearch to perform time-bounded reachability analysis and check whether there is a state transition that allows the system to evolve from loc(p1,start)ps(nil)(v(p1,0) x(p1,0)) to ps(p1)loc(p1,L:Label) v(p1,V:Rat)x(p1,X:Rat) and satisfy L == accel, that is, p1 enters the accel state and the total time is less than 50.

  (tsearch [1] {loc(p1,start)ps(nil)(v(p1,0)x(p1,0))} =>* {ps(p1)loc(p1,L:Label)
  v(p1,V:Rat)x(p1,X:Rat)} such that L == accel in time < 50 .)
  
Solution 1
L:Label --> accel ; TIME_ELAPSED:Time --> 0 ; V:Rat --> 0 ; X:Rat --> 0
		

Then, we obtain the execution result:

• Solution 1 indicates that a state that meets the conditions is found.
• L:Label –> accel indicates that p1 has indeed entered the accel state.
• TIME_ELAPSED:Time –> 0 indicates that the state transition occurs within 0 time units (i.e., instantaneous transition).
• V:Rat –> 0 and X:Rat –> 0 indicate that when entering the accel state, p1’s velocity v(p1,0) and position x(p1,0) are still 0.

This search verifies that p1 can be instantly transferred to accel in the start state without consuming time, which complies with the discrete conversion rules defined by the system.

6.2.2. Model Checking with Continuous Behavior

Velocity and distance as continuous observation ($o_C$) values are constrained when performing multiple tasks. When multiple tasks are performed simultaneously, the system requires that the velocity of each vehicle cannot exceed 4 units of time (0 <= nextv(L,P,T,V) <= 4), and the safety distance between the two vehicles should be more than 8 units (nextx(L2,P2,T,V2,X2) + 8 < nextx(L1,P1,T,V1,X1)).

(tsearch [1] {ps(p2 p1)loc(p2,accel)v(p2,0)x(p2,0)loc(p1,accel)v(p1,0)x(p1,9)}
=>* {ps(p2 p1)loc(p2,L2:Label)v(p2,V2:Rat)x(p2,X2:Rat)loc(p1,L1:Label)
v(p1,V1:Rat)x(p1,X1:Rat)} such that V2 > 4 in time < 50 .)
rewrites: 11040920744 in 232233443ms cpu (31227869ms real)
(47542 rewrites/second)
 
No solution
		  

The code was rewritten 11 billion times, taking 232,233.443 s (CPU time) and 31,227.869 s (real time), indicating that the amount of calculation is very large. No state that satisfies the conditions is found; that is, under the time limit of t < 50, the speed of p2 cannot exceed 4. The velocity constraint of p1 also meets the requirements of the system.

(tsearch [1] {ps(p2 p1)loc(p2,accel)v(p2,0)x(p2,0)loc(p1,accel)v(p1,0)x(p1,9)}
=>* {ps(p2 p1)loc(p2,L2:Label)v(p2,V2:Rat)x(p2,X2:Rat)loc(p1,L1:Label)
v(p1,V1:Rat)x(p1,X1:Rat)} such that V1 > 4 in time < 50 .)
rewrites: 11040920744 in 239387743ms cpu (32021922ms real)
(46121 rewrites/second)
 
No solution
		  

To verify the safety property of the system, we apply the command as follows:

(tsearch [1] {ps(p2 p1)loc(p2,accel)v(p2,0)x(p2,0)loc(p1,accel)v(p1,0)x(p1,9)}
=>* {ps(p2 p1)loc(p2,L2:Label)v(p2,V2:Rat)x(p2,X2:Rat)loc(p1,L1:Label)
v(p1,V1:Rat)x(p1,X1:Rat)} such that X2 >= X1 in time < 50 .)
rewrites: 11131793258 in 190739035ms cpu (44980131ms real)
(58361 rewrites/second)
 
No solution
		  

And the result is No solution, which means no state satisfying X2 >= X1 is found, i.e., p2 cannot catch up with p1 within t < 50.

6.2.3. Model Checking with Time Sampling $1/2$

The result of the Real-Time Maude search command may depend on a specific time sampling. We conduct experiments with different time sampling in the following sections.

We try to apply the search command with the time sampling $1/2$. First, we modify the definition of tick as follows:

(set tick def 1/2 .)
		  

where the occurrences of 1 are replaced with $1/2$.

Similar to the above search, we confirm that the rear car can approach the front car within 8 units.

(tsearch [1] {ps(p2 p1)loc(p2,accel)v(p2,0)x(p2,0)loc(p1,accel)v(p1,0)x(p1,9)}
=>* {ps(p2 p1)loc(p2,L2:Label)v(p2,V2:Rat)x(p2,X2:Rat)loc(p1,L1:Label)
v(p1,V1:Rat)x(p1,X1:Rat)} such that 8 > X1 - X2 in time < 20 .)
Solution 1
L2:Label --> brake ; L1:Label --> nothing ; TIME_ELAPSED:Time --> 2 ; V2:Rat
    --> 1 ; V1:Rat --> 0 ; X2:Rat --> 7/4 ; X1:Rat --> 37/4
		  

The result with time sampling $1/2$ is exactly the same as that with time sampling 1. When the vehicle is braking, there is no velocity limit or distance limit for the vehicle ahead.

Smaller time sampling searches more state space densely, which may find bugs that may not be found with coarse time sampling; however, it needs more computation time and spaces.

6.2.4. Model Checking with Time Sampling 5

We try to apply the search command with the time sampling 5 and modify the definition of tick as follows:

(set tick def 5 .)
		  

where the occurrences of 1 in the original one are replaced with 5 too. Since the time sampling is too coarse, we cannot find the situation where the distance between the rear vehicle and the front vehicle is less than 8 units as above, although there will be no collision between the two vehicles.

(tsearch [1] {ps(p2 p1)loc(p2,accel)v(p2,0)x(p2,0)loc(p1,accel)v(p1,0)x(p1,9)}
=>* {ps(p2 p1)loc(p2,L2:Label)v(p2,V2:Rat)x(p2,X2:Rat)loc(p1,L1:Label)
v(p1,V1:Rat)x(p1,X1:Rat)} such that 8 > X1 - X2 in time < 20 .)
No solution
		  

The search command with this coarse time sampling is considered to fail to find the situation of two vehicles approaching each other although the two vehicles did not collide. Thus, there is a trade-off between time sampling such that coarser time sampling may fail to find bugs and finer one may take more computation time and spaces.

6.3. Counterexample

We try to find a counterexample of the critical position between the vehicles, such as the following:

eq c-tick(P2 P1,T,loc(P2,L2)v(P2,V2)x(P2,X2)loc(P1,L1)v(P1,V1)x(P1,X1)OVS) =
... (L2 = accel implies (nextx(L2,P2,T,V2,X2) + 7 < nextx(L1,P1,T,V1,X1)))
and (L2 = nothing implies (0 < nextv(L2,P2,T,V2) and nextv(L2,P2,T,V2) <= 4
and nextx(L2,P2,T,V2,X2) + 7 < nextx(L1,P1,T,V1,X1)) ...) .
		  

In the previous part, we assume that the safe distance between the two vehicles is greater than 8 units when the maximum velocity of the vehicle does not exceed 4 units.

Now, we change the critical position between the vehicles from 8 to 7. Then, we found that at the same time, the position of the rear vehicle coincided with the position of the front vehicle, indicating that the two vehicles collided.

(tsearch [1] {ps(p2 p1)loc(p2,accel)v(p2,0)x(p2,0)loc(p1,accel)v(p1,0)x(p1,9)}
=>* {ps(p2 p1)loc(p2,L2:Label)v(p2,V2:Rat)x(p2,X2:Rat)loc(p1,L1:Label)
v(p1,V1:Rat)x(p1,X1:Rat)} such that X2 >= X1 in time < 20 .)
Solution 1
L2:Label --> brake ; L1:Label --> nothing ; TIME_ELAPSED:Time --> 9 ; V2:Rat
    --> 0 ; V1:Rat --> 0 ; X2:Rat --> 18 ; X1:Rat --> 18
		  

This counterexample shows that if the safety distance is less than 8 units, the system will not be able to guarantee safety, thus verifying that our theoretical analysis is correct.

During the verification process with model checking in Real-Time Maude, special attention was paid to the occurrence of false positives or spurious counterexamples, which are common challenges in the automated verification of complex hybrid systems. In our experiments and simulations, due to the precise formulation and careful translation of specifications between CafeOBJ and Real-Time Maude, we did not observe any spurious counterexamples or false positives. This absence of false alarms primarily results from the following: 1. Accurate Specification Translation: Our rigorous and structured translation methodology minimizes semantic discrepancies between CafeOBJ and Real-Time Maude, significantly reducing opportunities for spurious results. 2. Well-Formulated Verification Conditions: Verification conditions are designed explicitly and clearly, avoiding ambiguity that could lead to unintended false alarms. 3. Conservative State Exploration: Careful state-space exploration using appropriate temporal and state constraints mitigates state-explosion-induced artifacts. However, it is crucial to acknowledge that while no spurious counterexamples were observed in our current study, their potential occurrence cannot be completely excluded in more complex scenarios or larger-scale applications. Future work will thus involve further refinement of abstraction techniques, explicit handling of potential spurious results, and comprehensive validation to maintain high verification accuracy in more extensive and complicated systems.

7. Conclusions

7.1. Summary of Contributions

Based on the multitask hybrid systems framework, we propose a specification transformation method that can obtain the specification from the OTS/CafeOBJ to the Real-Time Maude. Then, taking advantage of the infinite state spaces of the OTS/CafeOBJ and fully automated of Real-Time Maude, we completed the safety property verification of the autonomous vehicle group control system. We ensure that model checking for the Real-Time Maude specification obtained through specification translation is useful for finding bugs in the original specification. A specification translation between different formal specification languages benefits the research area of integrated formal methods. These findings contribute to the development of reliable autonomous driving technologies and build safe and efficient autonomous vehicle group control systems.

During the verification process by CafeOBJ, we may need some lemma to verify an invariant property. A user should try to find a suitable lemma to prove the main property. Our translation system will also be useful for that task. When a user thinks some property is a candidate of a lemma, the user translates it by our translation system and applies the Real-Time Maude search command. If a counterexample is returned, the lemma is wrong. The user avoids wasting time to prove the wrong lemma and tries to find the next candidates.

Our approach aims not only to apply the safety and efficiency of the multitask autonomous vehicle group control systems shown in this research but also to extend its applicability to more complex real-world scenarios. These include straight-line operation combined with intersections or vehicles merging into the highway, thereby enhancing the practical verification method of autonomous vehicle group control systems technology. Our methodology contributes significantly to ongoing debates in formal verification by explicitly addressing a known challenge: the trade-off between automation and the handling of infinite-state and complex hybrid systems. Whereas methods based solely on interactive theorem proving, such as CafeOBJ [17,18,19], provide rigorous proofs but depend heavily on user interaction, fully automated methods like UPPAAL [5] and Real-Time Maude [6] facilitate automatic state-space exploration but may suffer from state explosion issues. By integrating theorem proving and model checking, our approach systematically mitigates these limitations, as illustrated by the formal verification of autonomous vehicle group control systems, thus positioning our research as a robust advancement within the existing scholarly discourse.

While the proposed verification approach effectively combines interactive theorem proving and automated model checking, it faces several key bottlenecks and limitations when scaling up to large multitasking hybrid systems: 1. State Explosion Problem: Automated model checking (Real-Time Maude) is significantly constrained by state-space explosion as the number of concurrent tasks or processes increases dramatically. This limitation restricts scalability when verifying thousands or more concurrent processes. 2. Manual Effort in Theorem Proving: Although theorem proving (CafeOBJ) provides strong expressiveness and rigorous proofs, its reliance on expert-driven manual interaction significantly limits practical scalability and efficiency when applied to extremely complex or large-scale systems. 3. Complexity of Specification Translation: The precise translation of large-scale system specifications between CafeOBJ and Real-Time Maude may become increasingly complex and error-prone as systems grow, necessitating careful verification of the translation itself. 4. Resource Demands (Memory and Computational Power): The computational resources (memory, CPU time) required for exhaustive verification quickly escalate with the complexity of continuous behaviors and the number of concurrent processes, presenting practical limitations. 5. Limitations in Continuous Dynamics Modeling: Current approaches to continuous-state modeling and verification may oversimplify real-world continuous dynamics (e.g., non-linearities, uncertainties), potentially impacting verification fidelity and accuracy. To overcome these bottlenecks, future research directions include enhancing abstraction techniques, employing compositional verification methods, developing incremental and modular verification strategies, and advancing tool automation to mitigate these inherent challenges.

A critical aspect of formal verification is to ensure that identified safety violations reflect genuine system failures rather than artifacts resulting from state-space exploration constraints. The proposed verification methodology ensures the authenticity of reported violations through several rigorous mechanisms: Rigorous Specification Translation: The translation procedure between CafeOBJ and Real-Time Maude strictly preserves semantic consistency. By clearly mapping observers, predicates, and verification conditions, we prevent the introduction of artificial violations due to translation discrepancies. Verification Conditions Precision: Safety properties are explicitly and unambiguously formulated, facilitating precise differentiation between genuine violations and exploration artifacts. Ambiguities or overly restrictive conditions, which commonly result in false violations, are carefully avoided through well-defined and carefully vetted predicates. Cross-validation through Theorem Proving: Any safety violation identified by automated model checking is further cross-validated via interactive theorem proving. This combination ensures that any reported violation is independently confirmed through rigorous logical proofs rather than solely relying on automated state exploration.

Thus, these combined measures robustly differentiate actual system safety failures from artifacts of state-space exploration constraints, enhancing verification accuracy, reliability, and trustworthiness in safety-critical system analysis.

7.2. Discussion on Model Adaptation for Real-World Features and Constraints

Typical challenges that may be encountered in real environments, such as sensor uncertainty (such as noise, error, failure), communication delay or interruption (communication signal delay or loss), environmental interference factors (weather changes, road conditions), system hardware limitations (such as computing power, power supply limitations, storage capacity), complexity and dynamics of traffic scenarios (such as emergencies, complex interaction scenarios).

Combined with our research content, we plan to adjust the solution in the following aspects in the future to address the above issues: 1. Model robustness enhancement: Adjust the definition of continuous observers and discrete observers in the MHOTS model to cover uncertainty (for example, add random perturbations or uncertain boundary conditions). Consider using probabilistic or statistical models to describe sensor errors or environmental uncertainties [26]. 2. Adaptation to Communication Delays: Add explicit communication delay variables to the model, set the communication timeout state, and formulate corresponding recovery strategies. Use the temporal logic of Real-Time Maude to describe the safety constraints of the system under communication constraints or delays [27]. 3. Environmental Disturbances Adaptation: Add environmental factors such as weather and road friction coefficient to the model to simulate the dynamic characteristics of the vehicle under different environmental conditions. Enhance safety specifications and ensure that the system safety properties can still be met under extreme weather or special conditions through additional constraints [28]. 4. Verification under Computational Constraints: Consider state space abstraction or reduction in the model, which is suitable for embedded devices with limited computing resources. Discuss how to reasonably choose model checking and theorem proving strategies under resource constraints [29].

Although these schemes can improve the practical relevance and robustness of the verification model to a certain extent, it should be noted that such extensions may increase the complexity and computational cost of state space analysis. Therefore, in the future, we will focus on studying effective abstraction techniques and optimization algorithms to maintain a balance between model security and computational feasibility so as to further bridge the gap between theoretical verification and practical applicability.