xDEVS user's manual

A processor atomic model consumes a job j. When the processor receives a job through an input port, thus the processor remains busy until the processing time j_p is finished. Then it sends the job through an output port.

The processor model can be formally described as

Processor=〈X,S,Y,δ_int,δ_ext,δ_con,λ,ta〉

• X = {(in, j ∈ J)}, where J is a set of Jobs.
• S = phase={"busy","passive"} × σ ∈ R₀⁺ × j ∈ J
• Y = {(out, j ∈ J)}
• ta(phase,σ,j) = σ
• λ(phase,σ,j) = j
• δ_int(phase,σ,j) = ("passive", ∞, ∅)
• δ_ext(phase,σ,j,e,(in,j')) = {("busy",j_p',j') if phase="passive", ("busy",σ-e,j) if phase="busy"
• δ_con(phase,σ,j,(in,j')) = δ_ext(δ_int(phase,σ,j),0,(in,j'))

Figure 2 shows an example of a DEVS coupled model with three components, M1, M2 y M3, as well as their couplings. These models are interconnected through the corresponding I/O ports presented in the Figure. The models are connected to the external coupled models through the EIC and EOC connectors. M1, M2 and M3 can be atomic or coupled models.

Figure 2. A DEVS coupled model

Following the previous coupled model definition, the model in Figure 2 can be formally defined as:

N =〈 X, Y, C, EIC, EOC, IC 〉

where:

• X is the set of input events.
• Y is the set of output events.
• C = {M1,M2,M3}
• EIC = {(N,in)→(M1,in)}
• EOC = {(M3,out)→(N,out)}
• IC = {(M1,out)→(M2,in),(M2,out)→(M3,in)}

The Experimental frame – Processor model is usually presented as one of the initial examples to start to practice with DEVS modeling and simulation. It is a DEVS coupled model consisting of three atomic models and one coupled model (see Figure 3).

Figure 3. Experimental frame (ef)-processor (p) model; boxes: models; arrows: couplings; arrow labels: input/output port names.

The Generator atomic model generates job-messages at fixed time intervals and sends them via the "out" port. The Transducer atomic model accepts job-messages from the generator at its "arrived" port and remembers their arrival time instances. It also accepts job-messages at the "solved" port. When a message arrives at the "solved" port, the transducer matches this job with the previous job that had arrived on the "arrived" port earlier and calculates their time difference. Together, these two atomic models form an Experimental frame coupled model. The experimental frame sends the generators job messages on the "out" port and forwards the messages received on its "in" port to the transducers "solved" port. The transducer observes the response (in this case the turnaround time) of messages that are injected into an observed system. The observed system in this case is the Processor atomic model. A processor accepts jobs at its "in" port and sends them via "out" port again after some finite, but non-zero time period. If the processor is busy when a new job arrives, the processor discards it. Finally the transducer stops the generation of jobs by sending any event from its "out" port to the "stop" port at the generator, after a given simulation time interval.

Based on Figure 3, we can define the coupled model for this example as:

EFP=〈 X, Y, C, EIC, EOC, IC 〉

where:

• X = ∅.
• Y = ∅.
• C = {EF,P}
• EIC = ∅
• EOC = ∅
• IC = {(EF,out)→(P,in),(P,out)→(EF,in)}

The Experimental Frame coupled model can be defined as:

EF=〈 X, Y, C, EIC, EOC, IC 〉

where:

• X = {(in,j∈J)}, where J is a set of Jobs.
• Y = {(out,j∈J)}, where J is a set of Jobs.
• C = {G,T}
• EIC = {(EF,in)→(T,solved)}
• EOC = {(G,out)→(EF,out)}
• IC = {(G,out)→(T,arrived),(T,out)→(Generator,stop)}

We have defined the behavior of the Processor model in a previous example. Now, we describe the functionality of both the Generator and Transduced models. The Generator model can be formally described as

Generator=〈 X, S, Y, δ_int, δ_ext, δ_con, λ, ta 〉

• X = {(stop,ν)}, where ν is any event
• S = (phase={"active","passive"})×σ∈R0+×i=1,2,…,N:ji∈J
• Y = {(out,ji∈ J)}
• ta(phase,σ,i) = σ
• λ(phase,σ,i) = ji
• δ_int(phase,σ,i) = ("active",σ,i+1)
• δ_ext(phase,σ,i,e,(in,ν)) = ("passive",∞,i)
• δ_con(phase,σ,i,(in,ν)) = δ_ext(δ_int(phase,σ,i),0,(in,ν))

The Transducer model can be formally described as

Transducer=〈 X, S, Y, δ_int, δ_ext, δ_con, λ, ta 〉

• X = {(arrived,j∈J),(solved,j∈J}, where J is a set of jobs
• S = (phase = {"active","passive"}) × (σ ∈ R₀⁺ ) × (clock ∈ R₀⁺ × J_A∈J × J_S∈J where J_A and J_S are sets of arrived and solved jobs, respectively.
• Y = {(stop,ν)}, where ν is any event.
• ta(phase,σ,clock,J_A,J_S) = σ
• λ(phase,σ,clock,J_A,J_S) = ν
• δ_int(phase,σ,clock,J_A,J_S) = ("passive",∞,clock+σ,J_A,J_S)
• δext(phase,σ,clock,J_A,J_S,e,(arrived,j^a),(solved,j^s))= … … = (active,σ-e,clock+e,J_A={j^a,J_A} if j^a≠∅, J_S={j^s,J_S}:j_t^s=clock if j^s≠∅) , where the time in which the job is solved is set to clock with j_t^s = clock.
• δ_con(phase,σ,clock,J_A,J_S,(arrived,j^a),(solved,j^s))=δ_ext(δ_int(phase,σ,clock,J_A,J_S),0,(arrived,j^a),(solved,j^s))

The Atomic class, derived from the Component class and marked as an abstract base class, serves as the base class for all atomic models in xDEVS. Here's a breakdown of its key components and functionalities:

• Initialization: The constructor initializes the atomic model, setting its name and initializing its phase to passive and its time advance (sigma) to infinity. This represents a state where the model is waiting indefinitely for an external event.
• Time Advance Function (ta): This property method returns the time until the next scheduled internal transition (sigma). It dictates how long the model stays in its current state before an internal transition occurs.
• Internal Transition (deltint): This abstract method must be implemented by all subclasses. It defines the state changes that occur when an internal event is triggered after the elapse of the time advance.
• External Transition (deltext): This abstract method handles state changes in response to external events. It takes the elapsed time (e) since the last transition as an argument, allowing the model to update its state based on external inputs.
• Output Function (lambdaf): Another abstract method that specifies the output of the model just before an internal transition occurs. This function is crucial for sending outputs to other models in a coupled model configuration.
• Confluent Transition (deltcon): By default, this method handles the simultaneous occurrence of internal and external events. It first processes the internal transition and then the external transition with zero elapsed time.
• State Management Methods: The methods hold_in, activate, passivate, and continuef are utility functions to manage the model's state and timing:
  • hold_in: Sets the model's phase and schedules the next internal transition.
  • activate: Immediately triggers an internal transition by setting sigma to zero.
  • passivate: Puts the model into a passive state with an infinite wait time.
  • continuef: Adjusts the time advance by reducing it by the elapsed time e, useful for resuming after a paused state.

To implement an atomic model in xDEVS, you need to subclass the Atomic class and provide concrete implementations for the deltint, deltext, and lambdaf methods. Each method should define how the model reacts to different types of events and manages its state transitions effectively.

Here is a simple example of an atomic model that increments a counter:

class CounterModel(Atomic):
    def __init__(self, name=None):
        super().__init__(name)
        self.count = 0
        self.hold_in("active", 1)  # Active for 1 time unit

    def deltint(self):
        self.count += 1
        self.hold_in("active", 1)  # Schedule next increment

    def deltext(self, e):
        self.continuef(e)  # Continue countdown

    def lambdaf(self):
        pass # No output

    def __str__(self):
        return f"CounterModel(name={self.name}, count={self.count})"

This model demonstrates basic internal and external transitions. It continuously counts upwards.

In xDEVS, ports are essential for enabling communication between atomic models and facilitating the flow of events in a coupled model configuration. Ports are used to send and receive messages, allowing models to interact with each other.

• Input Ports: These ports receive messages from other models. Each input port is associated with a specific type of message it can accept. When an external event occurs, the message is placed in the corresponding input port, and the deltext method is invoked to handle the event.
• Output Ports: These ports send messages to other models. Before an internal transition occurs, the lambdaf method generates the output, which is then placed in the appropriate output port. The coupled model configuration ensures that these messages are routed to the correct input ports of other models.

To define ports in an atomic model, you need to create instances of the Port class and add them to the model using the add_in_port and add_out_port methods. Here is an example demonstrating the use of ports in atomic models:

class Generator(Atomic):
    def __init__(self, name, period):
        super().__init__(name)
        self.i_stop = Port(Job, "i_stop")
        self.o_out = Port(Job, "o_out")
        
        self.add_in_port(self.i_stop)
        self.add_out_port(self.o_out)
        
        self.period = period
        self.job_counter = 1
        
    def initialize(self):
        self.hold_in(PHASE_ACTIVE, self.period)
        
    def deltint(self):
        self.job_counter += 1
        self.hold_in(PHASE_ACTIVE, self.period)
        
    def deltext(self, e):
        self.passivate()
    
    def lambdaf(self):
        self.o_out.add(Job(str(self.job_counter)))

class Processor(Atomic):
    def __init__(self, name, proc_time):
        super().__init__(name)
        
        self.i_in = Port(Job, "i_in")
        self.o_out = Port(Job, "o_out")
        
        self.add_in_port(self.i_in)
        self.add_out_port(self.o_out)

        self.current_job = None
        self.proc_time = proc_time
        
    def initialize(self):
        self.passivate()
        
    def deltint(self):
        self.passivate()
    
    def deltext(self, e):
        if self.phase == PHASE_PASSIVE:
            self.current_job = self.i_in.get()
            self.hold_in(PHASE_ACTIVE, self.proc_time)
        self.continuef(e)
    
    def lambdaf(self):
        self.o_out.add(self.current_job)

In this example, the Generator model has input ports i_start and i_stop and an output port o_out. The Processor model has an input port i_in and an output port o_out. These ports facilitate the communication between the Generator and Processor models, allowing them to exchange Job messages.

By defining and using ports, you can create complex coupled models where multiple atomic models interact seamlessly, enabling sophisticated simulations of system behaviors.

The Coupled class, derived from the Component class, serves as the base class for all coupled models in xDEVS. Here are the key components and functionalities of a coupled model:

• Submodels: A coupled model contains a collection of submodels, which can be either atomic models or other coupled models. These submodels are added to the coupled model using the add_component method.
• Ports: Similar to atomic models, coupled models have input and output ports. These ports are used to receive external messages and send messages to other models outside the coupled model.
• Couplings: Couplings define the connections between the ports of submodels and the ports of the coupled model. There are three types of couplings:
  • Internal Couplings: Connect the output ports of one submodel to the input ports of another submodel within the same coupled model.
  • /External Input Couplings (EIC)*: Connect the input ports of the coupled model to the input ports of its submodels.
  • /External Output Couplings (EOC)*: Connect the output ports of the submodels to the output ports of the coupled model.
• Routing: The coupled model is responsible for routing messages according to the defined couplings. When a message arrives at an input port, it is routed to the appropriate submodel(s) based on the EIC. Similarly, when a submodel generates an output, it is routed to other submodels or the coupled model's output ports based on the internal couplings and EOC.

To implement a coupled model in xDEVS, you need to subclass the Coupled class and define its submodels and couplings. Here is an example of a simple coupled model that combines a Generator and a Processor:

class BasicCoupledModel(Coupled):
    def __init__(self, name):
        super().__init__(name)
        
        # Define ports
        self.i_in = Port(Job, "i_in")
        self.o_out = Port(Job, "o_out")        
        self.add_in_port(self.i_in)
        self.add_out_port(self.o_out)

        # Create submodels
        self.generator = Generator("Generator", period=5)
        self.processor = Processor("Processor", proc_time=3)
        
        # Add submodels to the coupled model
        self.add_component(self.generator)
        self.add_component(self.processor)
        
        # Define couplings
        self.add_coupling(self.generator.o_out, self.processor.i_in)  # Internal coupling
        self.add_coupling(self.processor.o_out, self.o_out)           # External output coupling
        self.add_coupling(self.i_in, self.generator.i_stop)           # External input coupling

In this example, the BasicCoupledModel class defines a coupled model that includes a Generator and a Processor as submodels. The couplings are set up to route messages from the generator to the processor and from the processor to the coupled model's output port. Additionally, an external input coupling is defined to allow external messages to stop the generator.

By defining submodels and their couplings, you can create complex systems that simulate the interactions and behaviors of multiple components working together. Coupled models provide a powerful way to build hierarchical and modular simulations in xDEVS.

1. Prepare the Model: Define your coupled model and its components. Each component will run on a different process or machine.
2. Create Configuration Files: Use XML files to specify the configuration of the coupled model and its components, including their network addresses and ports.
3. Run the Coordinator: The coordinator manages the overall simulation and synchronizes the components. It reads the configuration file and initializes the simulation.
4. Run the Simulators: Each simulator runs a part of the model. They read the configuration file to know their role and communicate with the coordinator.

Below is an example of how to set up and run a distributed simulation using xDEVS.

1. Start the Coordinator: Open a terminal and run the coordinator with the XML configuration file as an argument:

      java RunDistributedSimulation config.xml
   

2. Start the Simulators: Open separate terminals for each simulator and run them with the XML configuration file and the name of the atomic model they simulate:

      java RunDistributedSimulation config.xml processor
      java RunDistributedSimulation config.xml generator
      java RunDistributedSimulation config.xml transducer
   

Distributed simulation in xDEVS allows for efficient and scalable simulation of complex models by distributing the workload across multiple machines or processes. By following the steps outlined above, you can set up and run distributed simulations, leveraging the power of xDEVS to handle large-scale simulations effectively.

1. Time Scaling: The RTCentralCoordinator allows you to scale the simulation time relative to real-world time. This means you can run the simulation faster or slower than the actual system. The time scaling factor is set using the setTimeScale method.
2. Real-time Synchronization: The coordinator ensures that the simulation events are processed in real-time, maintaining synchronization with the real-world clock.
3. Parallel Execution: Leveraging the CoordinatorParallel, the real-time coordinator can distribute simulation tasks across multiple threads, enhancing performance.

To set up a real-time simulation using xDEVS, follow these steps:

1. Define the Model: Create your coupled model as usual. For example, let's use the Efp model.
2. Initialize the Real-time Coordinator: Instantiate the RTCentralCoordinator with your model.
3. Set the Time Scale: Define the time scaling factor to control the speed of the simulation relative to real-world time.
4. Run the Simulation: Start the simulation for a specified duration.

Below is an example demonstrating how to set up and run a real-time simulation using the RTCentralCoordinator:

import java.util.logging.Level;
import xdevs.core.examples.efp.Efp;
import xdevs.core.simulation.realtime.RTCentralCoordinator;
import xdevs.core.util.DevsLogger;

public class RealTimeSimulationExample {
    public static void main(String[] args) {
        double timeStart = System.currentTimeMillis();
        DevsLogger.setup(Level.FINE);

        // Create the EFP model
        Efp efp = new Efp("EFP", 1, 3, 20);

        // Initialize the real-time coordinator with the model
        RTCentralCoordinator coordinator = new RTCentralCoordinator(efp);
        coordinator.initialize();

        // Set the time scale factor (e.g., 0.1 for 10x faster than real-time)
        coordinator.setTimeScale(0.1);

        // Run the simulation for 60 seconds of real-time
        coordinator.simulate(60.0);

        double timeEnd = System.currentTimeMillis();
        System.out.println("Total execution time: " + (timeEnd - timeStart) + "ms");
    }
}

1. Model Initialization: The Efp model is created and passed to the RTCentralCoordinator.
2. Time Scale Setting: The setTimeScale method is used to set the time scaling factor. In this example, a factor of 0.1 means the simulation runs 10 times faster than real-time.
3. Simulation Execution: The simulate method starts the real-time simulation for 60 seconds of real-world time.

Real-time simulation in xDEVS provides a powerful tool for applications requiring synchronization with real-world time. By using the RTCentralCoordinator, you can control the speed of your simulation, interact with it in real-time, and leverage parallel execution for enhanced performance. This feature is essential for developing and testing real-time systems and interactive applications.

To set up a HIL simulation using xDEVS, follow these steps:

1. Define the DEVS Model: Create your DEVS model as usual. This model will represent the part of the system that is simulated.
2. Implement Input and Output Handlers: Use the provided input and output handlers to interface with the hardware. These handlers will manage the communication between the DEVS model and the hardware components.
3. Configure the Real-Time Manager: Set up the real-time manager to handle the timing and synchronization of the simulation with the real world.
4. Run the Simulation: Initialize and run the simulation, ensuring that the real-time manager and handlers are correctly configured to interact with the hardware.

Below is an example of how to set up a HIL simulation using the MQTT protocol for communication between the DEVS model and the hardware.

By following these steps, you can set up a HIL simulation using xDEVS. The real-time manager and input/output handlers provide a flexible and powerful way to integrate hardware components into your simulation, allowing for more realistic and comprehensive testing of your system. This approach is particularly useful for applications such as hardware-in-the-loop testing, real-time control systems, and interactive simulations.

In this example, we will model a simple traffic light system using the xDEVS/Python API. The traffic light will cycle through three states: Green, Yellow, and Red. Each state will have a specific duration, and the system will transition between these states in a loop. We will create an atomic model for the traffic light, which will handle the state transitions and timing. The traffic light will have one output port to indicate the current state.

1. TrafficLight Class: This class extends the Atomic class from the xDEVS library. It defines the traffic light states and their durations.
   • initialize(): Sets the initial state to Green and the initial time advance (sigma) to the green light duration.
   • deltint(): Handles internal transitions between states.
   • lambdaf(): Outputs the current state to the output_port.
   • exit(): Placeholder for any cleanup operations.
2. Simulation Setup: The main block sets up the traffic light model with specified durations for each state. It then creates a Coordinator to manage the simulation and runs the simulation for 50 iterations.

This example demonstrates how to model a simple traffic light system using the xDEVS/Python API, showcasing the basic principles of discrete event simulation with DEVS formalism.

Modify the previous example. There should be an output right after the change in the state, i.e., once the light turns green, yellow, or red, the output is triggered with the new color, instantaneously.

In this example, we will simulate a queueing system, such as a bank or a customer service center, using the xDEVS/Python API. The system will consist of a generator that produces customers, a queue where customers wait, and a server that processes the customers. The goal is to model the arrival, waiting, and service processes. We will create atomic models for the generator, queue, and server. The generator will produce customers at a specified rate, the queue will manage the waiting customers, and the server will process the customers.

1. Customer Class: Represents a customer with a unique ID.
2. Generator Class: Produces customers at a specified interarrival time.
   • initialize(): Sets the initial state to active and the initial time advance to the interarrival time.
   • deltint(): Handles internal transitions by incrementing the customer ID and setting the next event.
   • lambdaf(): Outputs a new customer to the output port.
3. Queue Class: Manages the waiting customers.
   • initialize(): Sets the initial state to passive.
   • deltint(): Handles internal transitions by checking the queue and setting the next event.
   • deltext(): Handles external transitions by adding customers to the queue.
   • lambdaf(): Outputs the next customer from the queue.
4. Server Class: Processes customers with a specified service time.
   • initialize(): Sets the initial state to passive.
   • deltint(): Handles internal transitions by setting the server to idle.
   • deltext(): Handles external transitions by starting the service for a new customer.
5. QueueingSystem Class: A coupled model that integrates the generator, queue, and server.
   • __init__(): Initializes the components and sets up the couplings between them.
6. Simulation Setup: The main block sets up the queueing system model with specified interarrival and service times. It then creates a Coordinator to manage the simulation and runs the simulation for 100 iterations.

This example demonstrates how to model a queueing system using the xDEVS/Python API, showcasing the basic principles of discrete event simulation with DEVS formalism.

The EFP model is a coupled model that integrates the generator, processor, and transducer components.

package xdevs.core.examples.efp;

import java.util.logging.Level;
import xdevs.core.modeling.Coupled;
import xdevs.core.simulation.Coordinator;
import xdevs.core.util.DevsLogger;

public class Efp extends Coupled {

    public Efp(String name, double generatorPeriod, double processorPeriod, double transducerPeriod) {
        super(name);

        Ef ef = new Ef("ef", generatorPeriod, transducerPeriod);
        super.addComponent(ef);
        Processor processor = new Processor("processor", processorPeriod);
        super.addComponent(processor);

        super.addCoupling(ef.oOut, processor.iIn);
        super.addCoupling(processor.oOut, ef.iIn);
    }

    public static void main(String args[]) {
        DevsLogger.setup(Level.FINE);
        Efp efp = new Efp("efp", 1, 3, 100);
        Coordinator coordinator = new Coordinator(efp);
        coordinator.initialize();
        coordinator.simulate(Long.MAX_VALUE);
        coordinator.exit();
    }
}

The generator produces jobs at a specified period.

package xdevs.core.examples.efp;

import org.w3c.dom.Element;
import xdevs.core.modeling.Atomic;
import xdevs.core.modeling.Port;

public class Generator extends Atomic {
    public Port<Job> iStop = new Port<>("iStop");
    public Port<Job> oOut = new Port<>("oOut");
    protected int jobCounter;
    protected double period;

    public Generator(String name, double period) {
        super(name);
        super.addInPort(iStop);
        super.addOutPort(oOut);
        this.period = period;
    }

    public Generator(Element xmlAtomic) {
        this(xmlAtomic.getAttribute("name"), Double.parseDouble(
                ((Element) (xmlAtomic.getElementsByTagName("constructor-arg").item(0))).getAttribute("value")));
    }

    @Override
    public void initialize() {
        jobCounter = 1;
        this.holdIn("active", period);
    }

    @Override
    public void exit() {
    }

    @Override
    public void deltint() {
        jobCounter++;
        this.holdIn("active", period);
    }

    @Override
    public void deltext(double e) {
        super.resume(e);
        super.passivate();
    }

    @Override
    public void lambda() {
        Job job = new Job("" + jobCounter + "");
        oOut.addValue(job);
    }
}

The processor processes jobs with a given processing time.

package xdevs.core.examples.efp;

import org.w3c.dom.Element;
import xdevs.core.modeling.Atomic;
import xdevs.core.modeling.Port;

public class Processor extends Atomic {

    protected Port<Job> iIn = new Port<>("in");
    protected Port<Job> oOut = new Port<>("out");
    protected Job currentJob = null;
    protected double processingTime;
    protected double clock;

    public Processor(String name, double processingTime) {
        super(name);
        super.addInPort(iIn);
        super.addOutPort(oOut);
        this.processingTime = processingTime;
        this.clock = 0;
    }

    public Processor(Element xmlAtomic) {
        this(xmlAtomic.getAttribute("name"), 
             Double.parseDouble(((Element)(xmlAtomic.getElementsByTagName("constructor-arg").item(0))).getAttribute("value")));
    }

    @Override
    public void initialize() {
        super.passivate();
    }

    @Override
    public void exit() {
    }

    @Override
    public void deltint() {
        clock += super.getSigma();
        super.passivate();
    }

    @Override
    public void deltext(double e) {
        super.resume(e);
        clock += e;
        if (super.phaseIs("passive")) {
            currentJob = iIn.getSingleValue();
            super.holdIn("active", processingTime);
            currentJob.time = clock;
        }
    }

    @Override
    public void lambda() {
        oOut.addValue(currentJob);
    }
}

The transducer collects statistics about the jobs and finishes the simulation when the observation time is reached.

package xdevs.core.examples.efp;

import java.util.LinkedList;
import java.util.logging.Logger;
import org.w3c.dom.Element;
import xdevs.core.modeling.Atomic;
import xdevs.core.modeling.Port;

public class Transducer extends Atomic {

    private static final Logger LOGGER = Logger.getLogger(Transducer.class.getName());

    public Port<Job> iArrived = new Port<>("iArrived");
    public Port<Job> iSolved = new Port<>("iSolved");
    public Port<Job> oOut = new Port<>("oOut");
    protected LinkedList<Job> jobsArrived = new LinkedList<>();
    protected LinkedList<Job> jobsSolved = new LinkedList<>();
    protected double observationTime;
    protected double totalTa;
    protected double clock;

    public Transducer(String name, double observationTime) {
        super(name);
        super.addInPort(iArrived);
        super.addInPort(iSolved);
        super.addOutPort(oOut);
        totalTa = 0;
        clock = 0;
        this.observationTime = observationTime;
    }

    public Transducer(Element xmlAtomic) {
        this(xmlAtomic.getAttribute("name"), 
             Double.parseDouble(((Element)(xmlAtomic.getElementsByTagName("constructor-arg").item(0))).getAttribute("value")));
    }

    @Override
    public void initialize() {
        super.holdIn("active", observationTime);
    }

    @Override
    public void exit() {
    }

    @Override
    public void deltint() {
        clock = clock + getSigma();
        double throughput;
        double avgTaTime;
        if (phaseIs("active")) {
            if (!jobsSolved.isEmpty()) {
                avgTaTime = totalTa / jobsSolved.size();
                if (clock > 0.0) {
                    throughput = jobsSolved.size() / clock;
                } else {
                    throughput = 0.0;
                }
            } else {
                avgTaTime = 0.0;
                throughput = 0.0;
            }
            LOGGER.info("End time: " + clock);
            LOGGER.info("Jobs arrived : " + jobsArrived.size());
            LOGGER.info("Jobs solved : " + jobsSolved.size());
            LOGGER.info("Average TA = " + avgTaTime);
            LOGGER.info("Throughput = " + throughput);
            holdIn("done", 0);
        } else {
            passivate();
        }
    }

    @Override
    public void deltext(double e) {
        super.resume(e);
        clock = clock + e;
        if (phaseIs("active")) {
            if (!iArrived.isEmpty()) {
                Job job = iArrived.getSingleValue();
                LOGGER.fine("Start job " + job.id + " @ t = " + clock);
                job.time = clock;
                jobsArrived.add(job);
            }
            if (!iSolved.isEmpty()) {
                for(Job job : iSolved.getValues()) {
                    totalTa += (clock - job.time);
                    LOGGER.fine("Finish job " + job.id + " @ t = " + clock);
                    job.time = clock;
                    jobsSolved.add(job);
                }
            }
        }
    }

    @Override
    public void lambda() {
        if (phaseIs("done")) {
            Job job = new Job("null");
            oOut.addValue(job);
        }
    }
}

The parallel coordinator manages the parallel execution of the simulation.

// Complete the imports ...

public class ParallelExample {

    // ...

    public static void main(String[] args) {
        DevsLogger.setup(Level.INFO);
        Efp efp = new Efp("EFP", 1, 3, 1000000);
        CoordinatorParallel coordinator = new CoordinatorParallel(efp);
        coordinator.initialize();
        coordinator.simulate(Long.MAX_VALUE);
        coordinator.exit();
    }
}

This example demonstrates how to run a parallel simulation using the DEVS/Java API. The CoordinatorParallel class manages the parallel execution of the simulation, allowing for efficient processing of the EFP model components.