GPSS-Plus is a discrete-event and continuous systems simulation engine aimed at modeling and analyzing the behavior of real systems over time. Its purpose is not to program applications, but to describe how a system works<\/strong> and observe its evolution under different conditions.<\/p>\r\n In essence, it operates as a digital laboratory where a set of entities (customers, products, vehicles, signals, or data packets) flows through a network of processes and resources with defined capacities and delays.<\/p>\r\n The goal is to transform a real-world system description into an executable model: from an industrial production line or a logistics chain, to data traffic in a network or an emergency protocol. By simulating thousands of scenarios in minutes, it enables forecasting, decision optimization, and the design of contingency protocols within a general-purpose simulation environment.<\/p>\r\n There are different approaches to system modeling, depending both on the interface and on the objective.<\/p>\r\n Discrete and\/or continuous Drag & Drop based:<\/u><\/p>\r\n Discrete language-based approaches (domain-specific or general-purpose):<\/u><\/p>\r\n Thanks to inheriting the core concepts of classic GPSS, GPSS-Plus sits in both worlds, using its own language to define the model instead of building on general-purpose languages, and reinforcing the role of textual description as the system representation over graphical diagrams.<\/p>\r\n The ultimate goal is that everything can be understood:<\/p>\r\n The main innovations introduced are:<\/p>\r\n The most significant change lies in how block and command parameters are handled. In classic GPSS, parameters A, B, C... offered a fixed and limited syntax.<\/p>\r\n Classic example:<\/p>\r\n In GPSS-Plus, this structure is preserved but extended with a JSON-like format, allowing more details to be specified without breaking simplicity:<\/p>\r\n This makes it possible to integrate graphical, behavioral, or logical parameters without inventing new syntactic variants for each case.<\/p>\r\n GPSS-Plus visually represents entities and blocks using simple graphical elements: small “dots” moving across a canvas, following exactly the model flow. This representation allows observing the system in real time, immediately understanding its dynamics, and facilitating the detection of bottlenecks or unexpected behaviors during execution.<\/p>\r\n This visualization, absent in classic GPSS, introduces a new way of interacting with the model, where direct observation becomes a key validation and comprehension tool.<\/p>\r\n Virtual entities<\/b> help describe the invisible parts of the model. For those coming from other paradigms, they capture what was previously described externally in another language. For beginners, they are simply another type of entity.<\/p>\r\n In GPSS-Plus, everything that happens in the system unfolds over time and can be observed while it happens. To make this possible, all behaviors are treated the same way: as entities<\/u> that move—abstract, visible, or even just a volume.<\/p>\r\n Virtual entities are not visualized, but they are complete entities<\/strong> that execute internal logic or system events. They exist to describe behavior using Depending on their lifecycle, there are three main types:<\/p>\r\n With this approach, the model becomes an ecosystem of concurrent executions<\/strong>. An entity can wait for a bus while answering a call; an agent can control traffic; the sun can rise and set without any main entity needing to handle it.<\/p>\r\n Many common concepts from procedural or object-oriented programming are reinterpreted: behavior is not encapsulated in hierarchical objects, but explicitly modeled as entities that coexist and act in parallel within the system.<\/p>\r\n There is no this, no parent, no child: everyone is a brother. Functions stop being one-off calls and become living procedures. There is no “this.breathe()” that always breathes the same way, but a person who walks and, at the same time, breathes different air.<\/p>\r\n By being described entirely as an explicit model, GPSS-Plus allows its behavior to be automatically analyzed, interpreted, and cross-checked. An artificial intelligence or external auditor can reconstruct what the system does, detect internal inconsistencies, and compare the modeler’s intent with the actual execution.<\/p>\r\n This capability introduces a natural evolution of classic verification and validation (V&V) processes, which no longer rely solely on manual review and statistical analysis. Coherence between history (H), model (M), and execution (E) is incorporated, laying the groundwork for a new validation approach.<\/p>\r\n In GPSS-Plus, variables ( Continuous modeling in GPSS-Plus is based on a simple idea: dividing time into small frames. By executing these steps sequentially within the event queue, continuous behavior naturally emerges.<\/p>\r\n Simulation models can pursue three main objectives:<\/p>\r\n In the latter two cases, the model must interact with the external environment. GPSS-Plus enables this coupling through the BRIDGER<\/b>, which acts as a generic bidirectional channel between the model and real physical systems.<\/p>\r\n From a language perspective, access to external resources is uniform: a database, a file, or a sensor are handled with the same syntax. Opening a relay or storing a data point is expressed with Thanks to Rehydration<\/b>, the model not only connects to the real world but synchronizes with its ongoing state, allowing the simulator to “wake up” in the middle of a process without losing operational continuity after the last stored data, even after the model has been modified.<\/p>\r\n In addition to these innovations, GPSS-Plus incorporates multiple extensions that enhance expressiveness, modularity, and power:<\/p>\r\n We will simulate a basic system where entities (customers) arrive at a resource (service counter), wait if it is busy, are served, and then leave. In this model:<\/p>\r\n For those familiar with classic GPSS<\/b>, we would have:<\/p>\r\n In GPSS-Plus<\/b>, it is very similar, but with graphical representation. To achieve this, we configure resources and additional parameters:<\/p>\r\n Final step:<\/b> Press Play and observe the result. The first entity will exit the \"Generate\" block between time 60 and 70.<\/p>\r\n As can be observed, the program has not changed much to add the graphical component. Basically, we have defined the spatial layout of the elements.<\/p>",
"descripcion": "",
"parametros": "",
"parametros_json": "",
"ejemplo": "",
"hijos": []
},
{
"id": "137",
"nombre": "Syntax: Commands and blocks",
"texto": " In a simulation, there are two main elements at play:<\/p>\r\n 1. ENTITIES<\/b>, or transactions, are the elements that change their state during the simulation. They can represent people, boxes, or any kind of item. In GPSS-Plus, they are represented as colored dots. These entities interact with the environment. For example, they enter the system through the 2. RESOURCES<\/b>, which make up the environment and are used by entities, such as a service counter or a container larger than the entity itself.<\/p>\r\n For example, a person (entity) approaches a service counter (resource). This counter is defined by a COMMAND<\/b>, and a set of BLOCKS<\/b> describe what the person does in relation to that counter.<\/p>\r\n An example of defining a resource as a service counter is the COMMAND:<\/p>\r\n An example of an instruction for an entity to occupy that counter is the BLOCK:<\/p>\r\n In summary, the language is based on two main elements: blocks<\/b> and commands<\/b>.<\/p>\r\n 1. Blocks<\/b> bound to entities<\/b><\/p>\r\n Blocks are instructions that ENTITIES execute directly<\/b> during the simulation. Each block defines a specific action that affects the flow or state of that entity.<\/p>\r\n General syntax:<\/b><\/p>\r\n \r\nBLOCK [PARAMETERS A,B,C..] {JSON-LIKE OPTIONS}\r\n<\/p>\r\n Block examples:<\/p>\r\n Parameters are named by letters (A, B, C, ...). Depending on the block, they may also include parameters in a JSON-like format, usually defining graphical or advanced aspects.<\/p>\r\n Example:<\/p>\r\n Another example:<\/p>\r\n 2. Commands<\/b> bound to resources and the engine environment<\/b><\/p>\r\n Commands configure the simulation environment. Unlike blocks, they are not executed directly by entities. Instead, they define resources, graphical positions, and system rules.<\/p>\r\n General syntax:<\/b><\/p>\r\n \r\nCOMMAND {NAME:theName, JSON-LIKE OPTIONS}\r\n<\/p>\r\n Example of defining a storage resource:<\/p>\r\n This format allows adding additional information such as position (X, Y).<\/p>",
"descripcion": "",
"parametros": "",
"parametros_json": "",
"ejemplo": "",
"hijos": []
},
{
"id": "213",
"nombre": "Variables: Savevalues and Assigns",
"texto": " In GPSS-Plus, variables<\/b> allow storing information that can be used by entities or to configure elements of the environment. These variables are mainly divided into two types:<\/p>\r\n 1. SAVEVALUE<\/b> (global variables): Global variables are accessible by any entity and persist throughout the entire simulation. They are useful for storing shared data such as counters, accumulators, or global states.<\/p>\r\n Syntax:<\/b> Example:<\/p>\r\n This command sets the global variable \"TiempoEspera\" to a value of 8.<\/p>\r\n Once defined, the value can be updated at any time:<\/p>\r\n The value of \"TiempoEspera\" is now 10.<\/p>\r\n To retrieve the value of a global variable, SNA<\/b> are used, which follow a specific format:<\/p>\r\n X$savevalueName<\/b> or X$(savevalueName)<\/b><\/p>\r\n For example, incrementing the value of a savevalue can be done as follows:<\/p>\r\n Or through the method:<\/b><\/p>\r\n In particular, since these variables are used by more than one entity, they have an associated COMMAND for creation and initialization called Its syntax is simple:<\/p>\r\n Remember that 2. ASSIGN<\/b> (entity local variables): Syntax:<\/b> Example:<\/p>\r\n This block assigns the value 1 to the variable \"Identificador\" of the current entity invoking ASSIGN.<\/p>\r\n To retrieve the value of a local variable using its SNA<\/b> format:<\/p>\r\n P$assignName<\/b> or P$(assignName)<\/b><\/p>\r\n P$Identificador<\/b> is the form that allows obtaining the value of a local variable of the entity.<\/p>\r\n Key differences between SAVEVALUE and ASSIGN:<\/b><\/p>\r\n Combined example:<\/b><\/p>\r\n In this example, we combine SAVEVALUE and ASSIGN to calculate the average waiting time at a service counter. If the time is defined by an ADVANCE 15,10, it means it will range between 15 and 25 time units. This should gradually approximate the average to 20.<\/p>\r\n In this code: In this way, Later on, we will see how both BLOCKS support much more than just numerical variables.<\/p>",
"descripcion": "",
"parametros": "",
"parametros_json": "",
"ejemplo": "",
"hijos": []
},
{
"id": "134",
"nombre": "Structure: IF, CALL, PROCEDURE",
"texto": " In this example, we simulate a system where each entity randomly chooses one of three service counters<\/strong> to be served. Each counter has its own queue, and the flow is unevenly distributed depending on the service time.<\/p>\r\n The decision logic is resolved exclusively through structured procedures.<\/p>\r\n Compared to the previous example, only a few new BLOCKS are introduced:<\/p>\r\n This block creates a local variable in the entity (called These local variables are also called parameters<\/em> and are accessed using the SNA notation:<\/p>\r\n This is an \"IF\" control-structure block.<\/p>\r\n As can be seen, it is an \"if\" just like in any other language: a variable is compared against a value.<\/p>\r\n This other control-structure block also needs little introduction. It calls a PROCEDURE:<\/p>\r\n Finally:<\/p>\r\n Which also requires little explanation. PROCEDURE blocks encapsulate a set of actions.<\/p>\r\n In this example, we simulate a system where each entity randomly chooses one of three service counters<\/strong> to be served. Each counter has its own queue, and the flow is unevenly distributed depending on the service time.<\/p>\r\n The decision logic is resolved exclusively through structured procedures, without the use of jumps or labels.<\/p>\r\n Compared to the previous example, only a few new BLOCKS are introduced:<\/p>\r\n This block stores, in an entity-specific memory called \"ALEATORIO\", the value computed by \"RANDOM\", which is a random number between 0 and 1.<\/p>\r\n These ASSIGNs are referred to as parameters and are accessed using the SNA<\/b> notation:<\/p>\r\n This is an \"IF\" control-structure block.<\/p>\r\n As can be seen, it is an \"if\" just like in any other language: a variable is compared against a number.<\/p>\r\n This other control-structure block also needs little introduction. It calls a PROCEDURE.<\/p>\r\n Finally:<\/p>\r\n Which also requires little explanation. They encapsulate a set of actions (PROCEDURE).<\/p>\r\n One of the classic resources is What is a How does it work? It is defined with a total capacity, for example 40 units.<\/p>\r\n Entities use the If an entity tries to occupy more than what is available, it will automatically wait in an internal queue until the In the example: a box warehouse ( In addition to calculating it via additions and subtractions, you can also do it directly by querying the corresponding SNA for The event queue:<\/b><\/p>\r\n At the heart of any discrete-event simulation lies the event queue<\/strong>, a structure that defines how and when<\/strong> entity actions are executed within the model. This discrete-event<\/strong> approach is what distinguishes it from other programming languages.<\/p>\r\n You can think of it as if each entity had its own program, as you would do in C or Python, but jumping between entities according to the temporal order<\/strong> dictated by this queue. If we simulate 10 entities, there are 10 programs running “at the same time” (or almost).<\/p>\r\n What is the event queue?<\/strong><\/p>\r\n It is a time-ordered list of scheduled actions<\/strong>, each associated with a simulated time instant (AC1). The queue ensures actions are executed in the correct order according to when they must occur<\/strong>.<\/p>\r\n The most important thing: it is ordered by time<\/strong>. For example:<\/p>\r\n Example: Evolution of the event queue<\/strong><\/p>\r\n Let’s consider the classic case of a bank where customers enter through the door and are served at a counter. Entities are created with Imagine we are at instant Right now, we have one entity—#5—which is next in the queue. We will remove that element from the queue to process it. Now we know that time is 5! Not because time has “passed”, but because our next task is scheduled for T=5.<\/p>\r\n Let’s assume, for example, that Entity 5 is at the “step” (position in its program) that indicates an In that case, the solution is to schedule itself in the queue at T=15 (5+10) and pause its execution while it is being served.<\/p>\r\n Now the event queue will look like this:<\/p>\r\n We are now at the next event. Time must be updated again: “AC1” now takes the value 7. As we said, it’s not that time has passed; it’s that the event queue makes time jump because there is nothing to do until T=7.<\/p>\r\n We remove the element from the queue and find a \r\n1.- The Now it would be time to advance system time again and serve the next element: Entity 9.<\/p>\r\n This event queue will remain alive until one of the program-ending conditions is met.<\/p>\r\n In GPSS-Plus, this event queue also has additional characteristics to support tasks in the graphical world and to add “ON_*” type events.<\/p>\r\n In the GPSS-Plus event queue, we have 5 types of elements:<\/b><\/p>\r\n Resource queues:<\/b><\/p>\r\n Other existing queues are those belonging to resources; each resource can have one or two depending on the case.<\/p>\r\n These lists are ordered by arrival order, and their management depends exclusively on the resource itself.<\/p>\r\n For example, a When an entity attempts to When it performs Conclusion<\/strong><\/p>\r\n The event queue not only defines the order and time at which actions occur, but also acts as the core of the system. It ensures blocks execute correctly and that the simulation is consistent and accurate. Understanding this concept is essential to design efficient models and fully leverage GPSS-Plus capabilities.<\/p>\r\n In GPSS-Plus it is easy to view this queue: just open the menu window and click the “Event Queue” button.<\/p>",
"descripcion": "",
"parametros": null,
"parametros_json": null,
"ejemplo": null,
"hijos": []
},
{
"id": "174",
"nombre": "Conditions: Waiting for a condition",
"texto": "\/* Synchronization: CONDITIONS \/ WAITUNTIL\nEntities wait as a group and advance together.\n*\/\n\nPOSITION {NAME:POS1,X:208,Y:222}\nPOSITION {NAME:POS2,X:452,Y:215}\nPOSITION {NAME:POS3,X:752,Y:215}\n\nCONDITIONS {NAME:Conditions1,X:208,Y:317,expression:(X$counter>=5)} ; Holding resource\nINITIAL counter,0\n\nSTART 100\n;*****************************************************\n\nGENERATE 10,2 {NAME:GEN1,X:86,Y:228,ERADIO:10,ECOLOR:#FF9900}\n\nADVANCE 16,0 {TO:POS1}\nSAVEVALUE counter, X$counter + 1\nWAITUNTIL Conditions1\nWAITCHECK Conditions1\nSAVEVALUE counter, 0\nADVANCE 20,0 {TO:POS2} ; ALL entities advance together to the second position\nADVANCE 20,40 {TO:POS3} ; Advance to the third position with random time between 20 and 40, now SPLITTING\n\nENDGENERATE 1 ; Ends the life of the entity — IDENTICAL to TERMINATE 1\n",
"descripcion": " Imagine a group of people waiting for an automatic door to open. They are not queuing and they are not occupying anything; they are simply waiting for something to happen.<\/p>\n This is exactly what the Something similar existed in classic GPSS with the The Its associated block, When the 5th entity arrives, the condition is satisfied and it continues without being held. At that point, the remaining entities are released by checking all retained ones using another associated block: It is interesting to observe that all entities leave the We also begin using the Now that you already know how to use procedures and simple conditional decisions ( For this, we use the \r\n
\r\n
\r\nGENERATE 5\r\nADVANCE 10 {From:\"Madrid\", To:\"Paris\"}\r\nTERMINATE\r\n<\/pre>\r\n1. Syntax: extended compatibility<\/h3>\r\n
\r\nADVANCE 30,10 ; Wait between 30 and 40 time units\r\n<\/pre>\r\n
\r\nADVANCE 30,10 {From:\"Madrid\", To:\"Paris\"}\r\n<\/pre>\r\n2. Graphical visualization<\/h3>\r\n
3. Virtual entities (VE)<\/h3>\r\n
ON_ENTER<\/code>, a TIMER<\/code>, or TIMEOUT<\/code>, and they live within the model itself.<\/p>\r\n\r\n
4. Model auditing and V&V<\/h3>\r\n
5. Structured variables<\/h3>\r\n
SAVEVALUE<\/code>, ASSIGN<\/code>) can contain numbers, strings, arrays, or objects<\/strong>. This allows working with complex data structures directly in the model, without resorting to external languages or losing readability.<\/p>\r\n\r\nASSIGN DATA, {type:\"Student\", Name:\"Antonio\", Age:22, Grades:[8,5.8,6,8]}\r\n<\/pre>\r\n6. Hybrid discrete–continuous system<\/h3>\r\n
INTEGRATE<\/code>, DYNAMIC<\/code>, SOLVE<\/code> are the basic tools that allow defining continuous system structures integrated into the same discrete core. RK4, Jacobian matrices, and Newton–Raphson make it possible to simulate fluids, voltages, or velocities using the same DSL.<\/p>\r\n7. Sandbox, digital twins, and edge software<\/h3>\r\n
\r\n
BRIDGE_WRITE<\/code>, and replacing a GENERATE<\/code> that simulates packet input with a subscription to a real motion sensor is almost immediate. The transition from sandbox to digital twin or edge software is therefore transparent.<\/p>\r\nOther notable extensions:<\/h3>\r\n
\r\n
STOCK<\/code>, RESTROOM<\/code>, CONDITIONS<\/code>, finite state machines that extend the classic palette (STORAGE<\/code>, FACILITY<\/code>...).<\/li>\r\n FOREACH<\/code> loop and a NEWFACILITY<\/code>. This is the key difference between a textual language and classic graphical interfaces.<\/li>\r\n CONCAT<\/code>, MERGE<\/code>, PUSH<\/code> extend the language without relying on external code.<\/li>\r\n CX$<\/code>)<\/strong>: each model can define independent contexts, ideal for creating reusable libraries, modules, or components.<\/li>\r\n \r\n
\r\nGENERATE 60,10 ; Entities are generated every 60 to 70 time units.\r\nADVANCE 10 ; Takes 10 time units to move into the counter queue.\r\nSEIZE VENTANILLA ; The entity arrives at the counter queue.\r\nADVANCE 60,30 ; Service time: 60 to 90 time units.\r\nRELEASE VENTANILLA ; Leaves the counter.\r\nADVANCE 10 ; Takes 10 time units to leave.\r\nTERMINATE 1 ; The entity finishes.\r\nSTART 100 ; Executes until 100 entities have been served.\r\n<\/pre>\r\n
\r\nFACILITY {NAME:VENTANILLA, X:300, Y:300} ; Define the counter in space.\r\nPOSITION {NAME:SALIDA, X:500, Y:300} ; Define the exit in space.\r\n\r\nGENERATE 60,10 {NAME:GEN1, X:100, Y:300} ; Position the entity generator.\r\nADVANCE 10 {TO:VENTANILLA} ; Move towards the counter.\r\nSEIZE VENTANILLA ; Assignment of the \"VENTANILLA\" resource.\r\nADVANCE 60,30 ; Service time: 60 to 90 time units.\r\nRELEASE VENTANILLA ; Release of the resource.\r\nADVANCE 10 {TO:SALIDA} ; Move towards the exit.\r\nTERMINATE 1 ; The entity finishes.\r\nSTART 100 ; Executes until 100 entities have been served.\r\n<\/pre>\r\nGENERATE<\/b><\/code> block, move through a circuit using ADVANCE<\/code>, and terminate at a TERMINATE<\/b><\/code> block.<\/p>\r\n\r\nFACILITY {name:Ventanilla1, x:100, y:100}\r\n<\/pre>\r\n\r\nSEIZE Ventanilla1\r\n<\/pre>\r\n
\r\nASSIGN variableName,10\r\nTERMINATE 1\r\n<\/pre>\r\n
\r\nMOD {COLOR:#FF0000} ; sets an entity to red color.\r\n<\/pre>\r\n\r\nADVANCE 10,5 {TO:Ventanilla1} ; the entity advances in time towards \"Ventanilla1\"\r\n<\/pre>\r\n\r\nSTORAGE {NAME:ALMACEN1, CAPACITY:10, X:270, Y:200}\r\n<\/pre>\r\n
\r\nSAVEVALUE variable, value<\/b><\/p>\r\n\r\nSAVEVALUE TiempoEspera, 8\r\n<\/pre>\r\n
\r\nSAVEVALUE TiempoEspera, 10\r\n<\/pre>\r\n
\r\n; X$TiempoEspera or X$(TiempoEspera)\r\n\r\nIF (X$TiempoEspera > 10)\r\n...\r\n<\/pre>\r\n
\r\nSAVEVALUE TiempoEspera, X$TiempoEspera + 1\r\n<\/pre>\r\n
\r\nSAVEVALUE.inc TiempoEspera\r\n<\/pre>\r\n
INITIAL<\/b><\/code>.<\/p>\r\n\r\nINITIAL TiempoEspera,10\r\n<\/pre>\r\n
INITIAL<\/code> is a command. It is used at the beginning of the program for initialization.<\/p>\r\n
\r\nLocal variables belong to a specific entity. Each entity can have its own value for the same variable, which makes them useful for managing entity-specific data.<\/p>\r\n
\r\nASSIGN variable, value<\/b><\/p>\r\n\r\nASSIGN Identificador, 1\r\n<\/pre>\r\n
\r\n; P$Identificador or P$(Identificador)\r\nif (P$Identificador > 5) ...\r\n<\/pre>\r\n
\r\n
\r\nINITIAL TiempoTotal, 0\r\nINITIAL NumEntidades, 0\r\nFacility {NAME:Ventanilla,X:354,Y:204}\r\nGraphic {NAME:Text1,Type:TEXT,X:358,Y:321,Text:\"Average\"}\r\nPosition {NAME:Salida,X:577,Y:201}\r\nSTART 50\r\n;---------------------------------\r\n\r\nGenerate 20,0 {NAME:GEN1,X:100,Y:207}\r\nADVANCE 10 {to:Ventanilla}\r\nSEIZE Ventanilla\r\nASSIGN TiempoInicio, AC1$\r\nADVANCE 15,10\r\nASSIGN TiempoFinal, AC1$\r\nRELEASE Ventanilla\r\nADVANCE 15 {to:Salida}\r\nASSIGN TiempoEntidad, (P$TiempoFinal - P$TiempoInicio)\r\nSAVEVALUE NumEntidades, X$NumEntidades + 1\r\nSAVEVALUE TiempoTotal, X$TiempoTotal + P$TiempoEntidad\r\nSAVEVALUE promedio, round(X$TiempoTotal \/ X$NumEntidades,3)\r\nMOVE {NAME:Text1,text:\"Average: X$promedio\"}\r\nTERMINATE 1\r\n<\/pre>\r\n
\r\n- Each entity calculates its waiting time at the service counter.
\r\n- Times are accumulated in the global variable \"TiempoTotal\".
\r\n- The number of served entities is counted in \"NumEntidades\".
\r\n- At the end of the simulation, you can compute the average waiting time:
\r\nAverageTime = X$TiempoTotal \/ X$NumEntidades<\/b><\/p>\r\nSAVEVALUE<\/code> and ASSIGN<\/code> work together to provide efficient data handling within the simulation.<\/p>\r\n\r\nFACILITY {NAME:VENTANILLA1,X:320,Y:450}\r\nFACILITY {NAME:VENTANILLA2,X:320,Y:300}\r\nFACILITY {NAME:VENTANILLA3,X:320,Y:150}\r\n\r\nPOSITION {NAME:POS1,X:160,Y:300}\r\nPOSITION {NAME:POS2,X:497,Y:300}\r\n\r\nSTART 30 ; Executes until 30 entities are completed\r\n\r\nGENERATE 10,0 {NAME:GEN1,X:60,Y:300}\r\nADVANCE 20,0 {TO:POS1}\r\nASSIGN ALEATORIO,RANDOM\r\nIF (P$ALEATORIO < 0.3)\r\n CALL CAMINO1\r\n ELSE \r\n IF (P$ALEATORIO < 0.6)\r\n CALL CAMINO2\r\n ELSE\r\n CALL CAMINO3\r\n ENDIF\r\nENDIF\r\nADVANCE 20 {TO:POS2}\r\nTERMINATE 1\r\n\r\n;---------------------------------------------\r\n\r\nPROCEDURE CAMINO1\r\nADVANCE 20 {TO:VENTANILLA1}\r\nSEIZE VENTANILLA1\r\nADVANCE 25,10\r\nRELEASE VENTANILLA1\r\nENDPROCEDURE \r\n\r\nPROCEDURE CAMINO2\r\nADVANCE 20 {TO:VENTANILLA2}\r\nSEIZE VENTANILLA2\r\nADVANCE 10,2\r\nRELEASE VENTANILLA2\r\nENDPROCEDURE \r\n\r\nPROCEDURE CAMINO3\r\nADVANCE 20 {TO:VENTANILLA3}\r\nSEIZE VENTANILLA3\r\nADVANCE 10,2\r\nRELEASE VENTANILLA3\r\nENDPROCEDURE\r\n<\/pre>\r\n\r\nASSIGN ALEATORIO,RANDOM\r\n<\/pre>\r\n
ALEATORIO<\/code>) and assigns it a random number between 0 and 1, using the RANDOM<\/code> function.<\/p>\r\nP$ALEATORIO<\/code>\r\n\r\n
\r\nIF (P$ALEATORIO < 0.3)\r\n<\/pre>\r\n
\r\nCALL CAMINO1\r\n<\/pre>\r\n
\r\nPROCEDURE CAMINO1\r\n...\r\nENDPROCEDURE 100 ; would produce an ASSIGN in the calling entity named CAMINO1 with value 100\r\n<\/pre>\r\n
ENDPROCEDURE<\/code> may include a value in parameter A, which is returned in the same way as if an ASSIGN<\/code> instruction had been generated. It can be retrieved as P$ProcedureName (e.g., P$CAMINO1). In this case, it is not used.<\/p>",
"descripcion": "\r\nFACILITY {NAME:VENTANILLA1,X:320,Y:450}\r\nFACILITY {NAME:VENTANILLA2,X:320,Y:300}\r\nFACILITY {NAME:VENTANILLA3,X:320,Y:150}\r\n\r\nPOSITION {NAME:POS1,X:160,Y:300}\r\nPOSITION {NAME:POS2,X:497,Y:300}\r\n\r\nSTART 30 ; Executes until 30 entities are completed\r\n\r\nGENERATE 10,0 {NAME:GEN1,X:60,Y:300}\r\nADVANCE 20,0 {TO:POS1}\r\nASSIGN ALEATORIO,RANDOM\r\nIF (P$ALEATORIO < 0.3)\r\n CALL CAMINO1\r\n ELSE \r\n IF (P$ALEATORIO < 0.6)\r\n CALL CAMINO2\r\n ELSE\r\n CALL CAMINO3\r\n ENDIF\r\nENDIF\r\nADVANCE 20 {TO:POS2}\r\nTERMINATE 1\r\n\r\n;---------------------------------------------\r\n\r\nPROCEDURE CAMINO1\r\nADVANCE 20 {TO:VENTANILLA1}\r\nSEIZE VENTANILLA1\r\nADVANCE 25,10\r\nRELEASE VENTANILLA1\r\nENDPROCEDURE \r\n\r\nPROCEDURE CAMINO2\r\nADVANCE 20 {TO:VENTANILLA2}\r\nSEIZE VENTANILLA2\r\nADVANCE 10,2\r\nRELEASE VENTANILLA2\r\nENDPROCEDURE \r\n\r\nPROCEDURE CAMINO3\r\nADVANCE 20 {TO:VENTANILLA3}\r\nSEIZE VENTANILLA3\r\nADVANCE 10,2\r\nRELEASE VENTANILLA3\r\nENDPROCEDURE\r\n<\/pre>\r\n\r\nASSIGN ALEATORIO,RANDOM\r\n<\/pre>\r\n
P$ALEATORIO<\/code>\r\n\r\n
\r\nIF (P$ALEATORIO < 0.3)\r\n<\/pre>\r\n
\r\nCALL CAMINO1\r\n<\/pre>\r\n
\r\nPROCEDURE CAMINO1\r\n...\r\nENDPROCEDURE 100 ; would produce an ASSIGN in the calling entity named CAMINO1 with value 100\r\n<\/pre>\r\n
ENDPROCEDURE<\/code> may include a value in parameter A that will be returned in the same way as if an ASSIGN<\/code> instruction had been generated. It can be retrieved as P$ProcedureName (e.g., P$CAMINO1). In this case, it is not used.<\/p>",
"parametros": "",
"parametros_json": "",
"ejemplo": "",
"hijos": []
},
{
"id": "248",
"nombre": "Resources: Storage",
"texto": "\/* Warehouses: STORAGE\r\nCapacity management and storage usage.\r\n*\/\r\n\r\nINITIAL capacity,40 ; defines a savevalue named capacity with value 40\r\n\r\nSTORAGE {NAME:warehouse1, X:300, Y:200, capacity:X$capacity}\r\n\r\nPOSITION {NAME:EXIT, X:500, Y:200}\r\n\r\n; Text showing current contents\r\nGRAPHIC {NAME:text1, Type:TEXT, X:320, Y:240, Text:\"Current boxes: 0\"}\r\n\r\nSTART 100\r\n\r\n; Trucks arriving every 10 time units\r\nGENERATE 10,0 {NAME:Truck, X:100, Y:200}\r\n\r\nADVANCE 15 {TO:warehouse1}\r\nENTER warehouse1,(random*15)+1 ; Occupies between 1 and 16 storage units\r\nsavevalue usage,X$capacity - R$(warehouse1,LEFT)\r\nMOVE {name:text1,text:\"Current boxes X$usage : R$(warehouse1,OCCUPIED)\"}\r\nADVANCE 40,10\r\nLEAVE warehouse1 ; Releases the occupied units\r\nsavevalue usage,X$capacity - R$(warehouse1,LEFT)\r\nMOVE {name:text1,text:\"Current boxes X$usage : R$(warehouse1,OCCUPIED)\"}\r\nADVANCE 15 {TO:EXIT}\r\nTERMINATE 1\r\n",
"descripcion": "STORAGE<\/code>.<\/p>\r\nFACILITY<\/code> represents things such as a service counter, a machine, or an operator: it can serve only one entity at a time and according to its capacity (with CAPACITY:3, the FACILITY would serve 3 entities). STORAGE, on the other hand, represents something like a warehouse, a tank, or a network that can be used partially.<\/p>\r\nSTORAGE<\/code>? A STORAGE<\/code> is a type of resource that is not seized per entity, but by quantity. It is used when an entity must reserve part of a resource without occupying it entirely. For example, a truck can drop 10 boxes into a warehouse that can hold up to 40.<\/p>\r\n\r\nSTORAGE {NAME:warehouse1, X:300, Y:200, capacity:40}\r\n<\/pre>\r\nENTER<\/code> block to occupy a certain amount, and LEAVE<\/code> to give it back.<\/p>\r\n\r\nENTER warehouse1,5\r\nLEAVE warehouse1\r\n<\/pre>\r\n
STORAGE<\/code> has enough free capacity. You don’t need to program anything additional to manage that wait.<\/p>\r\nSTORAGE<\/code>) is defined with 40 capacity units. Trucks arrive every 10 time units and deposit between 1 and 16 boxes. After some time, they leave, freeing the occupied space. You will see on-screen text how many boxes are stored at any moment.<\/p>\r\nSTORAGE<\/code> occupancy:<\/p>\r\n\r\nR$(warehouse1,OCCUPIED) ; Units currently occupied\r\nR$(warehouse1,LEFT) ; Units available\r\n<\/pre>",
"parametros": null,
"parametros_json": null,
"ejemplo": null,
"hijos": []
},
{
"id": "307",
"nombre": "The event queue: the simulation engine",
"texto": "\r\nTime 15 - Serve entity 14 at step 88\r\nTime 45 - Serve entity 22 at step 16\r\nTime 77 - Serve entity 16 at step 25\r\n<\/pre>\r\n
GENERATE<\/code> and spend time being served via ADVANCE<\/code>.<\/p>\r\nT = 5<\/code>, with the following queue:<\/p>\r\n\r\nT 5: Entity 5: Waiting in the counter queue\r\nT 7: GENERATE: Create an item, a customer who will enter through the door\r\nT 8: Entity 9: Heading to the counter queue\r\nT 16: Entity 3: Heading to the counter queue\r\n<\/pre>\r\n
ADVANCE 10<\/code> to be served.<\/p>\r\n\r\nT 7: GENERATE: Create an item\r\nT 8: Entity 9: Heading to the counter queue\r\nT 15: Entity 5: Go to the exit\r\nT 16: Entity 3: Heading to the counter queue\r\n<\/pre>\r\n
GENERATE 20,5<\/code>. Therefore, we must compute what time is defined by 20,5; something between 20 and 25. Suppose the result is 22. That is, another person will enter in 22 time units. The queue now takes this form after the GENERATE<\/code> advances and performs 2 tasks<\/b>:<\/p>\r\nGENERATE<\/code> itself advances 20 (parameter A) (7+20=27).
\r\n2.- It creates a new entity (#10) so it can carry out its tasks 22 time units later (7+22=29).\r\n<\/p>\r\n\r\nT 8: Entity 9: Heading to the counter queue\r\nT 15: Entity 5: Go to the exit\r\nT 16: Entity 3: Heading to the counter queue\r\nT 27: GENERATE: Create an item\r\nT 29: Entity 10: Heading to the counter queue\r\n<\/pre>\r\n
\r\n
FACILITY<\/code> has two lists: the list of occupying entities and the list of entities waiting in queue.<\/p>\r\nSEIZE<\/code>, if the resource is busy, it moves to the waiting list. If there are no entities in the resource, it will seize it by entering the occupants list.<\/p>\r\nRELEASE<\/code>, it leaves that list and forces the resource to look for an entity in its pending queue to enter. If there is one, it will move it into the occupants list and schedule its entry into the event queue at that same instant, so that entity will take control of the engine as soon as the departing one stops its activity.<\/p>\r\nCONDITIONS<\/code> resource allows: stopping entities until a logical condition is met.<\/p>\nASSEMBLE<\/code> block for this purpose. In GPSS-Plus, this behavior is replaced by a more general and flexible resource.<\/p>\nCONDITIONS<\/code> resource allows holding entities<\/strong> until a condition is satisfied. This condition is defined as an expression that is evaluated each time an entity attempts to pass.<\/p>\n\nCONDITIONS {NAME:Conditions1,X:208,Y:317,expression:(X$counter>=5)}\n<\/pre>\nCONDITIONS<\/code> has additional options that will be covered later.<\/p>\nWAITUNTIL<\/code>, is responsible for validating the condition for the current entity — in this case, whether the counter is greater than or equal to 5.<\/p>\nWAITCHECK<\/code>.<\/p>\nCONDITIONS<\/code> resource together in the first segment. In the second one, the randomness of ADVANCE 20,40<\/code> causes them to spread apart.<\/p>\nENDGENERATE<\/code> block, which is more consistent with the structured approach than TERMINATE<\/code>. They are equivalent, but syntactically it is more appropriate to structure the block using GENERATE<\/code>\/ENDGENERATE<\/code>. This makes it easier to identify which block was generated, especially when multiple GENERATE<\/code> blocks exist in the program.<\/p>",
"parametros": "",
"parametros_json": "",
"ejemplo": "",
"hijos": []
},
{
"id": "216",
"nombre": "Second structural step",
"texto": "\/* Blocks: SWITCH and LOCK\/UNLOCK\nConditional routing and management of lockable resources.\n*\/\n\nFACILITY {NAME:COUNTER1,X:320,Y:450,CAPACITY:3}\nFACILITY {NAME:COUNTER2,X:320,Y:300,CAPACITY:3}\nFACILITY {NAME:COUNTER3,X:320,Y:150}\nFACILITY {NAME:COUNTER4,X:320,Y:50}\n\nPOSITION {NAME:POS1,X:158,Y:301}\nPOSITION {NAME:POS2,X:497,Y:300}\nPOSITION {NAME:POS3,X:627,Y:300,TYPE:TERMINATE,TITLE:END}\n\nGRAPHIC {NAME:Text1,Type:TEXT,X:320,Y:104,Text:\"Unlock\"}\n\nSTART 30\n\nGENERATE 10,0 {NAME:GEN1,X:57,Y:300}\nADVANCE 20,0 {TO:POS1,flow:1}\n\nASSIGN RANDOM_VALUE,(RANDOM)\n\nSWITCH P$RANDOM_VALUE\n CASE <,0.4\n CALL PATH1\n ENDCASE\n\n CASE <,0.8\n CALL PATH2\n ENDCASE\n\n CASE <,0.92\n CALL PATH3\n MOVE {NAME:Text1,text:\"Lock\"}\n LOCK COUNTER1\n LOCK COUNTER2\n LOCK COUNTER3\n ENDCASE\n\n DEFAULT\n CALL PATH4\n MOVE {NAME:Text1,text:\"Unlock\"}\n UNLOCK COUNTER1\n UNLOCK COUNTER2\n UNLOCK COUNTER3\n ENDCASE\nENDSWITCH\n\nADVANCE 20,10 {TO:POS2,flow:1,MERGE:\"exit\"}\nADVANCE 20,0 {TO:POS3,flow:1}\n\nENDGENERATE 1\n;****************************************\n\nPROCEDURE PATH1\n ADVANCE 20 {TO:COUNTER1,flow:1,DECISION:\"start\"}\n SEIZE COUNTER1\n ADVANCE 45,10\n RELEASE COUNTER1\nENDPROCEDURE\n\nPROCEDURE PATH2\n ADVANCE 20 {TO:COUNTER2,flow:1,DECISION:\"start\"}\n SEIZE COUNTER2\n ADVANCE 40,10\n RELEASE COUNTER2\nENDPROCEDURE\n\nPROCEDURE PATH3\n ADVANCE 20 {TO:COUNTER3,flow:1,DECISION:\"start\"}\n SEIZE COUNTER3\n ADVANCE 40,20\n RELEASE COUNTER3\nENDPROCEDURE\n\nPROCEDURE PATH4\n ADVANCE 20 {TO:COUNTER4,flow:1,DECISION:\"start\"}\n SEIZE COUNTER4\n ADVANCE 10,2\n RELEASE COUNTER4\nENDPROCEDURE\n\n;***************************************************************",
"descripcion": "IF<\/code>), let’s look at a case where an entity chooses between multiple possible routes<\/strong>.<\/p>\n