Method and system

Abstract

In one embodiment, a method includes sending, by a first machine disposed on a production zone, a first signal to a storage medium to write a first event on an event log stored on the storage medium, the first signal including data about tasks associated with running the first machine, the event log is recognizable by each of a plurality of executors operating on the production area, where the first event corresponds to a task; reading the event log by each of the plurality of executors; sending, by any of the plurality of executors capable of executing the task, one or more second signals to the storage medium to write corresponding, respective one or more second events on the event log, the one or more second signals including data about the respective one or more executors capable of executing the task; determining, by a processor coupled to the storage medium, which of the plurality of executors to assign the task based on the one or more second events; and a) in the event that only a first execution body of the plurality of execution bodies sends the second signal to the storage medium: sending, by the processor, a third signal to the storage medium, the third signal comprising data that writes a third event on the event log indicating that the task has been assigned to the first execution body; and reading the event log by each of the plurality of executors, where the first executor is informed that the task has been assigned to the first executor based on the reading of the event log by the first executor; and b) in case at least two of the plurality of execution bodies send at least two respective second signals to the storage medium: sending, by the processor, a fourth signal to the storage medium, the fourth signal comprising data for writing a fourth event on the event log indicating that the task has been assigned to one of the at least two execution bodies; and reading the event log by each of the plurality of executors, where one of the at least two executors is notified that the task has been assigned to the executor based on the reading of the event log by the at least two executors.

Description

TECHNICAL FIELD

[0001] The present invention generally relates to a method for reactive task management between machines and actors located on a shop floor. Furthermore, the present invention generally relates to a system for the method. The method and the system also relate to the control of a shop floor, a process line, a process cell or an independent process center. BACKGROUND

[0002] In current methods and systems, the integration of operators in the control software architecture is low. Operators use dashboards, implement a proactive plan task list or follow predefined task instructions. However, there is no fine-grained planning system that means assigning specific workers to specific tasks. The complexity of using and operating such a centralized fine-grained planning would cause a dramatic increase in software and hardware requirements due to the number of actors, actuators and resources needed in such a system. Current IT systems do not exhibit a communication and orchestration pattern as a human would do, because humans make tactical plans in smaller groups to better react to changing conditions and requirements. That is, today's IT system-orchestrated manufacturing operations are not human-centric.

[0003] Furthermore, the shop floor is not dynamic and agile, because parallel systems run on the shop floor, such as centrally (IT) distributed primary resources (like process centers) and decentralized human-orchestrated secondary processes.

[0004] In addition, today's automation is characterized by the separation of robots with fences. Humans can only interact with the system via predefined (local) hardware or software interfaces. With the introduction of mobile robots (AGV / AMR), the need for local actuators and fences will disappear. With it, the controller for orchestrating machines, devices and data must become more versatile and flexible in its action, and the manufacturing operations system has to bridge the gap between the PLC (Programmable Logic Controller) level and the MES (Manufacturing Execution System) level. However, the area of full automation is unrealistic, especially in brownfield / existing shop floors. The idea of a fully automated shop floor / factory / plant is known and only in a few cases becomes realistic considering the buffer area and the large amount of capital investment required. Finally, humans are the most versatile actuators in secondary processes like tool preparation or quality inspection. Operators are and will be an essential part of the whole shop floor. The latest automation systems on the first line show how it can be better, but these do not take into account the complexity of controlling process centers and flexible manufacturing system controllers, including the necessary planning and handling of devices and data for processing.

[0005] The most advanced cell controllers are encapsulated systems that automate repetitive secondary (or non-value-added) tasks, such as workpiece changeover, tool changeover, temporary workpiece and / or tool storage. Physically, these systems are separated from human-accessible production areas by safety fences. These systems have limited collaboration with human operators. Standard cell controllers are susceptible to human intervention. Human intervention causes a mismatch between the physical state and the state stored in the database, resulting in time-consuming recovery actions.

[0006] Standard unit controllers also have fixed system settings that cannot be changed during runtime. Updating software and adding or removing hardware causes system downtime, thereby reducing system throughput.

[0007] Therefore, better operator integration is needed in manufacturing operating systems. Summary of the Invention

[0008] The invention is set forth in the independent claims. Preferred embodiments of the invention are set forth in the dependent claims.

[0009] According to a first aspect, a method is described, the method comprising: sending a first signal from a first machine arranged on a production area to a storage medium to write a first event to an event log stored on the storage medium, the first signal including data about a task related to operating the first machine, wherein the event log is identifiable by each of a plurality of executors operating on the production area, wherein the first event corresponds to a task; reading the event log by each of the plurality of executors; sending one or more second signals from any of the plurality of executors capable of performing the task to the storage medium to write a corresponding, one or more second events to the event log, wherein the one or more second signals include data about a corresponding one or more executors capable of performing the task; and determining, by a processor coupled to the storage medium, which determines which of the plurality of executors to which the task is assigned based on the one or more second events; and a) In the case where only the first executor among multiple executors sends the second signal to the storage medium: the processor sends a third signal to the storage medium, the third signal including data of a third event written to the event log indicating that a task has been assigned to the first executor; and each of the multiple executors reads the event log, wherein, based on the first executor's reading of the event log, the first executor is informed that a task has been assigned to the first executor; and b) in the case where at least two of the multiple executors send at least two corresponding second signals to the storage medium: the processor sends a fourth signal to the storage medium, the fourth signal including data of a fourth event written to the event log indicating that a task has been assigned to one of the at least two executors; and each of the multiple executors reads the event log, wherein, based on the at least two executors' reading of the event log, one of the at least two executors is informed that a task has been assigned to that executor.

[0010] The term "capable of being identifiable" as used throughout this disclosure may be equivalent to or include "visible". For example, an event log may be readable by each of a plurality of executors or a subset of a plurality of executors. Additionally or alternatively, in any one or more of the examples outlined throughout this disclosure, the term "capable of being identifiable" (e.g., an event log is identifiable by an executor (and / or any component in the system)) may mean that the event log (i.e., events / data written to the event log) is readable and / or processable by an executor (and / or any component in the system).

[0011] The first machine can be one of any number (i.e., one or more) of possible machines suitable for deployment in the production area. For example, the first machine can be a generic assembly executor. The generic assembly executor can be responsible for performing physical assembly tasks. Assembly tasks can be defined by creating physical modules from physical items. Unique resource identifiers can be assigned from the system via the module assembly process, as will be described in more detail herein. The unique resource identifier of a module can describe a temporary physical item such as a tool holder or tool component. Each physical item within a component can maintain its own unique resource identifier to ensure independent lifecycle tracking. The unique resource identifier of a component can be published to the event log and made available to other generic executors, as will be described in more detail herein.

[0012] Event logs can be immutable, append-only event logs. Compared to standard unit controllers that use classical relational methods representing the state of the physical system, immutable, append-only event logs (referred to as "event logs" in this document) can be used. Event logs may need to be used as interfaces for general-purpose actuators. This can lead to potential activity refactoring if errors occur in the system. Therefore, supervisors, humans, or any other suitable personnel or devices can check which person / machine was assigned a task and / or completed it. For decoupling purposes, this interface may need to follow a publish / subscribe pattern. It can be ensured that incoming events are appended to the event log in both chronological and logical order. This logical order can be predetermined from real-world processes. Event logs can be deployed centrally or distributed. To ensure logical ordering on the event log, algorithms (i.e., IT algorithms) can be used. In some examples, IT algorithms may be needed to maintain the consistency of events written to the event log.

[0013] Multiple executors can be any suitable type of executor that can be arranged on and is suitable for the production area. An executor can be defined as one or more of the following:

[0014] A general-purpose geometry transformation actuator allows for geometric transformations, which can be subtractive machining (milling, lathe machining, EDM, sawing, etc.) and / or additive machining (welding, 3D printing, etc.). This actuator may represent a value-added entity in each production area. The general-purpose geometry transformation actuator can subscribe to events related to process steps and react accordingly to second signals and second events. During manufacturing, the general-purpose transformation actuator can also publish status events. The general-purpose transformation actuator can also interact with other general-purpose actuators via an event log. These interactions can be physical interactions exchanging physical objects such as workpieces or tools, or virtual interactions exchanging data such as NC files, tool data, or any other machine-specific parameters. As described below, a general-purpose transport actuator can interact with the general-purpose geometry transformation actuator to load workpieces or tools or other end-effectors capable of geometric transformations of solid bodies.

[0015] A generic transport executor can be responsible for carrying out transport tasks, including, for example, loading and / or unloading physical items. Transport tasks can be defined by actively changing the location of physical items such as workpieces or tools on the production area. These location changes can also be published to the event log and subscribed to by other generic executors. A successfully updated location can also trigger an information stream for the defined attributes of the physical item to be transported against the specified generic executor.

[0016] A general inspection executor can be responsible for performing physical or virtual inspection tasks. An inspection task can be defined as comparing a given setpoint with an actual value and / or providing feedback on subjective evaluations. In this disclosure, inspection tasks can be categorized as "maintenance." Comparison results (in some cases, based on a customizable set of rules) can be published to an event log. The customizable set of rules can allow the client to decide what to do in a particular situation via, for example, a decision tree based on the inspection task results. For example, if a hole's dimensions exceed tolerances due to tool wear causing tool bending, the executor can repeat the machining process. The result can be either success or failure. In a success case, the next process step can be triggered. In a failure case, the next action depends on the customizable set of rules. For example, the last process step can be triggered again, or the process can be interrupted. In some examples, the inspection task and / or the first machine and / or the event log may require the executor to input a task-related value. This value can then be used to determine the further actions that the first machine and / or the executor and / or different executors will take by comparing the input value with the expected value (in some examples). This value can refer to visual inspection, acoustic inspection, tactile inspection, physical inspection, or any other suitable type of inspection.

[0017] A general-purpose measurement actuator can be responsible for performing physical measurement tasks such as indicating the geometric quality / tolerance characteristics of a workpiece, the geometry of a tool, or the wear width and / or debris on a tool and / or other equipment and / or consumer goods. Measurement results can be published to an event log and made available to other general-purpose actuators.

[0018] Generic assembly executors can be responsible for performing physical assembly or disassembly tasks. Assembly tasks can be defined by creating physical modules from physical items. Through the assembly process of modules, unique resource identifiers can be assigned from the system, as will be described in more detail in this document. A module's unique resource identifier can describe temporary physical items such as tool holders and tool components. Each physical item within a component can maintain its own unique resource identifier to ensure independent lifecycle tracking. A component's unique resource identifier can be published to the event log and made available to other generic executors, as will be described in more detail in this document.

[0019] A generic executor can have a specific set of capabilities, referred to as X, and can also be described as a logical entity. During implementation, the generic executor can be coupled to a physical entity via a specific adapter. Due to this connection, a subset of individual capabilities, referred to as Y, can be automatically generated during startup. A physical entity can consist of multiple generic executors. A generic executor can be an entity capable of communicating with an event log via publish and subscribe. To interact with a physical device, a generic connector may need to be combined with a "specific adapter" that acts as the interface to the physical device. The specific adapter may implement an abstraction of the device's proprietary communication interface and / or a mapping of proprietary commands to the generic executor's capabilities. The specific adapter may also technically abstract the hardware device's proprietary interface using standardized communication protocols such as WebSockets. Not every physical device can support every capability of a generic executor, so each combination of a generic executor and a specific adapter may result in a different subset of capabilities. Based on the resulting subset of capabilities, the generic executor can publish and subscribe to a specific set of events in the event log and perform actions accordingly.

[0020] In some other examples, the execution body can be a software node. In this case, the execution body may not include any moving parts, but may include, for example, a processor and / or transceiver and / or memory, and may be capable of undertaking computations and / or processes related to tasks that require only data and / or software. This can also be applied to execution bodies having one or more moving parts as well as a processor and / or transceiver and / or memory.

[0021] The technician understands that the first machine can be any of the above-mentioned executors. The technician also understands that in the system, there may be any of the more than one executor and / or none of the above-mentioned executors may exist.

[0022] This determination can include two parts. The job injection executor can input the manufacturing job into the system and / or processor and / or storage medium via a first signal and / or a second signal. The job can consist of multiple process steps. Process steps can be divided into value-added steps or non-value-added steps. Value-added steps, such as performing geometric transformations on the workpiece, and non-value-added steps, such as inspection tasks and measurement tasks, can refer to any kind of inspection, and measurement tasks can refer to geometric measurements related to geometric tolerances. The job injection node can be a graphical user interface (for human-centered input) or an application programming interface (API) for interface connection with other computer systems such as ERP (Enterprise Resource Planning) or MES (Manufacturing Execution System) systems, or online platforms such as cloud manufacturing services. It can also be a hybrid version of GUI and API. The process manager can manage process steps and task assignments. The process manager can contain a cost function. The weights of the cost function can be adjusted independently via the process manager. Before each, or multiple, announcements of a new process or task, the process manager can check whether all the required prerequisites of the executor are met. Prerequisites can be defined as a rule set of the process manager. The rule set can be tailored independently for each use case (i.e., for each type of task performed by the executor). When a second event is published to the event log, the cost function component of the process manager can be triggered because the process manager and the executors have subscribed to these event types. The process manager can then publish the results of the cost function process to the event log. This can then inform the participating generic executors if they are assigned the task. This decoupled communication pattern via publishing and subscribing to event logs ensures the scalability of the methods and systems described herein.

[0023] The above allows for more efficient resource allocation, taking into account machines, robots, devices, data, and actuators, without system interruptions between planning and / or controlling primary and secondary processes.

[0024] Throughout this disclosure, it should be understood that the terms “machine” and “human” are interchangeable with the term “executor”.

[0025] The second event and / or the second signal may only include data about the possible capabilities of the actuator. That is, the actuator may send the second signal while it is busy with another task and / or has stopped operating, because the actuator still has the capability to perform that task.

[0026] In some examples, determining which of several executors to assign a task based on one or more second events is done by the processor reading the event log. In some examples, the processor can read the event log and see which executors have written the second event to it. The processor can then use only the executors that wrote the second event to the event log in the determination step. This can result in a more efficient process in terms of hardware requirements, as the processor may only need to run the determination step for a subset of executors, rather than for each executor wirelessly or wiredly coupled to the processor.

[0027] In some examples, once an event has been written to the event log, it cannot be removed from it. This allows publish-subscribe systems (sometimes referred to as publish / subscribe in this document) to function and allows executors and / or processors to parse all first and / or second events that have occurred, thereby improving the efficiency of methods and systems because executors and / or processors can scan the entire history of the event log. In fact, in some examples, the event log is immutable, and the event is immutably appended to the event log.

[0028] In some examples, at least one of the multiple actors is a human. Humans can be integrated into the system via intelligent devices such as smartphones, smartwatches, headsets, pagers, laptops, tablets, smart glasses, neural signal transmission devices, or any other suitable device. The intelligent device can be the physical interface between the human and the system / method. Humans can also listen to / scan / receive updates to / from event logs. Humans can use and parse the same events as machine actors, as humans can also simply be instances of generic actors. This allows for seamless integration of humans into the system and method, and humans can be used as components of the system without disrupting it. In some examples, humans can view the first and / or second lists, or in fact any lists mentioned herein, via applications on smartphones and / or laptops and / or computers and / or smartwatches and / or any other suitable device.

[0029] In some examples, upon being informed that a task has been assigned, the method includes updating or generating a first task list visible only to the executor assigned the task, where the first task list includes the tasks assigned to the executor. This allows the executor to easily see which tasks it has been assigned to but have not yet completed, thereby ensuring that each task has been completed. In some examples, there may be no first task list and / or a second task list, where the second task list will be described in more detail below. In this case, the executor may be able to directly read the event log via reading events and / or subscribing to certain events, where some events require the executor to have the capabilities that the task will require.

[0030] In some examples, when an executor assigned a task completes a portion of the task, the method includes the executor sending data about the partial completion of the task to the storage medium to write a fifth event to the event log. This allows the processor and / or other executors to see that the task is at least partially completed. The task can then be moved to a partially "completed" list, where the executor cannot write a second event to the event log for that task. This allows tasks to not be doubled, thereby improving the efficiency of the method and the system. In some examples, the event log and the executors subscribing to the event log can record the progress of the executors in the task so that, in the event of, for example, failure, malfunction, shift end, or any other reason that the executor may be unable to complete the task, one of the other executors can take over the task. In this case, another executor, at least capable of assuming the task, can take over and complete the task.

[0031] In some examples, when the executor assigned the task begins, the method includes the executor sending data about the task's start to the storage medium to write a sixth event to the event log. This allows the event log and / or other executors to see that the task has started. The task can then be moved to a partial "completed" list where the executor cannot write a second event to the event log for that task. This prevents tasks from being doubled, thereby improving the efficiency of the method and the system. In some examples, the event log and the executors subscribing to the event log can record that a task has started so that, in the event of a failure, malfunction, shift end, or any other reason why the executor may be unable to complete the task, one of the other executors can take over the task. In this case, at least one other executor capable of undertaking the task can take over and complete it.

[0032] In some examples, upon being informed that a task has been assigned, the method includes updating or generating a second task list visible to multiple executors, whereby the executor assigned the task includes the tasks assigned to the executor. This allows all executors to see which executor has been assigned a task. It also allows supervisors to check which executor has been assigned a task should a task fail and / or, for example, if an executor malfunctions. This can allow for better accountability within the system. This can be referred to as a "global task list" because each executor can see / recognize the list. In some examples, the second task list is independently available to each executor. That is, the second task list can be retrieved by each executor, and each executor can read / recognize the second task list at its local station and / or location, for example, via a processor included in the executor.

[0033] In some examples, an executor can only begin a task once the first and / or second task lists have been updated or generated. This may mean that an executor can only begin a task once the process has been determined to be complete. This can allow multiple executors to undertake tasks when one executor is sufficient, thereby improving system efficiency. In some examples, the first and / or second task lists may not be limited to a single executor, but may instead be visible to a team of executors and / or workstations comprising multiple executors.

[0034] In some examples, when the executor assigned the task completes the task, the method includes the executor sending data about the task completion to the storage medium to write a seventh event to the event log. This allows the processor and / or other executors to see that the task has been completed. The task can then be moved to another "completed" list where an executor cannot write a second event to the event log for that task. This prevents tasks from being doubled, thereby improving the efficiency of the method and the system.

[0035] In some examples, the method also includes preventing the transmission of data regarding task completion or partial task completion if the task or part of the task is not yet complete. This blocking of data transmission can be achieved by the first machine and the executor communicating with each other via an event log. That is, the first machine can write an event to the event log declaring the task complete, but before that event is written, the executor is prevented from sending data regarding task completion. For example, if closing a door or pressing a button is required to complete a task, the executor cannot write an event to the event log declaring the task complete until the first machine writes the event to the event log declaring the door closed or the button pressed.

[0036] In some examples, if the executor is a second machine capable of performing the task, the executor automatically sends one or more second signals, and / or if the executor is a human capable of performing the task, the executor manually sends one or more second signals. This allows the executor to send indications to the event log and / or processor that the executor is capable of performing the task. In particular, a machine can automatically send second signals regardless of what the second machine is currently doing, for example, if it is in the middle of undertaking a maintenance task, if it has not been assigned a task, etc. The same applies to humans, as humans can send second signals at any time.

[0037] In some examples, upon being notified that an executor has been assigned a task, if the executor is a second machine, the second machine then automatically begins the task, or the second machine rejects the task. If a machine is assigned a task, it cannot execute the task immediately, but can only begin it after a predetermined amount of time and / or after other more important tasks have been completed and / or after the machine has undergone maintenance. If the machine rejects the task due to, for example, downtime, maintenance, or involvement in another task, the task can be republished to the event log. In some examples, a human can reject a task on behalf of the machine.

[0038] In some examples, when informed that an executor has been assigned a task, if the executor is human, the human can manually start or reject the task. If a human is assigned a task, they cannot perform it immediately, but can only begin it after a predetermined amount of time and / or after other more important tasks have been completed. If a human rejects a task due to, for example, downtime or insufficient remaining shift time, the task can be republished to the event log.

[0039] In some examples, if the executor rejects the task, the method restarts by sending a fifth signal, including data about the task associated with running the first machine, to the storage medium to write an eighth event to the event log stored on the storage medium. The first and fifth signals relate to the same data. This can mean that the task is republished to the event log. If the task has not yet started, the fifth signal can be the same as the first signal. If the task has been partially completed, the fifth signal can include data related to the remaining portion of the task that is not yet completed.

[0040] In some examples, the executor assigned the task begins the task immediately, where this "immediately" is based on a priority weighting of one or more first events on the event log, where one or more of the following are considered in the priority weighting: the time spent completing the task; the cost of completing the task; the urgency of the task; and the cost of not completing the task. This can mean that the executor can take on the task once a more important task has been completed. The cost of completing the task can involve the material cost or sales cost of the item. The cost of not completing the task if it should not have been completed can involve monetary loss or other losses suffered by the system.

[0041] In some examples, the determination step is based on a priority weighting of one or more first events on the event log using one or more first signals to determine which of several executors to assign the task to, wherein one or more of the following are considered when weighting priorities: the time taken to complete the task; the cost of completing the task; the urgency of the task; and the cost of not completing the task. This can mean that a task can be assigned to an executor once a more important task has been assigned. The cost of completing the task can involve the material cost or sales cost of an item. The cost of not completing the task if it should not have been completed can involve monetary loss or other losses suffered by the system.

[0042] In some examples, the processor automatically assigns the task to the executor when a first signal, including data about a task related to running the first machine, is sent to the storage medium to write a first event to the event log stored on the storage medium. In this case, the method can jump from sending the first signal to sending the third / fourth signal. This can allow production areas and systems to be even more efficient because the deterministic steps can be avoided. This can also reduce the software requirements required to run the system because the deterministic steps are omitted.

[0043] In some examples, if the first event involves maintenance of the first machine, the first machine sends one or more maintenance-related sixth signals to the storage medium to write one or more ninth events to the event log stored on the storage medium at predetermined time intervals. Maintenance may involve repairing the first machine, checking parameters on the first machine, measuring parameters on the first machine, or any other suitable maintenance task related to the operation of the first machine. This allows certain tasks to be assigned to actuators at predetermined intervals, thereby ensuring the smooth operation of the first machine. In some examples, an actuator cannot undertake the same task twice. For example, if the task involves checking tolerances, the same actuator cannot be allowed to undertake the task twice within a predetermined time period. In this case, another actuator will be assigned the task. If the task is a maintenance task, this could be, for example, an inspection task covering the inspection of the status and / or output of the machine and / or machine tools, such as every 100 or 200 workpieces processed by the tool and / or repetitive maintenance tasks performed by technicians.

[0044] In some examples, the method further includes: sending one or more seventh signals from an executor assigned to a task to a storage medium to write a corresponding, one or more tenth events to an event log, wherein the one or more seventh signals include data about maintenance; reading the event log by a first machine; and i) changing the length of a predetermined time interval by the first machine based on maintenance; or ii) sending an eighth signal from the first machine to the storage medium, the eighth signal including data about a task related to running the first machine, to write an eleventh event to an event log stored on the storage medium, wherein the eleventh event corresponds to maintenance. This can allow maintenance to be performed at more appropriate intervals, and / or allow the first machine to write other maintenance-related events to the event log. For example, if the flow rate of coolant used in the machine is lower than planned and / or expected, the predetermined time interval can be extended. If the coolant level is below a safety threshold, other events written to the event log may involve refilling the coolant.

[0045] In some examples, the time gap between sending one or more second signals and the determination step depends on the task. For example, a transportation task can be "open," meaning that the actuator can send the second signal and write the second event over a longer period, allowing it to be undertaken by humans who can perform these tasks more quickly, rather than being rapidly and automatically assigned to an AGV that completes the task at a slower pace. The time gap can depend on one or more of the following: the time spent completing the task; the cost of completing the task; the urgency of the task; and the cost of not completing the task. The cost of completing the task can involve the material cost or sales cost of the item. The cost of not completing the task if it should not have been completed can involve monetary loss or other losses suffered by the system. In some examples, if a human actuator sends the second signal, the determination step can prioritize the human actuator over the machine actuator and make it more likely that the task will be assigned to the human actuator.

[0046] According to a second aspect, a system is described comprising: a first machine disposed on a production area, including a first transmitter; a processor coupled to a storage medium storing an event log; and a plurality of executors operating on the production area, each executor including a second transmitter, wherein the first transmitter is configured to send a first signal to the storage medium to write a first event to the event log, the first signal including data about a task related to the operation of the first machine, wherein the event log is visible to each of the plurality of executors, wherein the first event corresponds to a task, wherein each of the plurality of executors is configured to read the event log, wherein the second transmitter of any of the plurality of executors capable of performing the task is configured to send one or more second signals to the storage medium to write a corresponding, one or more second events to the event log, wherein the one or more second signals include data about a corresponding one or more executors capable of performing the task, wherein the processor is configured to To determine which of the plurality of executors to assign the task based on the one or more second events; and a) in the case where only the first executor among the plurality of executors sends the second signal to the storage medium: the processor is further configured to send a third signal to the storage medium, the third signal including data for writing the third event to the event log, indicating that the task has been assigned to the first executor, wherein each of the plurality of executors is further configured to read the event log, and wherein, by reading the event log, the first executor is informed that the task has been assigned to the first executor; and b) in the case where two of the plurality of executors send two corresponding second signals to the storage medium: the processor is further configured to send a fourth signal to the storage medium, the fourth signal including data for writing the fourth event to the event log, indicating that the task has been assigned to one of the two executors, wherein each of the plurality of executors is configured to read the event log, and wherein, by reading the event log, one of the two executors is informed that the task has been assigned to that executor.

[0047] Event logs can be considered raw data. Event logs and / or processors can prepare data for any of the signals mentioned herein in any executable-readable format within the executable.

[0048] In some examples, the data included in the first signal may include one or more of the following: G-code files; toolsheet data; simulation plans; read / write offset data; read / write product lifecycle PLC and / or NC parameters; read servo data; setpoint curves; path-dependent offset files; and NC parameter files. This allows any actuator to receive data from the first machine via the event log. While the term "first signal" is mentioned here, it will be understood by those skilled in the art that this can be applied to any signal mentioned herein.

[0049] These features can allow for other benefits. By implementing humans as actuators via wearable devices, including machine-like communication mechanisms for both unit controllers and machine controllers, a better operator integration model can be achieved in the manufacturing operating system. Therefore, humans can follow rules, such as being responsible for tasks after task request and assignment. Furthermore, any risk of damage to machines or unit controllers should be minimized, as humans could bypass every process and press every button. This can be reduced through better actuator integration. Clean event flows and datasets can help reduce this.

[0050] In human-centric cyber-physical manufacturing systems, with or without consideration of fine-grained planning (active scheduling) of key resources, human-centric task management can offer the following benefits:

[0051] If an agent wants to perform a task, then the agent can subsequently perform the task. In most minor processes, humans can perform tasks faster than robots.

[0052] a. Humans can perform more complex tasks or take over tasks in case of machine failure, such as during tool assembly or palletizing by AMRs (Autonomous Mobile Robots).

[0053] b. Humans can see and react to changes in boundary conditions (material availability, prioritization, etc.), which allows for on-demand flexibility.

[0054] c. At the end of a shift (e.g., from day to unmanned night shift), when increasing / decrease the capabilities of humans or robots, there may be no need for software reconfiguration or additional data processing. This allows for flexible switching between purely human-driven, hybrid, or purely robot-driven task implementation, thereby enabling robotic automation. This allows small production areas to start with process standardization and data automation before investing in budget-intensive automation hardware, and if the robot breaks down, tasks can be completed by humans in emergency situations.

[0055] d. This could be competency-based participation rather than role-based participation.

[0056] e. When an executor actively requests a task, it can better identify the task itself.

[0057] f. More event logs can be stored for task tracking, data mining, and model training.

[0058] Reactive task assignment can be based on employee interaction. Production areas can become more dynamic and agile. Parallel systems running concurrently on production areas can be merged, i.e., centralized (IT) allocated primary resources (like processing centers) and decentralized, human-coordinated secondary processes.

[0059] Furthermore, the claimed beneficial applications can improve human-system interaction, thus laying the foundation for human-cyberphysical manufacturing systems.

[0060] As an added benefit of wearable devices and the methods described above, notifications are human-specific and wireless, and confirmation events can be created to confirm that the notification and / or task has been seen and assigned.

[0061] Technicians understand that the above benefits apply not only to human-centered systems, but also to machine-centered systems and / or hybrid systems.

[0062] Any advantages and features described in relation to any of the above aspects and examples can be implemented in any other aspects and examples described herein. That is, for example, any aspect described in relation to the first aspect can be incorporated into the second aspect, and vice versa.

[0063] Those skilled in the art will understand that certain features of the systems described herein can be implemented using hardware (circuit), software devices, or a combination thereof. Software devices can be associated with a programmed microprocessor or general-purpose computer, an ASIC (Application-Specific Integrated Circuit), and / or a DSP (Digital Signal Processor). For example, the processing unit can be at least partially implemented as a computer, logic circuit, FPGA (Field-Programmable Gate Array), processor (e.g., microprocessor, microcontroller (uC), or array processor) / core / CPU (Central Processing Unit), FPU (Floating-Point Unit), NPU (Number Processing Unit), ALU (Arithmetic Logic Unit), coprocessor (for supporting other microprocessors of the main processor (CPU), GPGPU (General-Purpose Computing on a Graphics Processing Unit), multi-core processor (for parallel computing, such as performing arithmetic operations simultaneously on multiple main processors and / or graphics processors), or DSP.

[0064] Even though some of the features described above have been described with reference to the method, these features can also be applied to apparatus and / or system and / or computer-readable medium, and vice versa.

[0065] Furthermore, regarding the method steps, some steps may be undertaken simultaneously. Alternatively or alternatively, these steps may occur in a different order than that described herein. Additionally or alternatively, not all steps are necessary for the method to function. For example, there may be no defined steps and / or a global task list and / or any other suitable steps. Attached Figure Description

[0066] These and other aspects of the invention will now be further described by way of example only with reference to the accompanying drawings, wherein like reference numerals refer to like parts, and wherein:

[0067] Figure 1 A schematic diagram of a system, as described in this article, is shown based on some example implementations.

[0068] Figure 2 A schematic diagram of an execution body, as described in this article, is shown based on some example implementations.

[0069] Figure 3 A schematic diagram of a system, as described in this article, is shown based on some example implementations.

[0070] Figure 4A A flowchart of a method, as described in this article, based on some example implementations, is shown; and

[0071] Figure 4B A flowchart of a method, as described in this article, based on some example implementations, is shown; and

[0072] Figure 4C A flowchart of a method, as described in this article, based on some example implementations, is shown; and

[0073] Figure 5 A flowchart is shown illustrating a method implemented according to some examples, as described in this article. Detailed Implementation

[0074] Throughout the following text, "task" can be defined as an operation to be performed by, for example, a human, a mobile robot, an electrode charger, or a work charger (static robot). "Process" can be defined as an operation to be performed by a machine such as, for example, a discharge machine or a machining center. "Process group" can be defined as a collection of processes that may need to be performed on the same machine without intermediate transport tasks. "Operation" can be defined as a collective term for "task" or "process". "Job" can be defined as a directed graph describing the sequence of "operations". "Item" can be defined as a collective term for tools, electrodes, and workpieces such as materials, WIP (work in progress), and workpieces.

[0075] One or more of the following can also be applied:

[0076] - The operation may start from palletizing and end with unpalletizing.

[0077] - Processes with alternative processes may not be in a group.

[0078] - Only the EDM (Electrical Discharge Machining) process can be replaced by the milling process.

[0079] - If all groups / processes in the job have in-machine measurement results, then there may be no measurement task.

[0080] - Inspection tasks can be inserted anywhere, as long as there is a prior process. For example, the process could be a geometric transformation of a workpiece / item being processed before and / or after the inspection task.

[0081] - The machine that processes the next step can trigger the relevant operation.

[0082] - The related operations may not be part of the assignment.

[0083] Transportation tasks may be on-demand because it is unclear whether the task is needed or what the source and destination are. This can be called a reactive system.

[0084] - Manual transport tasks can be used to notify manual items of changes in location; this is not part of the job.

[0085] - After checking the task, it can be decided to repeat the final process, so it is not non-cyclic. This can also trigger rework, which can be classified as a new task.

[0086] - Inspection tasks can be performed by different entities, such as (for example) it is performed manually by humans, or it is performed automatically as a QA (quality assurance) measurement task in, for example, a milling machine or a CMM (coordinate measuring machine).

[0087] Additionally, the following can be applied:

[0088] The methods and systems described in this paper can create systems that integrate humans as components. They can create systems that allow for the coordinated management of homogeneous or heterogeneous fleets of robots. They can create systems where settings can be flexibly changed with respect to the hardware and software building blocks involved during runtime.

[0089] Every possible task "action" in the production area can be abstracted at the highest possible level of abstraction. As described in this paper, generic executors can implement tasks of abstract types. Generic executors can be decoupled logical entities. That is, in terms of communication between generic executors, direct communication may not occur; generic executors can be logically completely decoupled from each other; communication can be mapped via an immutable append-only event log; and generic executors can be coupled to the immutable append-only event log via a publish / subscribe pattern.

[0090] This allows for complete decoupling between the primary machine and the executor. It ensures the logical order of immutable, append-only event logs. That is, events can be written to the event log in chronological order. The generic executor can continuously observe the immutable, append-only event logs for specific events. Furthermore, responses to events can be reactive, meaning that events are used to trigger certain actions of the generic executor.

[0091] Task assignment can occur in a fully reactive manner. A cost function can be used for task assignment. The cost function can have a set of adjustable desired optimization objectives, including, for example, cost efficiency, energy efficiency, and earliest production. The cost function can implicitly define system behavior. Humans may be able to independently adjust the weights of certain hyperparameters to find the optimal customized system behavior that meets their actual needs. The cost function can be adjusted during system runtime, which may allow system behavior to change "online." Alternatively or alternatively, task assignment can occur proactively. That is, an agent can assume a task before it is assigned, but the agent knows that the task will be assigned in the near future. As an example, an agent may know that the oil level of the first machine needs to be checked soon, and therefore can assume the task before it has been assigned and / or even before the first event has been written to the event log.

[0092] A generic executor can have a specific set of capabilities, referred to as X, and can also be described as a logical entity. During implementation, the generic executor can be coupled to a physical entity via a specific adapter. Due to this connection, a subset of individual capabilities, referred to as Y, can be automatically generated during startup. A physical entity can consist of multiple generic executors. A generic executor can be an entity capable of communicating via publishing and subscribing to event logs. To interact with a physical device, a generic connector may need to be combined with a "specific adapter" that acts as the interface to the physical device. The specific adapter may cause an abstraction of the device's proprietary communication interface and / or a mapping of proprietary commands to the capabilities of the generic executor. The specific adapter can also technically abstract the proprietary interface of the hardware device using standardized communication protocols such as WebSockets. Not every physical device can support every capability of a generic executor, so each combination of a generic executor and a specific adapter may result in a different subset of capabilities. Based on the resulting subset of capabilities, the generic executor can publish and subscribe to a specific set of events in the event log and perform actions accordingly.

[0093] If a human is one of the actors, then the human can be integrated into the system via intelligent devices such as smartphones, smartwatches, headsets, pagers, laptops, tablets, smart glasses, or any other suitable device. The intelligent device can serve as the physical interface between the human and the system / method. The human can also listen to / scan / receive updates to / from the event log. The human can consume and parse the same events as the machine actor, since the human is also simply an instance of a generic actor. This allows for seamless integration of humans into the system and method, and the human can be used as a component of the system without disrupting it.

[0094] Figure 1 A schematic diagram of a system as described in this article, based on some example implementations, is shown.

[0095] A general flowchart of a possible system 100 is depicted. In this example, system 100 may include up to 10 parts, but those skilled in the art will understand that not all of these parts are necessary for the specific scenario in which system 100 may be located.

[0096] Event log 101 can be an immutable, append-only event log. This is advantageous compared to standard unit controllers that use classical relational methods representing the physical system state. Event log 101 may be needed for the interface of the generic actuator (see...). Figure 2For decoupling purposes, this interface may need to follow a publish / subscribe pattern. It can be ensured that incoming events are appended to event log 101 in both chronological and logical order. This logical order can be predetermined from real-world processes. Event log 101 can be deployed centrally or in a distributed manner. Event log 101 can be at least partially stored in storage media and driven by a processor. The storage media can be physical and / or at least partially stored in the cloud.

[0097] Event log 101 can communicate with job injection executor 102. Job injection executor 102 can input manufacturing jobs to system 100 and / or processor and / or storage medium via a first signal and / or a second signal. A job can consist of multiple process steps. Process steps can be divided into value-added steps or non-value-added steps. Value-added steps, for example, perform geometric transformations on the workpiece. Non-value-added steps can be, for example, inspection tasks and measurement tasks. Inspection tasks can refer to any kind of inspection, and measurement tasks can refer to geometric measurements related to geometric tolerance measurements. The job injection node coupled to job injection executor 102 can be a graphical user interface (for human-centered input) or an application programming interface (API) for interface connection with other computer systems such as ERP or MES systems or online platforms like cloud manufacturing services. It can also be a hybrid version of GUI and API. The job injection node and job injection executor 102 can be the same executor / node device.

[0098] Event Log 101 can communicate with Process Manager 103. Process Manager 103 can manage process steps and task assignments. Process Manager 103 can contain cost functions. The weights of cost functions can be adjusted independently via Process Manager 103. Before each, or multiple, announcements of a new process or task (i.e., the first event), Process Manager 103 can check whether all the necessary prerequisites for the executor are met. Prerequisites can be defined as a rule set for Process Manager 103. The rule set can be adjusted independently for each use case (i.e., for each type of task performed by the executor). When a second event is published to Event Log 101, the cost function component of Process Manager 103 can be triggered because Process Manager 103 and the executor have subscribed to these event types. Process Manager 103 can then publish the results of the cost function process to Event Log 101. This can then inform participating general executors if they have been assigned the task. This decoupled communication pattern of publishing and subscribing to Event Log 101 ensures the scalability of the methods and systems described herein.

[0099] Event log 101 can communicate with general geometry transformation executor 104, which allows geometry transformations, such as subtractive machining (milling, lathe machining, EDM, sawing, etc.) and / or additive machining (welding, 3D printing, etc.). Executor 104 may represent a value-added entity on each production area. General geometry transformation executor 104 can subscribe to events on event log 101 related to process steps and react accordingly to second signals and second events. During manufacturing, general transformation executor 104 can also publish status events to event log 101. General transformation executor 104 can also interact with other general actuators via event log 101. These interactions can be physical interactions exchanging physical objects such as workpieces or tools, or virtual interactions exchanging data such as NC files, tool data, or any other machine-specific parameters. As described below, general transport actuators can interact with general geometry transformation executor 104 to load workpieces or tools or other end effectors capable of geometric transformations of solid bodies.

[0100] The general transport executor 105 can be responsible for carrying out transport tasks for physical items. Transport tasks can be defined by actively changing the location of physical items such as workpieces or tools in the production area. These location changes can also be published to the event log 101 and subscribed to by other general executors. A successfully updated location can also trigger an information stream for the defined attributes of the physical item to be transported for the specified general executor.

[0101] Event log 101 can communicate with general inspection executor 106, which can be responsible for performing physical or virtual inspection tasks. An inspection task can be defined as comparing a given setpoint with an actual value. The comparison result (in some cases, based on a customizable set of rules) can be published to the event log. The result type can be success or failure. In the case of success, the next process step is triggered. In the case of failure, the next action depends on the customizable set of rules. For example, the last process step can be triggered again, or the process can be interrupted. An inspection task can be defined as a workpiece / item inspection and / or tool condition inspection of a workpiece / item being processed by the machine. In a tool condition inspection, the condition of the tool and / or any suitable parameters can be checked, thereby estimating the tool's lifespan before it requires repair or replacement. The executor can send the newly estimated tool lifespan as part of the task to event log 101, which can be read by the geometry transformation executor and may result in changes to values ​​in the tool table.

[0102] Event log 101 can communicate with general-purpose measurement actuator 107, which can be responsible for performing physical measurement tasks such as workpiece geometry / tolerance characteristics, tool geometry, or wear indications of tools or other end effectors. Measurement results can be published to event log 101 and made available to other general-purpose actuators.

[0103] Event Log 101 can communicate with Generic Assembly Executor 108, which is responsible for implementing physical assembly tasks. Assembly tasks can be defined by creating physical modules from physical items. Through the module assembly process, unique resource identifiers can be assigned from the system, as will be described in more detail herein. The unique resource identifier of a module can describe temporary physical items such as tool holders and tool components. Each physical item within a component can maintain its own unique resource identifier to ensure independent lifecycle tracking. The unique resource identifier of a component can be published to Event Log 101 and made available to other generic executors.

[0104] Event Log 101 can communicate with General Inventory / Item Manager 109, which tracks the lifespan of items in the production area. Each physical item can have a unique resource identifier assigned by Item Inventory / Item Manager 109. Inventory / Item Manager 109 ensures that physical items are tracked throughout the system's runtime. Inventory / Item Manager 109 can publish each newly logged-in physical item to System 100. Physical items can be workpieces, tools, or any other end effector. Each physical item can have a set of defined attributes that can be changed during its lifespan by any general actor via publishing events to Event Log 101. By querying Event Log 101, the actual state and any historical state of each physical item can be deduced from it. This can be done by each general actor. The attributes of each item can be used by different general actors to ensure correct usage. For example, General Geometry Transformation Actor 104 can use the geometric dimension attributes of a tool.

[0105] Event log 101 can communicate with a general information pool 110, which can derive any information by querying event log 101. Information receiver 110 can be central software configured to track event log 101 and / or any other suitable device and / or any actuator within system 100. Alternatively or additionally, information receiver 110 can be a process mining tool for processing event log 101 and / or any other suitable software.

[0106] Figure 2 A schematic diagram of an executor as described in this article, based on some example implementations, is shown.

[0107] exist Figure 2 In the illustration, four transport actuators 105 are shown in the form of a stationary robot, an AMR, a track-mounted robot, and a human operator. Those skilled in the art will understand that other types of transport actuators may be used, and in fact, any type of actuator mentioned herein may be used in addition to or in place of transport actuator 104.

[0108] The generic executor 200 may have a specific set of capabilities, referred to as X, which can also be described as a logical entity. During implementation, the generic executor 200 may be coupled to a physical entity via a specific adapter. Due to this connection, a subset of individual capabilities, referred to as Y, can be automatically generated during startup. These capabilities are... Figure 2 The general-purpose executor 200 is shown as an assignment to each executor. A physical entity can exist beyond multiple general-purpose executors 200. A general-purpose executor 200 can be an entity capable of communicating via publishing and subscribing to event log 101. To interact with a physical device, the general-purpose connector may need to be combined with a "specific adapter" that acts as an interface to the physical device. The specific adapter may cause an abstraction of the device's proprietary communication interface and / or a mapping of proprietary commands to the capabilities of the general-purpose executor 200. The specific adapter may also technically abstract the hardware device's proprietary interface using standardized communication protocols such as WebSockets. Not every physical device can support every capability of the general-purpose executor 200, therefore each combination of the general-purpose executor 200 and the specific adapter may result in a different subset of capabilities. Based on the subset of capabilities, the general-purpose executor 200 can publish and subscribe to a specific set of events in event log 101 and perform actions accordingly. Figure 2 As can be seen, specific abilities can overlap, and it is presumed that in such cases, a human operator could take over each task. In some examples, this may not be possible.

[0109] Figure 3 A schematic diagram of a system as described in this article, based on some example implementations, is shown.

[0110] Figure 3 System 400 can be with Figure 1 The system is the same as system 100. Here, it is also shown... Figure 2 The execution body 200.

[0111] First, instances of general measurement executors 107 and 210 trigger a transportation request for the tool requiring measurement in event log 101. Measurement executor 107 is mentioned here, but those skilled in the art will understand that this can alternatively refer to any executor mentioned herein. A previous assignment of a measurement task for a certain tool has not yet been completed. Instances of general measurement executors 107 and 210 issue a transportation task request including required attributes such as the item to be transported, pick-up location, and destination. Here, the task type is represented by a rectangle.

[0112] Second, all instances of the general transportation executor 200 continuously subscribe to event log 101. Depending on the capabilities required for the transportation tasks, the executor 200 determines whether they are appropriate.

[0113] Third, all instances of the general transportation executor 200 continuously subscribe to the event log, and only instances with a subset of individual capabilities adapted to the requested transportation task publish the event containing the second event to event log 101 based on the actual state of executor 200. Figure 3 As can be seen, only the executor 200 with rectangular capabilities responds to events being published to event log 101. Then, executor 200 subscribes to event log 101 to search for the output of process manager 103.

[0114] Fourth, the process manager 103 searches for and uses the second event written to the event log 101 by the executor 200, and the process manager keeps the search open for an adjustable time period depending on the task.

[0115] Fifth, after the search window for writing the second event to event log 101 expires, the execution body 200 that writes the second event is then fed into the cost function. The most suitable candidate is selected based on the actual configuration of the cost function's weights. The process manager can then publish the result of the cost function to event log 101.

[0116] Sixth, all instances of the general transport executor 200 continuously subscribe to the event log. Only the winning instance (i.e., the executor 200 that has been assigned a task) will begin the task, while the losing instance (i.e., the executor 200 that has not been assigned a task) will begin writing a second event to the event log 101 to attempt and obtain the task. If an executor 200 is assigned a task, it cannot execute the task immediately, but can only begin the task after a predetermined amount of time and / or after other more important tasks have been completed and / or after the machine has undergone maintenance.

[0117] Figures 4A to 4C A flowchart is shown illustrating a method implemented according to some examples, as described in this article.

[0118] Figures 4A to 4C A flowchart illustrating an example implementation of the systems 100, 400, and methods described herein is shown. Figures 4A to 4C The headings in the column are “Device,” “System,” “Operator A,” and “Operator B,” but those skilled in the art will understand that these refer to the first machine, the processor, and the storage medium, and the first and second actuators 200, respectively. Throughout the following text, the term “notification” may mean push notification, alarm, haptic feedback, audio feedback, visual feedback, or any other suitable type of feedback.

[0119] First, a machine alarm is triggered. This alarm can be a maintenance alarm, an error alarm, or any other suitable notification related to the operation of the first machine. The first machine then translates this alarm into a check task, but alternatively or alternatively, this can be a maintenance task, a transport task, or any other suitable type of task.

[0120] The first machine then sends the task to the processor and storage medium, inserting it into event log 101 by writing the event to event log 101. This is equivalent to the first event. In some examples, event log 101 may be immutable. In some examples, the task may be written to a list of tasks that may be immutable. In some examples, this list of tasks is a global list of tasks visible to each executor 200. Each executor 200 then sees the task and makes a “bid” on it. It is understood by those skilled in the art that a “bid” may be an auction among executors offering their services to undertake the task and / or an indication that executors 200 are available to undertake the task, such that these executors can use the cost function mentioned herein. This is equivalent to the second event.

[0121] Then, the "bid manager" in the diagram (but process manager 103 as described herein) verifies the second event by double-checking whether the executor 200, which has written the second event to the event log 101, is actually capable of undertaking the task, and then runs the cost function. The processor and storage medium then publish the "winner" of the cost function, in this case, the first executor 200. The first executor 200 can then begin undertaking the task at any suitable time (hereby pressing a button), and subsequently, the second executor 200 begins writing the second event to undertake other tasks, and the task is removed from the first global task list visible to all executors 200 and placed on a second individual task list visible only to the first executor 200.

[0122] In some examples, if each part of the task completes successfully, the processor and storage medium can track the progress of the task as the first executor 200 sends a notification. In some examples, the first executor 200 can send a notification only when the entire task is completed. The first executor 200 follows instructions to complete the task, and updates to the task completion are tracked by the processor and storage medium.

[0123] In this case, since it is an inspection task, the first executor 200 sends the inspected value to the processor and storage medium, which in turn sends the value to the first machine. It is understood by those skilled in the art that the same process occurs in maintenance tasks, and that this step can be omitted in transport tasks. The first machine then sends feedback related to the value to the processor and storage medium, which in turn updates the machine's status in the storage medium and / or event log 101 accordingly. In some examples, an executor cannot undertake the same task twice. For example, if the task involves checking tolerances, the same executor cannot be allowed to undertake the task twice within a predetermined time period. In this case, another executor will be assigned the task.

[0124] Once the first executor 200 has complied with all instructions, it sends a notification to the processor and storage medium, checking whether the current first machine state allows the task to be shut down. If the task can be shut down, it is removed from the second executor's task list, and in some examples, the task may be placed in a third list indicating which tasks have been completed. This third list may be visible only to the first executor 200, a subset of executors 200, or all executors 200. If the task cannot be shut down, a notification is sent to the first executor 200 indicating this.

[0125] In some examples, the first execution unit 200 may need to abandon the task midway due to more urgent needs, the end of a shift, maintenance reasons, errors, malfunctions, or any other suitable reason.

[0126] In this scenario, the task is reassigned to another executor 200, in this case, the second executor 200. The task is then transferred from a task list visible only to the first executor 200 to a task list visible only to the second executor 200. The second executor 200 then assumes the remainder of the task, with the processor and storage medium tracking the task's state as it has done relative to the first executor 200. Alternatively, the task can be rewritten and republished on the event log 101 by writing additional events to the event log 101, thereby allowing the other executor 200 to send a second signal and write a second event to the event log 101, effectively restarting the method described herein.

[0127] In some examples, the task is placed back on the first global task list instead of being reassigned, whereby executor 200 is then allowed to "bid" for the completion of the remainder of the task. In this case, the method essentially restarts, but the successful executor 200 completes the remainder of the task.

[0128] Figure 5 A flowchart is shown illustrating a method implemented according to some examples, as described in this article.

[0129] The method includes sending a first signal from a first machine arranged in the production area to a storage medium to write a first event to an event log stored in the storage medium. The first signal includes data about a task related to running the first machine. The event log 101 is visible to each of a plurality of executors 200 operating in the production area. The first event corresponds to a task (S300).

[0130] Then, each of the multiple executors 200 reads the event log 101 (S310).

[0131] Then, the method includes sending one or more second signals to the storage medium by any of the plurality of executors 200 capable of performing the task, to write a corresponding one or more second events on the event log 101, wherein the one or more second signals include data about the corresponding one or more executors 200 capable of performing the task (S320).

[0132] The method then includes a processor coupled to the storage medium determining, based on one or more second events, which of the plurality of executors 200 to assign the task to (S330).

[0133] In the case where only the first executor 200 among the plurality of executors 200 sends the second signal to the storage medium, the method includes: the processor sending a third signal to the storage medium, the third signal including data for writing a third event on the event log 101, indicating that a task has been assigned to the first executor (S340); and each of the plurality of executors 200 reading the event log 101, wherein, based on the first executor 200's reading of the event log 101, the first executor 200 is informed that a task has been assigned to the first executor 200 (S345).

[0134] In the case where two of the plurality of executors send two corresponding second signals to the storage medium, the method includes: the processor sending a fourth signal to the storage medium, the fourth signal including data for writing a fourth event to the event log 101, indicating that a task has been assigned to one of the two executors 200 (S350); and each of the plurality of executors 200 reading the event log 101, wherein, based on the reading of the event log 101 by the two executors 200, one of the two executors 200 is informed that a task has been assigned to that executor 200 (S355).

[0135] Undoubtedly, those skilled in the art will conceive of many other effective alternatives. It should be understood that the invention is not limited to the described embodiments, but covers modifications that are obvious to those skilled in the art and fall within the scope of the appended claims.

[0136] The following examples are also covered by this disclosure and may be incorporated in whole or in part into the embodiments.

[0137] 1. A method comprising:

[0138] A first signal is sent from a first machine located in the production area to a storage medium to write a first event to an event log stored on the storage medium. The first signal includes data about a task related to the operation of the first machine, wherein the event log is identifiable to each of a plurality of executors operating in the production area, and wherein the first event corresponds to the task.

[0139] The event log is read by each of the plurality of executors;

[0140] One or more second signals are sent to the storage medium by any of the plurality of executors capable of performing the task to write corresponding one or more second events to the event log, wherein the one or more second signals include data about the corresponding one or more executors capable of performing the task;

[0141] A processor coupled to the storage medium determines, based on the one or more second events, which of the plurality of executors to which the task should be assigned; and

[0142] a) In the case where only the first actuator among the plurality of actuators sends the second signal to the storage medium:

[0143] The processor sends a third signal to the storage medium, the third signal including data indicating that a third event has been written to the event log, indicating that the task has been assigned to the first executor; and

[0144] The event log is read by each of the plurality of executors, wherein, based on the first executor's reading of the event log, the first executor is informed that the task has been assigned to the first executor; and

[0145] b) In the case where at least two of the plurality of executors send at least two corresponding second signals to the storage medium:

[0146] The processor sends a fourth signal to the storage medium, the fourth signal including data indicating that a fourth event has been written to the event log, indicating that the task has been assigned to one of the at least two executors; and

[0147] The event log is read by each of the plurality of executors, wherein, based on the reading of the event log by the at least two executors, one of the at least two executors is informed that the task has been assigned to the executor.

[0148] The first event may involve the first machine writing information about the task to be completed to the event log. The second event may involve the executor writing information about its ability to perform a task to the event log. The third and fourth events may involve the processor writing information about the task assigned to the executor to the event log. The first through fourth signals may involve data signals sent in response to the first through fourth events via the various characteristics mentioned herein.

[0149] 2. The method according to Project 1, wherein determining which of the plurality of executors to assign the task based on the one or more second events is based on the processor reading the event log.

[0150] 3. The method according to item 1 or 2, wherein once any event has been written to the event log, the event cannot be removed from the event log.

[0151] 4. The method according to Project 3, wherein the event log is immutable, and the events are immutably appended to the event log.

[0152] 5. The method according to any one of the preceding items, wherein at least one of the plurality of executors is a human.

[0153] 6. The method according to any one of the preceding items, wherein, upon being notified that the task has been assigned, the executor to which the task has been assigned updates or generates a first task list visible only to the executor to which the task has been assigned, wherein the first task list includes the task to which the executor has been assigned.

[0154] 7. The method according to item 6 further includes, when the executor assigned the task completes a portion of the task, the executor sends data about the completion of the portion of the task to the storage medium to write a fifth event to the event log.

[0155] The fifth event may involve information about the completion of a portion of the task being written to the event log.

[0156] 8. The method according to item 6 or 7 further includes, when the executor assigned the task begins the task, the executor sends data about the start of the task to the storage medium to write a sixth event to the event log.

[0157] The sixth event may involve information about the start of the task being written to the event log.

[0158] 9. The method according to any one of the preceding items, wherein, upon being notified that the task has been assigned, the executor assigned the task updates or generates a second task list visible to the plurality of executors, wherein the second task list includes the executor assigned the task.

[0159] 10. The method according to any one of items 6 to 9, wherein the executor can only begin the task once the first task list and / or the second task list has been updated or generated.

[0160] 11. The method according to any one of the preceding items further includes, once the executor assigned the task completes the task, the executor sending data about the completion of the task to the storage medium to write a seventh event to the event log.

[0161] The seventh event may involve information about task completion being written to the event log.

[0162] 12. The method according to item 11 further includes preventing the transmission of data regarding the completion of the task or the completion of the portion of the task if the task or the portion of the task has not yet been completed.

[0163] 13. The method according to any one of the preceding items, wherein if the executor is a second machine capable of performing the task, the executor automatically sends the one or more second signals, and / or wherein if the executor is a human capable of performing the task, the executor manually sends the one or more second signals.

[0164] 14. The method according to any one of the preceding items, wherein, upon being notified that the executor has been assigned the task, if the executor is the second machine, the second machine then automatically starts the task, or the second machine rejects the task.

[0165] 15. The method according to any one of the preceding items subordinate to item 5, wherein, when informed that the executor has been assigned the task, if the executor is a human, the human can manually start or refuse the task.

[0166] 16. The method according to item 14 or 15, wherein if the executor rejects the task, the method restarts by sending a fifth signal to the storage medium via the first machine to write an eighth event to the event log stored on the storage medium, the fifth signal including data about the task in relation to running the first machine, wherein the first signal and the fifth signal relate to the same data.

[0167] The eighth event may involve information about tasks that need to be completed in relation to the operation of the first machine being written to the event log once the task has been rejected by the executor. The fifth signal may involve a data signal sent by the first machine that includes task-related data.

[0168] 17. The method according to any one of items 14 to 16, wherein the executor assigned the task begins the task at a first time, wherein the first time is based on a priority weighting of one or more first events on the event log based on one or more first signals, wherein one or more of the following are considered in the priority weighting:

[0169] - The time spent completing the task;

[0170] - The cost of completing the task;

[0171] - The urgency of the task; and

[0172] - The consequences of not completing the task.

[0173] 18. The method according to any one of the preceding items, wherein the determining step determines which of the plurality of executors to assign the task to based on a priority weighting of one or more first events on the event log by the one or more first signals, wherein one or more of the following are considered in the priority weighting:

[0174] - The time spent completing the task;

[0175] - The cost of completing the task;

[0176] - The urgency of the task; and

[0177] - The consequences of not completing the task.

[0178] 19. The method according to any one of the preceding items, wherein when the first signal, including data relating to a task related to running the first machine, is sent to a storage medium to write a first event on the event log stored on the storage medium, the processor automatically assigns the task to an executor.

[0179] 20. The method according to any one of the preceding items, wherein if the first event relates to the maintenance of the first machine, the first machine sends one or more sixth signals related to the maintenance to the storage medium to write one or more ninth events to the event log stored on the storage medium at predetermined time intervals.

[0180] The ninth event may involve information related to the maintenance of the first machine being written to the event log. The sixth signal may involve a data signal sent by the first machine that includes information about the ninth event.

[0181] 21. The method according to item 20, further comprising:

[0182] The executor assigned to the task sends one or more seventh signals to the storage medium to write a corresponding one or more tenth events to the event log, wherein the one or more seventh signals include data about the maintenance;

[0183] The event log is read by the first machine; and

[0184] i) The length of the predetermined time interval is changed by the first machine based on the maintenance; or

[0185] ii) The first machine sends an eighth signal to the storage medium to write an eleventh event to the event log stored on the storage medium, the eighth signal including data about a task related to running the first machine, wherein the eleventh event corresponds to the maintenance.

[0186] The tenth and eleventh events may respectively relate to maintenance information written to the event log and information related to running tasks on the first machine based on the maintenance results. The seventh and eighth signals may respectively relate to data signals sent by the executor including information about the tenth event and data signals sent by the first machine related to the eleventh event.

[0187] 22. The method according to any one of the foregoing items, wherein the time interval between sending the one or more second signals and the determining step depends on the task.

[0188] 23. A system comprising:

[0189] The first machine, which is located in the production area, includes a first transmitter;

[0190] A processor, the processor being coupled to a storage medium storing an event log; and

[0191] Multiple actuators, each operating in the production area, include a second transmitter.

[0192] The first transmitter is configured to send a first signal to the storage medium to write a first event to the event log, the first signal including data about a task related to running the first machine, wherein...

[0193] The event log is visible to each of the plurality of executors, wherein,

[0194] The first event corresponds to the task, wherein,

[0195] Each of the plurality of executors is configured to read the event log, wherein...

[0196] A second transmitter of any of the plurality of executors capable of performing the task is configured to send one or more second signals to the storage medium to write corresponding one or more second events to the event log, wherein,

[0197] The one or more second signals include data regarding a corresponding executor or multiple executors capable of performing the task, wherein,

[0198] The processor is configured to determine, based on the one or more second events, which of the plurality of executors to which the task should be assigned; and

[0199] a) In the case where only the first actuator among the plurality of actuators sends the second signal to the storage medium:

[0200] The processor is further configured to send a third signal to the storage medium, the third signal including data indicating that a third event has been written to the event log, indicating that the task has been assigned to the first executor, wherein...

[0201] Each of the plurality of executors is further configured to read the event log, and wherein,

[0202] By reading the event log, the first executor is informed that the task has been assigned to it; and

[0203] b) In the case where two of the plurality of executors send two corresponding second signals to the storage medium:

[0204] The processor is further configured to send a fourth signal to the storage medium, the fourth signal including data indicating that a fourth event has been written to the event log, indicating that the task has been assigned to one of the two executors, wherein...

[0205] Each of the plurality of executors is configured to read the event log, and wherein,

[0206] By reading the event log, one of the two executors is informed that the task has been assigned to that executor.

[0207] 24. The system according to item 23, wherein the data included in the first signal comprises one or more of the following:

[0208] G-code file;

[0209] Tool table data;

[0210] Simulation plan;

[0211] Read / write offset data;

[0212] Read / write product lifecycle, PLC and / or CNC parameters;

[0213] Read servo data;

[0214] Set the curve;

[0215] Path-related offset files; and

[0216] NC parameter file.

Claims

1. A method comprising: sending, by a first machine arranged on a production zone, a first signal to a storage medium to write a first event on an event log stored on the storage medium, the first signal comprising data about a task related to operating the first machine, wherein the event log is identifiable to each of a plurality of actors operating on the production zone, wherein the first event corresponds to the task; reading, by each of the plurality of actors, the event log; sending, by any of the plurality of actors capable of performing the task, one or more second signals to the storage medium to write corresponding, respective one or more second events on the event log, wherein the one or more second signals comprise data about the respective one or more actors capable of performing the task; determining, by a processor coupled to the storage medium, which of the plurality of actors to assign the task to based on the one or more second events; and a) in the event that only a first actor of the plurality of actors sends the second signal to the storage medium: sending, by the processor, a third signal to the storage medium, the third signal comprising data to write a third event on the event log indicating that the task has been assigned to the first actor; and reading, by each of the plurality of actors, the event log, wherein based on the first actor's reading of the event log, the first actor is informed that the task has been assigned to the first actor; and b) in the event that at least two of the plurality of actors send at least two respective second signals to the storage medium: sending, by the processor, a fourth signal to the storage medium, the fourth signal comprising data to write a fourth event on the event log indicating that the task has been assigned to one of the at least two actors; and reading, by each of the plurality of actors, the event log, wherein based on the at least two actors' reading of the event log, the one of the at least two actors is informed that the task has been assigned to the actor.

2. The method of claim 1, wherein, Determining which of the plurality of actors to assign the task to based on the one or more second events is based on the processor reading the event log.

3. The method of claim 1 or 2, wherein, Once any event has been written on the event log, the event cannot be removed from the event log.

4. The method of claim 3, wherein, The event log is immutable and the events are appended to the event log immutably.

5. The method according to any of the preceding claims, wherein, At least one of the plurality of actors is human.

6. The method according to any one of the preceding claims, wherein, Upon being informed that the task has been assigned, updating or generating, by the actor to which the task has been assigned, a first task list that is only visible to the actor to which the task has been assigned, wherein the first task list comprises the task that the actor has been assigned.

7. The method according to claim 6, further comprising, upon completion of the part of the task by the executors assigned the task, sending, by the executors, data about the completion of the part of the task to the storage medium to write a fifth event on the event log.

8. The method according to claim 6 or 7, further comprising, upon starting the task by the executors assigned the task, sending, by the executors, data about the starting of the task to the storage medium to write a sixth event on the event log.

9. The method of any of the preceding claims, wherein, upon being informed that the executors have been assigned the task, updating or generating, by the executors assigned the task, a second task list visible to the plurality of executors, wherein the second task list comprises the executors assigned the task.

10. The method of any one of claims 6-9, wherein, The executors can start the task only once the first task list and / or the second task list have been updated or generated.

11. The method according to any of the preceding claims, further comprising, upon completion of the task by the executors assigned the task, sending, by the executors, data about the completion of the task to the storage medium to write a seventh event on the event log.

12. The method according to claim 11, further comprising preventing sending data about the completion of the task or the part of the task if the task or the part of the task has not been completed.

13. The method of any of the preceding claims, wherein, The executors automatically send the one or more second signals if the executors are second machines capable of performing the task, and / or wherein the executors manually send the one or more second signals if the executors are humans.

14. The method of any of the preceding claims, wherein, The second machines subsequently automatically start the task if the executors are the second machines upon being informed that the executors have been assigned the task, or the second machines reject the task.

15. The method according to any of the preceding claims depending on claim 5, wherein, The humans can manually start or reject the task if the executors are humans upon being informed that the executors have been assigned the task.

16. The method of claim 14 or 15, wherein, The method restarts by the first machine sending a fifth signal to the storage medium to write an eighth event on the event log stored on the storage medium, the fifth signal comprising data about the task related to running the first machine, if the executors reject the task, wherein the first signal and the fifth signal relate to the same data.

17. The method of any one of claims 14 to 16, wherein, The executors assigned the task start the task at a first time, wherein the first time is based on a priority weighting of one or more first events on the event log by one or more first signals, wherein one or more of the following are considered in the priority weighting: - time taken to complete a task; - cost of completing a task; - urgency of a task; and - cost of not completing a task.

18. The method of any of the preceding claims, wherein, The determining step determines which of the plurality of executors to assign the task to based on a priority weighting of one or more first events on the event log by the one or more first signals, wherein one or more of the following are considered in the priority weighting: - time taken to complete a task; - cost of completing a task; - urgency of a task; and - cost of not completing a task.

19. The method of any of the preceding claims, wherein, The processor automatically assigns the task to an executor when the first signal comprising data about a task related to running the first machine is sent to a storage medium to write a first event on the event log stored on the storage medium.

20. The method of any of the preceding claims, wherein, If the first event relates to maintenance of the first machine, one or more sixth signals related to the maintenance are sent by the first machine to the storage medium to write one or more ninth events on the event log stored on the storage medium at predetermined time intervals.

21. The method of claim 20, further comprising: sending, by the executor assigned to the task, one or more seventh signals to the storage medium to write corresponding, respective one or more tenth events on the event log, wherein the one or more seventh signals comprise data about the maintenance; reading, by the first machine, the event log; and i) changing, by the first machine, a length of the predetermined time intervals based on the maintenance; or ii) sending, by the first machine, an eighth signal to a storage medium to write an eleventh event on the event log stored on the storage medium, the eighth signal comprising data about a task related to running the first machine, wherein the eleventh event corresponds to the maintenance.

22. The method of any of the preceding claims, wherein, A time interval between sending the one or more second signals and the determining step depends on the task.

23. A system comprising: a first machine arranged on a production area, comprising a first transmitter; a processor, the processor being couplable to a storage medium, the storage medium storing an event log; and a plurality of executors operating on the production area, each executor comprising a second transmitter, wherein the first transmitter is configured to send a first signal to the storage medium to write a first event on the event log, the first signal comprising data about a task related to running the first machine, wherein the event log is visible to each of the plurality of executors, wherein the first event corresponds to the task, wherein each of the plurality of executors is configured to read the event log, wherein a second transmitter of any of the plurality of executors capable of performing the task is configured to send one or more second signals to the storage medium to write corresponding, respective one or more second events on the event log, wherein the one or more second signals comprise data about the respective one or more executors capable of performing the task, wherein the one or more second signals comprise data about the respective one or more executors capable of performing the task, wherein the processor is configured to determine, based on the one or more second events, to which of the plurality of executors to assign the task; and a) in case only a first executor of the plurality of executors sends the second signal to the storage medium: the processor is further configured to send a third signal to the storage medium, the third signal comprising data to write a third event on the event log, indicating that the task has been assigned to the first executor, wherein each of the plurality of executors is further configured to read the event log, and wherein by reading the event log, the first executor is informed that the task has been assigned to the first executor; and b) in case two of the plurality of executors send two respective second signals to the storage medium: the processor is further configured to send a fourth signal to the storage medium, the fourth signal comprising data to write a fourth event on the event log, indicating that the task has been assigned to one of the two executors, wherein each of the plurality of executors is configured to read the event log, and wherein by reading the event log, the one of the two executors is informed that the task has been assigned to the executor.

24. The system of claim 23, wherein, the data comprised in the first signal comprises one or more of: a G-code file; a tool table data; a simulation plan; a read / write offset data; a read / write product life cycle, PLC, and / or numerical control, NC, parameters; a read servo data; a set curve; a path dependent offset file; and a NC parameters file. the data comprised in the first signal comprises one or more of: a G-code file; a tool table data; a simulation plan; a read / write offset data; a read / write product life cycle, PLC, and / or numerical control, NC, parameters; a read servo data; a set curve; a path dependent offset file; and a NC parameters file.

Images