A system for and method of simulating complex resource sharing for an industrial procedure

Abstract

A System for and Method of Simulating Complex Resource Sharing for an Industrial Procedure A system for and method of simulating complex resource sharing for an industrial procedure is set out herein and, more particularly, a method of controlling a shared resource store is described. The method comprises: simulating the shared resource store including providing a current level variable indicating a current level of available resource of the resource store, a maximum capacity level indicating a maximum capacity of the resource store and a minimum capacity value indicating a minimum capacity of the resource store; simulating an input queue for a resource store with one or more resource input requests; simulating an output queue for a resource store with one or more resource output requests; the one or more input and output requests each comprising: a quantity of the available resource; and a queue value which indicates the order in which the request was added to the queue; simulating systematic execution of resource input requests and resource output requests on the resource store; the simulating step including using the current level variable, the maximum capacity level and the and minimum capacity value to determine an alert condition, the alert condition being created if: i. the systematic execution of a next queued one of the one or more resource input requests will result the current level variable exceeding the maximum capacity level; or ii. systematic execution of a next queued one of the one or more resource output requests will result the current level variable being less than the minimum capacity value; and generating and sending a control signal to the resource store to change the maximum capacity level or current level of available resource in the resource store to mitigate the alert condition.

Description

A System for and Method of Simulating Complex Resource Sharing for an Industrial ProcedureTECHNICAL FIELD OF THE DISCLOSURE

[0001] The present disclosure relates to a computer-implemented system and method of simulatingcomplex resource sharing for an industrial procedure. More particularly, though not exclusively, the present disclosure concerns simulating industrial procedures (each made up of a plurality of processes) such as automated or semi-automated vehicle assembly lines, automated consumer electronic device manufacture, managing resources in a shared resource computing system, chemical plant resource management in manufacture of chemical formulations, where competition for shared resources may lead to bottlenecks which can be detected by the simulation and can lead to adjustment of the system design to mitigate such problems. The present disclosure also extends to simulation of other procedures (comprised of a plurality of individual processes) whereby potential problems in the implementation of a procedure, or a process,can be simulated, detected and resolved before implementation of the procedure or process in practice or,alternatively, potential problems can be mitigated by generation of appropriate control signals to changethe operation of the procedure in a real-time system before the problem occurs. A non-limiting example ofsuch a procedure is the loading and unloading of airfreight containers onto an aircraft to maximise efficientuse of available resources in an airport and minimise loading and unloading times for a cargo aircraft. BACKGROUND

[0002] Discrete event simulation (DES) models are used to describe a series of discrete events in a real-life system that can either be a physical system, such as a production line in a manufacturing facility, or a computer system, such as a computational network. Typically, DES models are used to describe real-lifesystems where the series of events competes for finite resources. As such, DES models are often used toevaluate the efficiency and efficacy of a system in order to determine possible bottlenecks such as resource shortages. Applications of such DES models include, but are not limited to, the healthcare sector, the manufacturing sector and the financial sector.

[0003] Despite the existence of DES models, the currently available models do not have sufficientmodularity and do not produce data with sufficiently high resolution to accurately model real-life systems. Furthermore, the currently available models are not able to optimize a system consisting of multiple subsystems with many inter-dependencies, whilst still being computationally efficient and having enough functionality and customisability to accurately describe real-life systems that are continuously changing. In particular, this problem is seen when managing shared resources for a procedure made up of a plurality of different processes. Here, without accurate simulation of the timing of the received requests to the resource and provision of the resource items to the requestor, such simulations become very crude and inaccuratewhich makes it difficult to use these simulations for determining potential problems or indeed, for control ofthe resource itself. Similarly, all processes which interact with a shared resource need to be modelled whichcan be difficult because the processes themselves can be very different in nature and operation. This leads to assumptions being made or the operation of a shared resource only being partially simulated, and thusbeing inaccurate. Such inaccuracies in turn can lead to bottlenecks and other sourcing problems occurringwhen using the results of such crude simulations.

[0004] Furthermore, DES models enable an amount of a resource, for example, to be changed. However,existing models have limited functionality for example when a flag status changes, as the change is typicallypermanent. Therefore, after the flag status has changed, the flag no longer reacts to a subsequent change in the system. This is computationally inefficient because the simulation has to be re-run as it does not respond to real-time changes.

[0005] An objective of the current disclosure is therefore to address at least one of the limitations outlinedabove. SUMMARY OF THE DISCLOSURE

[0006] According to one aspect of the disclosure there is provided a method of controlling a sharedresource store, the method comprising: simulating the shared resource store including providing a current level variable indicating a current level of available resource of the resource store, a maximum capacity level indicating a maximum capacity of the resource store and a minimum capacity value indicating a minimum capacity of the resource store; simulating an input queue for a resource store with one or more resource input requests; simulating an output queue for a resource store with one or more resource output requests; the one or more input and output requests each comprising: a quantity of the available resource;and a queue value which indicates the order in which the request was added to the queue; simulatingsystematic execution of resource input requests and resource output requests on the resource store; thesimulating step including using the current level variable, the maximum capacity level and the and minimumcapacity value to determine an alert condition, the alert condition being created if: i. the systematic execution of a next queued one of the one or more resource input requests will result the current levelvariable exceeding the maximum capacity level; or ii. systematic execution of a next queued one of the oneor more resource output requests will result the current level variable being less than the minimum capacityvalue; and generating and sending a control signal to the resource store to change the maximum capacitylevel or current level of available resource in the resource store to mitigate the alert condition.

[0007] The simulating execution of resource input requests and resource output requests on the resourcestore may comprise: selecting a next resource input request or a next output resource request to be fulfilled by the simulated resource store on the basis of the next resource input request or a next output resource request in the respective input or output queue, which is able to be fulfilled based on the current level variable, the maximum capacity level and the minimum capacity value.

[0008] The simulating execution of resource input requests and resource output requests on the resourcestore may further comprise: checking the status of a queue checking flag to determine if the simulation permits checking of the input queue and the output queue to determine of any request can be fulfilled by the simulated resource store.

[0009] Each resource input request or resource output request may comprise a size of an item of theresource; and the determining step may comprises establishing whether a resource input request of the one of more input requests or a resource output request of the one of more output requests can be fulfilled based on a size of the items of the resource present in the resource store.

[0010] Simulating the input queue or the output queue may comprise scheduling adding a resource inputrequest of the one of more input requests or a resource output request of the one of more output requests to the respective input or output queue at a specified time.

[0011] Simulating the input queue or the output queue may comprise delaying adding a resource inputrequest of the one of more input requests or a resource output request of the one of more output requests to the respective input queue or output queue by a specified time period.

[0012] Simulating the input queue or the output queue may comprise delaying adding a resource inputrequest of the one of more input requests or a resource output request of the one of more output requests to the respective input queue or output queue until a specified condition occurs.

[0013] In some embodiments, each resource input request or resource output request comprises a queuepriority value, which indicates the relative priority of the resource input request or the resource output request; and wherein simulating the input queue or simulating the output queue comprises reordering the simulated input queue or the simulated output queue respectively by either the queue priority value or the queue value.

[0014] Simulating the output queue may comprise reordering the output queue from a queue priority valueorder to a queue value order when the current level variable is above a minimum threshold level.

[0015] Simulating the output queue may comprise reordering the output queue from a queue value orderto a queue priority value order when the current level variable is below a minimum threshold level.

[0016] Simulating the input queue may comprise reordering the input queue from a queue value order toa queue priority value order when the current level variable is above a maximum threshold level.

[0017] Simulating the input queue may comprise reordering the input queue from a queue priority valueorder to a queue value order when the current level variable is below a maximum threshold level.

[0018] Simulating the input queue or simulating the output queue may comprise reordering the input queueor the output queue from a queue value order to a queue priority value order when demand for the resource is above the threshold level.

[0019] Demand for a resource may be measured by the number of output requests in the output queue orthe total quantity of the requested resource of all of the output requests in the output queue.

[0020] In some embodiments, simulating execution of resource input requests and resource outputrequests on the resource store comprises: triggering the checking of the simulated output queue todetermine if the next resource output request in the simulated output queue can be executed, once a resource input request is executed from the simulated input queue; or triggering the checking of the simulated input queue to determine if the next resource input request in the simulated input queue can be executed, once a resource output request is executed from the simulated output queue.

[0021] Each resource input or output request may comprise a Boolean true / false timeout indicator toindicate whether the time between a time when the request was created and a current time has exceeded a predetermined time limit, and the simulating step may comprise removing any resource input or resource output requests from the respective input or output queues if the timeout indicator is true.

[0022] In some embodiments at least one of the one or more resource input requests or one or moreresource output requests comprises a first available resource request that is placed into input or output queues of a plurality of resource stores simultaneously, each first available resource request comprising a Boolean true / false request remover indicator to indicate whether the first available request should beremoved from the input or output queue of the respective resource store in response to a first available resource request having been fulfilled by one of the plurality of resource stores; and wherein simulating systematic execution of resource input requests and resource output requests on the resource store comprises removing the first available input or output request from the respective resource store when the request remover indicator is true.

[0023] Simulating execution of resource input requests and resource output requests on the sharedresource store may comprise: determining the state of a Boolean updating queue flag of the resource store;and preventing the execution of resource input requests and resource output requests on the shared resource store whilst the Boolean updating queue flag is in a first predetermined state.

[0024] Simulating the input queue or the output queue may comprise enabling resource input requests orresource output requests to be added to the respective input or output queues whilst the Boolean updating queue flag is in a second predetermined state.

[0025] Simulating the shared resource store may comprise simulating the storage of resource items in aplurality of different sets within the resource store, each set comprising a plurality of items sharing a common characteristic.

[0026] In some embodiments, simulating the input queue or the output queue comprises: determining thestate of a Boolean Yield In Order flag; if the Yield in Order flag is in a first predetermine state, executingrequests in the input queue and output queue in the order determined by the queue; and if a Boolean Yield in Order flag is in a second predetermine state, and if a foremost request in the input queue or the outputqueue cannot be fulfilled, determining if the next request in the respective input or output queue can befulfilled.

[0027] Simulating systematic execution of resource input requests and resource output requests on theresource store may comprise using Boolean flags which are configured to be able to be switched multipletimes between different states.

[0028] The Boolean flags may provide a current status of the resource, flag wait events, show availabilityof a resource, change state once a predetermine condition has been detected, or modify queue ordering.

[0029] The present disclosure also extends to a method of controlling a plurality of shared resource stores,the method comprising: simulating the plurality of shared resource stores, the simulating step comprisingfor each one of the plurality of shared resource stores: including providing a current level variable indicatinga current level of available resource of the resource store, a maximum capacity level indicating a maximum capacity of the resource store and a minimum capacity value indicating a minimum capacity of the resourcestore; simulating an input queue for a resource store with one or more resource input requests; simulatingan output queue for a resource store with one or more resource output requests; the one or more input andoutput requests each comprising: a quantity of the available resource; and a queue value which indicatesthe order in which the request was added to the queue; simulating systematic execution of resource input requests and resource output requests on the resource store; the simulating step including using the current level variable, the maximum capacity level and the and minimum capacity value to determine an alert condition, the alert condition being created if: i. the systematic execution of a next queued one of the one or more resource input requests will result the current level variable exceeding the maximum capacity level;or ii. systematic execution of a next queued one of the one or more resource output requests will result thecurrent level variable being less than the minimum capacity value; and generating and sending a controlsignal to the resource store to change the maximum capacity level or current level of available resource in the resource store to mitigate the alert condition.

[0030] In some embodiments, at least one of the resource input or output requests comprises a firstavailable resource request and the simulation comprises: generating a copy of the first available resourcerequest and placing the copy of the first available resource request in each of the plurality input or outputqueues of the plurality of resource stores simultaneously, and upon fulfilment of any one of the plurality offirst available resource requests, removing any non-fulfilled first available resource requests from the input or output queues of the plurality of resource stores.

[0031] The present disclosure also extends to a method of controlling a shared resource store, the methodcomprising: simulating the shared resource store including providing a current level variable indicating a current level of available resource of the resource store and a current capacity variable indicating a currentcapacity of the resource store; simulating an input queue for a resource store with one or more resourceinput requests; simulating an output queue for a resource store with one or more resource output requests;the one or more input and output requests each comprising: a quantity of the available resource; and aqueue value which indicates the order in which the request was added to the queue; simulating systematic execution of resource input requests and resource output requests on the resource store; the simulating step including using the current level and current capacity variables to determine if the systematic execution of the resource input requests and resource output request from the input and output queues, will result indelays beyond a threshold delay period in fulfilling the requests; and generating and sending an alert signalindicating that a change in the current capacity or current level of available resource in the resource store is required to reduce the delay to below the threshold delay period.

[0032] According to another aspect of the present disclosure there is provided a multiple process simulatorfor simulating the handling of a ticket though a plurality of different processes using shared resources, the simulator comprising a processor and being configured to simulate: a plurality of simulated resources, each simulated resource being arranged to receive a resource request and provide a response to the source request indicating whether the request can be fulfilled by the simulated resource; the plurality of different processes, each process comprising: a ticket processor configured to receive a ticket to be by the handled by the process; a request manager configured to generate resource requests required to implement the process on the ticket; a resource requestor configured to handle the transmission of resource requests to one of more of the plurality of simulated resources and to handle the responses from the one of more ofthe plurality of simulated resources; a flow detail logger for recording the outcome of the process based onthe responses received from the one of more of the plurality of simulated resources, on the ticket to appraise a subsequent one of the plurality of different processes of the results of the process; and a process selector configured to determine a next process of the plurality of different processes to be implemented on the ticket based on the outcome recorded on the ticket.

[0033] In some embodiments the simulator is configured to provide the ticket to a first one of the pluralityof different processes and subsequently, to provide the ticket to a second one of the plurality of differentprocesses, the second one of the plurality of different processes reading the outcome of the first one of theplurality of different processes and selecting activity to be carried out by the second process as a consequence of the result carried out by the first process.

[0034] The simulator may be configured to simulate the second process and record the outcome of thesecond process on the ticket thereby creating a history of processing the ticket though the first and second processes.

[0035] The multiple process simulator may be further configured to simulate a success / timeout hook, thesuccess / timeout hook being triggered by a successful completion of the process on the ticket or by the expiry of a time limit for conducting the process on the ticket.

[0036] The multiple process simulator in some embodiments is further configured to simulate a flagrequestor for generating a Boolean flag status request regarding a status of a part of the simulator and to receive a flag status from the part of the simulator to provide to the request manager for determining the next action in the process.

[0037] The flag requestor may be configured to generate a request regarding a status of one or more ofthe plurality of simulated resources and to receive a flag status from the one or more of the plurality of simulated resources.

[0038] In some embodiments, the flag requestor is configured to generate a conditional request regardinga status of one or more of the plurality of simulated resources and to receive a flag status from the one or more of the plurality of simulated resources once the condition has been met.

[0039] The multiple process simulator may be further configured to generate events which are added toan environment execution queue for execution, with results of the events being provided to the process and recorded by the flow detail logger in a flow detail of the ticket.

[0040] The multiple process simulator may be further configured to generate events having a delay whichneeds to be executed before the event is added to the environment execution queue.

[0041] According to another aspect of the present disclosure, there is provided a multiple processsimulation system for simulating a plurality of processes which are simulated to determine an optimum configuration of the processes, the system comprising a processor configured to simulate processing a ticket by a first one of the plurality of processes, whereby each process of the plurality of processes generates events which, if they can be executed, are added to an environment execution queue for execution, results of the events are noted by the process and recorded in a flow detail of the ticket for use in subsequent processing of the ticket by a second one of the plurality of processes. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The above and other features and advantages of the present disclosure will become readilyapparent to those skilled in the art by the following detailed description of exemplary embodiments thereof with reference to the attached drawings, in which:Figure 1 is a schematic block diagram showing a system for simulating a procedure, for use in controllinga complex procedure, where a simulation environment simulates multiple different processes of theprocedure working on one or more tickets, the processes accessing shared resources and flags according to an embodiment of the present disclosure;Figure 2 is a flow diagram showing a method of processing events in the environment queue of Figure 1;Figure 3 is a block diagram showing an example of an environment queue of Figure 1 containing a pluralityof events;Figure 4A is a block diagram showing the essential features of an event comprised in the environmentqueue of Figure 1;Figure 4B is a block diagram showing the features of different types of events that can be comprised in theenvironment queue of Figure 1;Figure 5 is a schematic block diagram of a simulated process of Figure 1 and the simulation elementswhich make up the process showing how flags and resource requests are generated and used in the processing of a ticket;Figure 6 is a schematic block diagram of a ticket processor, a request manager, a flag requestor and aresource requestor of a first embodiment of the process shown in Figure 5 in greater detail together withthe composition (in its most basic essential form) of a ticket, a flag request, a flag and a resource request;Figure 7 is a schematic block diagram of a ticket processor, a flag requestor and a resource requestor ofa second embodiment of the process shown in Figure 5 in greater detail together with the composition (ina more detailed form) of a ticket, a flag request, a flag and a resource request;Figure 8 is a schematic block diagram of a request manager, a first available resource requestor and a firstavailable resource request of another embodiment of a resource requestor and resource request shown in Figure 5, as well as the essential elements of a resource;Figure 9 is a schematic block diagram of a simulated shared resource of Figure 1 showing the resourcewhich handles a resource request in greater detail. The simulated resource includes a get queue and a putqueue for getting and putting items into a resource stock, and the resource stock itself. Also shown is theflag / queue controller which sets / changes flag values dependent on state of resource. The simulatedresource can, in different embodiments, be a workpool or a store of a quantity of reusable resource or astore of consumable (non-reusable) items as a resource;Figure 10 is a schematic block diagram of another embodiment of a simulated shared resource shown inFigure 9, wherein the simulated resource comprises a store resource;Figure 11 is a flow diagram showing a method of processing a ticket within a simulated process of Figure5 and the relationship to flags and requests;Figure 12 is a flow diagram showing how requests are processed in a queue such as the queue at thesimulated resource of Figure 9;Figure 13 is a schematic block diagram of an embodiment of a simulation environment showing a way toimplement the software architecture;Figure 14 is a schematic block diagram showing how shared resources are computationally defined withinthe simulation environment of Figure 13, with the contents and behaviour of the resource varying independence upon the resource type;Figure 15 is a schematic block diagram showing how events and flags are defined within the environmentof Figure 13;Figure 16 is a schematic block diagram showing how processes are defined within the environment ofFigure 13; andFigure 17 is a schematic block diagram showing an example of how the simulation environment of Figure1 simulates an engine assembly line in a factory for manufacturing vehicles.DETAILED DESCRIPTION

[0043] Figure 1 shows the overview of an exemplary simulation system 10 for simulating a procedure andproviding an output to a control system 114 for controlling a procedure. The simulation system 10 comprisesa simulation environment 100, a data processing platform 112 and a control system for the procedure 114.Figure 1 shows the modular framework of the simulation environment 100 in accordance with anembodiment of the present disclosure, within which a real-life series of events is simulated and wherein thepassing of time is simulated by stepping from event to event. The simulation environment 100 is incommunication with the data processing platform 112 which can process the results of the simulation and provide information such as recommendations, and in some cases, control commands to the control system 114 for controlling the procedure being simulated. The present embodiments are described with respect to various real-life industrial systems and processes that require a more accurate modular framework than the prior art systems for determining possible bottlenecks and shortages of resource capacity.

[0044] The simulation environment 100 comprises at least one ticket 102, one or more processes104a / b / c / d which act on the ticket 102, one or more shared resources 110a / b / c which are required by the processes 104a / b / c / d to accomplish their task (or work) on the ticket, at least one flag 108 which controls the order of events (a flag representing a status of an event, or functional item within the simulation), and at least one processed ticket 106 (resulting from the last process 104d). The term ‘resource(s)’ as usedhereinafter, is to be considered to refer to any of a workpool, a store or a consumable type of resource andrelates to components / articles that must be requested in order to process a ticket. In particular, aconsumable type of resource comprises non-reusable, non-discrete items that can only be used once (consumed) and require the consumable resource subsequently to be replenished. The workpool and storetypes of resource generally include a quantity of reusable or non-reusable resource and the resourcetypically includes discrete items i.e. items for atomic utilisation. A workpool resource, as referred to inembodiments of the present disclosure, includes identical resource items, for example specific machinesthat perform work on a ticket such as a fleet of cars or people (or their robotic equivalents) that performwork on a ticket. Each identical resource item can be used for the same purpose or function. A storeresource, as referred to herein, typically includes a storage space for storing non-identical items such astickets. The term ‘ticket’ 102 is used to represent an item which flows through the simulation system 10.The item can be anything in the real world which is subject to real-world processes which are also simulated by the simulation system 10. Each ticket 102 has attributes (described later with reference to Figure 6), which affect the ticket’s journey through the simulation system 10. It is also to be appreciated that the term ‘an item’ or ‘a resource item’ can be an individual component or a measure of quantity of an amount of a resource. For example, an item can be a discrete object, such as a car part, or can be an amount of resource, such as a number of litres of lubrication oil.

[0045] The simulation environment 100 also comprises an environment manager 126, an environmentqueue 116, dictionaries for the processes, resources and flags 118, a list of tickets 120, a process networkmap 122 and a current simulation time 124 indicator. The environment manager 126 executes methods ofthe simulation environment 100 and is in communication with all processes 104, flags 108 and resources110, as well as the environment queue 116, dictionaries 118, ticket list 120, process network map 122 andcurrent simulation time 124. The ticket list 120 contains all the tickets 102 created in the environment 100for the current simulation. Similarly, all the processes 104, resources 110 and flags 108 created in theenvironment 100 for the current simulation are stored in corresponding dictionaries 118. In the exampleshown in Figure 1, the ticket list contains a ticket 102 and the dictionaries 118 contain Processes A, B, C and X 104a / b / c / d, flags 108 and Resources 1, 2 and 3110a / b / c.

[0046] In an embodiment, the ticket 102 is input into a first process, Process A 104a, which processes theticket 102 using flags 108 and resources 110 that it requests using requestors, as described below. Theserequests are added as events in the environment queue 116 by the environment manager 126. In the current embodiment, flags 108 comprise flag wait events, for example if the simulation platform 100 represented a manufacturing facility, a flag wait event could represent the on / off status of a production line. The output of Process A is a semi-processed ticket (not shown) which can then be passed to the next process in the series (Process B in the example of Figure 1). These sequential stages of work continue until the last process (Process X in the Figure 1 example) does work on the semi-processed ticket 102. The series of processes 104a / b / c / d generate a final processed ticket 106 that includes details of the work done by each previous process 104a / b / c / d using the resources 110 and flags 108.

[0047] As used herein, a resource 110 may refer to: a consumable that can be used once and then refilled;a workpool that has a discrete value and can be used and released multiple times; or a store that has slot- based storage.

[0048] The requests for resources and flags raised by the processes 104 are received by the environmentqueue 116 and processed as events. There can be different types of events, described in more detail below,wherein the different types of events have different attributes. The order that the events are placed in the environment queue 116 depends on the type of event. Such attributes may, for example, indicate a level of importance of an event or a time within which the event has to be processed. According to these attributes,and using the time received from the current simulation time indicator 124, the environment manager 126places the events at an appropriate position in the environment queue 116.

[0049] As mentioned above, the semi-processed ticket may be input into subsequent processes 104,wherein the subsequent processes are determined by the process network map 122. For example, oncethe ticket 102 has been processed by Process A 104a, which is monitored by the environment manager126, the environment manager 126 communicates with the process network map 122 to determine the nextprocess that the semi-processed ticket should be sent to. In the present example, the environment manager126 communicates to Process A 104a that the next process is Process B 104b and subsequently ProcessC 104c, and so on until it reaches Process X 104d. When there are no more processes in the processnetwork map 122, the semi-processed ticket is completed (processed) and becomes a processed ticket106 and is then read out to the data processing platform 112 for analysis. Alternatively, the semi-processedticket may be stored as described below.

[0050] Whilst the embodiment shown in Figure 1 illustrates a limited number of processes (Processes A,B, C to X), three resources and one set of flags, it will be appreciated that the number of processes 104corresponds to the number of processing tasks that occur in a real-life system that is being simulated, and the number of resources 110 and flags 108 corresponds to the number of different resources 110a / b / c and flags 108 provided in the real-life system. Similarly, the modularity of the system enables a given process (for example Process C) to be used by different procedures with different tickets and also for two processes to be carried out in parallel where in real-life the processes do not rely on the results of the process being carried out in series.

[0051] The data read out from the processed ticket 106 in the data processing platform 112 is used toimprove the efficiency of the real-life system it represents, such as determining whether the resource levelis sufficient to complete all processes successfully and / or with minimal delay. It will be appreciated that thesimulation can be used for one ticket as depicted in Figure 1 to test bottlenecks of a real-life system, such as whether one or more processes can be successfully completed within a time constraint, e.g. a time of manufacturing a resource or a time of replenishing the capacity of a resource. However, this environment 100 is also used to process a plurality of tickets 102 simultaneously, wherein the processes 104 compete for the finite resources 110. An advantage of this embodiment is that the environment 100 can process hundreds of thousands of tickets 102 simultaneously that are competing for common resources 110 and thus simulate real-life demand for those resources more accurately. Furthermore, the embodiment of Figure 1 is able to include simulations of real-life processes that are seemingly disconnected in order to more accurately represent the real-life system than has previously been possible. For example, in a non-industrial environment example, understanding resource requirements in a cinema usually requiresseparate discrete simulation models for a ticket queue and a food / drink queue. However, the present embodiment can be used to model both these queues simultaneously, wherein the tickets 102 are the customers in the queue and the resources 110 are the cinema tickets and food / drink being purchased. By modelling these two queues simultaneously, a shared resource of a final entrance barrier for all people entering the cinema hall can be modelled and an appropriate number of ushers provided to prevent long entrance queues forming or unsafe overcrowding in certain common areas of the cinema complex. In this way, the cinema ecosystem can be more accurately understood and appropriate resources deployed in order to avoid long queues in the cinema complex.

[0052] A method 200 used by the environment manager 126 of Figure 1 to process events in theenvironment queue 116, is shown in Figure 2. When the simulation is constructed, at least one event is added to the environment queue 116, wherein the event adds one or more tickets 102 into a process 104. Generally, the environment queue 116 comprises one or more events and the time at which the event willbe processed. Once the simulation starts, at Step 202, an event is taken, at Step 204, from the top of theenvironment queue 116 to be processed. Subsequently, the current simulation time 124 is updated, at Step206, to the time at which the event is processed. At Step 208, any code associated with the removed event(callbacks) is executed. If the callbacks generate new events, the new events are added, at Step 210, tothe environment queue 116. At Step 212, the environment queue 116 is checked for more events. If thereare more events in the environment queue 116, the method 200 is repeated, Step 204 to Step 212, untilthere are no more events in the environment queue 116. When there are no more events in the environmentqueue 116, the simulation is finished, at Step 214.

[0053] In an alternative embodiment, the simulation is finished after a predetermined period of time andas determined by the current simulation time 124.

[0054] In another embodiment of the present disclosure, if an event cannot be fulfilled, the simulation ispaused. For example, when a process 104 requests a resource 110, an event is created in the environment 100 (not shown in Figure 1). If the resource 110 has sufficient capacity to fulfil the request, the request is‘triggered’, meaning that the event is added into the environment queue 116 with the time at which it mustbe processed. However, if the resource 110 does not have sufficient capacity, the event is not triggered, and the simulation is paused until the request can be fulfilled.

[0055] The environment queue 116 of Figure 1 is shown in greater detail in the block diagram of Figure3. The environment queue 116 contains at least one event, wherein each event can be of a different type as explained below in relation to Figures 4A and 4B. An event goes through three stages in its lifetime: (i) may happen; (ii) will happen at a specified time and is in the environment queue 116 (triggered); and has happened (triggered and processed). The events in the environment queue 116 are ordered according to their relative priority and the time at which they should be processed. The order of events is maintained by the environment manager 126 which is also in communication with the current simulation time 124, asexplained above. The environment queue 116 comprises ordered events, such as Event 1, Event 2, Event3 etc. As described above, processing an event may lead to callbacks that can generate new events. In an example embodiment, processing Event 2 leads to callbacks that generate Events 2A, 2B and 2C as shownin Figure 3. Figure 3 also shows that processing Event 4, causes another event, Event 4A, to be added tothe environment queue 116. Although in the embodiment of Figure 3, the subsequent events generateddue to callbacks are added sequentially after the original events, in other implementations of the presentembodiment the subsequent events may be added in a different place in the environment queue 116. Theplacement of a subsequent event in the environment queue 116 depends on its priority and the time atwhich it should be processed.

[0056] The environment queue 116 can comprise different types of events, some of which are shown inFigures 4A and 4B. The essential features of an event 402 are shown in Figure 4A and include a resourceID 404, a yield priority 406, event details (callbacks) 408, the creation time 410 of the event, and a value412. The resource ID 404 is used to identify one of the plurality of various resources 110 in the environment100 such that an event 402 can be processed by the appropriate resource 110. The yield priority 406indicates the priority of the event 402 in the environment queue 116. The event details 408 comprise anycallbacks, which is code that is run when the event 402 is being processed, and information about the event402 such as its identifier. The value 412 is assigned to the event 402 when the event 402 is added to theenvironment queue 116 (triggered) and therefore indicates that the event 402 has been triggered.Advantageously, the presence of a value 412 can be used to check whether an event 402 is in theenvironment queue 116 without checking the entire environment queue 116. Additionally, the value 412 isused to identify the event in the simulation and therefore enables the transmission of information from thetime the event 402 is triggered to when the event 402 is processed. Therefore, the value 412 can be usedby multiple processes in the simulation.

[0057] In an embodiment, the event 402 may comprise a Timeout event 414. In addition to the essentialfeatures of an event 402 described above, a Timeout event 414 also comprises a delay 416 that is anamount of time from when the Timeout event 414 is created until it is automatically triggered. A Timeoutevent 414 can be created by a “yield within time creator” component (not shown here) that is comprised in a process 104 as further explained below with reference to Figure 5.

[0058] In another embodiment, the event 402 may comprise a Condition event 418, which depends onone or more provided events 402 and is automatically triggered when the dependent events 402 aretriggered according to one of three conditions: (i) all dependent events are in a certain condition (‘all of’);(ii) any dependent event has a specified status (‘any of’); or (iii) a specified number of dependent events(‘some of’) have a specified status. In addition to the essential features of an event 402 described above,a Condition event 418 also comprises an events monitor 420, namely a list of events to monitor, a targetcount 422 and a delay 424. If the Condition event 418 has a ‘some of’ condition, the target count 422 is theminimum number of provided events 402 that must be triggered for the Condition event 418 to be triggered.The delay 424 is an amount of additional simulation time from when the condition is passed until the Condition event 418 is processed.

[0059] In another embodiment, the event 402 may comprise an Add Generator event 426, which registerscode into the simulation. If code in the Add Generator 426 waits upon other events 402 to yield, the codecan be paused and resumed as appropriate. In addition to the essential features of an event 402 describedabove, an Add Generator event 426 further comprises a generator 428 that adds code to the simulation.

[0060] In another embodiment, the event 402 may comprise a Watcher event 430. Watcher events 430yield when the level of a resource 110 matches a condition or when the status of a flag 108 matches acondition. In addition to the essential features of an event 402 described above, a Watcher event 430 further comprises an amount 432 of a resource to watch for and a mathematical operator 434 which compares theamount 432 with the level of the resource. For example, the operator 434 of a Watcher event 430 may beset to ‘more than’ (>) such that the Watcher event 430 only becomes triggered when the resource it is‘watching’ is more than the pre-defined amount 432. Watcher events 430 are further described below inreference to Figure 9. In other embodiments, a Watcher event 430 may comprise a flag status to ‘watch’ or wait for (not shown here).

[0061] In another embodiment, the event 402 may comprise a resource request event. Resource requestevents will be described in further detail below with reference to Figures 5 to 8.

[0062] An exemplary process 104 that does work on a ticket 102 is shown in greater detail in Figure 5.The process 104 comprises a process ID 520, a ticket processor 502, a flag requestor 504, a resourcerequestor 506, a request manager 510, a success / timeout hook 512, a flow detail logger 514, a processselector 524, and a process time 522. Although the embodiment shown in Figure 5 only includes one flagwait requestor 504 and one resource requestor 506, in other embodiments the number of requestorscorresponds to the number of flags 108 and resources 110 requested by the process of the simulated real- life system. Any number of requestors 504, 506 can exist on a process 104, and this number can be changed dynamically. Additionally, there are numerous selection criteria options to customise how resources are selected.

[0063] The ticket processor 502 stores the requests required by the process 104 to process the ticket 102and also determines if there are any unfilled (incomplete) requests on the ticket 102 from a previous process 104. The requests required by the process 104, in addition to the unfilled requests on the ticket 102, arepassed on to the request manager 504. The request manager 504 instructs one or more requestors 506,508, which create requests 510, 512 as events 402. A resource request event is added to the environmentqueue 116 (triggered) if / when there is sufficient capacity at the resource 110 to succeed (complete) theresource request. The request manager 510 then receives the response from the resource request event402 in the environment queue 116 and processes the ticket 102 accordingly. The flag requests 510comprise flag wait events that are added to the environment queue 116 (triggered) when the flag is of thedesired status. If the flag status is enabling the process 104 to continue, the ticket 102 is processedaccording to the required status. However, if there is not enough capacity at the resource 110 to completethe resource request, or the flag 108 is unavailable (not in the correct state), the request remains on theticket 102 as an unreleased (incomplete) request.

[0064] The request manager 510 additionally communicates with the process / timeout time 516, whichcontrols the amount of time that the ticket 102 is held by the request manager 504. If all required resources110 and flags 108 are available, the process 104 is considered successful and once all the requests 510,512 have been fulfilled (succeeded), additional custom code may be run through the success hook 514.Optionally, the requests 510, 512 might have to be fulfilled within a predetermined amount of time using theoptional attribute or value ‘yield within time. When the “yield within time” value is used, a conditional “yieldwithin time creator” component (not shown here) is generated by the request manager 504. In thisembodiment, a Timeout event 414 is created by the “yield within time creator” component with a delay 416determined by the user, such that the Timeout event 414 is added to the environment queue 116 at a timeequal to the sum of the current simulation time 124 and the delay 416. If all the requests 510, 512 succeedbefore the Timeout event 414 is triggered, the process 104 is considered successful and custom code maybe run through the success hook 514. However, if the requests 510, 512 do not succeed before the Timeoutevent 414 is triggered, the process 104 is considered to have timed out. Additional custom code may berun through the timeout hook 514 and the process 104 is considered to have gone down a timeout pathway.When the Timeout event 414 is triggered, the response is returned to the request manager 504 via the“yield within time creator” component. In this example, the process / timeout time 516 determines how longthe ticket 102 should be held whilst the timeout hook 514 is run.

[0065] The request manager 504 comprises a resource releaser 522 wherein the resource releaser 522manages the unreleased (pending) requests on the ticket 102. Optionally, the unreleased requests can bereleased by the resource releaser 522, for example if a flag status changes, resources 110 becomeavailable or the process 104 times out. The request manager 504 then sends the ticket 102 to the flowdetail logger 518, which records all work done by the process 104 on the ticket 102. The work done i.e. theflow detail, may include one or more of: the requests that were successful (completed); the requests thatfailed (incomplete); the resources that were granted; the status of flags 108 that were checked; anymetadata added by way of the optional success or timeout hook 514 codes; and the amount of time requiredby the process 104 to succeed the requests 510, 512.

[0066] The flow detail logger 518 sends the ticket that includes details of the work done to the processselector 520. The process selector 520 reads data stored on the ticket to determine if the ticket should besent to another process 104, if it can be finished or if it can be stored. Selection of the next process iscarried out using a selection function (not shown) comprised in the process selector 520. The selectionfunction can either use information from a predetermined path stored on the ticket 102 to select the nextprocess 104 or can select the next process 104 dynamically using the environment manager 126 to accessinformation from the process network map 122. Additionally, the process selector 520 may check the flowdetail stored on the ticket 102 to adjust the next process 104. For example, if the flow detail indicates thata resource 110 requested by the current process 104 was not granted, the next process 104 may be adjusted to request the non-granted resource 110 in addition to any other resources 110 that the nextprocess requires. The process selector 520 produces either a semi-processed ticket (where the ticket 102is sent to further processes 104 or stored) or the processed ticket 106 for transmission to the data processing platform 112.

[0067] Recording the work done on a ticket 102 in each process 104 is advantageous for analysing thetime taken to acquire resources 110 or flags 108 and for understanding the limiting factors in a system,such as limited resource capacity. This is particularly useful for a system that includes many inter-dependent processes 104, for which it is complex and time-consuming to determine the limiting factors. Such a simulation enables bottlenecks in the system to be determined that can result from a resource 110 having insufficient capacity or a flag 108 being required in different states by many processes 104 simultaneously. For example, a flag 108 representing the on / off status of equipment wherein the equipment is simultaneously required by one process to be on and by another process to be off.

[0068] Furthermore, the present embodiments provide an advantage of being able to provide a higherresolution of work done on a ticket (item to be worked on) than previous discrete event simulations. This enables the real-life system to be simulated and hence analysed with a higher degree of detail and accuracy. This in turn enables bottlenecks and limiting factors in the system to be identified more accurately,leading to more targeted solutions and in the case of real-time control systems, enables preventativemeasures to be taken.

[0069] Referring now to Figure 6, the flag and resource requests 510, 512 sent by a ticket processor 502that receives a ticket 102, are now described in greater detail. Each ticket 102 comprises a ticket ID 602, ticket parameters 604 (e.g. type of item represented by ticket), unreleased requests 606 from previousprocesses 104, a flow detail 608 that includes a record of the work done on the ticket 102 by the currentprocess 104, a flow history 644 that includes a record of all work done on the ticket by previous processes104 i.e. previously logged flow details 608, and the time that the ticket was started 642. The flow detail 608may optionally be logged to the flow history 644. Once the ticket 102 has been processed (also referred toas ‘ended’) or the simulation finishes, the ticket 102 also includes the time 642 that the ticket was ended.

[0070] The ticket processor 502, which receives the ticket 102, comprises data storage 610 and a ticketreader 612. The ticket reader 612 analyses the information stored on the ticket 102 to determine whichrequests are required to process the ticket 102 and also to determine whether there are any unreleasedrequests 606 from previous processes 104 that need to be requested in the current process 104. The datastorage 610 stores the resources 110 and flags 108 required by the process 104 and as determined by theticket reader 612. The ticket processor 502 passes the ticket 102 and information of the required resources110 and flags 108 to the request manager 504, as described above.

[0071] The request manager 504 comprises a resource / flag processor 614. The resource / flag processor614 instructs the flag requestor 506 for a particular flag status and a particular resource requestor 508 forthe availability of and assignment of a certain quantity of resource to the current ticket 102. The resource / flag processor 614 also receives the flags 108 and resources 110 requested by the requestors 506, 508. The flag requestors 506 comprise a status attribute 616 which indicates whether the resource / flag processor is waiting on a True or False status of the flag 108. Additionally, the flag requestors 506 comprise flag selectors 618 which choose the flags 108 required from the available flags 108. The resourcerequestors 508 may comprise Boolean ‘wait on request’ attributes 628. If the ‘wait on request’ attribute 628is set to ‘True’, the request manager 504 will not go down the success pathway unless the request yieldsi.e. the request is fulfilled. Alternatively, if the ‘wait on request’ attribute 628 is set to ‘False’, the requestmanager 504 does not wait or check that the request has been fulfilled. An advantage of setting the ‘waiton request’ attribute 628 to ‘False’, is that a process may not require the requested resource 110 at the timeof the request but if the resource is available at the time of the request, the resource is reserved to be usedat a later time. Additionally, the resource requestors 508 also comprise one or more resource selectors 630,which choose the one or more resources 110 required from the available resources 110. The resourcerequestor 508 also comprises a resource amount 632 that indicates how much of the resource 110 to putin or get out. In an embodiment where the resource 110 is a storage unit, as will be further described below,the resource amount 632 may also indicate the physical size that the ticket 102 will occupy. Each requestor506, 508 sends a corresponding request 510, 512 to a flag 108 or resource 110.

[0072] The flag request 510 includes a request ID 620 for tracking the request 510 in the environment100. The resource request 512 comprises a request ID 636, a requested resource 638, and the resourceamount 640 required by the process 104. Information of the requested resource 638 may include a resourceidentifier.

[0073] Each flag 108 comprises a flag ID 622 and a flag status 624 that is either positive or negative (trueor false). Advantageously, the process 104 can wait upon either the positive or negative status of the flag 108 occurring. In addition, the status 624 of a flag 108 can be switched between positive and negative aninfinite number of times, unlike typical discrete simulation events where the status can only be switchedonce from negative to positive and then remains positive throughout the remainder of the simulation. Flags108 may therefore be used in a similar manner to logic gates, wherein the True of False status 624 of a flag108 may be waited upon and wherein the flag 108 continues to switch between the True and False statuses 624. Furthermore, the flag status 624 can optionally be scheduled to change at specific times.

[0074] Each flag 108 is associated with two events 402 in the environment queue 116, wherein the events402 can be any of a Timeout event 414, a Condition event 418, an Add Generator event 426, a Watcher event 430 or a resource request event 512. The two events 402 associated with the flag 108 comprise a‘Flag Status True’ event and a ‘Flag Status False’ event, wherein the ‘Flag Status True’ event is processedwhen the flag status 624 is set to ‘True’ and the ‘Flag Status False’ event is processed when the flag status624 is set to ‘False’. In more detail, when the flag 108 changes status the non-triggered event 402 becomesprocessed, and the processed event 402 is replaced with a freshly created event 402 that is not triggered.This additional functionality of the embodiment provides a more accurate representation of real-life systems. For example, where a resource is unable to fulfil a request the status (at that time) may be anegative flag i.e. ‘False’ status. However, at a later time the resource may be refilled, or some resourcereturned (unassigned) by an incomplete process 104 and the status of the resource may change. In thecase of a shared resource 110 where multiple different processes 104 can affect the amount of resource110 available, this is particularly important to simulate correctly if the simulation is to be accurate. When the‘Flag Status True’ event gets processed by the environment queue 116, the callback 408 on the ‘Flag StatusTrue’ event is triggered. The callback 408 optionally comprises a check function, wherein each time thecode waits for a flag 108 to have a desired status 624, the check function is called. This checks the flag’sstatus 624 and depending on whether the flag’s status 624 is equal to the desired status, the check functioncan change the status of the flag.

[0075] In another embodiment shown in Figure 7, the ticket 102, flags 108, resources 110 as well as therequestors 506, 508, and requests 510, 512 may comprise further functions to those shown in theembodiment of Figure 6. In this other embodiment, a ticket 102 comprises a ticket ID 602, ticket parameters 604 (e.g. type of item represented by ticket), unreleased requests 606, a flow detail 608, a flow history 644,the start time (and eventually end time) 642 of the ticket, and a path of processes 702. As mentioned above,the predetermined path of processes 702 is used by the process selector 520 to send the ticket 102 to asubsequent process 104.

[0076] As in the embodiments of Figures 5 and 6, the request manager 504 instructs flag and resourcerequestors 506, 508. The flag requestor 506 of the present embodiment comprises the same features as in the embodiment of Figure 6. The flag requestor 506 raises a flag request 510, which may comprise apriority value 720 in addition to a request ID 520. The priority value 720 is used to set a relative priority ofthe resultant event 402 in the environment queue 116.

[0077] In the current embodiment, a flag 108 comprises a flag ID 622, a flag status 624, a delay flag 704,a check function 706, a status controller 708, success hooks 710, a reset function 712, a status loggingfunction 714, links to dependent flags 716 and a dependent flag status function 718. The status controller708 indicates either a positive or negative (true or false) status of the flag 108, which is logged by the statuslogging function 714 for evaluation purposes.

[0078] The delay flag 704 enables an optional delay to be provided such that the flag status 624 will notchange during the delay period. Additionally, whilst the delay is elapsing, the flag 108 cannot be commanded to change status.

[0079] The check function 706 is evaluated when something waits upon the flag 108, and if the function706 returns True the flag 108 changes status.

[0080] Flags 108 can optionally be enabled to ‘return to false’ using the reset function 712. When thisfunction is True, upon the flag becoming positive (true), processes 104 waiting upon the flag 108 are resumed, but the flag 108 instantly returns back to negative (false). This is analogous to a gate that can temporarily open to allow only those currently waiting to proceed.

[0081] Flags 108 can generate events ‘when true’ and ‘when false’, which are typical discrete eventsimulation events but become permanently positive (true) when the flag 108 changes to the correspondingstatus. These changes are effected by the status controller 708.

[0082] Optionally, flags may comprise success hooks 710, which easily allows custom code to run whenthe status 624 of the flag changes. The flag status 624 can be scheduled to change at multiple times duringthe simulation. These status changes can also be logged by the status logging function 714 for evaluationpurposes.

[0083] Optionally, flags 108 comprise ‘Condition Flags’ and have a plurality of dependent flags 108, towhich they are connected through the links 716. The status of a ‘Condition Flag’ depends on the status of its dependent flags 108. A ‘Condition Flag’ can change status to True or False using the dependent flagstatus function 718 if: (i) all dependent flags 108 are a certain condition (‘all of’); (ii) any dependent flags108 are a specified status (‘any of’); or (iii) a specified number of dependent flags 108 (‘some of’) are aspecified status. In this embodiment, ‘Condition Flags’ also comprise a list of dependent flags 108 and thedesired status of the dependent flags 108 to monitor.

[0084] The resource requestor 508 of the present embodiment comprises a ‘wait on request’ 628 attribute,a resource selector 630, a resource amount 632, a delay 724 value, a delay priority 726 value, a queuepriority 728 value and a yield priority 730 value. The delay 724 value provides an optional delay betweeninstructing the requestor 508 and raising the resource request 512. The delay priority 726 value is the priority associated with the timeout to enable delay functionality. The queue priority 728 value is used to set the relative priority of the resultant resource request 512 in a queue comprised in a resource, as furtherdescribed below. The yield priority 730 value is the priority in the environment queue 116 associated with the resultant resource request event when it is yielded. The resource requestor 508 additionally determines where to store the raised request 512 on the ticket 102.

[0085] The resource request 512 of the current embodiment comprises a request ID 636, a requestedresource 638, a resource amount 640, a delay value 732, a timeout indicator 734, a delay priority value 736and a queue priority value 738. Many of these functionalities are determined by the corresponding resourcerequestor 508. The delay value 732 is used to set an amount of simulation time before the resource request512 is raised. The resource request 512 is then placed in the environment queue 116 as an event 402 at atime equal to the sum of the current time 124 and the delay. If the requested resource 110 has capacitywhen the event 402 is triggered, the resource request 512 is fulfilled (i.e. completed) and the time at whichit is fulfilled may be communicated to the data processing platform 112 for analysis. The timeout indicator734 can either have a True or a False status and indicates whether a process 104 has gone down thetimeout pathway. If the timeout indicator 734 has a True status, indicating that the process 104 that raisedthis resource request 512 has timed out, the timeout indicator 734 tells the resource queue comprising theresource request 512 to ignore this request 512 when it comes to the top of the queue. Additionally, if thetimeout indicator 734 has a True status, when the event 402 reaches the top of the environment queue 116and is processed, the resource request 512 is removed from the resource queue. Without timeout indicators734, the resources would process the requests 512 despite the corresponding process 104 having timedout and this would lead to errors in the resource stock amounts / levels. The cancellation of requests 512may be recorded on the data processing platform 112 for analysis. If the delay priority value 736 is used,the value provided corresponds to the delay 416 provided to the Timeout event 414 raising the request. Ifthe queue priority value 738 is used, the resource request 512 is placed in a priority position in a queue ofa resource 110 as further described below.

[0086] In another embodiment of the present disclosure, as shown in Figure 8, the resource request 512may comprise a first available resource (FAR) request 810. The embodiment of Figure 8 also showsexamples of resources 110a, 110b comprising the most essential features. In particular, the resources 110a,110b, comprise a Get queue 832, 838 and a Put queue 834, 840 for getting out a quantity (amount) of aresource 110 and putting in a quantity (amount) of the resource 110 into the resource stock 836, 842 asappropriate. In this embodiment, the request manager 504 raises a FAR requestor 802 which generates aFAR request 810. The FAR requestor 802 comprises an optional Boolean ‘wait-on-request’ attribute 804,which when ‘False’ indicates that the process 104 will not wait on the request 810 that the FAR requestor802 creates to be fulfilled. Additionally, the FAR requestor 802 comprises a resource selector 806 and theamount of resource 808 required by the process 104.

[0087] The FAR request 810 comprises a request ID 812, the requested resource 814, the resourceamount 816 required, a delay 818 value, a list of available resources 820, a timeout indicator 822, a delaypriority value 824, a queue priority value 826, a list of queues 828 to which the FAR request 810 can beadded, and a request remover 830. The event 402 in the environment queue 116 corresponding to theFAR request 810 is added to two or more resource queues included in the list of queues 828, according totheir priority determined by the queue priority value 826. In some embodiments, the event 402corresponding to a FAR request 810 may be added to a large number of queues included in the list ofqueues 828. The first resource 110 to succeed (complete) the request 810 ‘wins’ and the request 810 isthen automatically removed from all other queues which have not completed using the request remover830. With typical prior art DES models, this function can only be implemented by raising n number ofrequests (where n is the number of resources), and then subsequently cancelling all the requests that didnot ‘win’, namely n-1 requests. Therefore, the FAR functionality provided by the present embodiment issignificantly more computationally efficient when dealing with large numbers of requests than FAR requestsas implemented in the prior art.

[0088] The delay value 822 provides an optional delay which will be an amount of time before the requestis added to the Get queue 832, 838 or Put queue 834, 840 of a resource 110a, 110b. The timeout indicator822 indicates whether the process that generated the FAR request 810 has timed out. If the timeoutindicator 822 has a True status, the process 104 that raised this FAR request 810 has timed out and thetimeout indicator 822 tells the resource queue comprising the FAR request 810 to ignore this request 810when it comes to the top of the queue. Without timeout indicators 822, the resources would process theFAR requests 810 despite the corresponding process 104 having timed out and this would lead to errors inthe resource stock amounts / levels.

[0089] Figure 9 shows a block diagram of elements of a resource 110 comprised in an embodiment of thedisclosure. Resources 110 each comprise a resource ID 944, a Get queue 900, a Put queue 902, aflag / queue controller 942, a resource stock 932, a capacity logging function 938 and a level logging function940.

[0090] The Put and Get queues 900, 902 receive resource requests 512 from the environment queue 116.Requests 512 from processes 104 that require a resource 110 are received by the Get queue 900. The Putqueue 902 receives requests 110 for adding an amount of the resource 110 to the resource stock 932.

[0091] The Get queue 900 comprises a queue modification control 904, a status modifier 906, a levelchecker 908, one or more success hooks 910, an indicator of the type of queue 912 and an ordered list914 of the requests 512 with information about each request 512. The type of queue 912 may either be a‘first in, first out’ (FIFO) queue or a priority queue.

[0092] The Put queue 902 comprises a queue modification control 916, a status modifier 918, a capacitychecker 920, one or more success hooks 922, an indicator of the type of queue 924 and an ordered list ofthe requests 926 with information about each request 512. Similar to the Get queue 900, the type of Putqueue 924 may either be a ‘first in, first out’ (FIFO) queue or a priority queue.

[0093] Optionally the history of items that succeed out of the queues 900, 902 may be logged on the dataprocessing platform 112 for post-simulation analysis. Similarly, the history of changes to the length and amount of the queues 900, 902 may optionally be logged on the data processing platform 112.

[0094] The status modifiers 906, 918 are an optional component that control whether a queue 900, 902 isavailable or unavailable for requests to be succeeded out of the queue 900, 902. Each status modifier hasan associated flag 108, also referred to herein as an active flag, and an associated status. When the activeflag is provided and the status 624 of the active flag 108 does not match the associated status of the statusmodifier 906, 918, the queue 900, 902 is unavailable for requests to be succeeded. When the active flag isprovided and the status 624 of the active flag matches the associated status of the status modifier 906,918, the queue 900, 902 is checked to see if any Requests added whilst the queue 900, 902 was unavailable can be fulfilled.

[0095] The queue modification control 904 is used to determine whether the queue should be yielded inorder. When the queue modification control 904 indicates that the queue does not have to yield in order, ifthe first Request in the queue cannot succeed for some reason, subsequent Requests are checked in the queue to see if they can succeed.

[0096] Each ordered list of requests 914, 926, contains the requests 512 with information that includes arequest priority 914a, 926a (also referred to as a ‘priority value’) indicating the relative priority of eachrequest 512; an added order list 914b, 926b (also referred to as a ‘queue value’) indicating the order inwhich the request 512 was added to the queue 900, 902; and a request ID list 914c, 926c comprising theidentifiers 928, 930 of the requests 512. This information enables requests 512 to be processed in thecorrect order. For example, a list 914, 926 in a FIFO order, can easily be rearranged to accommodate ahigher priority request 512 wherein the priority is set by the queue priority value 738 comprised in theresource request 512. The Get queue 900 of Figure 9 shows an example of a priority queue wherein therequests 512 are ordered according to their priority 914a. An example of a FIFO queue is shown by the Putqueue 902 of Figure 9, wherein the requests 512 are stored according to their added order 926b. The Typeof queue 912, 924 is set to either FIFO or priority, and the queues 900, 902 can change between theseordering types an infinite number of times and at any time throughout the simulation. Although theembodiment of Figure 9 shows that the Get and Put queues 900, 902 are of a different type, in otherembodiments the Get and Put queues 900, 902 may be of the same type.

[0097] The resource stock 932 has an associated occupation level 936 (current resource level) of resourcecurrently stored and a resource stock capacity 934 (current resource capacity) indicating the maximumamount of resource that can be held. These variable parameters enable the capacity (such as size / volume) of the resource stock 932 to be known as well as how much of that capacity 934 is currently being used.

[0098] As mentioned above, the Get queue 900 comprises a level checker 908 which reads the currentlevel 936 of the resource stock 932 and determines if the current level 936 is sufficient for the request 512to be fulfilled. Advantageously, when there is a low current level of a resource stock 932, below a chosenminimum resource capacity level, the request list 914 of the Get queue 900 can be re-shuffled from a FIFOto a priority type queue to fulfil the most important requests first. Similarly, when fulfilment of a resourcerequests will result in a delay greater than a threshold delay period, then the request list 914 of the Get queue 900 can be re-shuffled from a FIFO to a priority type queue to fulfil the most important requests first.The threshold delay period can be dependent on the chosen minimum resource capacity level. Conversely,when there is a higher level of a resource stock 932, above the chosen minimum resource capacity level, the request list 914 of the Get queue 900 can be re-shuffled from a priority type queue to a FIFO to fulfil the oldest queued requests first.

[0099] The Put queue 902 comprises a capacity checker 920 that reads the maximum capacity level 934of the resource stock 932. A request 512 in the Put queue 902 can only be fulfilled if there is sufficientdifference between the maximum capacity level 934 and the current resource level 936 to accommodatethe amount of resource indicated by the request 512. This is determined by the capacity checker 920. Ifthere is not sufficient difference between the maximum capacity level 934 and the current resource level936 there are three optional actions that can be taken: (i) the request 512 can be waited on to be fulfilled;(ii) the current resource level 936 of the resource stock 932 can be immediately decreased to accommodatethe additional resource amount indicated by the request 512; or (iii) the first request 512 can be skippedand the subsequent requests 512 in the queue list 926 can be sequentially checked for whether they canbe fulfilled dependent on the amount of resource specified in the respective requests. The choice of whichaction to take when there is insufficient resource capacity 934 is determined by the queue modificationcontrol 916.

[0100] When a request 512 is fulfilled in either the Get queue 900 or the Put queue 902, additional customcode can be run through the success hooks 910, 922.

[0101] Additionally, when a request 512 in a queue 900, 902 is fulfilled, the queue 900, 902 may generateWatcher events in the environment queue 116. Watcher events yield when the level of a resource 110matches a condition. For example, the condition for a Watcher event to yield may be that the level 936 of aresource stock 932 is below a threshold. Therefore, when a request 512 in the Get queue 900 is fulfilled,the Get queue 900 triggers all Watcher events in the environment queue 116 to check if any can yield. The Watcher event that is conditional on the level 936 of the resource stock 932 being below a threshold isyielded, causing the level 936 of the resource stock 932 to be replenished. The replenishment of aconsumable can happen at scheduled times, for example every day at the end of an industrial working period (e.g. a shift in factory).

[0102] Additionally, when a request 512 from the Get queue 900 is fulfilled, causing the level 936 ofresource stock 932 to decrease, the capacity checker 920 comprised in the Put queue 902 is automatically triggered so as to determine whether the next request 512 in the Put queue 902 can be fulfilled. Similarly, the level checker 908 is triggered when a request 512 in the Put queue 902 is fulfilled.

[0103] The resource 110 also comprises a flag / queue controller 942 which controls the queue modificationcontrol 904, 916 and the status modification flag 906, 918. The controller 942 communicates their statusset by one or more flags 108 as described below. Additionally, the flag / queue controller 942 maintains theorder of the Get and Put queue lists 914, 926.

[0104] The data indicated by the flags 108 and communicated to the flag / queue controller 942, can includethe desired status of a queue 900, 902 i.e. whether it is True and fulfilling requests or False and not fulfillingrequests, whether the requests should be yielded in the order they were received (by maintaining the queuelist 914, 926 order) and whether the queue is currently a ‘first in, first out (FIFO)’ or ‘priority’ type queue (bycontrolling the queue modification control 904). Flags 108 can be changed after the simulation has started,and the flag / queue controller 942 is used to communicate this information to the Get and Put queues 900,902 in order to reshuffle one or both of the queues accordingly.

[0105] An advantage of the queues 900, 902 being able to change from a FIFO type to a priority typequeue, is given herein with reference to a non-limiting example. In a non-limiting example of the presentdisclosure, the tickets 102 comprise patients at a COVID testing centre, wherein a COVID testing centrerequires time sensitive logistics. In a process 104 comprising testing the patients for COVID, the patients(tickets 102) require COVID tests (resources 110). The required tests comprised in the resource stock 932of the resource 110 would be processed by the Get queue 900 according to the requests 512 received.Furthermore, the requests 512 in the Get queue are ordered in a FIFO or priority manner depending on thestatus of the queue modification control 904. The queue modification control 904 would be set to FIFOunder normal circumstances, such that the order that the requests for tests are fulfilled depends on a firstcome first serve basis of the patients. However, during abnormal events such as a local outbreak, the queuemodification control 904 would be set to priority, wherein priority may be based on geographical factors ofthe local outbreak. Therefore, by advantageously enabling the Get queue 900 to be switched from FIFO topriority an infinite number of times during the simulation, bottlenecks can be identified in the long-term andin crisis periods. This provides a better understanding of possible real-life scenarios.

[0106] Resources 110 can change capacity 934 after initialisation. When a change of a capacity 934occurs any over-capacity or under-capacity issues can be resolved, and the resource capacity 934 can beoptimised. For example, any requests 512 waiting on the resource 110, namely which could not be fulfilleddue to insufficient resource levels 936, that now can be succeeded (due to an increase in the availableresource level 936) are succeeded (completed). Additionally, resources 110 can be scheduled (by way ofcontrol signals) to change capacity 934 at many times in the future and this scheduling can be matched toknown demands determined by the simulation. Changes in capacity 934 of the resource 110 can also belogged for evaluation purposes by the capacity logging function 526 of the resource 110. Similarly, changesin the level 936 of resource 110 can be logged for evaluation purposes by the level logging function 940.

[0107] Figure 10 shows a block diagram of elements of a resource 110 comprising a store 1000 comprisedin an embodiment of the disclosure. A store 1000 resource comprises similar elements to the embodimentof a resource shown in Figure 9. Specifically, a store 1000 comprises a Get queue 1002 and a Put queue1016 which communicate with a flag / queue controller 1052, wherein the flag / queue controller 1052 receivesdata from flags 108. Additionally, a store 1000 comprises a slot-based storage 1034 which contains itemsgrouped in several sets 1042, 1044, 1046. The order that items are added to the storage 1034 isremembered. The retrieval order of items from a storage 1034 can either be first in, first out (FIFO) or according to the storage priority. The ordering method can be changed an infinite number of times during the simulation using the storage order modification flag 1040, which is controlled by the flag / queue controller 1052. When switching from priority to FIFO, the items in the store are shuffled into the correct order. Itemsin stores are stored in sets that can be sorted by insertion order or priority. The usage of sets makes theretrieval of the items computationally fast. This is because a set creates a fast to check index which an itemcan be compared against to see if it is or is not in the set (membership testing with sets and dictionaries ismuch faster than searching sequences of items). Additionally, the storage 1034 has an associated level1038 of items stored and a storage capacity 1036. These parameters enable the capacity (such assize / volume) of the storage 1036 to be known as well as how much of that capacity 1038 is currentlyoccupied.

[0108] The Get queue 1002 comprises the same elements as described above in relation to a resource110. Specifically, the Get queue comprises a queue modification control 1004, a status modifier 1006, a level checker 1008, one or more success hooks 1010, an indicator of the type of queue 1012 and an ordered list 1014 of the requests 512 with information about each request 512. The type of queue 912 may either be a ‘first in, first out’ (FIFO) queue or a priority queue.

[0109] Similarly, the Put queue 1016 comprises a queue modification control 1018, a status modifier 1020,a capacity checker 1022, one or more success hooks 1024, an indicator of the type of queue 1026 and an ordered list of the requests 1028 with information about each request 512. The type of Put queue 1016 may either be a ‘first in, first out’ (FIFO) queue or a priority queue.

[0110] Elements of a resource 110 such as a workpool can also be simulated with the model of a resourceas shown in Figure 10. The Figure 10 embodiment works in the same way as has been described abovein relation to the Figure 9 embodiment, and so is not described further.

[0111] Figure 11 shows a method 1100 of a process receiving and processing a ticket 102. The ticket isprocessed, at Step 1102, by the ticket processor comprised in the process to determine the required resources or flags. The required resources and / or flags are requested, at Step 1104, using one or moreresource requestors and / or one or more flag requestors. Subsequently, the process is checked, at Step1106, for a ‘yield within time’ attribute. If there is no yield within time attribute, the process waits, at Step 1108, for all new requests that are to be waited upon to yield. Once all new requests have yielded (fulfilled),the process follows the ‘succeed pathway’ and one or more existing unfulfilled requests (from a previousprocess) can be released at Step 1116. The flow detail is then recorded, at Step 1122, on the ticket. Theflow detail may comprise one or more of the requests that succeeded or failed, the time it took for the requests to succeed, and any remaining requests on the ticket.

[0112] Alternatively, if there is a yield within time attribute, a Timeout event is created, at Step 1110, thatyields at the time that the requests must be yielded by. The process then waits, at Step 1112, for all newrequests that are to be waited upon to yield or the Timeout event to yield. If at Step 1114 the requests yieldbefore the Timeout event, one or more existing unfulfilled requests can be released at Step 1116 and theflow detail is then recorded, at Step 1122, on the ticket. However, if the Timeout event yields first, at Step1114, the new requests are cancelled, at Step 1120, and one or more existing unfulfilled requests can bereleased. Again, the flow detail is then recorded, at Step 1122, on the ticket.

[0113] At Step 1124, it is determined if there is another process to be carried out. If there is another processto be carried out, the path of processes on the ticket is checked to determine, at Step 1128, if the processis included in a predetermined path of processes comprised in the ticket. If the process is included in thepredetermined path, the ticket is passed, at Step 1130, onto the next process in the predetermined path. Ifthe next process is not in the predetermined path, the next process is determined, at Step 1132,dynamically. Alternatively, if it is determined at Step 1124 that there is no other process to be carried out, the ticket is finished, paused or placed into a store at Step 1126.

[0114] Figure 12 shows a method of processing requests in a queue, such as a queue comprised in aresource. When a request is added to the queue, it enters the queue according to its queue priority attributeand depending on whether the queue is FIFO or priority as determined by the queue modification control. Adding a request to the queue, triggers an attempt, at Step 1202, to check the queue for unfulfilled requests. The queue may also be checked for unfulfilled requests when one of the following occurs: a request is succeeded out of the queue of the opposite type (e.g. if a request has succeeded out of the Put queue, then the Get queue is checked); the capacity of a resource changes; or the queue changes from being inactive to being active. When the queue is checked, the requests are already in the correct order accordingto whether the queue is FIFO or priority type.

[0115] The active flag of the queue is then checked to determine, at Step 1204, whether it allows checkingof the queue and therefore whether requests can succeed out of the queue. If the active flag has a statusthat prevents the queue from being checked, the process ends at Step 1206. If the active flag has a statusthat allows the queue to be checked, the resource / store capacity and flags are checked to determine, atStep 1208, whether the first request in the queue can be fulfilled (i.e. completed).

[0116] If there is sufficient resource capacity and / or the flags have the correct status, the request is fulfilledat Step 1210 and the result is returned, at Step 1212, to the request manager. Subsequently, the queue ischecked to determine, at Step 1214, whether there are more requests to check in the queue. If there areno more requests to check, the process ends, at Step 1206. If there are more requests to check, the nextrequest is checked to determine, at Step 1218, whether it can be fulfilled.

[0117] If the next request can be fulfilled, the next request is fulfilled, at Step 1210, and the processcontinues to Steps 1212 and 1214 as described above.

[0118] Optionally, if the next request cannot be fulfilled e.g. due to limited capacity, the request is skipped,at Step 1220, and the queue is checked to determine, at Step 1214, whether there are more requests to check in the queue. The process then continues to Steps 1206 or 1218 as described above.

[0119] If the next request cannot be fulfilled, at Step 1218, due to the timeout indicator 734 comprised onthe next request having a True status, this next request is ignored. Furthermore, each time a request with a timeout indicator 734 having a True status comes to the top of the queue that is being checked, the request is ignored. Therefore, when such a request cannot be fulfilled, at Step 1218, the request is skipped,at Step 1220. As described above, each request is placed in the environment queue as an event. When anevent corresponding to a request that comprises a timeout indicator 734 having a True status reaches thetop of the environment queue and is processed, the request is removed from the queue.

[0120] In an embodiment, further action could be taken to dynamically increase the level of items in theresource stock 932 or to change the capacity 934 to increase the size of the resource stock 932 in order tofulfil the requests. Additionally, the queue can advantageously be changed from a ‘FIFO’ type queue to a‘priority’ type queue whilst the simulation is running if the number of requests require this to be done e.g. ifthe rate of items requested from the stock exceeds the rate of items added to the stock leading to insufficient stock levels.

[0121] If the first request cannot be fulfilled at Step 1208, the queue is checked to determine, at Step 1216,whether the queue should be yielded in order as determined by the status of the queue modification control.If yield in queue order is True, the process ends at Step 1206. However, if yield in queue order is not True the next request is checked to determine, at Step 1218, whether it can be fulfilled. The process continuesafter Step 1218 as described above. In one non-limiting example, the method 1200 is repeated for allsubsequent processes.

[0122] In another embodiment, the request that is fulfilled at Step 1210 comprises a FAR request. Oncethe FAR request has been fulfilled (succeeded), the request remover comprised in the FAR request removes the FAR request from any other queues that it was added to.

[0123] Figures 13 to 16 illustrate implementations of the software showing logical relationships in asoftware architecture. These figures show a simulation environment of a system according to theembodiments of Figures 1 to 12 of the present disclosure. In this environment, all components of thesimulation are modelled and further dictionaries of components are available to easily add and managecomponents. These figures also show how shared resources are computationally defined within thesimulation environment with the contents and behaviour of the resource varying in dependence upon istype. Furthermore, these figures illustrate how events and flags are defined within the environment.

[0124] Figure 13 shows an environment class corresponding to the software implementation of theenvironment 100 of Figure 1, in communication with a resource dictionary, a process dictionary and network and a ticket dictionary. These dictionaries correspond to the dictionaries 118 and process network map 122 of Figure 1, and comprise lists and information pertaining to all resources, processes and tickets used in the simulation of a real-life procedure.

[0125] The software architecture of Figure 14 shows a base resource class that defines how resourcesbehave and further communicates with the workpool, consumable and store classes. Each class comprisestwo queues, as in the embodiments illustrated in Figures 8, 9 and 10, wherein a base queue class defineshow queues for resources behave. The queues are implemented as attributes of a class. The workpoolclass comprises slot-based storage wherein items are checked-in and checked-out via workpool requestand release queues. The consumable class comprises a refillable resource wherein an amount of theconsumable can be requested or refilled via a consumable request queue and a consumable refill queue.The store class comprises a storage for items that enter and exit via store entry and store exit request queues. The store class is the software implementation of the embodiment of Figure 10.

[0126] Figure 15 shows the software architecture of how events and flags are defined. The event classdefines how events can yield in the environment queue 116 by defining the different types of events.Although Figure 15 shows that the event class is only used to define condition events, timeout events andAdd Generator events, the event class is also used to define other types of events such as those describedabove in relation to Figure 4. The events defined by the event class may comprise class methods. In thepresent embodiment, the timeout event has class methods ‘lowest priority timeout’ and ‘highest prioritytimeout’. Additionally, the condition event comprises the class methods ‘all of’, ‘any of’ and ‘some of’. Whenan event comprises a condition event, the class method determines the condition upon which an event yields. Each of the class methods of a condition event has a flag condition class as an attribute, whereinthe flag condition class comprises a flag that changes status as a result of dependent flags. The flagcondition class is defined by a flag class, wherein the flag class uses events to allow repeat waiting asdescribed above in relation to Figure 6. As such, the flag class has attributes from the event class.

[0127] Figure 16 shows the software implementation of the flow diagram of Figure 11 and describes theflow of a ticket through a process. The ticket 102 which is the subject of the simulation has work done on it by the process class, wherein the process class coordinates the work done and the flow of the ticket. Asmentioned above, the ticket may have a flow detail stored on it, recorded by the process class, that includesa record of the work previously done on the ticket. In addition, the ticket can control which processes to runnext, for example by means of a path of processes 702 stored on the ticket (see the embodiment of Figure7). The process class can hold multiple requestors which are defined by a base requestor class. The baserequestor class controls the requests sent to resources and flags. The base requestor class can defineseveral requestors including but not limited to a workpool requestor, a consumable requestor, a consumablerefiller (a requestor to refill a consumable resource), a store entry requestor, a store exit requestor and aflag wait requestor.

[0128] Figure 17 shows non-limiting working example of an industrial procedure that can simulated. Herethe procedure simulation platform simulates an engine assembly line in a factory for manufacturingvehicles. In more detail, Figure 17 shows an example simulation of a car factory with two parallel productionlines, Line 11710 and Line 21712, wherein the two lines meet and feed into an Assembly 1714 line. Eachof the Line 1 1710, Line 2 1712 and Assembly 1714 lines comprise a plurality of processes 104 as willfurther be described below. In this example, the car factory also comprises two store resources, namely the‘Line 1 Buffer Store’ 1000A and the ‘Line 2 Buffer Store’ 1000B. The objective of this simulation is to monitorthe storage level of the Line 1 Buffer Store 1000A to check whether the storage level decreases to zeroduring the manufacturing procedure. The Line 1 Buffer Store 1000A provides engine components to theAssembly 1714 line in order to complete the manufacturing procedure. Therefore, when the Line 1 BufferStore 1000A becomes empty during the procedure, the Assembly 1714 line ceases operation. Thissimulation provides an understanding of the multiple components of the procedure in order for the carfactory to operate successfully and efficiently, and in particular for the Assembly 1714 line to maintaincontinuous operation.

[0129] It is proposed that the storage level of the Line 1 Buffer Store 1000A is mostly affected by the ratioand build sequence of different car types (e.g. petrol, electric, diesel). However, the real-world dynamicsare hard to understand due to the volume, complexity and inter-dependencies of the processes. Therefore,this simulation enables the dynamics of the storage level of the Line 1 Buffer Store 1000A to be betterunderstood in order to improve the efficiency of the car factory. In the present example, the number andcomplexity of processes has been simplified as compared to a real-world car factory to highlight theadvantages of the simulation.

[0130] The simulation comprises a plurality of flags 108, namely a master factory flag 1702 that determinesif any line (e.g. Line 1 and Line 2) can run, a Line 1 Active flag 1704 which controls whether Line 11710can run, a Line 2 Active flag 1706 which controls whether Line 21712 can run and an Assembly line flag1708 which controls whether the Assembly 1714 line is running. The statuses of the flags 108 are controlledby the environment. Furthermore, the flags 108 are scheduled to have a status of ‘True’ at specific timesand as determined by a factory schedule.

[0131] Tickets 102 are created at the start of the simulation according to a pre-specified build order. Thetickets 102 comprise one or more ‘Main Chassis’ ticket 102A and one or more ‘Subassembly’ ticket 102B.Additionally, the type of car e.g. petrol, diesel or electric, is stored as an attribute on the ticket 102.

[0132] Line 11710 comprises five processes 104, namely Line 1 Processes 1 to 5, Line 21712 comprisesthree processes 104, namely Line 2 Processes 1 to 3, and the Assembly 1714 line comprises threeprocesses. Each process comprises a plurality of flag and / or resource requestors 506, 508 including flagrequestors 506A, 506B that check the statuses of the master factory flag 1702 and the corresponding lineActive flag 1704, 1706, 1708 to confirm whether the factory and corresponding line are active. Additionally,each process comprises a workpool requestor 508A that requests an amount of resource from a workpoolthat corresponds to each process. For example, a workpool may comprise mechanics or may comprisemachine operator specialists (or their robotic equivalents). The capacity of each workpool 1716 determinesthe number of tickets 102 that can be worked on by that process 104 simultaneously i.e. the concurrencyof the process 104.

[0133] To start the first processes 104 of each of Line 1 and Line 2 i.e. ‘Line 1 Process 1’ 104A and ‘Line2 Process 1’ 104F, a ticket 102 is input to each of the first processes 104. Specifically, a ‘Main Chassis’ticket 102A is input to ‘Line 1 Process 1’ 104A and a ‘Subassembly’ ticket 102B is input to ‘Line 2 Process1’ 104F. Each process 104 has a pre-defined process time which determines the amount of time that aticket 102 is held at that process. The process time for each process is determined by curves, driven byhistoric factory data and there are separate curves for each type of car.

[0134] Starting at Line 2 1712, a Subassembly ticket 102B is input into Line 2 Process 1 104F and thisprocess 104 does work done on the ticket 102B using a master factory flag requestor 506A, a Line 2 Activeflag requestor 506C and a workpool requestor 508A. Line 2 Process 1104F succeeds on the conditionsthat the factory is active, Line 21712 is active and there is sufficient capacity in the workpool 1716. If Line2 Process 1104F is successful, the ticket 102B is passed to the flow detail logger 518 and subsequentlyto the process selector 520 comprised in the process 104F. The subsequent process 104 is selecteddynamically using the environment manager 116 which uses the results of Line 2 Process 1 104F todetermine the next process from the process network map 122. The process selector 520 produces a semi-processed ticket that is sent to the subsequent process, Line 2 Process 2104G.

[0135] Line 2 Process 2 104G comprises the same flag and resource requestors as Line 2 Process 1104F, in addition to a Gearbox Consumables requestor 508B. Line 2 Process 2104G therefore requires agearbox from a gearbox consumable resource 1718 wherein a consumable resource can only be usedonce and cannot be returned (unlike a workpool). For post-simulation analysis and specifically for auditpurposes, the request for this consumable is attached to (stored on) the ticket 102B. Since the consumableresource is not returned to the consumable resource stock, the consumable resource stock must bereplenished in order to ensure the procedure is not halted. Therefore, the gearbox resource stock is refilledaccording to a schedule that is determined by the environment 100. If the level of the resource stock dropsto zero i.e. the consumable stock becomes empty, the Subassembly ticket 102B waits at Line 2 Process 2104G. Once the resource stock is replenished and the request manager 504 receives the gearbox, theticket 102B is passed to the flow detail logger 518 comprised in the process 102 and then to the processselector 520.

[0136] Subsequently, the Subassembly ticket 102B is passed to the last process 104 of Line 2 1712,namely Line 2 Process 3 104H, which comprises the same flag and resource requestors as Line 2Processes 1 and 2104F, 104G in addition to a store entry requestor 508C. This store entry requestor 508Ctries to put the Subassembly ticket 102B into the Line 2 Buffer Store 1000B by generating a request in thePut queue 902 comprised in the Line 2 Buffer Store 1000B. The addition of the request to the Put queue902 triggers the Put queue to be checked for requests. If the Put queue status modifier 918 has a status that allows requests to be succeeded out of the queue, the capacity of the Line 2 Buffer Store 1000B storageis checked by the capacity checker 920. In the example, the Line 2 Buffer Store 1000B comprises a smalltemporary storage with a capacity of four. If there are available storage slots, the Subassembly ticket 102Bis placed into the storage, otherwise the Subassembly ticket 102B waits at Line 2 Process 3508C until therequest in the Put queue 902 is successful. A Subassembly ticket 102B stored in the Line 2 Buffer Store1000B is then ready to be picked up by Line 1 1710, specifically by Line 1 Process 4 104D as furtherdetailed below.

[0137] Simultaneously to the Subassembly tickets 102B being processed in Line 2 1712 as describedabove, the Main Chassis tickets 102A are progressed through Line 11710. The Main Chassis tickets 102Aare first input to Line 1 Process 1 104A. If the resources and flags requested by Line Process 1 104Arespectively have sufficient stock levels and the correct statuses, Process 1 104A is successful, and theticket 102A is sent to Line 1 Process 2104B. Similarly to Process 1104A, the ticket 102A is progressedthrough Line 1 Processes 2 to 5104B, 104C, 104D, 104E.

[0138] As noted above, Line 1 Process 4104D requires a Subassembly ticket 102B to succeed. To retrievea Subassembly ticket 102B, Line 1 Process 4 104D comprises a store exit requestor 508D that requestsone or more tickets 102B stored in the Line 2 Buffer Store 1000B as child tickets on the Main Chassistickets 102A. The request generated by the store exit requestor 508D is placed into the Get queue 900 ofthe Line 2 Buffer Store 1000B which triggers the Get queue 900 to be checked. If the Get queue statusmodifier 906 enables requests to be succeeded out of the queue, the Line 2 Buffer Store 1000B storagelevels are checked by the level checker 908. The Get queue 900 is a first in, first out (FIFO) type of queueand so when there are sufficient storage levels, the Subassembly tickets 102B leave the storage in a FIFOorder. The store exit request for a Subassembly ticket 102B is thus successful and the response is returnedto the request manager of Line 1 Process 4104D. However, if the Line 2 Buffer Store 1000B storage levelis insufficient, the Main Chassis ticket 102A waits at Line 1 Process 4104D.

[0139] Once Line 1 Process 4104D has succeeded, the semi-processed ticket is sent to Line 1 Process5104E which aims to send the Main Chassis ticket 102A to the Line 1 Buffer Store 1000A using a StoreEntry requestor 508E. The Store Entry requestor 508E generates an entry request in the Put queue 902 ofthe Line 1 Buffer Store 1000A and, as described above, this triggers the Put queue 902 to be checked.Subject to the status modifier 918 enabling requests to be succeeded out of the Put queue 902 and sufficientstorage capacity as determined by capacity checker 920, the Main Chassis ticket 102A is then placed intothe Line 1 Buffer Store 1000A storage. It is noted that the Main Chassis tickets 102A stored in the Line 1Buffer Store 1000A contain a Subassembly ticket 102B as a child ticket, due to the work done in Line 1Process 4104D. This child ticket does not do work on the Main Chassis ticket 102B but is stored thereinas metadata.

[0140] The Assembly line 1714 does work on one or more Main Chassis tickets 102A comprising a childSubassembly ticket 102B. The first process in the Assembly line 1714, the Rework process 104J, retrievesa Main Chassis ticket 102A from the Line 1 Buffer Store 1000A using a Line 1 (L1) Store Exit requestor508F. The requestor generates a request in the Get queue 900 of the Line 1 Buffer Store 1000A, whichretrieves a Main Chassis ticket 102A as long as the Get queue status modifier 906 has the correct status,and the storage has a sufficient level as determined by the level checker 908. The Main Chassis ticket 102Ais held at the Rework process 104J for a set amount of time (the process time) which is determined byfaults from any of the previous processes in Lines 1 and 2 1710, 1712, wherein these faults have beenstored on the Main Chassis ticket 102A as metadata. The Rework process 104J calculates the amount ofrework to be done based on these faults and works on the ticket for that amount of process time.

[0141] The Main Chassis ticket 102A then flows through the subsequent Assembly line 1714 processes,namely Assembly Process 1104K and Assembly Process 2104L. Each process succeeds on the conditionthat there is sufficient capacity in the associated workpool. Once all Assembly line 1714 processes havesucceeded and there are no further processes to run, a processed ticket 106 is produced which is endedand can then be sent to the data processing platform 112.

[0142] The data processing platform 112 analyses various metadata stored on the ticket 106 such as theflow history, the faults of Line 11710 and Line 21712 recorded as metadata and the amount of time requiredby each process to succeed. These data may then be used to improve the efficiency of the car factoryprocedure. Modifications to the procedure may include changing the refill schedule of the gearboxconsumable resource stock to satisfy the rate of demand by Line 2 Process 2104G. Additionally, the speedof Line 2 Processes 1 to 3 and Line 1 Processes 1 to 4 may have to be altered by e.g. changing the capacityof the workpool 1716, to ensure an efficient input / output of Subassembly tickets 102B in the Line 2 BufferStore 1000B such that the procedure is not halted. An understanding of the inter-dependencies of Line 1and Line 2, enables the Line 1 Buffer store 1000A storage levels to be maintained such that the Assembly line 1714 operates effectively and efficiently.

[0143] The present disclosure is applicable to the simulation and optionally the control of many differentindustrial situations and in some cases non-industrial situations as has been mentioned above. As has been mentioned previously, embodiments of the present disclosure can be used for simulating, and optionally controlling, automated or semi-automated vehicle assembly lines, automated consumer electronic device manufacture, managing resources in a shared resource computing system, chemical plant resourcemanagement in manufacture of a chemical formulation. Additionally, resource management in a complexload handling station can be simulated and optimised to avoid bottlenecks. An example of such a loadhandling station is a cargo port for shipping. The processes that can be simulated may include the dockingof sea vessels, the unloading of shipping containers from the vessel, the reloading of other cargo containersand the dispatching of laden sea vessels and cargo carrying road vehicles. In particular, simulation of use of complex load handling resources of the cargo port such as cranes, lifts, pallets, temporary storage area for containers, personnel, berths, and road vehicles to transport the containers from the cargo port can be carried out with tickets being used to represent a container being moved through various cargo handling processes to achieve an overall cargo handling procedure. Similarly, a sea vessel carrying container cargo can also be represented by a ticket as the sea vessel has work carried out on it from being docked,unloaded, reloaded and subsequently dispatched by the seaport control. By reviewing the simulation,potential bottlenecks can be identified in the use of shared resources and preventative action can be taken to improve the throughput of the cargo port. This improvement in efficiency can lead to faster unloading and loading times of a sea vessel as well as optimised use of limited berths in a busy cargo port. Also in some examples, the output of the simulation can be provided to a control system which can actively assign additional resources to mitigate potential bottleneck situations in real-time.

[0144] Having described several exemplary embodiments of the present disclosure and theimplementation of different functions of the simulation system in detail, it is to be appreciated that the skilled addressee will readily be able to adapt the basic configuration of the simulation system to carry out described functionality without requiring detailed explanation of how this would be achieved. Therefore, in the present specification, several functions of the system have been described in various places without an explanation of the required detailed implementation as this not necessary given the abilities of the skilled addressee to implement functionality into the system.

[0145] Furthermore, it will be understood that features, advantages, and functionality of the differentembodiments described herein may be combined where context allows.

Claims

Claims:

1. A method of controlling a shared resource store, the method comprising:simulating the shared resource store including providing a current level variable indicating a current level of available resource of the resource store, a maximum capacity level indicating a maximum capacity of the resource store and a minimum capacity value indicating a minimum capacity of the resource store; simulating an input queue for a resource store with one or more resource input requests; simulating an output queue for a resource store with one or more resource output requests; the one or more input and output requests each comprising: a quantity of the available resource; and a queue value which indicates the order in which the request was added to the queue; simulating systematic execution of resource input requests and resource output requests on the resource store; the simulating step including using the current level variable, the maximum capacity level and the and minimum capacity value to determine an alert condition, the alert condition being created if: i. the systematic execution of a next queued one of the one or more resource input requestswill result the current level variable exceeding the maximum capacity level; or ii. systematic execution of a next queued one of the one or more resource output requestswill result the current level variable being less than the minimum capacity value; and generating and sending a control signal to the resource store to change the maximum capacity level or current level of available resource in the resource store to mitigate the alert condition.

2. The method of Claim 1, wherein simulating execution of resource input requests and resourceoutput requests on the resource store comprises: selecting a next resource input request or a next outputresource request to be fulfilled by the simulated resource store on the basis of the next resource inputrequest or a next output resource request in the respective input or output queue, which is able to be fulfilled based on the current level variable, the maximum capacity level and the minimum capacity value.

3. The method of Claim 2, wherein simulating execution of resource input requests and resourceoutput requests on the resource store further comprises: checking the status of a queue checking flag to determine if the simulation permits checking of the input queue and the output queue to determine of any request can be fulfilled by the simulated resource store.

4. The method of any of Claims 1 to 3, wherein each resource input request or resource output requestcomprises a size of an item of the resource; and the determining step comprises establishing whether a resource input request of the one of more input requests or a resource output request of the one of more output requests can be fulfilled based on a size of the items of the resource present in the resource store.

5. The method of any of Claims 1 to 4, wherein simulating the input queue or the output queuecomprises scheduling adding a resource input request of the one of more input requests or a resource output request of the one of more output requests to the respective input or output queue at a specified time.

6. The method of any of Claims 1 to 5, wherein simulating the input queue or the output queuecomprises delaying adding a resource input request of the one of more input requests or a resource output request of the one of more output requests to the respective input queue or output queue by a specified time period.

7. The method of any of Claims 1 to 6, wherein simulating the input queue or the output queuecomprises delaying adding a resource input request of the one of more input requests or a resource output request of the one of more output requests to the respective input queue or output queue until a specified condition occurs.

8. The method of any of Claims 1 to 7, wherein each resource input request or resource output requestcomprises a queue priority value, which indicates the relative priority of the resource input request or the resource output request; and wherein simulating the input queue or simulating the output queue comprises reordering the simulated input queue or the simulated output queue respectively by either the queue priority value or the queue value.

9. The method of Claim 8, wherein simulating the output queue comprises reordering the outputqueue from the queue priority value order to a queue value order when the current level variable is abovea minimum threshold level.

10. The method of Claim 8 or 9, wherein simulating the output queue comprises reordering the outputqueue from a queue value order to a queue priority value order when the current level variable is below a minimum threshold level.

11. The method of any of Claims 8 to 10, wherein simulating the input queue comprises reordering theinput queue from a queue value order to a queue priority value order when the current level variable is above a maximum threshold level.

12. The method of any of Claims 8 to 11, wherein simulating the input queue comprises reordering theinput queue from a queue priority value order to a queue value order when the current level variable is below a maximum threshold level.

13. The method of any of Claims 8 to 12, simulating the input queue or simulating the output queuecomprises reordering the input queue or the output queue from a queue value order to a queue priority value order when demand for the resource is above the threshold level.

14. The method of Claim 13, Wherein demand for a resource is measured by the number of outputrequests in the output queue or the total quantity of the requested resource of all of the output requests in the output queue.

15. The method of any of Claims 1 to 14, wherein simulating execution of resource input requests andresource output requests on the resource store comprises: triggering the checking of the simulated output queue to determine if the next resource output request in the simulated output queue can be executed, once a resource input request is executed from the simulated input queue; or triggering the checking of the simulated input queue to determine if the next resource input request in the simulated input queue can be executed, once a resource output request is executed from the simulated output queue.

16. The method of any of Claims 1 to 15, where each resource input or output request comprises aBoolean true / false timeout indicator to indicate whether the time between a time when the request was created and a current time has exceeded a predetermined time limit, and the simulating step comprises removing any resource input or resource output requests from the respective input or output queues if the timeout indicator is true.

17. The method of any of Claims 1 to 16, wherein at least one of the one or more resource inputrequests or one or more resource output requests comprises a first available resource request that is placed into input or output queues of a plurality of resource stores simultaneously, each first available resource request comprising a Boolean true / false request remover indicator to indicate whether the first available request should be removed from the input or output queue of the respective resource store in response to a first available resource request having been fulfilled by one of the plurality of resource stores; and wherein simulating systematic execution of resource input requests and resource output requests on the resource store comprises removing the first available input or output request from the respective resource store when the request remover indicator is true.

18. The method of any of Claims 1 to 17, wherein simulating execution of resource input requests andresource output requests on the shared resource store comprises: determining the state of a Boolean updating queue flag of the resource store; and preventing the execution of resource input requests and resource output requests on the shared resource store whilst the Boolean updating queue flag is in a first predetermined state.

19. The method of Claim 18, wherein simulating the input queue or the output queue comprisesenabling resource input requests or resource output requests to be added to the respective input or output queues whilst the Boolean updating queue flag is in a second predetermined state.

20. The method of any of Claims 1 to 19, wherein simulating the shared resource store comprisessimulating the storage of resource items in a plurality of different sets within the resource store, each set comprising a plurality of items sharing a common characteristic.

21. The method of any of Claims 1 to 20, wherein the simulating the input queue or the output queuecomprises: determining the state of a Boolean Yield In Order flag; if the Yield in Order flag is in a first predetermine state, executing requests in the input queue and output queue in the order determined by the queue; and if a Boolean Yield in Order flag is in a second predetermine state, and if a foremost request in the input queue or the output queue cannot be fulfilled, determining if the next request in the respective input or output queue can be fulfilled.

22. The method of any of Claims 1 to 21, wherein simulating systematic execution of resource inputrequests and resource output requests on the resource store comprises using Boolean flags which are configured to be able to be switched multiple times between different states.

23. The method of Claim 22, wherein the Boolean flags provide a current status of the resource, flagwait events, show availability of a resource, change state once a predetermine condition being detected, or modify queue ordering.

24. A method of controlling a plurality of shared resource stores, the method comprising:simulating the plurality of shared resource stores, the simulating step comprising for each one of the plurality of shared resource stores: including providing a current level variable indicating a current level of available resource of the resource store, a maximum capacity level indicating a maximum capacity of the resource store and a minimum capacity value indicating a minimum capacity of the resource store; simulating an input queue for a resource store with one or more resource input requests; simulating an output queue for a resource store with one or more resource output requests; the one or more input and output requests each comprising: a quantity of the available resource; and a queue value which indicates the order in which the request was added to the queue; simulating systematic execution of resource input requests and resource output requests on the resource store; the simulating step including using the current level variable, the maximum capacity level and the and minimum capacity value to determine an alert condition, the alert condition being created if:i. the systematic execution of a next queued one of the one or more resource input requestswill result the current level variable exceeding the maximum capacity level; or ii. systematic execution of a next queued one of the one or more resource output requestswill result the current level variable being less than the minimum capacity value; and generating and sending a control signal to the resource store to change the maximum capacity level or current level of available resource in the resource store to mitigate the alert condition.

25. The method of Claim 24, wherein at least one of the resource input or output requests comprisesa first available resource request and the simulation comprises: generating a copy of the first available resource request and placing the copy of the first available resource request in each of the plurality input or output queues of the plurality of resource stores simultaneously, and upon fulfilment of any one of the plurality of first available resource requests, removing any non- fulfilled first available resource requests from the input or output queues of the plurality of resource stores.

26. A method of controlling a shared resource store, the method comprising:simulating the shared resource store including providing a current level variable indicating a current level of available resource of the resource store and a current capacity variable indicating a current capacity of the resource store; simulating an input queue for a resource store with one or more resource input requests; simulating an output queue for a resource store with one or more resource output requests; the one or more input and output requests each comprising: a quantity of the available resource; and a queue value which indicates the order in which the request was added to the queue; simulating systematic execution of resource input requests and resource output requests on the resource store; the simulating step including using the current level and current capacity variables to determine if the systematic execution of the resource input requests and resource output request from the input and output queues, will result in delays beyond a threshold delay period in fulfilling the requests; and generating and sending an alert signal indicating that a change in the current capacity or current level of available resource in the resource store is required to reduce the delay to below the threshold delay period.

Images