## 3 Modelling and Implementation of the Simulation Prototype
### Proposed Simulation Meta-Model
In DEVS, the behavior of indivisible blocks (e.g., MachineProcess, PartStorageProcess or ControlSimulation) is governed by an atomic DEVS model defined by a set of states, a set of input events, a set of output events, and four functions that define the dynamics: (a) the time advance function, (b) the internal transition function, (c) the external transition function, and (d) the output function. On the other hand, the behavior of compound blocks (e.g., AssemblyWorkstationProcess or the Simulation_AssemblyProcess itself) is governed by a coupled DEVS model, in which output events from one subsystem are input events from another subsystem. The signals corresponding to the input and output events handled in the atomic DEVS model are included in the assembly_item, data_item, and control_data connectors, indicated above. For the definition of the atomic DEVS models corresponding to the different types of blocks, a categorization structure has been defined. This categorization allows to specialize the blocks from some ancestors (general class), depending on the type of input and/or output events and the type of connectors (ports) used. As previously indicated, the behavior model of indivisible blocks is governed by an atomic DEVS model. This behavior is represented by a state machine diagram because it begins when the block is instantiated and finishes when the instance is destroyed. This type of behavior can be displayed using a SysML state machine diagram. For example, in Figure 5, the state machine diagram for the Assembly_Process block is shown. As can be seen, the states of the assembly process are: Idle, Setup, Assembling, Repairing, and Blocked. Idle is a composited state of the Empty, Part_Loaded, Assembly_Loaded, and Ready substates. The diagram also shows the transitions between states that are triggered when certain events occur. For example, the transition between Assembling and Repairing is triggered by the failure_event. Once the simulation system is modelled, and as indicated in Step 4 of the methodology, the modelling of simulations is the next task. In this step, the simulation system model must be related to other relevant design information for defining a simulation. The BDD in Figure 6 defines the model context that shows the relation between the system to be analyzed (MAS) and the simulation system (Simulation_AssemblyProcess). Furthermore, the model context shows that each execution of a simulation (SimulationRun), in addition to using a simulation system (Simulation_AssemblyProcess), contains a set of parameters that define the simulation scenario (Simulation_Scenario). Two types of parameters are distinguished: those that are static in each simulation and only change in the different simulations of a MAS, StaticScenario, and those to which dynamic changes can be assigned during each simulation, DynamicScenario, such as the wear of locators, a change in the failure rates of a machine, etc. Figure 4: Internal block diagram of the WorkstationProcess block. The full model specification includes a number of different types of SysML diagrams which, due to space constraints, have not been included in the manuscript.