Task-driven process control and autonomous process resource configuration

Abstract

To provide a software definition manufacturing solution capable of processing a production process specified through a task.SOLUTION: The present invention relates to a resource object (26) operative for execution of at least one task (28) supporting operation of a module processing system (10). Each task (28) is defined by a required capacity specification representing a capacity expected for task execution and / or a required resource specification representing at least one processing resource expected for task execution. Since a task describes the capabilities and / or resources provided for the execution of the associated task, the resource object (26) can perform autonomous process resource configuration. The invention also relates to a processing resource pool for providing processing resources to be used through resource objects (26) during autonomous process resource configuration.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to resource objects that are operated in a modular processing system to perform at least one task that supports the operation of the modular processing system, processing resource pools that are operated in conjunction with the resource objects to provide access to at least one processing resource that can be used by the resource objects to perform the tasks, and methods of operating the resource objects and processing resource pools. [Background technology]

[0002] Digitalized and automated production processes form the basis of production infrastructure and industrial automation. In recent years, software-defined manufacturing (SDM) offers increased flexibility in the manufacturing context and independence from changes in processing conditions over time.

[0003] While traditional industrial automation approaches focus on hardware and control infrastructure such as machines, software-defined manufacturing (SDM) controls the hardware and infrastructure through software systems and / or software platforms.

[0004] This enables integrated real-time optimization of process resources. Software-defined manufacturing (SDM) supports adaptation to new production requirements and designs, as well as changes in production processes. The key technologies enabling software-defined manufacturing (SDM) are cloud computing, artificial intelligence, and the Internet of Things (IoT).

[0005] Furthermore, the convergence of information technology and operational technology plays a central role in software-defined manufacturing (SDM). This convergence results in the seamless integration of management and production-related data. Potential production issues can be predicted and resolved before they actually occur. As a result, predictive maintenance strategies enable shorter production downtimes and reduced costs.

[0006] However, while software-defined manufacturing (SDM) delivers the benefits outlined above, it remains processing-resource oriented. The emphasis is on integrating existing production hardware, control infrastructure, and different information and data flows. This implies early decisions about how to leverage existing processing resources within the software-defined manufacturing process.

[0007] Overall, there are limitations to handling changes in process conditions that have real-time impacts on the availability of processing resources, processing contexts, and / or handling of failure constellations. Summary of the Invention [Problem to be solved by the invention]

[0008] In view of the above, a technical object of the present invention is to provide a software-defined manufacturing solution capable of handling production processes specified via tasks that describe the capabilities provided for the associated task executions that support autonomous process resource configuration.

[0009] According to a first aspect of the present invention, there is provided a resource object operating within a modular processing system to perform at least one task supporting the operation of the modular processing system. Every task is defined by a required capability specification that represents the capabilities expected for task execution and / or a required resource specification that represents at least one processing resource expected for task execution. The resource object also continuously references a resource object signature that represents the operational status of the modular processing system over time, external to and / or local to the resource object.

[0010] According to a first aspect of the present invention, a resource object comprises a task preprocessor adapted to release task execution for a target task if at least one selected processing resource available to the resource object has a capacity specification that matches the required capacity specification of the task and / or a resource specification that matches the required resource specification of the task, and if at least one operational status represented by the resource object signature and that must be used as a release condition for task execution matches a required operational status specified for the resource object.

[0011] According to a first aspect of the present invention, the resource object also includes a task execution controller adapted to observe the resource object signature and control task execution by at least one selected processing resource.

[0012] According to a second aspect of the present invention, there is provided a processing resource pool operative in association with a resource object to provide access to at least one processing resource that may be used by the resource object for task execution during operation of the modular processing system.

[0013] According to a second aspect of the present invention, a processing power pool includes a processing resource registry adapted to register at least one processing resource according to at least one registration criterion characterizing the at least one processing resource, and a resource pool manager including a resource allocation controller.

[0014] According to a second aspect of the present invention, the resource allocation controller is adapted, upon receiving a search request specifying at least one search criterion, to search the processing resource repository to check whether the at least one registration criterion of the at least one registered processing resource matches the at least one search criterion for generating search results.

[0015] According to a second aspect of the present invention, the resource allocation controller is adapted to apply a search optimization function to update the search results when multiple registered processing resources are listed in the search results, wherein the search optimization function evaluates at least one search-related characteristic of the registered processing resources listed in the search results for identification of at least one preferred registered processing resource from the search results and associated updating of the search results.

[0016] According to a second aspect of the present invention, the resource allocation controller is also adapted to allocate all registered processing resources listed in the search result to the allocated resource object for subsequent use via the allocated resource object.

[0017] According to a third aspect of the present invention, there is provided a method of manipulating resource objects within a modular processing system to perform at least one task to support operation of the modular processing system, wherein every task is defined by a required capability specification representing capabilities expected for task execution and / or a required resource specification representing at least one processing resource expected for task execution, and wherein a resource object signature represents the external and / or local operational status of the resource object over time within the modular processing system.

[0018] According to a third aspect of the invention, the method comprises the step of checking whether at least one selected processing resource available for use by the resource object has a capacity specification that matches the required capacity specification of the task and / or a resource specification that matches the required resource specification of the task.

[0019] Furthermore, according to a third aspect of the present invention, the method includes the step of checking whether at least one operational status represented by the resource object signature matches a required operational status that must be used as a condition for release of task execution via the resource object.

[0020] Further, according to a third aspect of the present invention, the method includes the step of releasing task execution for the target task if the availability of at least one selected processing resource meets the capacity specification and / or resource specification and meets the required operational status.

[0021] Further, according to a third aspect of the present invention, the method includes the step of controlling task execution by at least one processing resource selected upon observation of the resource object signature.

[0022] According to a fourth aspect of the present invention, there is provided a method of operating a processing resource pool operated in association with a resource object to provide access to at least one processing resource that can be used by the resource object for task execution during operation of a modular processing system.

[0023] According to a fourth aspect of the invention, a method comprises the step of registering at least one processing resource according to at least one registration criterion characterizing the at least one processing resource.

[0024] According to a fourth aspect of the present invention, a method includes, upon receiving a search request specifying at least one search criterion, searching a processing resource registry to check whether at least one registration criterion of at least one registered processing resource registered in the processing resource registry matches the at least one search criterion to generate search results.

[0025] According to a fourth aspect of the present invention, a method includes optimizing search results by applying a search optimization function when a plurality of registration processing resources are listed in the search results, wherein the search optimization function evaluates at least one search-related characteristic of the registration processing resources listed in the search results for identification of at least one preferred registration processing resource from the search results and for related updating of the search results.

[0026] According to a fourth aspect of the invention, the method includes allocating all registered processing resources listed in the search results to the allocated resource object for subsequent use via the allocated resource object. [Brief explanation of the drawings]

[0027] [Figure 1] 1 shows an overview of a different modular processing system using a resource object portion implementing at least one resource object according to the invention to solve tasks during operation of the modular processing system; [Figure 2] 1 illustrates the basic concept of the operation of resource objects according to the present invention and the related basic overview of resource objects; [Figure 3] FIG. 1 illustrates a task specification and its associated processing via resource objects in accordance with the present invention. [Figure 4] FIG. 1 illustrates an observation-based feedback mechanism for achieving parallelization of operations on multiple resource objects in accordance with the present invention. [Figure 5] FIG. 1 illustrates the process of configuring an observation instance using an observation capability template and an observation capability set template according to the present invention. [Figure 6] FIG. 3 is a diagram showing a more detailed outline of the observation device shown in FIG. 2. [Figure 7] 7 is a flowchart showing the operation of the observer shown in FIG. 6. [Figure 8] FIG. 2 illustrates the basic structure of a resource object signature used to control resource object manipulation in accordance with the present invention. [Figure 9] FIG. 9 is a diagram showing a more detailed structure of the resource object signature shown in FIG. 8. [Figure 10] FIG. 3 is a more detailed schematic diagram of the task processors and processing resources shown in FIG. 2. [Figure 11] 11 is a flowchart showing the operation of the resource object base portion shown in FIG. [Figure 12] 10 is a flowchart illustrating further details related to global release conditions, local release conditions, and checking processing resources before releasing task execution. [Figure 13] FIG. 11 is a more detailed schematic diagram of a resource object according to the present invention shown in FIGS. 2 and 10. [Figure 14]14 illustrates the interoperability of the functional units shown in FIG. 13 according to the following scenarios: (a) task execution through the use of local capabilities / functions, (b) task execution through the execution of process sequences, and (c) task execution through task delegation. [Figure 15] 10 is a flowchart illustrating the operation of a task preprocessor with respect to directing task execution through local capabilities / functions, process sequences that provide the requested capabilities at run time, or delegating task execution to further resource objects. [Figure 16] FIG. 11 shows a more detailed schematic of the local capability / function manager shown in FIG. 10. [Figure 17] FIG. 10 illustrates an example of functional allocation as a means of distinguishing local capabilities / functions that have the same structure but are used to achieve different functional effects. [Figure 18] 10 is a flowchart showing the operation of the task execution controller shown in FIG. 9 regarding task execution by local capabilities / functions. [Figure 19] FIG. 1 illustrates a process sequence in which each step in the process sequence is assigned a step start condition, a step stop condition, and at least one task definition for a task to be executed as part of the step execution. [Figure 20] FIG. 11 is a more detailed schematic diagram of the sequence manager shown in FIG. [Figure 21] 21 is a flowchart showing the operation of the sequence manager shown in FIG. 20. [Figure 22] FIG. 1 illustrates the association of task specifications and the association of different resource object signatures for task acceptance, initiation of processing sequence execution, and initiation of process sequence step execution. [Figure 23] FIG. 14 is a diagram showing a more detailed outline of the sequence execution controller shown in FIG. 13. [Figure 24] 24 is a flowchart showing the operation of the sequence setup controller shown in FIG. 23. [Figure 25] 24 is a flowchart showing the operation of the sequence controller shown in FIG. 23. [Figure 26] 24 is a flowchart showing the operation of the step controller shown in FIG. 23. [Figure 27] 24 is a flowchart showing in more detail the operation of checking step execution conditions by the step controller shown in FIG. 23. [Figure 28] 28 is a flowchart showing the operation of checking local processing resource conditions in step S120 shown in FIG. 27. [Figure 29] 27 is a flowchart showing the operation relating to task execution in step S116 shown in FIG. 26. [Figure 30] 27 is a flowchart showing the operation of checking the step end condition in step S118 shown in FIG. 26. [Figure 31] FIG. 14 shows further details of the pose manager shown in FIG. 13. [Figure 32] 32 is a flowchart showing the operation of the pause manager shown in FIG. 31. [Figure 33] FIG. 1 illustrates an example of how resource object signatures drive process sequence execution, for example, determining consent for sequence execution, initiation of sequence execution, and processing of process sequence steps and associated step tasks. [Figure 34] FIG. 14 illustrates the interoperation of the resource objects shown in FIG. 13 with a processing resource pool that provides pooled process sequences and / or pooled processing resource objects as task delegates when an associated search request is submitted. [Figure 35] FIG. 35 is a diagram illustrating an outline of the processing resource pool illustrated in FIG. 34. [Figure 36] 36 is a flowchart showing the operation of the resource processing pool shown in FIG. 35. [Figure 37] 14 is a flowchart illustrating the operation of the task delegation controller shown in FIG. 13. [Figure 38] FIG. 2 illustrates interoperability options between a resource object and an associated resource object pool. DETAILED DESCRIPTION OF THE INVENTION

[0028] The present invention will be described in detail below with reference to the drawings. It should be understood that such description is merely an example of the present invention and does not restrict the scope of the present invention as defined in the claims. Reference to specific functional units should be considered as functional examples in which the functional units are clearly interchangeable as long as the same functionality is achieved by implementation in software, hardware, or any combination thereof.

[0029] FIG. 1 shows an overview of a different modular processing system that uses a resource object portion implementing at least one resource object according to the invention to solve tasks during operation of the modular processing system.

[0030] 1, in accordance with the present invention, a modular processing system 10 may be understood as a collection of interrelated operating parts that are distinct from their environment, either as a whole or in a particular context. Furthermore, the modular processing system 10 may be configured with computer-implemented system portions 12, 14 and / or physical devices integrated into the physical system portion 16.

[0031] As shown in FIG. 1, the computer-implemented system portions 12, 14 of the modular processing system 10 communicate with the physical system portion 16 or other computer-implemented system portions via a communication channel 18.

[0032] For example, examples of computer-implemented system portions 12, 14 may be traditional PLC control logic or fieldbus drivers. Examples of physical devices in physical system portion 16 may be A / D converters, mechanical devices such as conveyor belts, electrical devices such as sensors and / or actuators. Typically, these components are used to configure production system 20.

[0033] Yet another example of a computer implemented system portion may be an IT system 22 operable as a production module for service optimization or as a connector module.

[0034] 1, a modular processing system 10 according to the present invention comprises a resource object portion 12 executing on a computing device 24. The resource object portion 12 comprises and executes at least one resource object 26. The resource object 26 accepts tasks derived from a process plan specified for the operation of the modular processing system, where the tasks are sent to the resource object 26 for processing according to predetermined operating conditions.

[0035] 1, a first example (a) of a configuration of modular processing system 10 is a traditional shop floor system 20 augmented by a computing device 24 executing resource object portion 12. Here, a first communication channel 18-1 is set up between resource object portion 12 and computer-implemented control portion 14 of production system 20. Also, a second communication channel 18-2 is established between computer-implemented control portion 14 and physical system portion 16. According to this configuration (a), resource objects in resource object portion 12 can monitor and extend control of system control portion 14 during operation of production system 20.

[0036] 1, a second example (b) of the configuration of the modular processing system 10 can be a combination of the resource object portion 12 and the physical system portion 16. Here, a communication channel 18-3 is directly established between the resource object portion 12 and the physical system portion 16. According to this configuration, the resource object executed by the resource object portion 12 can directly control the physical system portion 16 of the production system 20 without traditional PLC control.

[0037] As shown in Fig. 1, a third example (c) of the configuration of the modular processing system 10 can be a combination of the resource object part 12 and the IT system 22. Such a scenario applies, for example, to the configuration of a production module for optimizing production services or to the configuration of an MES / ERP connector.

[0038] As shown in FIG. 1, a fourth example (d) of the configuration of the modular processing system 10 is a standalone operation of the resource object portion 12, for example, a configuration for a diagnostic communications management system (DCM).

[0039] According to the present invention, there is no particular limitation on how the resource object portion 12 is actually realized, as long as the related functions described below are provided. Typical examples would be dedicated software, a SaaS system in a cloud-based environment, or a system that uses digital twin objects to provide logical operations specified at the behavioral level.

[0040] FIG. 2 illustrates the basic concept of the operation of resource objects according to the present invention and the related basic overview of resource objects.

[0041] As shown in FIG. 2, in the resource object portion 12 of the module processing system 10, a plurality of resource objects 26 may operate, each accepting the execution of a task assigned to the resource object 26 according to predetermined conditions.

[0042] It should be noted here that the present invention does not impose any limitations on the type of modular processing system 10. Typical examples would be manufacturing systems, logistics systems, or any other type of processing system arranged to operate according to a predetermined processing plan.

[0043] Furthermore, there are no particular limitations on the type of resource object 26 according to the present invention, as to its implementation and use. The resource object 26 may be operated in relation to different levels of processing in the modular processing system 10, for example, physical devices operated on the shop floor of a manufacturing site, control logic, or digital functionality provided in the digital domain, for example, digital twins operated in a cloud system for monitoring and controlling field devices.

[0044] Additionally, tasks 28 may specify partial processes that are derived from a process plan set up for the modular processing system 10 and that are executed by resource objects 26. The process plan is not bound to a specific processing resource when it is set up, but rather the execution of a task-driven process plan specifies only what to do, regardless of how it is to be done, thereby greatly increasing the flexibility of execution of the modular processing system 10.

[0045] 2, every resource object 26 is adapted to keep track of an associated signature 30 that drives the behavior of the resource object 26. In other words, the information conveyed by the signature 30 controls the behavior of the resource object 26 when executing tasks 28 sent to it.

[0046] As shown in FIG. 2, the information conveyed by the signature 30 may be externally specified, may reflect the internal status of the resource object 26, or may be generated by observing the operational status of the modular processing system 10.

[0047] As shown in FIG. 2 , when observing the operational status of the modular processing system 10, it may be assumed, without loss of generality, that the overall status of the modular processing system 10 can be represented as an observation space 32 set up from multiple observation sizes 34 observable in the modular processing system 10.

[0048] 2, manipulation of any resource object 26 may affect at least a subset of the observation size 34 of the observation space 32. When such changes are observed and fed back into the different signatures 30 of the resource objects 26 manipulated in the modular processing system 10, the manipulation of different resource objects 26 may be performed independently.

[0049] 2, any resource object 26 always has access to observation information related to its operation via resource object signature 30 without monitoring other resource objects 26 in the modular processing system. Thus, the establishment of an observation mechanism in accordance with the present invention allows for parallel operation of different resource objects 26.

[0050] 2, a resource object 26, e.g., resource object 26-2, may delegate the execution of a task to another resource object, e.g., resource object 26-3. Here, once the task is delegated, the delegating resource object no longer tracks or monitors the results of the task processing in a sequential and controlled manner. In contrast, the delegated resource object continues its own related processing without directly and sequentially monitoring the execution results. This decoupling is achieved through the monitoring mechanism of the present invention and the feedback of monitoring size-related information via signature 30.

[0051] In conclusion, the observation mechanism according to the invention supports parallelization of operations between different resource objects and increases the flexibility and speed of processing within a modular processing system.

[0052] As shown in FIG. 2, a task 28 is generally set up from a specification of the resource objects required to perform the task, the capabilities required of the resource objects 26 to perform the task, and the capabilities required of data associated with the task, such as a set of parameters that drive the execution of the task.

[0053] Thus, in accordance with the present invention, the specification of tasks 28 does not require the dedicated assignment of task execution to specific processing resources, thereby increasing processing flexibility within the model of processing system 10, because tasks 28 are specified at the level of capabilities, regardless of how such capabilities are ultimately realized and implemented.

[0054] Additionally, task 28 may specify a required resource specification, but again only the type of processing resource is given, without specifying a processing resource instance. Associated information may be resource category, resource subcategory, version, and optionally applicable technology domain. The resource specification allows for categorizing processing resources to the extent necessary for selecting an execution processing resource capable of executing task 28.

[0055] 2, resource object 26 generally comprises at least an observer 36, a signature memory 38, and a processing-based portion 40. Processing-based portion 40 is set up from a task processor 42 that runs on processing resources 44 available to resource object 26.

[0056] Operationally, the observer 36 is adapted to continuously observe the observation size 34 associated with the behavior of the resource object during task execution and to send the observation results into the resource object signature memory 38 for updating the resource object signature 30. The observer 36 may also be adapted to continuously observe the internal status of the resource object for associated updates of the resource object signature 30.

[0057] Furthermore, the task processor 42 is adapted to determine the acceptance of a task 28 sent for execution to the resource object 26. Heretofore, the task processor 42 is adapted to evaluate the processing resources 44 available to the resource object 26 to determine the compatibility of the required capacity and required resource specifications defined in the task with the available processing resources 44. Furthermore, the task processor 42 is adapted to check the overall operational status of the resource object 26 before accepting the task execution.

[0058] In conclusion, with reference to FIG. 2, the key concepts underlying the present invention are explained as follows.

[0059] The first such concept is to operate resource objects 26 based on tasks sent to them, where the tasks specify the required capabilities and resources that must be provided by the resource objects 26 without defining how they are to be realized. Thus, the process specification is described at a higher level of abstraction and offers increased flexibility compared to existing process specification approaches.

[0060] A second such concept is the establishment of observation-based feedback loops, which allow parallelizing operations between different resource objects 26 and avoiding communication-intensive sequential monitoring between different resource objects 26.

[0061] A third such concept is the control of task execution via signatures 30. Signatures 30 allow filtering of observation sizes 34 associated with the operation of resource objects 26 and defining operational conditions for task execution via resource objects 26. Thus, signatures 30 drive the operational control of processing resources 26 and reduce the processing load of relevant information, as only relevant information is provided to resource objects 26 via the relevant signatures 30.

[0062] Overall, the present invention relies on the cascading execution of task-related processes, observing and adapting to continuous changes in operating conditions, and establishing an observation-based feedback loop mechanism to parallelize the execution of task-related processes.

[0063] FIG. 3 is a diagram illustrating task specification and its associated processing through resource objects of the present invention.

[0064] Generally, in accordance with the present invention, a task 28 communicates minimal information about what to accomplish, and not how to accomplish that something.

[0065] As outlined above, the specification of a task 28 includes a required capability 46 specification describing the capabilities expected for the execution of the task, a required resource specification 48 describing the types of resources expected for the execution of the task's data, and optionally data 50 that drives the task execution process, e.g., a set of parameters regarding the degrees of freedom for the task execution.

[0066] 3, the required resources and required capabilities are specified as six tuples and four symbols, although it should be understood that there are no limitations on the representation of such information. The essence of processing such information is to find a match between the specification and the relevant information provided by the resource object. Once a match between the required resource specification 48 and the required capabilities 46 is established between the task 28 and the processing resources available and usable by the resource object 26, the task 28 is accepted by the resource object 26 subject to the conditions reflected in the signature 30 of the resource object 26.

[0067] As shown in FIG. 3, the task processor 42 of the resource object 26 may use at least one local resource provided as a function 54 or available from a local capability / function reservoir 52 provided as a capability 56 .

[0068] 3, local resources may be categorized as functions 54 or capabilities 56, where functions 54 are permanently installed in resource objects 26 and are continuously available. Alternatively, local resources may be categorized as capabilities 56, which are not continuously available like functions 54 but are only available for specific periods of time. For example, a capability may be an AGV robot that is temporarily positioned adjacent to a conveyor line for certain periods and is away from the conveyor line for other periods of time.

[0069] From the above, it can be seen that due to differences between the capabilities 54 and the capabilities 56 of the resource object 26 as a local resource, a situation may arise where a task 28 is accepted for task execution at one time, while the same task 28 may be rejected at another time, with task-related capabilities no longer available to the resource object 26. This illustrates that by specifying tasks 28 independently of the allocation of associated execution to specific resources within the modular processing system 10, dynamic constellation processing is supported within the modular processing system 10, thus increasing overall operational flexibility.

[0070] As shown in FIG. 3, through accessing the sequence reservoir 58, the task processor 42 of the resource object 26 may optionally use at least one local resource provided as at least one process sequence 601-, 60-2, 60-3, ..., or short sequence.

[0071] Generally, the process sequence 60 is a short sequence and describes the orchestration of local resources and related activities, i.e., the interoperation of multiple capabilities / functions to provide a particular capability.

[0072] Additionally, if process sequence 60 is no longer executable due to a change in operating conditions reflected in signature 30, the corresponding request capability may allow for re-entry and activation of another process sequence that may become executable due to the same change in operating conditions.

[0073] In conclusion, the processing of tasks 28 within resource objects 26 involves real-time allocation of available processing resources to specified requested resources and / or requested capabilities, which implies autonomous resource object configuration in response to the submission of tasks 28.

[0074] It should be understood that such allocation may be accomplished in a static manner such that for a particular specified capacity, only one local processing resource is available and therefore may be statically allocated, where the static allocation occurs as soon as possible during process configuration of the modular processing system 10.

[0075] Otherwise, if a particular processing resource is only available for a particular period of time, the relevant allocation is dynamic allocation, which, according to the present invention, is performed as late as possible before task execution begins, thereby maximizing the availability of the processing resource.

[0076] FIG. 4 illustrates an observation-based feedback mechanism that achieves parallelization of operations on multiple resource objects 26 in accordance with the present invention.

[0077] As shown in Figure 4 and as outlined above with respect to Figure 2, in accordance with the present invention, an observation-based feedback loop 62 is established that feeds back observation data related to observation size 34 from observation space 32 to the signature 30 of resource object 26.

[0078] 4, manipulation of a resource object 26 may generally affect a subset of the observation sizes 34 of the observation space 32. In other words, manipulation of a resource object 26 changes the observation sizes 34, and the set of changed observation sizes constitutes an observation size range 64 for the resource object 26.

[0079] As shown in Figure 4, within the framework of an observation-based feedback loop 62, multiple observers 66 operate, each operating on a subset of the observation size 34 for the observations. Every subset of the observation size constitutes an observation size input (feed) 68 for the associated observer 66.

[0080] In accordance with the present invention, the observed size 34 may represent, for example, a physical size, a local status within the modular processing system 10, external inputs to the modular processing system 10, sensor data, actuator data, or any other size that may be relevant to be observed during operation of the modular processing system 10. It should be understood that the observed size 34 may also exist in a digital domain external to the modular processing system 10, i.e., in a cloud-based control system operating outside of the modular processing system 10 for control of the modular processing system 10.

[0081] 4, for observations of observation size 34, the observation format may need to be converted into a format suitable for further processing within observation-based feedback loop 62. Such conversions are specified as observation capabilities 70, where different observation sizes 34 may require different observation capabilities 70. To cover different observation sizes 34 in the observer size input 68 of observer 66, multiple observation capabilities 70 may be combined into an observation capability set 72 for subsequent configuration of the associated observer 66.

[0082] It should be understood that, in accordance with the present invention, all observers 66 operate in association with the signature 30 of a resource object 26 and are generally integrated into the resource object 26. Additionally, a resource object 26 may use multiple observers 66 in association with different observation size inputs 68 associated with the execution of one or more tasks through the resource object 26. Thus, because every resource object 26 observes all observation sizes 34 associated with its operation, mutual exchange of relevant information between resource objects 26 is unnecessary, allowing parallel operation of different resource objects 26.

[0083] 4, the observation size 34 of the observation input 68 may also be related to the internal observation size that prevails internally with respect to the resource object 26. That is, with respect to the observer 66, there is no distinction between the observation size 34 that is internally observable within the resource object 26 and the observation size 34 that is observable externally to the resource object 26.

[0084] Furthermore, it should be noted that, according to the present invention, observation and task execution are separated through the signature 30. The observation process runs continuously regardless of whether a task 28 is being executed, and when a resource object 26 accepts a task 28, it may check its signature 30 to evaluate its execution conditions. Also, the observer 66 continuously inputs the signature 30 in real time, so that task execution can begin as soon as possible once all relevant conditions are met. Here, the observer 66 may input multiple signatures 30, and one signature 30 may contain feedback information from multiple observers 66.

[0085] Furthermore, because monitoring and task execution are separated, sequential checks of task execution status are not required when one resource object 26 delegates task execution to another resource object 26, and therefore sequential query processing does not block the operation of the resource object 26. This forms the basis for parallel operation of resource objects 26 in the modular processing system 10.

[0086] FIG. 5 is a diagram illustrating the process of configuring an observation instance using an observation capability template 78 and an observation capability set template 80 according to the present invention.

[0087] 5, the configuration of an observation instance depends on the observation capability 74 and the observation capability set 76. For every observation capability, an associated template 78 may be provided that is available from an observation capability template pool 88. Also, for each observation capability set 76, an associated observation capability set template 80 may be provided that is available from an observation capability set template pool 90.

[0088] It should be noted that for a particular operational constellation, the configuration of mandatory observation sets is required. A typical example is observing the global release condition GLS of a resource object 26 before starting task execution via a processing resource, since the global release condition GLS is externally specified and requires continuous monitoring. Other examples are observing the operating mode AOM assigned to the resource object 26, observing the local release status LRS before starting task execution via a processing resource, and observing the safety condition SAF before starting task execution via a processing resource. In addition to the above, observation instances can be configured according to specific task execution requirements.

[0089] It should be noted that although the above observations are described in terms of observation size 34, it is also possible in accordance with the present invention to observe pauses. A pause is defined by the combination of an observation capability set and the conditions imposed on the observation size 34 covered by the observation capability set 76.

[0090] A pose carries a name and allows an abstract view on the observation size 34, since generally not all possible observations are considered, but only specific observations. A pose reflects the degrees of freedom in the operation of available processing resources subject to imposed conditions. When all conditions are met, the pose is observed. For example, it may be sufficient to know that all doors in a particular room are closed, without necessarily knowing how many doors there are in that room, which doors are open, and which doors are closed.

[0091] FIG. 6 is a diagram showing a more detailed schematic of the observer 36 shown in FIG.

[0092] 6, the observer 36 includes at least one observation instance 82, an observation configurator 84, and an observation controller 86. The observation configurator 84 has access to an observation capability template pool 88 and an observation capability set template pool 90.

[0093] Operationally, at least one observation instance 82 is adapted to perform the observation process defined by the observation capability set 76 .

[0094] Further, operationally, the observation configurator 84 is adapted to configure at least one observation instance 82. Thus, the observation configurator 84 accesses an observation capability template pool 88 and an observation capability set template pool 90 to load at least one observation capability template 78 and / or at least one observation capability set template 80.

[0095] Further, operationally, the observation configurator 84 is adapted to use at least one observation capability template 78 and / or at least one observation capability set template 80 for at least one observation instance 82 .

[0096] Here, the observation capability template 78 specifies how the observed size is actually observed, which may mean specifying the associated sensors, identifying read access for stored measurement data related to the observed size, specifying a communication protocol for accessing the observed size sensor, etc. The observation capability template 78 may also specify the data format required to provide the captured observed size-related data to at least one signature 30.

[0097] Furthermore, the observation capabilities 74 are grouped into related observation capability sets 76 for the setup of observation instances 66. The use of observation capability set templates 80 allows for mapping process knowledge to observed processes and for flexible setup of observation-based feedback loops 62. If multiple resource objects 26 use the same observation process, only one observation capability set template needs to be specified.

[0098] Furthermore, the observation controller 86 is adapted to control the operation of the observation instances 82 and the observation configurator 84. Once the observation configurator 82 configures the observation instances 82 required to set up the observation-based feedback loop 62, the observation controller 86 is adapted to control tracking of the status of at least one operation performed in the modular processing system 10 through the use of the at least one observation instance 82.

[0099] FIG. 7 is a flowchart showing the operation of the observer 36 shown in FIG.

[0100] As shown in FIG. 7 , in step S10, when operatively performed by the observation configurator 84, an observation capability template pool 88 and an observation capability set template pool 90 are accessed to load at least one observation capability template and / or at least one observation capability set template.

[0101] 7, in step S12, when operatively performed by the observation configurator 84, configuring at least one observation instance 82 is performed. The execution of step S12 relies on the use of at least one observation capability template and / or the use of at least one observation capability set template.

[0102] As shown in FIG. 7, in step S14, when operatively performed by the observation controller 86, observation control of at least one observation size 34 observable in the modular processing system 10 via at least one observation instance 66 is performed.

[0103] It should be noted that, according to the present invention, in step S14, the observation of at least one observation instance 66 is controlled independently and continuously from any task execution. Furthermore, step S14 is performed such that multiple observation instances 66 are observed independently and in parallel with each other.

[0104] FIG. 8 illustrates the basic structure of a resource object signature 30 used to control resource object manipulation in accordance with the present invention.

[0105] As shown in FIG. 8, the basic structure of the signature 30 is divided into a global status section 90, a safety section 92, a local status section 94, and a current step section 96.

[0106] Here, a global status section 90 and a safety section 92 are configured external to the resource 26. The global status section 90 reflects the overall operational status of the modular processing system 10 external to the resource object 26, and the safety section 92 is associated with at least one externally defined condition that must be satisfied before the task 28 can be executed.

[0107] Additionally, local status section 94 is a reflection of the local status occurring within resource object 26 and is therefore dependent on the internal operating status of resource object 26 .

[0108] Additionally, the current step section 96 is associated with the execution of the process sequence by the resource object 26. During the execution of the process sequence, the status of the currently executing step is continually tracked and reflected within the current step section 96.

[0109] FIG. 9 shows a more detailed structure of the resource object signature shown in FIG.

[0110] As shown in Figure 9, the global status section 90 includes at least a global release status GRS and an assigned operating mode AOM. The global release status GRS summarizes all status information that must exist outside of the resource object before task execution can begin and is therefore externally defined. The assigned operating mode AOM specifies an operating mode that is externally assigned to the resource object 26 and is therefore externally defined. For example, the assigned operating mode AOM may specify a particular operating mode for the resource object 26 or may indicate an immediate halt to operation when an error occurs within the module processing system 10.

[0111] 9, the safety section 92 defines the functional safety status SAFs and is externally defined. The specification of the safety section SAFs relates to the setup of the process plan for the modular processing system 10 and requires process knowledge.

[0112] 9, the local status section 94 includes a local release status LRS. The local release status LRS reflects the local status that must be used within the resource object 12 before task execution begins and is set by the observation instance 82. The local release status LRS may be different for each task and is used to protect local processing resources within the resource object 12.

[0113] 9, the local status section 94 includes an internally defined marker IDM that is set by the local processing resource. The internally defined marker IDM is a named, internally defined marker that is set when the combination of observations of a group of observation instances 82 meets a predetermined required observation pattern or observation evaluation result.

[0114] 9, the local status section 94 includes a current task result CTR that continually reflects the status of task execution during operation of the resource object 26. This is set internally by the resource object 26. It is used to control task execution through the resource object 26.

[0115] 9, the local status section 94 includes a current step result CSR that is set during execution of the process sequence through the resource object 26. The current step result CSR is continually referenced during execution of the process sequence to control the execution of the process sequence.

[0116] As shown in FIG. 9, the local status section 94 contains the current capability result CCR that is set internally within the resource object 26 upon use of local capabilities / functions for task execution.

[0117] As shown in FIG. 9, the current step section 96 is associated with the execution of a process sequence that includes at least one step. The current step section 96 includes a step entry condition status SCO and a step exit condition status FCO, which are checked at the beginning and end of the step. Both are externally set. The current step section 96 also includes a section DBG that defines a sequence processing mode that is externally or alternatively set for at least one observation instance 82. Section DBG allows switching between continuous operation on the steps of the process sequence and a step-by-step mode for testing and debugging the process sequence.

[0118] FIG. 10 is a more detailed schematic diagram of the task processor 42 and processing resources 44 shown in FIG.

[0119] As shown in FIG. 10, the task processor 42 includes a task preprocessor 98 and a task execution controller 100.

[0120] As shown in FIG. 10, task preprocessor 98 is adapted to accept tasks 28 sent to task processor 42 and evaluate whether the tasks are acceptable for task execution.

[0121] 10, a task 28 to be processed by task processor 42 may be an external task sent externally to resource object 26, or an internal task generated internally during task execution by resource object 26. Here, an internal task is a subtask identified during execution of a process sequence step, as described below, or a task that arises due to, for example, an error constellation or a change in signature 30 that blocks continued task execution.

[0122] Furthermore, the task execution controller 100 is adapted to determine whether to process the task execution using any processing resources available to the resource object 26. Thus, the local processing resource manager 102 is adapted to provide the processing resources that the task execution controller 100 can use for task execution. More specifically, the local processing resource manager 102 can provide either local capabilities / capabilities available from the local capability / capability manager 104 or short sequences processed by the sequence manager 106.

[0123] 11 is a flowchart showing the operation of the resource object base portion shown in FIG.

[0124] As shown in FIG. 11, in step S18, when operationally performed by the task preprocessor 98, the global conditions applied in the modular processing system 10 are checked to see if they are appropriate for task execution.

[0125] More specifically, it is checked whether the global release status GRS, which is represented by the resource object signature 30 and which must be used as a release condition for task execution, matches the required operation status specified in association with the task and resource object 26.

[0126] Additionally, the local release status LRS, which is represented by the resource object signature 30 and which must be applied locally at the resource object 26 as a release condition for task execution, is checked to see if it matches the requested operation status specified in association with the task and resource object 26.

[0127] 11, in step S20, when operatively performed by the task preprocessor 98, it is checked whether at least one processing resource available to the resource object 26 matches the requirements of the submitted task 28, regardless of whether the submitted task 28 is an external or internal task. More particularly, it is checked whether at least one selected processing resource available to the resource object 26 has a capability specification that matches the task's required capability specification and / or a resource specification that matches the task's required resource specification.

[0128] 11, once task execution is operationally released by the task preprocessor 98 in step S22, it proceeds to step S24 where it is operationally executed by the task execution controller 100, which controls task execution by at least one selected processing resource while observing the resource object signature 30. Thus, the task execution controller 100 has access to different sections of the resource object signature 30, such as the current task result CTR, the current step result CSR, and the allocated operating mode AOM.

[0129] 11, if the task execution is not released in step S22, the process proceeds to step S26, where the task execution is stopped when operationally executed by the task execution controller 100. On the other hand, if the task execution is successful, the process proceeds to step S28, where the current task result CTR is set to task idle when operationally executed by the task execution controller 100.

[0130] 12 is a flowchart showing the operational details of checking global release conditions, local release conditions, and processing resources before releasing a task execution. All steps shown in FIG. 12 are operatively performed by the task preprocessor 98.

[0131] 12, in step S30, a check is performed to see whether the requested global release status specified for the target task matches the global release status GRS through accessing the resource object signature 30. If the result of this check indicates that the global release status GRS does not match the requested global release status, in step S32 the current task result CTR of the section is set to global status error. Alternatively, if the global release status matches the requested global release status or is marked as a wildcard condition, the execution process proceeds to step S34.

[0132] 12, in step S34, it is checked whether the required resource specification of the target task matches the available processing resources of the resource object 12. If there is no match, in step S36, the current task result CTR in the signature section 14 is set to a resource specification error.

[0133] 12, if the requested resource specification is met, the next step S38 is to check the local release status LRS, which represents the local status present within the resource object 26 and must match the requested local status specified in the resource object 26 as a release condition for task execution.

[0134] Furthermore, a match in step S38 means that any resource available by resource object 26 is available for task execution, or that a particular processing resource available by resource object 12 matches the required resource specification set in the task specification.

[0135] The task execution is also released if the local release status LRS matches the requested local release status, as shown in Figure 12. Otherwise, in step S40, the current task result section of the signature 30 of the resource object 26 is set to local release error.

[0136] FIG. 13 shows a more detailed schematic of a resource object 26 according to the present invention shown in FIGS.

[0137] As shown in FIG. 13, in addition to the components described above, the resource object 26 also includes a sequence execution controller 108, a task delegation controller 110, and a pause manager 112.

[0138] Operationally, the sequence execution controller 108 has access to the sequence manager 106 and to all process sequences processed by the sequence manager 106. Additionally, if the task execution controller 100 selects a sequence execution process as the basis for task execution, the sequence execution controller 108 is adapted to control the execution of the process sequence selected for task execution.

[0139] Additionally, the task delegation controller 110 is operatively adapted to delegate processing of a task sent to a resource object 26 to yet another delegate (target) resource object 26 operating in the modular processing system 10. As previously explained with respect to Figure 2, when such task delegation occurs, no continuous monitoring of the delegatee resource object 26 is required, as full responsibility for processing the task is handed over to the task delegatee resource object 26 at the time of task delegation.

[0140] 13, the resource object 12 includes a pause manager 112, where a "pause" defines a combination of observations that must conform to a predefined pause pattern that allows for the setting of internally defined markers IDM. These internally defined markers IDM can serve as entry points for initiating various process sequences or as re-entry points for resuming operation of the resource object 26 in the event of an operational error.

[0141] The remaining components of resource object 26 shown in FIG. 13 have already been described above and will not be repeated here.

[0142] Figure 14 illustrates the interoperability of the functional units shown in Figure 13 for each of the following scenarios: (a) task execution through the use of local capabilities / functions, (b) task execution through the execution of a process sequence, and (c) task execution through task delegation. Interoperability between functional units is indicated by circled numbers.

[0143] As shown in FIG. 14, the first scenario (a) relates to task execution through the use of local capabilities / functions (circled numbers 1 to 6).

[0144] As shown in Figure 14, the task is sent to the task preprocessor 98. Then, the task preprocessor 98, in cooperation with the local processing resource manager 102, checks the availability of local capabilities / functions to process the task (circled number 2). If there is availability of local capabilities / functions, the task preprocessor 98 instructs the task execution controller 100 to control the task execution (circled number 3). The task execution controller 100 then controls the task execution through the selected local capabilities / functions (circled number 5). Finally, the task execution controller 100 provides the task execution results to the task preprocessor 98 (circled number 6).

[0145] 14, in accordance with the present invention, resource objects 26 are also adapted to interoperate with an external resource pool 114. Operationally, external resource pool 114 is adapted to provide information about and access to processing resources that are available to resource objects 26 but that are processed externally to resource objects 26. Such processing resources may be, for example, process sequences that may be loaded into sequence manager 106 (circled number 7) for subsequent use by sequence execution controller 108. Alternatively, such processing resources may be, for example, references to resource objects 26 that may be the subject of task delegation processing and, in turn, that can take over task execution from a delegating resource object 26.

[0146] The second scenario (b) is related to task execution through the execution of a process sequence (circled numbers 9 to 15), as shown in Figure 14. This scenario is only relevant when there are no local capabilities / features available for task execution (see circled number 2).

[0147] 14, in the second scenario, the task preprocessor 98, together with the sequence manager 106, checks whether a process sequence that provides the capability required by the task is being processed by the sequence manager 106 (circled number 9). If not, the sequence manager 106 accesses the external resource pool 114 to resolve the problem (circled number 10). If a process sequence that provides the required capability is available, the task preprocessor 98 instructs the sequence execution controller 108 through the task execution controller 100 to control the execution of the process sequence (circled number 11).

[0148] As shown in Figure 14, different sub-scenarios can occur during the execution of a process sequence.

[0149] 14, in the first sub-scenario (b1), the steps of the process sequence are executed one by one. In this case, when the execution of the process sequence is completed, the related processing results are transferred to the task preprocessor 98 (circled number 15).

[0150] 14, the second sub-scenario (b2) relates to the case where a currently executing sequence needs to be stopped due to a change in operating conditions, e.g., a change in the signature 30 (e.g., global release status GRS or local release status LRS) of a resource object 26. In this case, the sequence execution controller 108 may find a suitable process sequence for the given constellation by directly accessing the sequence manager 106 (circled number 12) or indirectly accessing the external resource pool 114 via the sequence manager 106 (circled number 13). Task execution then continues with the new process sequence, or the task execution is terminated and the associated processing results are forwarded to the task preprocessor 98 (circled number 15).

[0151] As shown in Figure 14, the third sub-scenario (b3) relates to the case where an unexpected error or external event occurs during the execution of a process sequence step, requiring the processing of a new task to deal with this unexpected situation. In the latter scenario (b3), the new task is fed back as an internal task to the task preprocessor 98 for subsequent processing (circled number 14).

[0152] As shown in Figure 14, the third scenario (c) relates to task execution by task delegation (circled numbers 16 and 17). It should be noted that this scenario is only relevant when a process sequence for task execution is not available (see circles 12 and 13).

[0153] 14, in the third scenario, the task preprocessor 98 cooperates with the external resource pool 114 to check the availability of an external delegate resource object 26 that can process the target task (circled number 16). If availability exists, the task preprocessor 98 delegates the processing of the target task to the delegate resource object 26 (circled number 17).

[0154] It is important to understand that, in accordance with the present invention, once a task is delegated, the delegating resource object 26 is no longer involved in processing that task, and ongoing monitoring of task execution of the delegated task is not performed by the delegating resource object 26. Status feedback regarding the delegated task, if necessary, is established via the observation-based feedback loop 62 outlined above with respect to FIG.

[0155] FIG. 15 shows a flowchart of the operation of the task preprocessor 98 with respect to directing task execution through local capabilities / functions, process sequences that provide the required capabilities at run time, or delegating task execution to further resource objects.

[0156] It should be noted that all steps shown in FIG.

[0157] 15, in step S42, the required capacity specification and / or the required resource specification of the target task are sent to the local processing resource manager 102 of the resource object 26 for identification in the form of local capacity / function that matches the selected processing resource. Before the required capacity specification and / or the required resource specification are sent to the local processing resource manager 102, in step S42, the allocation operation mode section AOM and the local release status section LRS are also checked to verify the operating conditions for the execution of step S42.

[0158] As shown in FIG. 15, in step S44, it is checked whether local capabilities / functions having capability specifications and / or resource specifications that match the required capability specifications and / or required resource specifications for the target task are available from the local processing resource manager 102.

[0159] 15, in step S46, if a local capability / function is unavailable for task execution, the current step result section CSR is set to resource busy error. Otherwise, in step S48, the operation of the matching local capability / function is instructed. This instruction in step S48 is subjected to checking of the allocation operation mode section AOM, the local release status section LRS, and the current task result section CTR to verify the operating conditions for the execution of step S48.

[0160] As shown in FIG. 15, if local capabilities / functions are not available in step S50, the current task result section CTR is checked to determine whether to continue task execution by local sequencing if the task has not started, or by task delegation instructions if the task has started.

[0161] 15, task execution continues with local sequence processing, after which, in step S52, the required capacity specification is sent to the sequence manager 106 to identify the selected processing resource in the form of a process sequence that provides the required capacity specification when executed. Here, before the required capacity specification is sent to the sequence manager 106, the allocation operation mode section AOM and the local release status section LRS are checked to verify the operating conditions of step S52.

[0162] 15, step S52 is followed by step S54, where the current step result section CSR is checked to see if a process sequence that will provide the required capability when executed is available. If so, step S56 directs execution of the process sequence that will provide the required capability when executed.

[0163] To verify the operating conditions of the instruction step S56, a check is performed on the global release status section GRS, allocation operating mode section AOM, current step result section CRS, local release status section LRS, and current task result section CTR of the resource object signature 30 before the instruction.

[0164] 15, after checking the current step result section CSR in step S54, if the process sequence is not available, the current task result section CTR is checked in step S58 to check whether the task has started. If the task has started, task execution is not possible. If the task has not started, step S60 is executed to instruct the target task to be delegated for task execution.

[0165] In conclusion, according to the present invention, the direction of task execution through local capabilities / functions, process sequences, or delegation of task execution to other resource objects is dynamically realized at task execution time. The dynamic allocation of processing resources greatly increases the flexibility of task execution, allowing resource objects to maximize autonomous execution configuration in real time in response to task submission.

[0166] FIG. 16 is a more detailed schematic diagram of the local capability / function manager 104 shown in FIG.

[0167] As shown in FIG. 16, the local capability / capability manager 104 includes a local capability / capability repository 116 and a local processing resource controller 118 .

[0168] As shown in FIG. 16, the local capabilities / functions repository 116 provides different access methods and any type of local capabilities / functions.

[0169] Further, operationally, the local processing resource controller 118 is adapted to control the operation of the local capabilities / capabilities repository 116 and to process queries for local capabilities / capabilities.

[0170] 16, the first access is direct access 120 to at least one local capability / function that is statically pre-configured in the resource object 26. Thus, the local capability / function is available at all times during operation, regardless of the operational status of the resource object 26.

[0171] 16, the second access is a direct access 122 to at least one dynamically allocated capability / subfunction. The second direct access 122 is applicable when, during operation of the resource object 26, at least one local capability / function is available only when the resource object 26 enters a particular operational status. Since the operational status of the resource object 26 may change over time, it may be an option to use the dynamically allocated local capability / function only during a particular period of time.

[0172] An example of dynamic allocation of local capabilities / functions may be an AGV robot positioned at a particular location, where the AGV robot is only allowed to load goods while positioned at the particular location, while otherwise the AGV robot transports goods and moves within the modular processing system 10.

[0173] As shown in FIG. 16, yet another option for accessing local capabilities / functions relies on a function assignment 100 that supports differentiated access through logical reference to multiple local capabilities / functions with identical configurations but different technical effects.

[0174] Thus, the capability allocation 100 allows for processing of partial functions of local capabilities / functions to achieve task alignment while hiding the details of the local capabilities / functions from the outside. The capability allocation 100 encapsulates specific knowledge about the relevant local capabilities / functions by using logical names for the partial functions and by using data structures that describe the partial functions and are parameterized by the task at run time. The capability allocation supports unambiguous access to multiple local capabilities / functions with identical configurations but different technical effects in the local capability / function repository 116.

[0175] FIG. 17 shows an example of functional allocation as a means of distinguishing local capabilities / functions that have the same structure but are used to achieve different functional effects.

[0176] As shown in FIG. 17, an example of the use of functional allocation may be a linear cylinder 126 having a piston 128 and a number of valves v_i, v_j, v_k provided to extend and retract the piston 128 within the linear cylinder 126.

[0177] 17, valves v_i and v_j that operationally extend piston 128 have the same function assignment "expand," while valve v_k that contracts (retracts) piston 128 has the function assignment "retract." During execution, a task specifies only the function assignment "expand" or "retract," and the task execution controller 100 resolves the function assignment "expand" to the actual valve v_i or v_j, or to both valves v_i and v_j.

[0178] In conclusion, the operation of the task preprocessor 98 with respect to accepting a task 28 and identifying processing resources available for task execution has been described above with reference to Figures 10 to 17. In the following, with reference to Figures 18 to 30, the description will focus on the control of task execution by the task execution controller 100. It should be noted that such control is performed by the task execution controller 100 shown in Figure 10.

[0179] Generally, the starting point for the operation of the task execution controller 100 is the processing result of the task preprocessor 98. This processing result specifies the type of task execution: local execution, execution by process sequence, or execution by task delegation. The processing result of the task preprocessor 98 also specifies at least one processing resource that can be used by the resource object 26 for task execution.

[0180] Furthermore, if the processing result of the task preprocessor 98 specifies multiple processing resources, the task execution controller 100 is adapted to select at least one processing resource for task execution from the multiple processing resources at the start of task execution. Preferably, the task execution controller 100 is adapted to apply an allocation cost function during selection from the selected multiple processing resources.

[0181] Furthermore, according to the present invention, such a selection at the start of task execution means the selection as late as possible, especially with regard to dynamically available processing resources. A particular advantage of such an approach is that it maximizes the number of processing resources taken into account for task execution, compared to traditional scenarios where the process plan is defined in advance without taking into account knowledge of the on-site and real-time process status.

[0182] 14 relates to the generation of internal tasks triggered by the execution of a process sequence selected for task execution or by a change in the resource object signature 30 due to an external event. In such cases, the task execution controller 100 sends the internal task to the task preprocessor 98 for further processing.

[0183] The following describes the control of task execution by the task execution controller 100, focusing in more detail on task execution through local capabilities / functions, process sequences, and task delegation. The relevant controls are performed by the task execution controller 100 shown in FIG. 10.

[0184] FIG. 18 shows an operational flowchart of task execution by the local capabilities / functions of the task execution controller 100 shown in FIG.

[0185] As shown in FIG. 18, in step S62, if a local capability / function matching the task execution is available, a check is performed on the active current step result section CSR of the resource object signature 30 to check the operational status of the resource object 26 before task execution.

[0186] As shown in FIG. 18, in step S64, the type of local capability / function mapping S64 is identified according to the local capability mapping, the local function mapping, and the type of local capability / function accessible via the function assignment 124, which is used to distinguish between local capabilities / functions that have the same specification but different technical effects when activated as outlined above.

[0187] As outlined above, a function assignment defines a functional association between local capabilities / functions and allows addressing independent of the specific identity of the local capabilities / functions. When a local capability / function is used via a function assignment, all local capabilities / functions that have this function assignment must communicate a resource assignment request by the task 28 to be executed.

[0188] Furthermore, only one local capability / function can be assigned to a task execution, and when multiple local capabilities / functions are to convey the same function assignment, predetermined criteria are applied to the selection of the local capability / function during execution to optimize the selection result.

[0189] 18, proceeding to steps S66, S68, and S70, the execution of the mapped local capabilities / functions is instructed according to the identified type. Thus far, in step S70, the function assignment to a specific matching local capability / function 64 is resolved before task execution.

[0190] 18, in step S72, the task execution result realized by the corresponding local capability / function is checked, and in step S74, when an error occurs, the current step result section CSR of the resource object signature is set to function error.

[0191] In conclusion, task resolution based on local capabilities / functions is the most intuitive approach to task execution. According to the present invention, local capabilities have the unique advantage of allowing for dynamic allocation of local processing resources over time during operation of the modular processing system 10. This provides increased flexibility and reflects changes in the operating status of the modular processing system 10, allowing for optimal allocation of local capabilities / functions at all times.

[0192] FIG. 19 illustrates a process sequence in which each step in the process sequence is assigned a step start condition, a step stop condition, and at least one task definition for a task to be executed as part of the step execution.

[0193] 19, every process sequence 130 has a header 132 that carries information related to the processing of the process sequence 130. A process sequence 130 can be specified via an ID or a name. The name is a local name and is used within the resource object 26 that executes the process sequence 130. Additionally, executing a process sequence 130 provides specific capabilities for task execution that can be used as an external reference to the process sequence 130.

[0194] Generally, before the start of the process sequence 130, a check of the allocation operating mode section AOM, the local release status section LRS, the current step result section CSR, and optionally the internally defined marker section IDM is performed to evaluate the operating conditions for starting the process sequence. The internally defined marker section IDM helps to determine the operating status at which execution of the process sequence 130 may be suspended and / or resumed.

[0195] 19, the process sequence 130 includes at least one step S134 specified by a step start condition SCO 136 and a step end condition FCO 138. The execution of the at least one step S134 also requires the execution of at least one subtask 140 that is redefined according to a required resource specification, a required capacity, and a provisioning parameter set (see 142).

[0196] 19, the execution of step S134 means verifying the step start condition SCO 136, executing the step-related subtask 140, and verifying the step end condition FCO 138. Note that after verifying the step start condition 136SCO, the step-related subtask 140 is processed without reconsidering the step start condition 136. This means that the step-related subtasks 140 can be executed in parallel independently of each other, improving processing efficiency.

[0197] Furthermore, if a fault occurs during the execution of the process sequence 130, the first option for dealing with the fault scenario is to issue an error message. The second option is to identify an alternative process sequence that can deal with the fault scenario. After resolving the fault constellation, the interrupted process sequence can be continued using the internally defined marker section IDM.

[0198] Overall, the execution of a process sequence 130 implies access to at least the local capabilities / functions of the resource object 26 executing the process sequence 130 .

[0199] Here, when multiple local capabilities / functions are used to execute a process sequence, the definition of the process sequence 130 allows for orchestration of the operations of the multiple local capabilities / functions, thus providing an expanded capability relative to the single capability of each individual local function / capability in the multiple local capabilities / functions.

[0200] Furthermore, if a process sequence 130 contains only one step that uses only one subtask 140 step, this is equivalent to using a local capability / function. However, it is still possible to specify step start conditions SCO 136 and step end conditions FCO 138 for the operation of the local capability / function.

[0201] FIG. 20 shows a more detailed overview of the sequence manager 106 shown in FIG.

[0202] As shown in FIG. 20, the sequence manager 106 includes a sequence repository 144, a sequence repository controller 146, and a sequence preprocessor 148.

[0203] Operationally, the sequence repository 144 is adapted to store at least one process sequence 130 that, when executed, provides a predetermined capability.

[0204] Here, all process sequences registered in the sequence repository 144 are named similarly to the required capabilities and are marked with the currently assigned operating mode (AOM or Empty), the current local release status (CRS or Empty), an internally defined marker (IDM or Empty), and the current step result (CSR or Empty). This marking supports pre-execution processing of process sequences.

[0205] Furthermore, according to the present invention, for every registered capability / function registered in the local capability / function repository 116 shown in FIG. 16, a corresponding process sequence should be registered in the sequence repository 144, because otherwise it is not known under what conditions the local capability / function can be used.

[0206] Further, operatively, the sequence repository controller 146 is adapted to search the process sequence repository 144 in response to transmission of the required capability specification to the sequence manager 106. If a search of the process sequences 130 reveals multiple process sequences that provide the same required capability, the sequence repository controller 146 is adapted to select a final process sequence for propagation through application of a selection cost function that optimizes the search results.

[0207] The sequence repository controller 146 is also adapted to continuously register / deregister process sequences 130 with the sequence repository 144 depending on the operational status of the resource object 26 executing the sequence manager 106 and the availability of the process sequences.

[0208] Additionally, the sequence pre-processor 148 is operatively adapted to pre-process the process sequence 130 .

[0209] Here, the first pre-processing involves identifying at least one local capability / capability available from the local capability / capability manager 104 that is involved in the execution of the process sequence.

[0210] The second preprocessing step concerns the impact of local capacity availability on the execution of process sequences. Because local capacity availability changes over time, a particular process sequence may be executable at one time but not at another, depending on the availability of local capacity.

[0211] The third pre-processing relates to handling information related to the process sequence 130, such as versioning, ID and name handling.

[0212] The use of sequence manager 106 increases the operational flexibility of resource object 26. Sequence manager 106 supports real-time, autonomous configuration within resource object 26 in response to processing requirements obtained by submitting tasks 28 to resource object 26. Additionally, through access to external resource pool 114, sequence manager 106 allows for the continuous expansion of capability provisioning options within resource object 26.

[0213] FIG. 21 is a flowchart showing the operation of the sequence manager 106 shown in FIG.

[0214] As shown in Figure 21, during operation of the sequence manager, it continuously switches between managing the availability of process sequences and searching for process sequences.

[0215] As shown in FIG. 21 , in step S76, when an action is performed by the sequence repository controller 146, three options are checked for the management of process sequences by the sequence manager 106: (a) registering a new process sequence, (b) updating the availability of a process sequence currently registered in the sequence repository, and (c) deregistering a process sequence from the sequence repository 144.

[0216] 21, in registering a new process sequence according to option (a), the sequence preprocessor 148 performs a series of steps before registering the new process sequence in the sequence repository 144 via the sequence repository controller 146. For example, the process sequence to be registered may be provided from a process sequence pool operated external to the resource objects 26. Alternatively, the process sequence to be registered with the sequence manager 106 may be provided from a process sequence design system operated external to the resource objects 26.

[0217] 21, in step S80, operations are performed by the sequence preprocessor 148 to resolve at least one requirement specification referenced by at least one process sequence step to at least one matching local processing resource available from the local capability / capability manager 104 of the resource object 26. Here, the local capabilities are marked as dynamic to indicate that the availability of the local capabilities must be checked before the process sequence is executed, while the local functions are marked as static and therefore can be directly assigned to the process sequence.

[0218] 21, in step S80, when the sequence preprocessor 148 performs its operation, if all matching local capabilities / functions involved in the execution of the process sequence are available at the time of preprocessing the sequence, the process sequence is marked as available. Otherwise, if at least the local capabilities / functions to execute are not available at the time of preprocessing the sequence, the process sequence is marked as unavailable.

[0219] It should be noted that the marking of the process sequence is performed in real time at the start of the process sequence execution, i.e. as late as possible, thereby maximizing the amount of process sequence resources available for task execution, since temporary unavailability of the process sequence before task execution is simply irrelevant.

[0220] For example, the reason for checking the availability of matching local capabilities / functions is that local capabilities are not continuously available, but only available for certain periods of time. For example, an AGV robot moving towards and from a loading station can only be loaded if it is positioned at the loading station. This means that sequences that depend on local capabilities for their execution, such as a process sequence for loading products onto an AGV robot, are also limited in their feasibility by the availability of local capabilities. Furthermore, even local capabilities can be unavailable, for example, due to a malfunction in their operation.

[0221] 21, in step S82, when the sequence preprocessor 148 is operating, further checks are made on the information about the process sequence being registered, such as checks related to the identity of the version of the process sequence and checks related to at least one process sequence step.

[0222] As shown in FIG. 21, in step S84, the sequence preprocessor 148 performs the same operation as in step S80 for option (b) of updating the availability of process sequences currently registered in the sequence repository 144.

[0223] As shown in FIG. 21, in step S86, the sequence repository controller 146 executes the operation for option (c) of deregistering the process sequence, and the process sequence is deleted from the sequence repository 144.

[0224] As shown in FIG. 21, following the management of process sequence availability, the operation switches to searching for process sequences.

[0225] 21, in step S88, when action is taken by the sequence repository controller 146, it is checked whether a search request has been sent to the sequence manager 106. If not, action returns to managing the availability of the process sequence.

[0226] 21, when a search request is sent to the sequence manager 106, in step S90, action is taken by the sequence repository controller 146 to perform a search of the sequence repository 144. If the search reveals multiple process sequences, the sequence repository controller 146 applies a selection cost function to optimize the search results.

[0227] As shown in FIG. 21, in step S92, once action has been taken by the sequence repository controller 146, the search results are communicated to the entity that sent the search request before returning to managing the availability of the process sequence.

[0228] FIG. 22 illustrates the association of task specifications with signature sections for task approval, initiation of process sequence execution, and initiation of process sequence step execution.

[0229] As shown in Figure 22, the execution of a process sequence requires checking the signature section and task specifications at different behavioral levels.

[0230] As shown in Figure 22, the first such level is the task level, where the required resource specification and the required capacity expected during the execution of a process sequence are checked for each execution of the task-related process sequence. This is because a process sequence is specified to provide capacity during its execution, so conformance with the required capacity is checked only at the start of the execution of the process sequence.

[0231] Also, the examination of required resource specifications at the task level is optional, but not mandatory, in that the instructions in the required resource specification allow the execution of a process sequence to be bound to specific processing resources, if deemed appropriate.

[0232] As shown in Figure 22, the research object signature 30 also has sections that are checked only once at the sequence level: the global release status section GRS, the local release status section LRS, and the functional safety status section SAF.

[0233] 22, the object resource sections GRS, LRS, and SAF are inherited by each step of the process sequence and are re-examined at the start of execution of each step. However, the sequence-related sections GRS, LRS, and SAF are not re-examined when at least one subtask 140 of each step is processed. This allows for parallel processing of subtasks when multiple subtasks 140 are processed.

[0234] 22, the step-related signature sections of the resource object signature 30 are a step entry condition status section SCO and a step exit condition status section FCO. Optionally, a sequence processing mode section DBG of the resource object signature 30 may be considered to specify a continuation mode for the execution of the process sequence and / or a debug processing mode for executing and debugging different steps of the process sequence.

[0235] Furthermore, the step entry condition status section SCO and the step exit condition status section FCO are considered only once at the beginning and end of step execution, but these sections are not reconsidered during subtask execution for individual subtasks 140 within a step, thereby ensuring the independence of subtask execution and supporting parallel execution when executing multiple subtasks 140.

[0236] FIG. 23 shows a more detailed overview of the sequence execution controller 108 shown in FIG.

[0237] Although the operation of the sequence execution controller 108 is described below with respect to the execution of a process sequence, the sequence execution controller 108 is also adapted to cascade multiple partial process sequences to provide a capability that matches a required capability during the cascading of partial process sequences.

[0238] Additionally, as outlined above, the resource object signature 30 may include an internally defined marker IDM that represents an operational status observed as a condition for re-entering process sequence execution during execution of cascaded partial process sequences or as a condition for transitioning from a first partial process sequence to a second partial process sequence.

[0239] As shown in FIG. 23, the sequence execution controller 108 includes a sequence setup controller 150, a sequence controller 152, a step controller 154, and a step execution unit 156.

[0240] The sequence setup controller 150 is operatively adapted to check the availability of a process sequence for task execution and also to check operational conditions that must be satisfied before the process sequence execution can begin.

[0241] Additionally, the sequence controller 152 is operatively adapted to control the execution of the process sequences as they become available for task execution.

[0242] Additionally, the step controller 154 is operatively adapted to control the execution of all steps specified in the process sequence and to continuously check the operating conditions associated with the execution of all steps.

[0243] Additionally, the step executor 156 is operatively adapted to handle the execution of the step-related subtasks 140 .

[0244] Fig. 24 shows a flowchart of the operation of the sequence setup controller shown in Fig. 23. All steps shown in Fig. 25 are executed by the sequence setup controller 150 shown in Fig. 23.

[0245] 24, step S94 is performed to obtain a process sequence that meets the required capacity through access to an external resource pool 114 operated outside of the sequence manager 106 or resource object 26. A check is also performed on the global release status GRS, the allocated operating mode AOM, the current step result CSR, and the local release status LRS to check that the operating status within the modular processing system 10 is appropriate for initiating process sequence execution.

[0246] 24, in step S96, it is checked whether a process sequence matching the required capabilities is available. If not, step S98 is subsequently executed to set the current step result section CSR of the resource object signature 30 to sequence error not found. Otherwise, step S100 is executed to set the current task result section CTR of the resource object signature 30 to task started, and if a matching process sequence is successfully provided, step S102 is executed to set the current step result section CSR to valid.

[0247] Fig. 25 is a flowchart showing the operation of the sequence controller shown in Fig. 23. All steps shown in Fig. 25 are executed by the sequence controller 152 shown in Fig. 23.

[0248] As shown in FIG. 25, the sequence controller 152 is adapted to repeat the execution of the steps of the process sequence by executing a repetitive control sequence of obtaining the next step of the process sequence that matches the required capacity (S104), instructing the execution of the next step (S106), and evaluating the execution result of the next step (S108) (S110).

[0249] 25, step S104 for obtaining the next step in the process sequence to be executed requires evaluation of the current step result section CSR of the resource object signature 30. Also, before issuing an instruction to execute the next step in step S106, the global release section GRS, the allocation operation mode section AOM, the current step result section CSR, and the local release status section LRS of the resource object signature must be checked to verify the operation status before executing the step.

[0250] 25, after the next step is executed, step S108S108 is executed to check the current step result section CSR of the resource object signature 30 and evaluate the execution result of the next step. Here, if the current step result section CSR remains valid for the continuation of the process sequence execution, the sequence setup controller 150 continues the operation of obtaining the next process sequence that matches the change in the current step result section CSR.

[0251] As shown in FIG. 25, if the current step result section CSR has not changed after the next step is executed, step S110 is executed to check the end of the control sequence iteration.

[0252] Fig. 26 shows an operation flowchart of the step controller 154 shown in Fig. 23. All steps shown in Fig. 26 are executed by the step controller 154 shown in Fig. 23.

[0253] 26, the step controller 154 controls step execution for a processing sequence that matches the required capabilities. This is achieved by a series of control steps: checking at least one step execution start condition in step S112, checking the current step result section CSR of the resource object signature 30 in step S114, instructing step execution in step S116, and checking at least one step end condition in step S118.

[0254] Generally, as illustrated in Figure 19, each step is assigned a step task list that lists at least one subtask 140 to be processed for step execution. Here, at least one task specification specifies a required capacity specification and / or a required resource specification, and optionally a parameter set. Then, in step S122, a check is performed to determine whether at least one step execution start condition of the step satisfies a task execution release condition for at least one subtask 140 listed in the step task list.

[0255] More specifically, before releasing task execution of at least one subtask 140 listed in the step task list, in step S112 it is checked whether the global release status section GRS of the resource object signature 30 matches the requested global release status, whether the local release status section LRS of the resource object signature 30 matches the requested local release status, and whether the functional safety status section SAF of the resource object signature 30 matches the requested functional safety status. As outlined above with respect to Figure 22, the resource object sections GRS, LSR and SAF are specified at the sequence level and are re-examined during the execution of each step of the process sequence.

[0256] Furthermore, before the task execution of at least one subtask 140 listed in the step task list is released, in step S112, it is checked whether the step start condition section SCO of the resource object signature 30 meets the conditions required for the start of step execution, which are specified at the step level and are therefore step-specific.

[0257] As shown in FIG. 26, after at least one step execution start condition is checked in step S112, if the current step result section CSR of the resource object signature 30 is set to invalid, step execution S114 is stopped.

[0258] Otherwise, in step S116, execution of step subtask 140 is instructed, followed by checking whether the step termination condition status section FCO matches the step execution termination condition. If so, step execution ends normally. Otherwise, processing of the step-related subtask continues at step S114.

[0259] Fig. 27 shows a more detailed flowchart of the step execution start condition check operation by the step controller shown in Fig. 23. All steps shown in Fig. 27 are executed by the step controller 154 shown in Fig. 23.

[0260] As shown in FIG. 27, in step S120, the operational status of the local processing resources of the resource object 26 that is executing the step is checked.

[0261] Here, if the current step result section CSR of the resource object signature 30 indicates that all local processing resources involved in the execution of the step are not available, the step processing is terminated as an error case.

[0262] Furthermore, if the current step result section CSR of the resource object signature 30 indicates that the step execution is not yet released, the step S120 of checking the operational status of the local processing resources is repeated.

[0263] Furthermore, if the current step result section CSR indicates release of step execution, the process proceeds to step S124, where the step start condition status section SCO of the resource object signature 30 is checked.

[0264] 27, if the result of step S124 is that the step start condition is not satisfied, step S120 of checking the operation status of the local processing resource is repeated. Otherwise, the process proceeds to step S126, where the interactive processing mode section DBG of the resource object signature 30 is examined for execution of the process sequence step in interactive mode. In that case, the process proceeds to step S128, where the interactive processing mode in interactive mode is released, after which step S120 is repeated to check the status of the local processing resource.

[0265] As shown in FIG. 27, if all step execution start conditions are met, step S130 is executed to set the current step result section of the resource object signature 30 to step start.

[0266] Figure 28 shows a flowchart of the operation of checking the status of at least one local processing resource according to step S120 shown in Figure 27. All steps shown in Figure 28 are performed by the step controller 154 shown in Figure 23.

[0267] 28, in step S132, the current step result section CSR of the resource object signature 30 is accessed to check for any step errors. If a step error exists, the checking of at least one local processing resource condition stops with an error.

[0268] 28, if there is no step error, in step S134, the allocation operation mode AOM of the resource object signature 30 is accessed to check that the allocation operation mode AOM does not require an immediate stop of the process sequence step. If an immediate stop is required, step S136 is executed to set the current step result section CSR of the resource object signature 30 to step external interrupt.

[0269] 28, if there is no step external interrupt, step S138 checks whether the status section LSR of the resource object signature 30 is valid. If not valid, step S140 is executed to set the current step result section CSR of the resource object signature 30 to step local stop.

[0270] As shown in Figure 28, if there is no step local stop, then execution mode is entered. Step S142 is then executed to check whether the functional safety requirements are met by accessing the functional safety section SAF of the resource object signature 30. If there is no release, then processing branches to step S134, where it is checked whether the immediate stop mode is enabled. Otherwise, step S144 is executed to set the current step result section CSR of the resource object signature 30 to step execution release, indicating that at least one local processing resource condition has been checked successfully.

[0271] Fig. 29 shows a flowchart of the operation relating to task execution in accordance with step S116 shown in Fig. 26. All steps shown in Fig. 29 are executed by step execution unit 156 shown in Fig. 23.

[0272] As shown in Figure 29, execution of a process sequence step requires task execution for all tasks 140 listed in the task list. First, a first step task is identified in step S144. During further task execution, a next step task is identified in step S148. Step S150 is then executed to check whether a next step is available. If a next step is available, execution of the step task continues; otherwise, execution of the step task ends.

[0273] 29, after the first or next step task has been identified, step S152 is executed to send the first or next step task to task processor 42 for execution through the associated local capability / function. In accordance with the present invention, no start or end conditions are imposed on the execution of step task 140, thereby avoiding continuous monitoring during the execution of different tasks.

[0274] As shown in FIG. 29, in step S152, a check is also performed whether the allocation operation mode section AOM of the resource object signature 30 matches the requested allocation operation mode, whether the current task result section CTR of the resource object signature 30 indicates task start, and whether the current step result section CSR of the resource object signature 30 indicates step execution release.

[0275] 29, in step S154, it is checked whether the current step result section CSR of the resource object signature 30 indicates a task execution error after the execution of each step task 140. If there is a task execution error, the step task execution ends, otherwise the step task execution proceeds to the next step task identification step S148.

[0276] Fig. 30 shows a flowchart of the operation relating to checking the step end condition FCO in accordance with step S118 shown in Fig. 26. All steps shown in Fig. 30 are executed by the step controller 154 shown in Fig. 23.

[0277] As shown in Figure 30, to evaluate the success of the step execution, step S156 is performed to access the local release status section LSR of the resource object signature 30 to check whether at least one local processing resource condition is satisfied, step S158 is performed to check whether the current step result section CSR of the resource object signature 30 is set to release, and step S160 is performed to check whether at least one step-related termination condition FCO is satisfied.

[0278] As shown in Figure 30, if the current step result section CSR of the resource object signature 30 is not set to release or if the step related termination condition FCO is not satisfied, step S156 of checking whether at least one local processing resource condition is satisfied is repeated.

[0279] 30, if at least one step-related exit condition FCO is set to error, step S162 is executed to set the current step result section CSR of the resource object signature 30 to step error. Otherwise, if the step-related exit condition FCO is satisfied, step S164 is executed to set the current step result section CSR of the resource object signature 30 to step end.

[0280] FIG. 31 shows a more detailed overview of the pose manager 112 shown in FIG.

[0281] Generally, the pause manager 112 is adapted to set a named internally defined marker section IDM of the resource object signature 30 when the observation instance group 82 observes a predetermined pattern of observation size 34 .

[0282] As shown in FIG. 31, the pause manager includes an observation processor 158 and a pause processor 160 .

[0283] The observation processor 158 is operatively adapted to evaluate the observations of the observation instance group 82 .

[0284] The pause processor 160 is operatively adapted to check a match of the evaluated observation with respect to at least one named internally defined marker section IDM and to set the named internally defined marker section IDM if an associated internally defined marker pattern is observed.

[0285] FIG. 32 shows a flowchart of the operation of the pause manager 112 shown in FIG.

[0286] As shown in FIG. 32, operations performed by the observation processor 158 in step S168 include evaluating the observations of the observation instance group 82.

[0287] 32, the pause processor 160 performs an operation in step S170 to check whether the evaluated observation matches at least one named internally defined marker section IDM, where a match means that the observation provided by the observation instance group 82 matches a predetermined pattern, requested observation, or observation evaluation. If a match does not occur, the operation returns to step S168 to continue evaluating the observations.

[0288] Otherwise, as shown in Figure 32, action is taken by the pause processor 160 in step S172 to set the named internally defined marker IDM and operation returns to step S168 to continue observation evaluation.

[0289] Here, multiple named internally defined markers IDM may be set at any time, and all defined named internally defined markers IDM form a one-dimensional vector that forms the internally defined marker section IDM of resource object signature 30.

[0290] FIG. 33 shows an example of how a resource object signature 30 drives process sequence execution, for example, determining acceptance of sequence execution, initiation of sequence execution, and processing of process sequence steps and associated step tasks.

[0291] As shown in Figure 33, execution of a process sequence requires verification of global and local processing conditions, including resource object signatures 30, which change continuously during operation of the modular processing system 10. Other conditions include required functional safety status 164 and required process sequence signatures 166.

[0292] As shown in Figure 33, before execution of a process sequence begins, a match 168 between the actual functional safety status 170 and the requested functional safety status 164 is required. If both are set to *, operation continues. In the example shown in Figure 33, such a constellation is assumed to be always valid in the following:

[0293] 33, before process sequence execution can begin, there must be a match 172 between the resource object signature 30 and the requested process sequence signature 166. This is because the resource object signature 30 matches the patterns △△ and OO specified in the requested process sequence signature 168. +(The second letter O + means that the task must show a cross with a circle, in which case the process sequence execution will be started in relation to the task.

[0294] 33, the start of a process sequence step does not necessarily mean the start of execution of the associated step task 140. The reason is that before the next step can begin, the associated step start condition status section SCO of the resource object signature 30 must be checked 174. Here, first, the up arrow ↑ does not match →, so the execution of the step task 140 is delayed.

[0295] However, the step start condition status section SCO of the resource object signature 30 may change (see 176), for example, through an external event occurring outside the resource object 26, or an internal event occurring within the resource object 26. Then, when ↑ changes to → 178, execution of the step task begins 180.

[0296] 33, a recheck 182 of the step start condition status section SCO 182 indicates that the requested step start condition status → and the associated entry → in the step start condition status section SCO match the resource object signature 30, so execution of the step task continues. However, execution of such a step task may result in other sections in the resource object signature changing 184 from / to □ to / / .

[0297] As shown in Figure 33, during the execution of a process sequence step, the comparison 172 between the request sequence signature 166 and the resource object signature 30 is not repeated. This means that the step task is executed unconditionally and only the re-evaluation of the start condition of the process sequence step is conditional. This concept is used to support the independent execution of all step tasks.

[0298] 33, during the execution of different step tasks 140, the entry in the step end condition status section FCO also changes 186, for example, from ↓ to ↑ to ←. Finally, when the entry in the step end condition status section FCO matches the requested step end condition status →←, the processing of the process sequence step ends 188.

[0299] As shown in Figure 33, the status of the resource object signature 30 at the end of a process sequence step forms the basis for the execution of the next step in the process sequence. Here too, the functional safety status SAF of the resource object signature 30 and the section specifying the required process sequence execution conditions are evaluated before considering the step entry condition status SCO specified for the next step to ensure operational safety 190.

[0300] FIG. 34 illustrates the interoperation of the resource objects shown in FIG. 13 with a processing resource pool 192 that provides pooled process sequences and / or pooled processing resource objects 196 as task delegates when an associated search request is submitted.

[0301] As shown in Figure 34, the task delegation controller 110 shown in Figure 13 includes a pool search controller 208 and a task delegation executor 210. Details of the operation of these functional units are described below with reference to Figure 37.

[0302] 34, the processing resource pool 192 operates independently and external to the resource objects 26. This makes it possible to extend the reservoir of available process sequences and to provide a pool of resource objects to which task execution can be delegated. The use of the processing resource pool 192 therefore forms the basis for increased flexibility during the operation of the resource objects 26.

[0303] Here, the interoperation between the processing sequence pool 194 and the local processing resources 26 is associated with the release of process sequence execution and / or the release of task delegation.

[0304] To release a process sequence execution, the task processor 42 may access the sequence pool 194 directly or indirectly via the sequence manager 106 before releasing the process sequence execution.

[0305] Additionally, new process sequences from the sequence pool 194 can be uploaded to the sequence manager 106 as they become available, regardless of the ongoing release of process sequence executions. This allows for a continuous update of the reservoir of available process sequences in the sequence manager 106.

[0306] To release the task delegation, the task processor 42 may access the task processor 42. More specifically, the task processor 42 directly accesses the resource object pool 196 to see which additional resource objects 26, outside of the operating resource objects 26, are ready to take over handling of the task execution process.

[0307] FIG. 35 shows a schematic diagram of the processing resource pool shown in FIG.

[0308] Generally, the processing resource pool 192 operates in conjunction with the resource objects 26 to provide access to at least one processing resource that may be used by the resource objects for task execution during operation of the modular processing system 10. Such a processing resource may be a process sequence or a delegation of a further resource object for task execution.

[0309] 35, the processing resource pool 192 includes a processing resource registry 198 and a resource pool manager 200. The resource pool manager 200 includes a resource registration controller 202, a resource allocation controller 204, and a capacity controller 206.

[0310] The processing resource registry 198 is operatively adapted to register at least one processing resource according to at least one registration criterion that characterizes the at least one processing resource.

[0311] Furthermore, the resource registration controller 202 of the resource pool manager 200 is operatively adapted to control the registration and deregistration of processing resources in the processing resource registry 198. This may be done statically per description (subscribe) or dynamically per execution of a process sequence step.

[0312] Additionally, the resource allocation controller 204 of the resource pool manager 200 is operatively adapted to pool multiple search requests, handle the reservation of processing resources, perform criteria-based searches, apply selection optimization during searches through application of a selection cost function, perform advance reservation of processing resources, and / or release processing resources after use.

[0313] Furthermore, the capacity controller 206 of the resource pool manager 200 is operatively adapted to control the allocation of registered processing resources to the resource objects 26 that have sent the search requests. In general, capacity management refers to managing the availability of processing resources. Capacity groups may be used, where allocation of one processing resource in the group automatically allocates the remaining processing resources in the group.

[0314] It should be noted that the capacity controller 206 is adapted for virtual capacity management, supporting advance reservation of processing resources over a period of time. Another application area is simulation of processing resource allocation or pooling for processing resource allocation optimization.

[0315] FIG. 36 is a flowchart showing the operation of the resource processing pool shown in FIG.

[0316] As shown in FIG. 36, while the processing resource pool 192 is in operation, the processing switches continuously between registration processing and search processing.

[0317] 36, in step S174, when an operation is performed by the resource registration controller 202, an inquiry is made as to whether to update the processing resource registry 198. If an update is required, in step S176, the update is performed by the resource registration controller 202 and the processing resource registry 198 is updated accordingly.

[0318] According to a first registration option, at least one processing sequence may be registered in the sequence pool 194 of the processing resource pool 192. The processing sequence is registered in combination with at least one criterion characterizing the at least one processing sequence, such as a predetermined capability specification that is provided when the at least one process sequence is executed. Typically, the at least one registered process sequence executes a part of a process plan configured for the modular processing system. However, the process sequence may also be executable independently of the process plan.

[0319] Furthermore, according to a second option of registration, at least one resource object in the resource object pool 196 is adapted to register at least one resource object 26 as a registered processing resource in the resource object pool 196. The at least one resource object 26 is registered in combination with at least one criterion characterizing the at least one resource object, for example, a capability specification and / or a predetermined resource specification of the at least one resource object or that the at least one registered resource object accepts task delegation.

[0320] Furthermore, another criterion may be a functional allocation that characterizes several resource objects that have the same predetermined capacity specifications and achieve different technical effects during their operation.

[0321] Furthermore, registration of processing resources may be performed statically through the use of a subscription mechanism, or may be performed in a dynamic manner by registering and deregistering processing resources with the processing resource registry 198 to reflect the availability of processing resources over time depending on the operational status of the modular processing system 10.

[0322] Additionally, at least one registered processing resource may be registered in association with operational constraints that must be used within modular processing system 10 before the registered processing resource can be used to perform a task.

[0323] As shown in FIG. 36, if no registry update is required, step S180 is executed by the resource allocation controller 204 to check whether the processing resource registry 198 is to be searched.

[0324] If the processing resource registry 198 is to be searched, processing proceeds to step S182, where the processing resource registry 198 is searched by the resource allocation controller 204. Otherwise, processing returns to step S174, where it is checked whether the processing resource registry needs to be updated.

[0325] As shown in FIG. 36, in step S184, the resource allocation controller 204 performs optimization of processing resource allocation based on the search results obtained in step S182.

[0326] Here, optimization may relate to process resource specific criteria such as execution time for processing resource usage, processing cost for processing resource usage, as well as associated availability, reliability, and / or configurability, selection considering multiple search requests, and overall picture evolution.

[0327] Additionally, the present invention allows for pooling of multiple search requests prior to searching the processing resource registry 198. Also, registered processing resources may be reserved prior to their allocation.

[0328] As shown in Figure 36, in step S186, at least one processing resource is allocated from the optimized processing resource allocation by the resource allocation controller 206 and the associated entry in the processing resource registry 198 is marked accordingly.

[0329] As shown in FIG. 36, in step S188, the capacity controller 206 updates the available processing resources and associated processing capacities.

[0330] Furthermore, the capacity controller 206 is adapted to manage the virtual allocation of processing resources registered in the processing resource registry 198 to support processing resource reservation, processing resource allocation simulation, and / or processing resource pooling during optimization or processing resource allocation.

[0331] FIG. 37 shows a flowchart of the operation of the task delegation controller 110 shown in FIG.

[0332] Generally, for task delegation from a delegating resource object 26 to a delegatee resource object 26, the delegatee resource object 26 is available from the resource object pool 194 of the processing resource pool.

[0333] As shown in FIG. 34 above, to handle task delegation, the task delegation controller 110 shown in FIG. 13 comprises a pool search controller 208 and a task delegation executor 210.

[0334] The pool search controller 208 is operatively adapted to perform the following steps.

[0335] 37, in step S190, a pooled resource object search request is sent to resource object pool 194 to retrieve pooled resource objects that match the search request, where the search request includes a desired resource specification and, optionally, a desired resource capability.

[0336] As shown in Figure 37, in step S192, it is checked whether a pooled resource object is available for task delegation. If not, in step S194, if a pooled resource object with a resource specification that matches the requested resource specification is not available, the current step result section CSR of the resource object signature 30 is set to step error.

[0337] The task delegation executive 210 is operatively adapted to perform the following steps.

[0338] As shown in FIG. 37, in step S196, the current task result section CTR of the resource object signature 30 is set to the task that will be started if a pooled process resource that matches the search request is available.

[0339] 37, in step S198, task processing is delegated to the matching resource object searched for task delegation, and in step S200, the current step result section CSR of the delegating resource object is set to external result. Here, evaluating the resource occupancy status of the resource object when delegating the task is an option to ensure its operability.

[0340] According to the present invention, the above task delegation is always performed at the latest possible point in time, thereby ensuring that the operational status is taken into account at the actual time of task delegation, and not at a point independent of the task delegation process.

[0341] Also, a resource object may be blocked before task delegation is considered, but at the time of task delegation the associated blocking condition may be lifted and the previously blocked resource object may again become available for task delegation. Thus, delaying task delegation as long as possible increases the pool of resource objects available for task delegation.

[0342] Another question is how it is possible to directly specify the capabilities of a resource object that is searched for task delegation. So far, the present invention allows for the use of wildcards in capabilities or for specifying task delegation based on a condition or set of conditions.

[0343] FIG. 38 illustrates interoperability options between resource objects and associated resource object pools.

[0344] As shown in FIG. 38, no hierarchy is imposed on the interoperability between resource objects 26 and their associated resource object pools 192.

[0345] As shown in Figure 38, the first option for interoperability is for resource object 23-1 to access 212 its own processing resource pool 192-1.

[0346] As shown in Figure 38, a second option for interoperability is for the resource object 23-2 to access 214 the processing resource pool 192-1 in which it is registered.

[0347] As shown in Figure 38, a third interoperability option is for resource object 23-1 to access 216 the processing resource pool 192-2 of resource object 23-2 that is registered with its own processing resource pool 192-1.

[0348] 38, for practical reasons, there are no further references between resource objects 23 and processing resource pool 192. For example, resource object 23-1 may not have access to processing resource pool 192-3, and resource object 23-3 may not have access to either resource object 23-1 or processing resource pool 192-1.

[0349] Although the present invention has been described with reference to the drawings, it is apparent that the present invention can be implemented with modifications and variations that can be readily implemented by those skilled in the art without departing from the scope and spirit of the present invention. For example, the functions described above can be realized by software, hardware, or a combination thereof.

[0350] Accordingly, the claims appended hereto are not intended to be limited to the description set forth herein, but rather the claims should be construed to encompass all features of novelty presently contained in the present invention and all features that would be treated as equivalents thereof by those skilled in the art to which the invention pertains.

Claims

1. 1. A method of operating resource objects (26) within a modular processing system (10) for the execution of at least one task (28) supporting operation of the modular processing system, wherein each task (28) is defined by a required capability specification representing functionality expected for task execution and / or a required resource specification representing at least one processing resource expected for task execution, and wherein a resource object signature (30) represents an operational status used within the modular processing system (10) external to and / or locally to the resource object (26) over time, the method comprising: a step (S20) of checking whether at least one selected processing resource available to the resource object (26) has a capability specification that matches the required capability specification of the task and / or a resource specification that matches the required resource specification of the task; a step (S20) of checking whether at least one operational status (GRS, LRS) represented by said resource object signature (30) matches a required operational status that must be used as a release condition for task execution through the resource object (26); Releasing task execution for the target task if at least one selected processing resource having a matching capability specification and / or resource specification is available and matches the requested operation status (S22); and (S24) controlling task execution by at least one selected processing resource while observing said resource object signature (30).

2. 10. The method of claim 1, wherein the modular processing system (10) is a production system, and the method is performed for control of the production system and with respect to at least one of the tasks (28) from a process plan specified for the production system.

3. 2. The method of claim 1, further comprising the step of: tracking (S14) an operational status being performed in the modular processing system (10) by observing at least one observable size (34) in the modular processing system (10).

4. 2. The method of claim 1, wherein the step of controlling task execution (S24) is performed for an external task sent from outside the resource object (26) or for an internal task generated internally in the resource object (26) during task execution or due to a change in a resource object signature (30).

5. 2. The method of claim 1, wherein the resource object signature includes a global release section that represents a global status used outside the resource object, and further comprising the step of checking whether the global release section matches a requested operation status specified for the resource object before releasing task execution.

6. 2. The method of claim 1, wherein the resource object signature (30) includes a current task result section (CTR) representing a result of task execution or a task idle status of a resource object, and the method includes a step (S28) of setting the current task result section (CTR) to task idle in response to successful task execution.

7. 2. The method of claim 1, wherein the resource object signature (30) includes a local release section (LRS) that represents a local status used within the resource object (26) and that must match a required local status specified for the resource object (26) as a release condition for task execution, and the method includes a step (S38) of checking whether the local release status (LRS) matches the predetermined required local release status specified for the task execution before releasing the task execution.

8. 2. The method of claim 1, wherein the resource object signature includes a safety section (SAF) that represents at least one safety-related condition for release of task execution, and the method includes checking whether an observed operating mode conforms to the assigned safety section (SAF) before release of task execution.

9. 2. The method of claim 1, wherein the step of controlling task execution (S24) comprises selecting, at the start of task execution, at least one processing resource for task execution from a plurality of processing resources that meet a capability specification and / or that meet a resource specification.

10. At least one pooled resource object is available for task delegation through access to a processing resource pool (192, 194, 196, 198), each pooled resource object being assigned in a resource specification, and task delegation is performing a step (S190) of sending a pooled resource object lookup request to the processing resource pool (192) and, in response to said sending, obtaining pooled resource objects that match said lookup request; and performing a step (S198) of observing the resource object signature (30) and delegating execution of a task to a retrieved resource object.

11. A resource object (26) operates in a modular processing system (10) to perform at least one task (28) to support the operation of the modular processing system, each task (28) being defined by a required capability specification representing a capability expected for task execution and / or a required resource specification representing at least one processing resource expected for task execution, the resource object (26) continuously referencing a resource object signature (30) representing operational status occurring within the modular processing system (10) over time external to and / or locally to the resource object (26), the resource object comprising: a task preprocessor (98) configured to release task execution for a task, at least one selected processing resource available to the resource object (26) has a capability specification that matches the required capability specification of the task and / or a resource specification that matches the required resource specification of the task; a task preprocessor that takes into account, for said release, if at least one operational status (GRS, LRS) represented by said resource object signature (30) matches a required operational status that must be used as a release condition for task execution through said resource object (26); a task execution controller (100) adapted to control task execution by said selected at least one processing resource while observing said resource object signature (30).

12. 12. A processing resource pool (192) operative in conjunction with a resource object (26) of claim 11 to provide access to at least one processing resource that may be used by the resource object for task execution during operation of a modular processing system (10), said processing resource pool comprising: a processing resource registry (198) adapted to register (S176) at least one processing resource according to at least one registration criterion characterizing said at least one processing resource; a resource pool manager (200) including a resource allocation controller (204), said resource allocation controller comprising: In response to receiving a search request specifying at least one search criterion, searching (S182) the processing resource registry (198) and checking whether at least one registration criterion of at least one registered processing resource registered in the processing resource registry (198) matches the at least one search criterion to generate search results; If the search results list multiple registration processing resources, applying a search optimization function to optimize the search results (S184), wherein the search optimization function evaluates at least one search-related characteristic of the registration processing resources listed in the search results to identify at least one preferred registration processing resource from the search results and for associated updating of the search results; and assigning (S186) each registered processing resource listed in the search result to an allocated resource object for subsequent use through the allocated resource object.

13. 13. The processing resource pool of claim 12, wherein the resource pool manager comprises a capacity controller (206) adapted to manage virtual allocation of processing resources registered in the processing resource registry to support processing resource reservation, processing resource allocation simulation, and / or processing resource pooling during optimization or processing resource allocation.

14. 12. A method of operating a processing resource pool (192) operative in conjunction with a resource object (26) of claim 11 to provide access to at least one processing resource that can be used by the resource object for task execution during operation of a modular processing system (10), comprising: - registering (S176) at least one processing resource according to at least one registration criterion characterizing said at least one processing resource; a step (S182) of searching a processing resource registry (198) in response to receiving a search request specifying at least one search criterion, and checking whether at least one registration criterion of at least one registered processing resource registered in the processing resource registry (198) matches the at least one search criterion for generating search results; If the search results list multiple registration processing resources, applying a search optimization function to optimize the search results (S184), the search optimization function evaluating at least one search-related characteristic of the registration processing resources listed in the search results to identify at least one preferred registration processing resource from the search results and for related updating of the search results; and (S186) allocating each registered processing resource listed in the search result to an allocated resource object for subsequent use through the allocated resource object.

15. 15. The method of claim 14, comprising managing a virtual allocation of processing resources registered in the processing resource registry to support processing resource reservation, processing resource allocation simulation, and / or processing resource pooling during optimization or processing resource allocation.

Images