JP7118726B2 - workflow engine framework - Google Patents

Description

TECHNICAL FIELD The present invention relates to workflow and framework technology, and more specifically, to process workflows of diverse business domains or objective domains, through organic composition of dynamic engine components, a single domain adaptive system. , and thus a workflow engine framework that can create a cross-domain adaptive workflow execution platform.

Workflow technology means business process automation technology that transfers documents, information, tasks, etc. from one user (application) to another user for processing according to a set of business procedure rules. In particular, the data infrastructure service workflow generation procedure is as follows. First, determine the data sources and how the data sources are collected. Determining how to process the data collected to determine how to analyze it (e.g., analysis through machine learning, prediction, knowledge inference, etc.). Decide how to service the analyzed results. The workflow generation procedure is completed by configuring the engines necessary to execute this relevant workflow and defining how the engines will work together.

Recently, the so-called intelligent internet of things, which imparts artificial intelligence to various things, has attracted attention. In particular, for intelligent Internet applications (such as smart cities) that include a large number of heterogeneous Internet-of-things domains, a system capable of controlling, managing, and controlling heterogeneous intelligence-of-things domains is required. In addition, problems may occur that require intelligent processing of various business domains (eg, energy, health, transportation, education, power plants, etc.). Within a single business domain, there are various devices that generate and act on data, the edge that processes, transmits, analyzes, and judges data, and the cloud that performs complex analysis and applications. target domains can exist. Moreover, even within the business domain and the purpose domain, there may exist a spatial domain based on spatial classification and a temporal domain based on temporal classification. In addition, there may be various method domains such as data processing domain, learning domain, prediction domain, and service domain. Accordingly, there is a need for a centralized method and system for effectively governing, managing and controlling such complex multi-layered domains (hereafter referred to as cross-domains).

On the other hand, in order to quickly extract insights contained in big data collected through the Internet of Things and connect them to business, we extract and analyze insights from Internet of Things data to support quick and accurate decision making. Various techniques have been developed for this purpose. This will definitely require the backing of stream processing technology for real-time analytics and platform technology for real-time prediction/analysis.

In addition, there is a growing need to design workflows by utilizing machine learning technology, which has recently emerged rapidly, for IoT big data analysis. There is a need for a centralized platform technology that can be integrated into multiple systems to enable more insightful analysis and services. However, conventional workflow technology has limitations in combining IoT big data and machine learning, which have different characteristics depending on devices, data, and domains.

In order to overcome the limitations and problems mentioned above, it is possible to generate and execute a workflow that meets the purpose of each domain through the organic configuration of engine components, and can be easily applied to other domains. There is a need for a centralized system that can generate and execute adapted (domain-adaptive) workflows and that can be controlled and managed in an integrated manner, especially for cross-domain coverage.

Accordingly, the present invention seeks to propose a workflow engine framework for creating a fit-for-purpose, domain-adaptive and even cross-domain-adaptive workflow execution platform through the organic composition of dynamic engine components.

According to one aspect of the present invention for solving the above problems, a resource manager for managing resources including a workflow attribute specification component and an engine component necessary for executing a workflow defined by a user; assembling an attribute specification component , a system component that dynamically combines engine components necessary for workflow execution and configures necessary engine component containers according to the workflow specification to generate an engine; A workflow engine framework is provided that includes a system controller that drives and controls the execution of one or more generated engines.

According to another aspect of the present invention, the workflow engine frameworks are respectively assigned to two or more different single domains, and are networked with these single domain workflow engine frameworks to provide user-defined cross-domain workflows. A cross-domain adaptive workflow engine framework is provided that includes a cross-domain fusion system that determines a single domain that distributes the required engine to each single domain included in the cross-domain by the workflow.

Through the organic composition of engine components, it is possible to generate and execute workflows that match the field and purpose that each domain tries to solve, and easily apply to other domains to generate workflows that are suitable for other domains. can be run as That is, easily configure a domain-adaptive workflow engine framework that can dynamically recycle engine components so that an execution platform for solving similar problems in various business domains or target domains can be easily configured. can do. Also, by further including a cross-domain knowledge fusion brain, a cross-domain adaptive workflow engine framework can be constructed. In addition, in the real-time analysis service for large amounts of data that combines and analyzes IoT, big data, and machine learning, implement and manage the machine learning model and big data analysis model developed to solve specific problems as components. be able to.

In an environment where various artificial intelligence services and applications are required, by developing and installing additional necessary components instead of developing individual solutions for each application, or by recycling already developed and installed components , a framework that can construct/execute a workflow execution engine set that satisfies a new workflow.

1 is a schematic diagram of a workflow engine framework according to the present invention; FIG. FIG. 3 is a detailed configuration diagram of the system configuration unit 30; . FIG. 3 is an exemplary diagram of a GUI screen for explaining the configuration of the system definition editing machine 70; A drawing showing the procedure for configuring an engine from the specifications for the engine that configures the workflow. FIG. 2 is a configuration diagram of an engine as an example of a workflow execution instance that can be configured by the workflow configuration unit 36 of FIG. 1; The drawing which showed an example of the engine structure which mounts a unit processor. FIG. 7 is a diagram of a specific embodiment of the data processing engine illustrated in FIG. 6; The drawing which showed the other example of the engine structure which mounts a unit processor. FIG. 2 is a diagram showing the configuration of a workflow execution system in which one or more engines are connected in a pipeline fashion; FIG. FIG. 3 is a diagram showing the configuration of a workflow execution system in which one or more engines pass through multiple types of data paths; Explanatory diagram of IoT and artificial intelligence-based illuminance/temperature control workflow service scenario. Explanatory diagram of a deep learning-based traffic speed monitoring service scenario. FIG. 11 is an internal configuration of the workflow engine framework 10 of FIG. 11; FIG. 4 is a diagram illustrating an example of a configuration of a serving engine for providing intelligent services, which is an engine for providing services to clients and users; 13 shows the internal configuration of the workflow engine framework 10 of FIG. 12; Drawing showing an example of a cross-domain workflow engine framework configuration. A drawing showing the execution procedure of a cross-domain workflow. A drawing to explain the scenario for achieving a smart city. An embodiment of a workflow engine framework configured to achieve the smart city of FIG. An embodiment of a smart street light control recommendation engine configuration for the workflow 94 shown in FIG.

FIG. 1 is a configuration diagram showing one embodiment of the workflow engine framework of the present invention. The workflow engine framework 10 of the present invention is basically composed of: - a system definition editor 70 for creating the structure and details of work (workflow) to be executed; That is, an attribute detail component related to attributes for defining each engine component of a detail composed of one or more engines that constitute a workflow) and an engine that can be said to be an engine component that constitutes an engine that executes the workflow A resource management unit 20 that manages components and resources such as workflow specification instances that have already been created, - assembles workflow attribute specifications, dynamically combines and configures engine components necessary for workflow execution, and executes the workflow. A system configuration unit 30 that configures an engine instance 32 (hereinafter also referred to as “engine”), an engine (instance) 32 generated by the system configuration unit 30, a resource management unit 20, a system configuration unit 30, an engine It includes a system controller 40 that controls the execution of T.32.

In the workflow engine framework 10, users define workflows that consist of one or more engines to create the desired system. Here, a workflow is composed of definitions for one or more engines, and this "definition for engines" means a combination of an engine component container for containing engine components and engine components that enter the engine component container. An engine component container can be made up of a combination of one or more reader, writer, runner, operator, and controller components. Each of these one or more input device components, output device components, executor components, processor components, and control components includes an attribute specification component for defining attributes that determine the properties of the component, and an actual implementation of the component. It is made up of a combination of execution components that correspond to As an example, the execution component corresponds to a class such as Java, C++, etc., and the attribute specification component corresponds to a generator parameter that can be included in the generator of the class or a class that contains the generator parameter. By defining a workflow for one or more engines corresponding to the definition of the execution system created in this way, the execution engine is dynamically configured to create a workflow system required for various business domains. be able to.

FIG. 2 shows a specific configuration of the system of FIG. 1 and possible additional components.

An execution instance unit 50 in which the engine 32 configured by combining engine components dynamically generated by the system configuration unit 30 is saved in the form of an engine instance (engine completed and executed as a result); resource management unit 50; component section 60, which is a space where attribute detail components 62 and engine components 64 managed by 20 are physically or virtually stored; A front end 77 may also be included that serves to communicate to.

The front end 77 plays a role of mediating the execution of processes for processing requests from clients and also plays a role of responding to various requests such as user management and storage management. The front end 77 may be, for example, a system including a general application server, a web application server providing a web-based REST API, or a general socket communication-based listener module. In some cases, the front end 77 may run on a different network than the back end comprising the system definition editor 70 or framework 10 .

Prior to a full-fledged explanation of the workflow engine framework 10 of FIGS. Described above is the system definition editor 70, which performs the role of asking the front end 77 to tell it to do so.

The system definition editor 70 defines detailed domains for desired tasks, defines the structure of work to be processed for each domain (workflow structure), selects engine components to match this structure, and executes the workflow. Performs the functions of defining flows and creating specific specifications for each engine component. For this purpose, the framework (especially the resource manager 20) can query the attribute description component and the engine component.

Here, the 'work structure' is, for example, the process of data collection, data processing, learning, etc. from a specific Internet of Things platform, and the sequential processing of these may correspond to the workflow execution flow. 'Component details' refers to which device the data is collected from, what the connection method is, in order to perform the work of which data is brought from, what processing process is passed, and where it is sent. It means specific definition items for each element component, such as whether data is received and stored in memory or stored, what is the memory information, and where is the location of the storage.

A user (data scientist, model developer, business developer, etc.), through the system definition editor 70, defines the engine components 64 that make up the workflow and the attribute specification components 62 that can define the parameters that determine the characteristics of the engine components. , and can define and edit component-attribute specification pairs.

FIG. 3 is an exemplary diagram of a GUI screen 71 for explaining the configuration of the system definition editing machine 70. As shown in FIG. Explanation of the GUI screen 71 replaces the explanation of the configuration and operation of the system definition editor 70 .

The GUI screen 71 includes a function menu 72 , an engine type selection section 73 , a component selection section 74 , a component attribute inquiry/editing section 75 , and a workflow instance storage/inquiry section 76 .

The function menu 72 is a menu for selecting various functions of the system definition editing machine 70. For example, New (creating a new workflow), Open (reading a saved workflow), Save (saving a workflow), Run (executing a workflow). ), Result (to see the execution result), and Help (help).

The engine type selection unit 73 presents various types of engines so that the user can select a desired engine type. Engine types include, for example, real-time stream processing engine, deployment analysis engine, on-demand data processing engine, evaluation engine, deployment data loading engine, stream machine learning prediction engine, on-demand fusion Serving engine, etc.

The component selection unit 74 provides various engine component lists for each component type so that the user can select the component type and engine components for each type. Table 1 below is an example of the component types and engine component inventories presented in the component selector 74 .

The component attribute selection/editing unit 75 presents the properties of the engine component selected by the component selection unit 74, and allows the user to inquire, select, and edit the properties.

The workflow instance selection portion 76 displays a list of saved workflows that have already been created. It is possible to select a workflow desired to be recycled from among these and re-edit it, or directly request the framework 10 to execute it. The unit of recycling may be the entire workflow, or a single engine included in the workflow may be reused for editing or execution.

When a workflow specification file is created by the system definition editor 70, it is submitted to the system configuration section 30 of the framework 10 shown in FIG. At this time, the front end 77 can play a role of receiving input of the workflow specification and transmitting it to the system configuration unit 30 .

Referring again to FIGS. 1 and 2, resource manager 20 of framework 10 performs the function of managing the components necessary for workflow execution. Specifically, as shown in FIG. 2, the resource manager 20: manages (including updates) an attribute specification component 62 containing attribute specifications that determine the component characteristics or attributes of a workflow instance and its inventory; Attribute specification component manager 22 - includes an engine component manager 24 that manages (including updates) components for execution (engine components) and their inventories.

In addition, it can further include a workflow description instance manager 26 that manages previously created and saved workflow description instances. This workflow specification instance management unit 26 stores and manages workflow specification instances so that they can be used later at the request of the system definition editor 70 (for example, through the workflow instance selection unit 76 of FIG. 3).

Also, in FIG. 1, the system configuration unit 30 performs a function of generating components necessary for executing the created workflow. The system configuration unit 30 configures the necessary engine component container 32 according to the workflow specifications (details) passed from the front end 77 and generates an engine instance.

With particular reference to FIG. 2, the system configuration component 30 includes: - a workflow attribute specification assembly that binds the execution platform configuration workflow specification received from the system definition editor 70 to attribute specification components to generate a series of attribute specification components; Part 34, - constructing a series of engine components to form a workflow execution platform through the process of extracting defined engine component information from the assembled attribute specification component 62 and binding the attribute specification component 62 and the engine component 64; A workflow configuration unit 36 is included.

The workflow attribute specification assembler 34 binds the workflow specification for configuring the execution platform to the attribute specification component 62 to generate a series of attribute specification component instances. Examples of the attribute description component 62 generated by the workflow attribute description assembler 34 include Google's Protobuf message object, Scala's Case Class, Java's Property object, and the like.

The workflow configuration unit 36 binds the engine component 64 that configures the workflow and the attribute detail component 62 that defines the parameters that determine the characteristics of this engine component 64, and binds the instance of the engine component generated through the binding process to the engine container. This dynamically configures the workflow execution instance portion 50 that includes a series of engine instances for executing the workflow. One or more engines 32 dynamically generated by the workflow configuration unit 36 are created and executed in the workflow execution instance unit 50 . These engines 32 generated to execute one workflow are distributed and executed on the same computing machine or computing machines connected to a network as one independent program package, or are executed on a virtual machine basis. and distributed to different physical computing machines.

The system control unit 40 of FIGS. 1 and 2 drives the engine instance 32 generated by the system configuration unit 30 according to the processing procedure and terminates the driven engine instance 32. It is a module that performs the core role of the framework of the invention. It also controls execution by driving one or more engines 32 created within the workflow execution instance unit 50 according to the method defined in the workflow attribute specification. In other words, when the system control unit 40 requests the workflow execution instance unit 50 to execute the workflow, the workflow is executed. This accomplishes the goals that user-created workflows seek to achieve for any desired domain.

For example, the system controller 40 may control one or more engines 32 with multiple different types of data sources and destinations to be pipelined with each other. Alternatively, one or more engines with multiple different types of data origin and destination can be controlled to run simultaneously. Various types of engine configurations will be described in detail below.

FIG. 4 illustrates the procedure for configuring the engine 32 from the workflow specifications created by the system definition editor 70. As shown in FIG.

First, the workflow configuration unit 36 of the system configuration unit 30 receives input of the workflow specification (340), and generates a series of attribute specification component instances (342) in which attribute specifications for the engine components that make up the engine are entered. . At this time, the attribute specification component 62 used may be Google's Protobuf message, Scala's Case Class, or other "Class" that can enter a value in a programming language.

The generated attribute specification component instance is designated as the generator parameter of the engine component 64 to generate the engine component instance (344).

When an engine instance including a controller, an input device, an executor, an output device, and a unit processor that constitute the engine is generated, these are dynamically bound to the engine component container 31 as engine component container instance generator parameters. An engine instance is created through the process of creating an engine instance (346). An engine instance 32 is generated for all engine definitions on the workflow, and the generated engine instance is executed and managed by the workflow execution instance section 50 .

A workflow execution instance is dynamically configured with such a procedure of FIG. Here, one engine can be defined and configured in the form of a virtual machine.

FIGS. 5-10 illustrate various engine 32 configuration schemes as examples of workflow execution instances configured by the workflow configuration component 36 referred to in FIG.

The basic engine 32 shown in FIG. 5 includes a reader 322 that brings in data from one or more data sources, and outputs internally processed data to one or more data destinations. one or more writers 324 to process the input data, a runner 326 to execute a separate execution program or platform for processing the input data or manage a session, and input such data through an input device. It is composed of a controller 328 in charge of a series of controls for processing and outputting on the executor.

The controller 328 performs a function of controlling a series of processes using the input unit 322, the output unit 324, the execution unit 326, and the unit processor 323 described below. The input device 322 is requested to read data from the data source (starting point), and the execution device 326 is requested to drive the processing framework to process the data read through the input device and send it to the output device. and requests the output device 324 to write the processed data to the data destination.

Input 322 of engine 32 performs the function of reading data from a data store (not shown) of one type of in-memory buffer, cache, file system, messaging system, database, or network driver. Similarly, the output device 324 performs the function of writing data to a data store (not shown) of any one type of in-memory buffer, cache, file system, messaging system, database, network driver. The unit processor 323 receives, processes and sends data. For example, it can be an embodiment of various data processing functions involved in refinement/integration/reduction/conversion methods referred to in data mining. The executor 326 can be any program or external platform/framework needed to process the data, such as Spark for big data processing, Caffe for deep running analysis, deep running platforms like Tensorflw, Jena It can be a connector, controller, session manager, etc. for interlocking with one of the knowledge processing engines such as .

On the other hand, as shown in FIGS. 5 and 6, the controller 328 sequentially pipelines data when a node is configured in the order of the input unit 322, one or more unit processors 323a-c, and the output unit 324. A sequential processing method that controls execution by transmitting it to the next node, a simultaneous processing method that allows each node to execute at the same time, and a simultaneous/sequential processing method that combines these two can be controlled.

FIG. 6 illustrates a series of processes for processing input data by a controller 328 among methods constituting the basic engine 32 of FIG. FIG. 1 illustrates an engine configured to process data in a sequential pipeline manner using c and to transmit to an output unit 324. FIG. The controller 328 requests the input device 322 to read data from the data origin, and drives the data processing framework to the executor 326 to process the data read through the input device. Each unit processor 323a-c is requested to execute pipeline processing, and an output request is made to the output unit 324 to write the processed data to the data destination. According to the configuration method of FIG. 6, various unit processors can be combined and used to easily perform processing suitable for various domain purposes. Unit processors 323a-c may embody methods for refinement, reduction, integration, transformation, which are common data mining techniques.

FIG. 7 shows a specific embodiment of the data processing engine illustrated in FIG. A unit processor that executes the Spark framework for processing data, reads data through a reader that reads data from a file, JDBC, Kafka, etc., and removes a specific column; Through concatenation and missing value imputation unit processors, scaling unit processors, filter unit processors, pivot unit processors to files, JDBC, Kafka, etc. A data processing engine can be configured that includes a writer for output.

FIG. 8 shows another type of engine in which the controller 328 of FIG. 6 drives the unit processors 323a to 323c. Upon receiving data from the input unit 322, a series of unit processors sequentially process the data by pipelining. FIG. 2 illustrates a method for controlling the processing and an engine configuration for a method in which one or more unit processors are driven to perform simultaneous processing.

Other embodiments of the various configurations of engine 32 described above include implementation of executor 326 in a deep-running framework such as Caffe or Tensorflow, a big data processing framework such as Spark or Hadoop MapReduce, an R or Python It can be configured to work with or include a variety of processing frameworks and software programs, such as analysis frameworks.

In yet another embodiment, the engine 32 described above can be configured with inputs and outputs that use multiple data paths within the same system as data origins and destinations. In other words, the sources of various logical driver concepts such as in-memory buffer/cache, file system, messaging system, database, network, etc. (included in the same system) are defined as data origin and destination, and data is input from these. The engine can be configured by configuring the input and output devices to receive and output data to them.

In yet another embodiment, the engine 32 described above can be configured to use data paths existing in different systems or networks as the data origin and destination, respectively. To this end, the settings for inputs and outputs can include network address information, host information, and remote driver information. By using different data origins and destinations separately for inputs and outputs, the engine can be used like a stream processing engine between data origins and destinations and a filter on the data path.

FIG. 9 shows that when multiple workflow execution engines 32a-c are configured, the destination of data output from the output of one engine is transmitted to the data origin of the input of another engine in a pipeline manner. An embodiment is illustrated in which data communication path 338 is used as shown. Here, the data transfer path 338 can be Kafka, for example. By using the configuration shown in FIG. 9, it is possible for the engines 32a to 32c, which perform workflow processing for a plurality of different purposes, to cooperate to execute a complex workflow.

Also, in FIG. 9, one or more of the engines 32a-c may reside in different physical environments (eg, networks, clusters, etc.) and may be configured with different types of executors. For example, if the first engine 32a is associated with a data processing executor and the second engine 32b is associated with a deep learning framework, the data transfer path 338 can be used to solve complex problems in different environments. It is possible to execute one workflow. At this time, each engine can be executed concurrently, sequentially one by one, or individually according to a specific point in time.

FIG. 10 illustrates a workflow in which at least one engine 32a-c pipelines different types of data transfer paths (eg, file system transfer path 340 and network stream transfer path 342) according to data origin and destination. 4 illustrates an example of configuring an execution system; In this case, each engine has a plurality of input devices and output devices. Here, the file system transmission path 340 means a batch transmission path, and the network stream transmission path 342 means a real time transmission path. With the method of FIG. 10, it is possible to configure a workflow system with a structure like a lambda architecture that enables real-time processing and batch processing at the same time.

A specific workflow service scenario is introduced to aid understanding of the structure and operation of the framework of the present invention described above.

FIG. 11 is an explanatory diagram of an IoT and artificial intelligence-based illuminance/temperature control workflow service scenario. The workflow engine framework 10 receives the temperature sensing value from the temperature sensor 81 in the building, executes a predetermined workflow through the engine generated in the framework 10, and controls the smart light bulb 82 to achieve the optimum illuminance. Adjust and control the smart system air conditioner 83 to adjust the optimum temperature.

"80" uses the data from the temperature sensor 81 as an input, predicts future temperature changes, for example, one hour from now, using a prediction model, and sets the illuminance settings and air conditioner temperature control settings that match the predicted temperatures. It shows the brightness and temperature control artificial intelligence service that infers and transmits this as brightness control for smart light bulbs 82 and temperature setpoints for smart system air conditioners 83 .

FIG. 12 is an explanatory diagram of a deep learning-based traffic speed monitoring service scenario. The workflow engine framework 10 of the present invention receives transmission of speed information from a traffic speed sensor (simulator) 84 constructed at a traffic scene in a specific area, and generates a predetermined workflow through an engine generated within the framework 10. is executed to provide the execution data to the traffic speed prediction intelligent service 85 built in the relevant area, so that it can be monitored through the dashboard 87 of the vehicle in operation or the screen 88 of the smartphone. The content monitored through the vehicle 87 or the smart phone 88 is traffic speed information displayed, for example, on a map of a specific area like "86".

FIG. 13 explains the internal configuration of the workflow engine framework 10 of FIG. Engines generated by workflow engine framework 10 include ingestion/data/prediction engine 52 and serving engine 53 .

The components of the ingestion/data/prediction engine 52 are as follows.
522: A stream input device that opens a web service port and reads incoming data 338: A controller that sequentially processes the input device 522, operators 523a-f, and output device 524 when the stream data is read and reaches a certain number ( controller)
523a: An operator (processor) that extracts the column in which the temperature value is located in the data
523b: An operator that normalizes values to a specified value range 523c: An operator that transforms columns into columns or vice versa 523d: An operator that predicts/determines the transmitted values using a specified machine learning model 523e: An operator that reduces values to a specific range of values for denormalization 523f: An operator that extracts specific columns containing label values among the multiple values generated in the prediction result 524: Stream final values An outputter that writes with an engine (eg, Kafka) 526: an executor that provides an environment in which an operator can be executed The components of the serving engine 53 are:
532: An input device that reads values from the stream engine whenever necessary 538: Ingestion/data through an input device 342 when a request is received through a specific web port on the web server running on the Rest Runner 536 / A controller that controls a series of flows to read the processing result values of the prediction engine 52, refer to the database, search for the optimum value, and respond.

The temperature sensing value of the temperature sensor 81 is input to the ingestion/data/prediction engine 52 as a REST signal, processed through a number of processors designed through the system definition editor 70, and the output prediction result value is stored. It is read from the source and transmitted to the serving engine 53, and the smart light bulb 82 is controlled according to the temperature sensing value of the temperature sensor 81 to automatically adjust the illuminance.

FIG. 14 shows an exemplary configuration of a serving engine for providing intelligent services, which is an engine for providing services to clients and users. The components of input unit 322, multiple pipeline processors 323a-c, output unit 324, execution unit 326, and controller 328 are similar to those described in FIG. However, the serving engine of FIG. 14 is configured for the function of servicing the execution of the services in the workflow services of FIGS. 11 and 13 . FIG. 14 shows the external systems Spark, Tensoflow, Jena (time), REST Server, Jena (space), and Jena (domain-specific) linked with each component.

The controller of the serving engine is an input device that reads processed data from an engine configured with an executor such as Spark or an engine configured with a deep running framework such as tensorflow. , and an engine that performs ontology-based inference using its values and an executor that serves the result through a REST interface, thereby providing intelligent services.

FIG. 15 explains the internal configuration of the workflow engine framework 10 of FIG. When the time/speed/TRV is transmitted in real time from the traffic sensors 84 of 1382 links to the engine generated by the workflow engine framework 10 in units of 5 minutes, it is read and analyzed for each link for Tensorflow RNN operation. It includes a data engine 54 that preprocesses and transmits 24 time series data, and a prediction engine 55 that receives 24 time series for each link for Tensorflow RNN operation and outputs a prediction value after 15 minutes. there is

Data engine 54 includes input unit 542, controller 548, executor 546, and processors 543a-f, similar to FIGS. The prediction engine 55 also includes an input unit 552 and a controller 558 similar to FIGS. ) 555 are included.

FIG. 16 illustrates a method for cooperatively linking multiple single-domain adaptive workflow engine frameworks 10 described above through a network to dynamically configure a cross-domain adaptive workflow engine framework system. do. Further includes a cross-domain fusion system 10' for collectively managing and controlling one or more single-domain adaptive workflow engine frameworks 10 when the target of the workflow configuration of FIG. 1 corresponds to cross-domains. , can implement a cross-domain adaptive workflow engine framework.

The cross-domain fusion system 10' basically has a configuration and functions similar to the single domain workflow engine framework 10 of FIG. 1 or FIG. It is a system that manages resources related to the execution of cross-domain workflows, assigns a part of cross-domain workflows to each domain as workflows, and executes them on the framework of each domain. Accordingly, the cross-domain fusion system 10' includes a cross-domain resource management unit 20', a cross-domain system configuration unit 30', and a cross-domain system control unit 40'.

Using the system definition editor 70' of the concept described above, the user defines the workflow, which sensor to collect data from, which model to select, and the engine is generated and placed in an appropriate place. When a workflow specification containing a request for distribution is created, the cross-domain fusion system 10' determines a domain to distribute the engine required for the relevant domain according to the workflow defined by the system definition editor 70'. . At this time, the criteria for determining engine distribution are, for example, which domain is most suitable for using a particular engine, whether components for executing this engine exist in the relevant domain, network load, performance, network Consider the distance between

The cross-domain resource manager 20' periodically receives workflow resource reports from the resource managers 20 of multiple single-domain workflow engine frameworks 10 (see FIG. 1 or 2), and updates and manages them. to carry out For example, a workflow resource may be one or more of component resources for workflow execution, network connection information, hardware resource information, virtual machine specification information, organization configuration information, organization available device information, and availability status. can be In addition, the cross-domain resource manager 20' periodically updates and maintains available components and hardware, network information, and device information within the domain through the resource information received from each domain. Resources managed by the resource management unit 20' include, for example, an engine component list for each domain, materials for cost calculation, reliability between domains, and the like.

The cross-domain system configuration unit 30' refers to the location and connection method of available resources from the cross-domain resource management unit 20' in order to process the cross-domain workflow instance specification received from the system definition editor 70'. Then, one cross-domain workflow instance specification is divided into multiple single-domain workflow specification and distributed to each single-domain workflow engine framework 10 . Each domain's workflow engine framework 10 dynamically configures the engines assigned to its respective domain.

The cross-domain system control unit 40' controls each workflow execution system generated by one or more single domain workflow engine frameworks 10, i.e., the start, end, etc. of execution of one or more engines distributed to the domain. For the control of , the execution control is requested to the system control unit 40 on the single-domain workflow engine framework 10 respectively, thereby executing and terminating the workflow execution system on the cross-domain.

The workflow engine framework 10 of each domain dynamically configures the engine assigned to its own domain, and then drives the engine according to the execution request of the cross-domain system control unit 40 to perform processing. At this time, the transmission of data between engines may be performed directly through a network driver, as mentioned in FIG. It may be conveyed using more than one. The system controller 40 of each single-domain workflow engine framework 10 transmits signals such as engine progress and completion back to the cross-domain system controller 40' of the cross-domain fusion system 10'.

The cross-domain resource manager 20' requests resource information received from each domain, that is, usable components and hardware, network information, device information within the domain, etc., from each single-domain workflow framework 10 to obtain the latest resource information. maintain information; In addition, the cross-domain system configuration unit 30' divides the cross-domain workflow into one or more domain workflows in order to arrange the optimum engine workflow in one or more domain workflow engine frameworks 10 in executing the cross-domain workflow. To divide. For this purpose, the cross-domain system configuration unit 30' requests the latest resource information for each single-domain workflow engine framework 10 from the cross-domain resource management unit 20', and selects the optimal engine according to step 260 of FIG. The division into one or more domain workflows is completed through the process of determining the engines to be configured on each single domain workflow engine framework 10 according to the distribution policy. The cross-domain system configuration unit 30' then sends each divided domain workflow to each single-domain workflow engine framework 10 to configure the engine to perform the cross-domain workflow on one or more domains. Dynamically configure a system that can be executed.

Each single domain workflow engine framework 10 registers its inventory of resources with the cross-domain fusion system 10' and periodically requests updates. Here, the resource inventory can be a component resource inventory for workflow execution, such as network connection information, hardware resource information, virtual machine specification information, organization configuration information, organization available device information, availability status, and so on. may also apply.

FIG. 17 illustrates execution procedures for receiving workflow specifications and effectively distributing and executing them in the cross-domain fusion system 10' of FIG. The workflow at this time can be a single-domain or cross-domain adaptive workflow depending on the problem or application to be solved.

First, the system definition editing machine 70' determines a series of workflows by a workflow generation procedure, and defines workflow specifications including engine component container groups for creating an engine that constitutes the workflows (100). When the cross-domain fusion system 10' receives the workflow specification from the system definition editor 70', the distribution position is determined to which domain the engine component container set in the workflow specification is to be distributed, and in the process of distribution (200). proceed. When the specifications for the engines required on the workflow are distributed to the domains, all preparations for executing the workflow for a single domain or for cross-domains are completed, and finally the corresponding workflow is executed (300).

The process (200) in which the cross-domain system configuration unit 30' determines the distribution position of each engine component container in the cross-domain fusion system 10' and distributes it will now be described in detail.

First, the initial departure point of the data required for each engine (the location of the data that the engine must collect. For example, a specific DB, sensor location, etc.) and the final arrival point (for example, the data departure point for other engines, or storage location) exists in the same domain (210). At this time, the origin and destination of data can be an Internet of Things device, a structured data repository such as a database, a file system, etc., and can be a web service endpoint.

If the origin and destination of data exist in the same domain, inquire the resource management unit whether it is possible to configure a series of engines from the origin of the first data to the final destination using resources within the domain. (220). If engine configuration is possible (for example, if there are all engine components that can be configured in the resource registry of the domain), distribute the engine specification to the domain to dynamically configure the engine. (230) Allow the workflow to run.

Returning to step (210), if the engine data origin and destination do not belong to the same domain, or in step (220), an engine component container can be configured using resources within the corresponding domain. If it is determined that the configuration is not possible as a result of determining whether the proceed.

Once the candidate domains are determined, cost estimation is performed 250 to determine alternate domains among them. At this time, the cost is a combination of one or more of the distance on the network topology, the amount of network processing, the estimated amount of network transmission cost such as expected delay time, the amount of available computing resources, and the reliability between domains. can be calculated.

Next, the optimal domain to be distributed is selected by applying the distribution domain selection policy with the calculated cost (260). At this time, the domain selection policy includes a fair allocation policy that allocates the resources of each domain in the same ratio or the same amount, an optimal energy policy that considers energy efficiency, and a priority allocation for each domain. It can be a priority policy and so on. The sequence of cost and policy stages is non-sequential.

When the specifications for all engines required for the workflow are distributed to the relevant domain (230), all preparations for executing the workflow for the relevant domain or cross-domain are completed, and the workflow is finally executed. (300). An execution instruction of the system controller 40' in the cross-domain fusion system 10' is transmitted to the system controller 40 component 30 of each single domain framework 10 through the control channel and executed.

For better understanding of the cross-domain adaptive workflow engine framework of FIGS. 16 and 17, a more detailed description will be given through drawings (FIGS. 18-20) for describing specific related scenarios and system configurations.

FIG. 18 is for explaining a scenario for achieving a smart city. First, a smart city can be achieved through optimal (smart) public energy supply and demand control, public transport control, and other areas of optimal control. Among them, optimal public energy supply and demand control can be achieved through optimal public energy demand control and supply control according to public energy supply and demand policy. Here, smart public energy demand control can be achieved through optimal street light control and fog control (eg, control of fog eliminators), and other optimal utility device control. Among them, the optimum street light control can be achieved by referring to the optimum road traffic control policy according to the predicted traffic volume of each road and the predicted weather conditions. Traffic volume forecast by road can be achieved by referring to the monitoring results of traffic volume by road and using it for forecasting.

FIG. 19 illustrates one embodiment of a cross-domain workflow engine framework configured to achieve the smart city of FIG.

First, road traffic volume monitoring consists of an engine that collects sensing data from various traffic sensors, and a traffic volume that reads the sensing information collected by this collection engine and performs operation processing for traffic volume statistics such as totals and averages. Through the road traffic monitoring workflow 91, which consists of a traffic statistics processing engine and a traffic statistics serving engine that responds to traffic statistics processing results in response to external requests, the target system is realized by executing it in the engine framework. Can be configured.

Next, the traffic volume prediction by road processes the traffic sensor information collection engine of the road traffic volume monitoring workflow 91 and the collected sensing information in the form of input data necessary for prediction, reads the processed data, and performs machine learning based The target system is operated by defining and executing a road-by-road traffic volume forecasting workflow 92 that consists of a traffic volume forecasting engine that executes forecasting and a traffic volume forecasting serving engine that responds to external requests for forecast results. can be configured

The weather forecast consists of a weather information collection engine that collects and appropriately processes weather information, a weather forecast engine that forecasts weather based on machine learning models, and a weather forecast serving engine that serves weather forecast results. By defining and executing a weather forecast workflow 93, the desired system can be configured.

The road traffic control policy uses the context corresponding to a specific situation as an input, and extracts the optimal road traffic control policy using knowledge base and machine learning through rule-based inference or recommendation operation Roads by situation By defining and executing a road traffic control workflow 90 that includes a traffic control recommendation engine, a system can be configured to accomplish the objectives.

The smart street light control is an operation for interrogating the traffic volume forecast result and the weather forecast result for each road to the traffic forecast serving engine and the weather forecast serving engine, respectively, and the result to the situation-based road traffic control recommendation engine. By defining and executing a smart street light control workflow 94 that provides and generates a smart street light control recommendation engine that includes operations for inferring and obtaining the required road traffic control and that responds to external requests. A system can be configured to achieve

The scenarios illustrated in FIG. 18, which are not otherwise discussed, can be dynamically configured to achieve their respective objectives by configuring their respective workflows in a manner similar to that described above.

FIG. 20 illustrates one embodiment of the smart street light control recommendation engine configuration in the workflow 94 configuration for smart street light control in the scenario shown in FIG. The smart street light control recommendation engine uses the Runner component 326 to drive the RESTful Server 325 to respond to external requests, and the weather prediction engine 93 through the operator to inquire the weather forecast results when a request comes in from the RESTful Server 325. ' and an operator 323c who asks questions to the traffic prediction engine 92' and brings traffic prediction results for each road, the results obtained by each operator. Then, the generated situation information is used to ask questions to the situation-specific road traffic control recommendation engine 90' to obtain the road-specific traffic control that matches the situation, from which the street light control policy is extracted. It can consist of an Operator 323b that communicates to the REST Server 325 and a Controller 328 that controls the logic flow relationship between these Runners 326 and the Operator.

Returning again to the cross-domain workflow execution procedure in FIG. Of the procedure (200), the cost calculation (250) and optimal candidate domain determination (260), which serve as criteria for determining alternative candidate domains, will be additionally explained for each scenario.

In the case of the traffic control recommendation engine for each situation in the road traffic control workflow 90, the recommendation result is directly linked to the street light control recommendation, so the engine distribution is performed according to the weighted value policy that prioritizes reliability among domains.

For the sensing data collection engine, the traffic statistics processing engine, and the traffic statistics serving engine in the road traffic monitoring workflow 91, the network transmission costs and available computing resources are prioritized at the time of engine distribution for real-time monitoring. Distribute the engine.

The traffic prediction engine and the traffic prediction serving engine of the road traffic monitoring workflow of the traffic prediction workflow by road 92 must perform prediction using the collection results of the collection engine, so the collection engine is distributed. Distribute the engine with domain and network costs as priority.

In the weather forecast workflow 93, weather information is not security critical information, so the engine is distributed with priority given to available computing resources.

In the smart street light control workflow 94 that includes the smart street light control recommendation engine, each query target engine is distributed to other domains and contains important information. Distribute the engine by value policy.

Through the above configuration and process, the machine learning model and big data analysis model developed to solve specific problems in the Internet of Things, big data, real-time analysis service for large amounts of data that analyzes by combining machine learning, etc. Components can be implemented and managed. Also, a single-domain or cross-domain adaptive workflow engine framework that can dynamically recycle said components so that execution platforms for solving similar problems in diverse business and target domains can be easily configured. can be embodied.

Claims (20)

a resource management unit that manages resources including a workflow attribute detail component and an engine component required to execute the workflow ;
a system component that generates an engine by assembling the attribute specification components and combining the engine components required for execution of the workflow to construct the required engine component containers according to the workflow specification ;
A workflow engine framework including a system controller that drives one or more engines generated by the system component in a manner defined in a workflow attribute specification to control the execution. 2. The workflow engine framework of claim 1, further comprising an execution instance portion in which an engine configured by a combination of engine components generated by said system configuration portion is stored. the resource manager is an attribute description component manager that manages an attribute description component that includes an attribute description that determines component attributes of a workflow instance;
2. The workflow engine framework of claim 1, comprising an engine component manager that manages engine components for execution. 4. The workflow engine framework of claim 3, wherein the resource manager further comprises: a workflow description instance manager that manages previously created and saved workflow description instances. the system component includes: a workflow attribute detail assembler that binds workflow specifications to attribute detail components to generate attribute detail components;
2. The workflow configuration part of claim 1, which configures the engine and configures the workflow execution platform through a process of extracting defined engine component information from the assembled attribute detail component and binding the attribute detail component and the engine component. workflow engine framework. The workflow configuration unit is an engine for executing the workflow by binding the engine component and the attribute detail component in accordance with the rules of the engine component that configures the workflow and the attribute detail component that defines the parameters that determine the characteristics of this engine component. 6. The workflow engine framework of claim 5, further comprising a workflow execution instance portion in which is stored. The workflow specification is defined by the system definition editor and submitted to the system configuration unit, and the system definition editor presents various types of engines and allows the user to select the necessary engine from among them. engine type selector,
a component selection unit that provides various engine component lists by component type so that the user can select the component type and the engine component for each type;
2. The workflow of claim 1, including a component attribute selector/editor for presenting attributes of engine components selected by the component selector and allowing a user to query, select and edit the attributes. engine framework. The engine is
an input device that brings in data from one or more data origins;
one or more unit processors for receiving and processing data from the input device;
one or more output devices for outputting internally processed data to one or more data destinations;
An executor that executes a separate execution program or platform for processing input data and manages sessions;
2. The workflow engine framework according to claim 1, comprising a controller responsible for a series of controls for inputting such data through an input device, processing it on an executor, and outputting it. The controller is
A sequential processing method in which when the nodes are configured in the order of the input device, the unit processor, and the output device, the data is pipelined sequentially and controlled to be executed in a method of transmitting to the next node, each node 9. The workflow engine framework according to claim 8, wherein control is executed in one of a simultaneous processing method that allows the processes to be executed simultaneously, and a simultaneous/sequential processing method that combines the two. The controller controls such that one or more unit processors receive data from the input device and sequentially process the data through pipelining, and the one or more unit processors are driven to perform simultaneous processing. 9. The workflow engine framework of claim 8. the workflow engine framework includes one or more of the workflow execution engines;
9. The workflow engine framework of claim 8, wherein data communication paths are used to communicate in a multi-engine pipeline fashion in this case. 12. The workflow engine framework of claim 11, wherein the one or more engines are located in different physical environments and include different types of executors. 12. The workflow engine framework of claim 11, wherein the data transmission path includes one or more different types of data transmission paths. A resource management unit that manages resources including workflow attribute specification components necessary for workflow execution and engine components ; assembling the attribute specification components and configuring necessary engine component containers according to the workflow specifications . a system component that generates an engine by combining the engine components necessary for execution of the workflow in order to create an engine; one or more engines generated by the system component in a manner defined in a workflow attribute specification ; a single domain workflow engine framework including system controls that drive and control said execution;
A cross-domain fusion system (10') coupled with the single-domain workflow engine framework to determine a single-domain distributing engine required for each single-domain included in the cross-domains according to the defined cross-domain workflow. Cross-domain adaptive workflow engine framework, including. The cross-domain fusion system receives reports of workflow resources from the resource management unit of the single-domain workflow engine framework, updates them, and uses available components and hardware through resource information received from each domain, network information, and intra-domain a cross-domain resource manager that updates device information in
including a cross-domain system component that divides one cross-domain workflow specification into a number of single-domain workflow specifications and determines and distributes the distribution position of each engine component container for processing the cross-domain workflow specifications. 15. The cross-domain adaptive workflow engine framework according to Item 14. The cross-domain fusion system determines a single domain that distributes the necessary engine to each single domain included in the cross-domain: 1) The origin and destination of data necessary for each engine are in the same domain. a means of determining whether or not there is
2) A means for determining whether an engine configuration is possible using resources within the domain when the data origin and destination of the engine exist in the same domain;
3) Means for distributing the engine specification to configure the engine in the relevant domain, if engine configuration is possible;
4) As a result of determination in means 1), if the engine data origin and destination do not exist in the same domain, or if it is determined in means 2) that engine configuration is not possible, configuration of the same engine components is possible. a means for searching for other domains that are similar to each other and determining a group of candidate domains that can be substituted;
5) once the candidate domains have been determined, performing a cost calculation to determine alternative domains among them, and applying a distribution domain selection policy to select the optimal domain that should be distributed; Cross-domain adaptive workflow engine framework according to claim 14. The workflow specification is defined by a system definition editor and submitted to the cross-domain fusion system, and the system definition editor presents types of various engines so that the user can select a necessary one from among them. an engine type selector that allows
a component selection unit that provides various engine component lists by component type so that the user can select the component type and the engine component for each type;
15. The cross of claim 14, including a component attribute selection/editor for presenting attributes of engine components selected by the component selector and allowing a user to query, select and edit the attributes. A domain-adaptive workflow engine framework. The engine is
an input device that brings in data from one or more data origins;
one or more unit processors for receiving and processing data from the input device;
one or more output devices for outputting internally processed data to one or more data destinations;
An executor that executes a separate execution program or platform for processing input data and manages sessions;
15. The cross-domain adaptive workflow engine framework according to claim 14, comprising a controller responsible for a series of controls for inputting such data through an input device, processing it on an executor, and outputting it. The workflow execution engine by assembling the workflow attribute specification components required for user-defined workflow execution and dynamically combining the engine components required for workflow execution to configure the engine component container. A method for generating a
a step of receiving the input of the workflow details and generating an attribute details component instance in which the attribute details for the engine components that make up the engine are entered;
generating an engine component instance by designating the generated attribute specification component instance as a generator parameter of the engine component;
A method of generating a workflow execution engine, including generating the engine with an engine component container instance bound to the engine component container as a generator parameter. A method for determining a single domain in which the cross-domain fusion system included in the cross-domain adaptive workflow engine framework of claim 14 distributes the required engine for each single domain included in the cross-domain. and
1) Step of understanding whether the origin and destination of data required for each engine exist in the same domain;
2) determining whether the engine can be configured using resources within the corresponding domain when the data origin and destination of the engine are in the same domain;
3) distributing the engine specification to configure the engine in the relevant domain, if the engine configuration is possible;
4) As a result of determination in step 1), if the engine data origin and destination do not exist in the same domain, or if it is determined in step 2) that the engine configuration is not possible, the same engine component configuration is possible. searching other domains to determine a group of substitutable candidate domains;
5) Once the candidate domains have been determined, performing a cost calculation to determine alternative domains among them, and applying a distribution domain selection policy to select the optimal domain that should be distributed; How the engine distribution domain is determined.

Images