KR102259927B1 - Workflow engine framework - Google Patents

Abstract

The present invention relates to a workflow engine framework system for creating a domain adaptive and further cross-domain adaptive workflow execution platform that suits the purpose through the organic configuration of dynamic engine components. According to the present invention, there is provided a resource management unit for managing a resource including a workflow attribute specification component and an engine component required for the execution of a workflow defined by a user; a system configuration unit for assembling attribute specification components and dynamically assembling engine components necessary for workflow execution to configure engine component containers required according to workflow specification to create an engine; There is provided a workflow engine framework system including a system control unit for controlling execution by driving one or more engines generated by the system configuration unit according to a method defined in a workflow attribute specification. In addition, in the present invention, the workflow engine framework is each assigned to two or more different single domains, connected to these single domain workflow engine frameworks and a network, and included in the cross domain according to the user-defined cross domain workflow. A cross-domain adaptive workflow engine framework system is provided, including a cross-domain fusion system that determines which single domain to deploy the required engine to each single domain.

Description

{Workflow engine framework}

The present invention relates to workflow and framework technology, and specifically, single-domain adaptive and further cross-domain adaptive through organic configuration of dynamic engine components to process workflows of various business domains or target domains. It is about a workflow engine framework that can create a workflow execution platform of

The workflow technology refers to a 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-based service workflow creation procedure is as follows. First, the data source and the data source collection method are determined. It determines the processing method of the collected data and determines the analysis method (eg, analysis by machine learning, prediction, knowledge inference, etc.). Decide how to service the analyzed results. The workflow creation process is completed by configuring the engine(s) required to execute this corresponding workflow and defining the linkage method between the engines.

Recently, the so-called intelligent Internet of Things (IoT), which imparts artificial intelligence to various objects, is attracting attention. In particular, for an intelligent Internet application (eg, a smart city) that encompasses multiple heterogeneous IoT domains, a system capable of controlling, managing, and controlling heterogeneous IoT domains is required. In addition, various business domains (eg, energy, health, transportation, education, power plant, etc.) may be intelligently processed. Even within a single business domain, a variety of purpose domains can exist, from devices where data is generated and actions occur, to edges where data is processed and delivered, instantaneous analysis and judgment, and cloud, where complex analysis and applications occur. In addition, a spatial domain according to the classification of space and a time domain according to the classification of time may exist within the work domain or the destination domain. In addition, there may be various method domains, such as a data processing domain, a learning domain, a prediction domain, and a service domain. Therefore, there is a need for a unified method and system for effectively controlling, managing, and controlling such complex multi-type multi-layered domains (hereinafter, cross domains).

Meanwhile, in order to quickly extract insights contained in big data collected through the Internet of Things and apply them to business, various technologies are being developed to extract and analyze insights from IoT data to support fast and accurate decision-making. For this, it is essential to support stream processing technology for real-time analytics and platform technology for real-time prediction/analysis.

In addition, the need to design a workflow by using the recently emerging machine learning technology for IoT big data analysis is growing, and as IoT domains for various purposes and fields are created, more insightful analysis or services can be created by organically integrating them. There is a need for a unified platform technology that makes this possible. However, there is a limit to combining IoT big data and machine learning with different characteristics according to devices, data, and domains with the conventional workflow technology.

In order to overcome the above-mentioned limitations and problems, a workflow suitable for the purpose of each domain can be created and executed through the organic configuration of engine components, and can be easily applied to other domains (domain adaptive) work A unified system that can create and execute flows, and can control and manage them in an integrated way, especially in order to respond to cross domains is required.

Therefore, the present invention intends to propose a workflow engine framework for creating a domain-adaptive and even cross-domain-adaptive workflow execution platform that suits the purpose through the organic configuration of dynamic engine components.

According to one aspect of the present invention for solving the above problems, a resource management unit for managing resources including a workflow attribute specification component and an engine component necessary for executing a workflow defined by a user; a system configuration unit for assembling attribute specification components and dynamically assembling engine components necessary for workflow execution to configure engine component containers required according to workflow specification to create an engine; There is provided a workflow engine framework system including a system control unit for controlling execution by driving one or more engines generated by the system configuration unit according to a method defined in a workflow attribute specification.

Also, according to another aspect of the present invention, the workflow engine framework system is assigned to two or more different single domains, respectively, and is connected to these single domain workflow engine framework systems by a network, so that the cross-domain workflow defined by the user is performed. Accordingly, a cross-domain adaptive workflow engine framework system is provided, including a cross-domain fusion system that determines a single domain to distribute an engine required for each single domain included in the cross domain.

Through the organic configuration of engine components, each domain can create and execute a workflow suitable for the field and purpose to be solved, and easily apply it to other domains to create and execute a workflow suitable for other domains. That is, a domain adaptive workflow engine framework capable of dynamically reusing engine components can be easily configured to easily configure an execution platform for solving similar problems in various business domains or destination domains. In addition, by additionally including a cross-domain knowledge fusion brain, a cross-domain adaptive workflow engine framework can be configured. Furthermore, in the real-time analysis service of large-capacity data that combines IoT, big data, and machine learning to analyze, the machine learning model and big data analysis model developed to solve a specific problem can be managed by implementing components.

Instead of developing individual solutions for each application in an environment that requires various artificial intelligence services or applications, we develop a set of workflow execution engines that satisfy new workflows by developing and loading additional components or recycling pre-developed and loaded components. A framework that can be configured/executed can be realized.

1 is a schematic diagram of a workflow engine framework according to the present invention;
2 is a detailed configuration diagram of the system configuration unit 30
3 is an exemplary view of a GUI screen for explaining the configuration of the system definition editor 70
4 is a diagram showing a procedure for configuring an engine from a specification for an engine constituting a workflow;
5 is a schematic diagram of an engine as an example of a workflow execution instance configurable by the workflow configuration unit 36 of FIG. 1 .
6 is a view showing an example of the configuration of an engine equipped with a unit processor;
Fig. 7 is a diagram of a specific embodiment of the data processing engine illustrated in Fig. 6;
8 is a view showing another example of the configuration of an engine on which a unit processor is mounted.
9 is a diagram illustrating a configuration of a workflow execution system in which one or more engines are connected in a pipeline manner.
10 is a diagram illustrating the configuration of a workflow execution system in which one or more engines pass through multiple types of data paths.
11 is an explanatory diagram of an IoT and artificial intelligence-based illuminance / temperature control workflow service scenario
12 is an explanatory diagram of a traffic speed monitoring service scenario based on deep learning
13 is an internal configuration of the workflow engine framework 10 of FIG.
14 is a view showing an example of the configuration of a serving engine for providing an intelligent service as an engine for providing a service to a client or a user
15 is an internal configuration of the workflow engine framework 10 of FIG.
16 is a diagram showing an example of a cross-domain workflow engine framework configuration
17 is a diagram showing an execution procedure of a cross-domain workflow
18 is a diagram for explaining a scenario for achieving a smart city
19 is a workflow configured to achieve the smart city of FIG. 18 One embodiment of the engine framework
20 is an embodiment of the configuration of the smart street light control recommendation engine of the workflow 94 shown in FIG. 19

1 is a block diagram showing an embodiment of a workflow engine framework of the present invention. The workflow engine framework 10 of the present invention is basically,

- System definition editor 70 to create the structure and specification of the task (workflow) to be executed;

- A property specification component related to an attribute for refining each engine component on a workflow specification (= engine specification, that is, a specification consisting of one or more engines constituting a workflow) to be created by the user through the system definition editor 70 and A resource management unit 20 that manages resources such as engine components corresponding to engine components constituting the engine to perform workflow execution, and previously created workflow specification instances;

- A system configuration unit (hereinafter referred to as 'engine') that assembles the workflow attribute specification and dynamically combines and configures engine components necessary for workflow execution, and creates an engine instance 32 (hereinafter, mixed with 'engine') that performs the workflow. 30),

- the engine (instance) 32 created by the system component 30;

- Includes a resource management unit 20, a system configuration unit 30, and a system control unit 40 for controlling the execution of the engine 32.

In the workflow engine framework 10, a user defines a workflow consisting of one or more engines to create a desired system. At this time, the workflow consists of the definition of one or more engines, and the definition of the engine corresponds to a combination of an engine component container for containing engine components and an engine component to be included in the engine component container.

An engine component container can be created by combining one or more of a reader component, a writer component, a runner component, an operator component, and a controller component. These one or more input component components, output component components, executor components, handler components, and controller components are each made of a combination of a property specification component for defining properties that determine the properties of the component and an execution component corresponding to the actual implementation of the components. For example, the execution component corresponds to a class such as Java or C++, and the attribute specification component corresponds to a constructor parameter that can be included in the class constructor or a class containing the constructor parameter. By defining a workflow path for one or more engines corresponding to the definition of the execution system created in this way, it is possible to dynamically configure the execution engine to create a workflow system necessary for a business domain for various purposes.

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

an execution instance unit 50 in which engines 32 composed of a combination of engine components dynamically created by the system configuration unit 30 are created and managed in the form of an engine instance (resultingly completed and executed engine); a component unit 60 which is a space in which the attribute specification component 62 and the engine component 64 managed by the resource management unit 20 are physically or virtually stored; In addition, a front end 77 that receives the workflow specification from the system definition editor 70 and transmits it to the system configuration unit 30 may be additionally included.

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

Before describing the workflow engine framework 10 of FIGS. 1 and 2 in earnest, a workflow defining a series of work specifications for driving the execution system in the framework 10 is created and the framework ( 10), the system definition editor 70, which performs a request to the front end 77 in order to instruct it to run, will be described first.

The system definition editor 70 defines a detailed domain for a desired task, defines the structure (workflow structure) of the work to be processed for each domain, and selects the engine component(s) according to this structure to determine the workflow execution flow. It defines and performs the function of writing the detailed specification of each engine component. For this, the attribute specification component and the engine component can be inquired from the framework (in particular, the resource management unit 20).

Here, for example, the 'structure of work' is a process of data collection, data processing, and learning from a specific IoT platform, and processing these sequentially may correspond to a workflow execution flow. 'Specification of components' is where data is taken from, what processing, and where to export, from which device to collect, what is the connection method, to receive and store data in memory It means specific definitions for each element component, such as what is, what memory information is, and where is the storage location.

A user (data scientist, model developer, business developer, etc.) can define the engine component 64 constituting the workflow and parameters determining the characteristics of the engine component through the system definition editor 70. (62) is defined according to the convention, and a pair of component and attribute specification can be defined and edited.

3 is an exemplary diagram of a GUI screen 71 for explaining the configuration of the system definition editor 70. As shown in FIG. By explaining the GUI screen 71, the description of the configuration and operation of the system definition editor 70 will be replaced.

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

The function menu 72 is a menu for selecting various functions of the system definition editor 70, for example, New (create new workflow), Open (load saved workflow), Save (save workflow), Run ( It can consist of a menu to select functions such as workflow execution), Result (view execution result), and Help.

The engine type selection unit 73 suggests various engine types and allows the user to select necessary ones among them. The engine type includes, for example, a real-time stream processing engine, a batch analysis engine, an on-demand data processing engine, an evaluation engine, a batch data loading engine, a stream machine learning prediction engine, and an on-demand fusion serving engine. have.

The component selection unit 74 provides various engine component lists for each component type so that a user can select a component type and an engine component for each type. Table 1 below is an example of the component type and engine component list presented by the component selection unit 74 .

component type engine component

Reader FileReader
HttpServerReader
Kafka Reader
MongodbReader
...
Writer FileWriter
KafkaWriter
MongodbReader
...
Controller SparkSessionController
SparkSessionStreamController
...
Runner SparkRunner
TensoflowRunner
...
Operator MinMaxScaler
Aggregator
...

The component property selection/editing unit 75 presents properties of the engine component selected by the component selection unit 74 , and the user can inquire about the properties to select and edit them.

In the workflow instance selection unit 76, a list in which a pre-made workflow is stored is displayed. Among them, you can select a workflow you want to recycle and re-edit it, or you can make an execution request to the framework 10 as it is. The unit of recycling may be the entire workflow, or it may be recycled for each single engine included in the workflow and used for editing or execution.

When a workflow specification file is created in the system definition editor 70, it is submitted to the system configuration unit 30 of the framework 10 shown in FIG. At this time, the front end 77 may serve to receive the workflow specification and transmit it to the system configuration unit 30 .

1 and 2, the resource management unit 20 of the framework 10 performs a function of managing components necessary for the execution of the workflow. The resource management unit 20 specifically as shown in Figure 2,

- The attribute specification component 62 including the attribute specification that determines the component characteristic or attribute of the workflow instance and the attribute specification component management unit 22 for managing (including updating) the list;

- Includes the engine component management unit 24 for managing (including updating) components for execution (engine components) and the list.

In addition, it may further include a workflow specification instance management unit 26 for managing the previously created and stored workflow specification instance. The workflow specification instance management unit 26 stores and manages the workflow specification instance so that it can be utilized later (eg, through the workflow instance selection unit 76 of FIG. 3 ) at the request of the system definition editor 70 . do.

In addition, 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 containers 32 according to the workflow specification (specification) received from the front end 77 to create an engine instance.

In more detail with reference to FIG. 2 , the system configuration unit 30 is

- A workflow attribute specification assembly unit 34 that binds the execution platform configuration workflow specification received from the system definition editor 70 to an attribute specification component to create a series of attribute specification components;

-Extract defined engine component information from the assembled property specification components 62 and configure a series of engine components through the process of binding the property specification component 62 and the engine component 64 to create a workflow execution platform and a workflow configuration unit 36 to configure.

The workflow attribute specification assembly unit 34 binds the workflow specification for constituting the execution platform to the attribute specification component 62 to create a series of attribute specification component instances. Examples of the attribute specification component 62 generated by the workflow attribute specification assembling unit 34 include Google's Protobuf message object, Scala's Case Class, and Java's Property object.

The workflow configuration unit 36 binds the engine component 64 constituting the workflow and the attribute specification component 62 defining parameters that determine the characteristics of the engine component 64, and the engine generated through the binding process. By binding the instances of the components to the engine container, the workflow execution instance unit 50 including a series of engine instances for executing the workflow is dynamically configured. In the workflow execution instance unit 50 , one or more engines 32 dynamically created by the workflow configuration unit 36 are created and executed. These engines 32 created to execute one workflow are deployed and executed as one independent program package on the same computing machine or networked computing machine, or packaged in virtual machine units and distributed to different physical computing machines. can be

1 and 2, the system control unit 40 drives the engine instances 32 generated by the system configuration unit 30 according to the processing procedure, and also serves to terminate the driven engine instance 32, etc. , a module that plays a key role in the framework of the present invention. The execution is controlled by driving one or more engines 32 created in the workflow execution instance unit 50 according to a method defined in the workflow attribute specification. In other words, when the system control unit 40 makes a workflow execution request to the workflow execution instance unit 50, the workflow is executed. In this way, the purpose of the workflow created by the user for any desired domain can be achieved.

For example, the system controller 40 may control one or more engines 32 having a number of different types of data as a data source and a destination to run in a pipelined manner to each other. Alternatively, one or more engines with a number of different types of data source and destination may be controlled to run concurrently. Various types of engine configurations will be described later in detail.

4 shows a procedure for constructing the engine 32 from the workflow specification created in the system definition editor 70. As shown in FIG.

First, the workflow configuration unit 36 of the system configuration unit 30 receives a workflow specification input (340), and from this, a series of attribute specification component instances in which attribute specifications for engine components constituting the engine are contained. to generate (342). The attribute specification component 62 used at this time may be a 'Class' that can contain a value in Google's Protobuff message, a Scala case class, or other programming language.

An engine component instance is created by designating the created attribute specification component instance as a constructor parameter of the engine component 64 (344).

When an engine instance including the controller, input device, executor, output device, and unit processor constituting the engine is created, the engine instance is created by dynamically binding them to the engine component container 31 using the engine component container instance as a constructor parameter Create an engine instance through (346). An engine instance 32 is created for all engine definitions on the workflow, and the generated engine instance is executed and managed in the workflow execution instance unit 50 .

The workflow execution instance is dynamically configured by the procedure of FIG. 4 . Here, one engine may be defined and configured in the form of a virtual machine.

5-10 show various ways of configuring the engine 32 as examples of workflow execution instances configured by the workflow configuration unit 36 mentioned in FIG. 1 .

The basic engine 32 shown in FIG. 5 includes a reader 322 for fetching data from one or more data sources, and one or more writers for outputting internally processed data to one or more data destinations. 324, a runner 326 that executes a separate executor or platform for processing input data or manages a session, inputs such data through an input device, processes it on the runner and outputs it It consists of a controller (controller) 328 in charge of control.

The controller (controller) 328 performs a function of controlling a series of processes using the input device 322 , the output device 324 , the executor 326 , and the following unit processor 323 . An input request is made to the input device 322 to read data from the data source (source), and a processing request is made to the executor 326 to process and send the data read through the input device to the output device by driving the processing framework, and to the output device ( 324) makes an output request to write the processed data to the data destination.

The input device 322 of the engine 32 performs a function of reading data from a data storage (not shown) of any one type of an in-memory buffer or cache, a file system, a messaging system, a database, and a network driver. Similarly, the writer 324 performs a function of writing data to any one type of data storage (not shown) among an in-memory buffer, cache, file system, messaging system, database, and network driver. The unit processor 323 performs a function of receiving, processing, and exporting data. For example, it may be an implementation of various data processing functions included in the purification/integration/reduction/transformation methods mentioned in data mining. The executor 326 may be any program or external platform/framework required to process data, and deep learning platforms such as Spark for big data processing, Caffe for deep learning analysis, and Tensorflw, and knowledge processing such as Jena. It can be a connector, controller, session manager, etc. for interworking with or executing one of the engines.

On the other hand, the controller 328, as shown in Figs. 5 and 6, when the nodes are configured in the order of the input device 322, one or more unit processors 323a to c, and the output device 324, sequentially pipelining the data It can be controlled using a sequential processing method that controls execution in such a way that it is transmitted to the next node, a concurrent processing method that allows each node to be executed at the same time, and a concurrent/sequential processing method that combines the two.

6 shows a series of processes of processing input data by the controller 328 among the methods of configuring the basic engine 32 of FIG. 5 using one or more continuous unit operators 323a-c. It shows an engine configured to sequentially process data in a pipelined manner and deliver it to the output device 324 . The controller 328 makes an input request to the input device 322 to read data from the data source, and drives the framework for data processing to the executor 326 to process the data read through the input device. A pipeline processing execution request is made to each unit processor 323a-c, and an output request is made so that the output device 324 writes the processed data to the data destination. According to the configuration method of FIG. 6 , it is possible to easily perform processing according to the purpose of various domains by using various unit processors in combination. The unit processors 323a - c may be implementations of methods for refining, reduction, integration, and transformation corresponding to general data mining techniques.

7 shows a specific embodiment of the data processing engine illustrated in FIG. 6 . A unit processor that executes the Spark framework to process data and reads data through a reader that reads data from a file, JDBC, Kafka, etc. and deletes a specific column, concatenation and Data processing including a writer outputting to a file, JDBC, Kafka, etc. through a missing value imputation unit processor, a scaling unit processor, a filter unit processor, and a pivot unit processor You can configure the engine.

8 is another engine in which the controller 328 of FIG. 6 drives the unit processors 323a to c, receiving data from the input device 322 and sequentially processing the data by pipelining in a series of unit processors. Along with the method, the engine configuration of the method in which one or more unit processors are driven to perform simultaneous processing is shown.

As another embodiment of the engine 32 of various configurations described above, the executor 326 is a deep learning framework such as Caffe or Tensorflow, a big data processing framework such as Spark or Hadoop MapReduce, and analysis such as R or Python. It can be configured to interwork with or include various processing frameworks or software programs such as frameworks.

As another embodiment, the engine 32 described above may be configured to mount input and output devices that use various data paths within the same system as data source and destination. That is, the source (included in the same system) of various logical driver concepts such as in-memory buffer/cache, file system, messaging system, database, and network is defined as the data source and destination, receives data from them, and outputs data to them. The engine can be configured by configuring the input and output devices to do this.

As another embodiment, the engine 32 described above may be configured to use data paths that exist in different systems or networks as data source and destination, respectively. For this, network address information, host information, and remote driver information can be included in the settings for input and output devices. By separately using different data source and destination for input and output, the engine can be used as a stream processing engine between data source and destination or as a filter on the data path.

9 shows a data transmission path 338 such that, when a plurality of workflow execution engines 32a to 32c are configured, the destination of data to be output from the output device of one engine is transmitted in a pipeline manner to the data source of the input device of another engine. ) shows the embodiment in which it is used. Here, the data transfer path 338 may be, for example, Kafka. By using the configuration shown in FIG. 9 , it is possible for the engines 32a to c to perform a complex workflow in cooperation with a plurality of different-purpose workflow processing engines.

Also in FIG. 9 , one or more engines 32a - c may be placed in different physical environments (eg, networks, clusters, etc.), and it is possible to configure different types of executors. For example, if the first engine 32a interworks an executor that processes data and the second engine 32b interworks a deep learning framework, it is a complex problem in a different environment by the data transfer path 338 It is possible to run a single workflow to solve At this time, each of the engines can be executed concurrently, sequentially one by one, or individually according to a specific point in time.

10 is a method in which one or more engines 32a to c pipeline different types of data transfer paths (eg, a file system transfer path 340 and a network stream transfer path 342) for each data source and destination. shows an example of configuring the workflow execution system with In this case, the input and output devices in each engine are constituted by a plurality. Here, the file system delivery path 340 means a batch delivery path, and the network stream delivery path 342 means a real-time delivery path. By the method of FIG. 10 , a workflow system having the same structure as a lambda architecture capable of real-time processing and batch processing can be configured.

A detailed workflow service scenario will be introduced to help the understanding of the structure and operation of the framework of the present invention described above.

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 and executes a predetermined workflow through the engine(s) generated in the framework 10 to perform a smart light bulb 82 . to perform optimal illuminance control and to control the smart system air conditioner 83 to perform optimal temperature control.

"80" predicts a change in temperature in the future, for example, 1 hour later, by a prediction model by inputting data flowing from the temperature sensor 81, and infers the illuminance setting suitable for the predicted temperature and the air conditioner temperature control setting value Thus, it represents the illuminance and temperature control artificial intelligence service that transmits the illuminance control of the smart light bulb 82 and the temperature setting value of the smart system air conditioner 83.

12 is an explanatory diagram of a traffic speed monitoring service scenario based on deep learning. The workflow engine framework 10 of the present invention receives speed information from a traffic speed sensor (simulator) 84 built in a traffic site in a specific area and uses the engine(s) generated in the framework 10 By executing a predetermined workflow, the execution data is provided to the traffic speed prediction intelligent service 85 built in the region, and it can be monitored through the dashboard 87 of the vehicle or the smartphone screen 88 while driving. . The content monitored through the vehicle 87 or the smart phone 88 is traffic speed information displayed on a map of a specific area, for example, '86'.

13 illustrates the internal configuration of the workflow engine framework 10 of FIG. 11 . An engine 52 and a serving engine 53 for ingestion/data/prediction are included in the engine generated by the workflow engine framework 10 .

The components of the ingestion/data/prediction engine 52 are as follows.

522: Stream input device to open web service port to read incoming data

528: A controller (controller) that reads stream data and sequentially processes the input unit 522, the operators 523a to f, and the output unit 524 when a certain number is accumulated

523a: An operator (processor) that extracts a column in which a temperature value is located among data

523b: operator that normalizes values to a range of specific values

523c: operator to convert column to column or column to column

523d: An operator that predicts/determines the passed value using a specified machine learning model

523e: An operator that returns a value to a range of specific values for denormalization

523f: An operator that extracts a specific column containing a label value from among multiple values generated as a result of prediction

524: Writer that writes the final value to a stream engine (eg Kafka)

526: An executor that provides an environment that allows operators to be executed.

The components of the serving engine 53 are as follows.

532: Input device that reads values from stream engine whenever necessary

536: A web server runner (RestRunner) that opens a specific web port and listens for requests from end users.

538: When a request comes through a specific web port on the web server running in the Rest Runner (536), the processing result value of the ingestion/data/prediction engine 52 is read through the input device 342 and this predicted value A controller that controls a series of flows to retrieve and respond to the optimal value by referring to the database in combination with the context information value contained in the user request.

When the temperature sensing value of the temperature sensor 81 is input to the ingestion/data/prediction engine 52 as a REST signal and processed through a plurality of processors designed through the system definition editor 70, the output prediction result value is stored It is read from and delivered 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 perform automatic illuminance adjustment.

14 shows an example of a configuration of a serving engine for providing an intelligent service as an engine for providing a service to a client or a user. Components of the inputter 322 , the plurality of pipeline processors 323a - c , the outputter 324 , the executor 326 , and the controller 328 are similar to those described in FIG. 8 . However, the serving engine of FIG. 14 is configured for the function of serving the service execution in the workflow service of FIGS. 11 and 13 . In FIG. 14, external systems interoperating with each component, Spark, Tensoflow, Jena (time), REST Server, Jena (space), and Jena (domain-specific) are shown.

The controller of the serving engine reads data processed from an engine composed of executors such as Spark or an input unit that reads data processed from an engine composed of an executor such as a deep learning framework such as TensorFlow, and uses the value to perform ontology-based inference. An intelligent service can be provided by configuring the engine with a processor and an executor that serves the result through a REST interface.

15 illustrates an internal configuration of the workflow engine framework 10 of FIG. 12 . When time/speed/TRV is transmitted in real time from traffic sensors 84 of 1382 links to the engine created in the workflow engine framework 10 in 5 minute units, it is read and a 24-hour series (time per link) for Tensorflow RNN operation series) includes a data engine 54 that preprocesses and transmits data, and a prediction engine 55 that receives a 24 time series for each link for Tensorflow RNN operation and outputs a predicted value after 15 minutes.

The data engine 54 includes an input device 542 , a controller 548 , an executor 546 , and processors 543a-f similar to FIGS. 5-8 . In the case of the prediction engine 55, similar to FIGS. 5-8, the input device 552 and the controller 558 are included, but instead of the executor, Tensorflow 555 that performs RNN (recurrent neural network)-based prediction ) is included.

16 shows a method for dynamically configuring a cross-domain adaptive workflow engine framework system by cooperatively connecting a plurality of single-domain adaptive workflow engine frameworks 10 described above through a network. . In the case where the target of the workflow configuration of FIG. 1 corresponds to a cross-domain, a cross-domain convergence system 10' for collectively managing and controlling one or more single-domain adaptive workflow engine frameworks 10 is additionally provided. Including, cross-domain adaptive workflow engine framework can be implemented.

The cross-domain convergence system 10' basically has a configuration and function similar to that of the single-domain workflow engine framework 10 of FIG. 1 or 2, and serves to integrate and layer various domains. It is a system that manages resources related to flow execution, allocates a part of cross-domain workflow to each domain as a workflow, and executes it on the framework of each domain. Accordingly, the cross-domain convergence 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'.

The user defines the workflow using the system definition editor 70' of the previously introduced concept, from which sensor to acquire data, which model to select, creates an engine and distributes it to an appropriate place, etc. After writing the workflow specification with the request of the cross-domain convergence system 10', according to the workflow defined in the system definition editor 70', it determines the domain to distribute the engine(s) required for the corresponding domain. do. At this time, the criteria for determining engine distribution consider, for example, which domain is optimal for using a specific engine, whether components for the execution of this engine exist in the corresponding domain, network load, performance, and distance within the network.

The cross-domain resource management unit 20' periodically receives and updates the workflow resources from the resource management unit 20 of a plurality of single-domain workflow engine frameworks 10 (see FIG. 1 or FIG. 2) and manages them. carry out For example, the 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. In addition, the cross-domain resource management unit 20' periodically updates and maintains available components, hardware, network information, and device information in the domain through resource information received from each domain. The resources managed by the resource management unit 20' are, for example, a list of engine components for each domain, data for cost estimation, and reliability between domains.

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'. One cross-domain workflow instance specification is divided into a plurality of single domain workflow specifications and distributed to each single domain workflow engine framework 10. The workflow engine framework 10 of each domain is in its own domain. Dynamically configure the assigned engine.

The cross-domain system control unit 40' is each workflow execution system generated by the one or more single-domain workflow engine frameworks (10). That is, in order to control the start, end, etc. of the execution of one or more engines distributed in the domain, the execution control is requested to the system control unit 40 on the single domain workflow engine framework 10, respectively, thereby executing the workflow on the cross domain. Starts and shuts down the system.

The workflow engine framework 10 of each domain dynamically configures the engine assigned to each domain, and then drives the engine according to the execution request of the cross-domain system control unit 40 to perform processing. In this case, data transfer between engines may be performed directly through a network driver as described in FIG. 10 , or may be transferred using one or more of various data paths such as a messaging system such as a distributed message queue or a distributed file system. The system control unit 40 of each single domain workflow engine framework 10 transmits signals such as progress and completion of the engines back to the cross domain system control unit 40 ′ of the cross domain convergence system 10 ′.

The cross-domain resource management unit 20' requests the resource information received from each domain, that is, available components, hardware, network information, device information within the domain, etc., to each single domain workflow framework 10 to request the latest resource information. to keep In addition, the cross-domain system configuration unit 30' performs the cross-domain workflow in one or more domain workflows in order to place the optimal engine workflow in the one or more domain workflow engine frameworks 10 in performing the cross-domain workflow. Split into flows. To this end, the cross-domain system configuration unit 30' requests the cross-domain resource management unit 20' for the latest resource information on each single-domain workflow engine framework 10, and the optimum according to step 260 of FIG. Through the process of determining the engines to be configured on each single domain workflow engine framework 10 according to the engine distribution policy of , the division into the one or more domain workflows is completed. Next, the cross-domain system configuration unit 30' sends each divided domain workflow to each single domain workflow engine framework 10, and an engine for performing cross-domain workflows on one or more domains. Dynamically configure the system to execute

Each single domain workflow engine framework 10 registers a list of its own resources in the cross domain convergence system 10' and periodically requests update. Here, the resource list may be a component resource list for workflow execution, and may also include network connection information, hardware resource information, virtual machine specification information, organization configuration information, organization available device information, and availability status. have.

FIG. 17 shows an execution procedure for receiving and effectively distributing and executing a workflow specification from the cross-domain convergence system 10 ′ of FIG. 16 . In this case, the workflow may be a single domain or a cross domain adaptive workflow depending on the problem or application to be solved.

First, the system definition editor 70' determines a series of workflows by the workflow creation procedure, and defines a workflow specification including an engine component container group for making engines constituting the workflow specification (100). When the cross-domain convergence system 10' receives the workflow specification from the system definition editor 70', the process of determining the distribution location to which domain to distribute the engine component container(s) set in the workflow specification and deploying ( 200) goes to When the specification of the engine(s) required in the workflow is distributed to the domain(s), all preparations for executing the workflow for a single domain or for a cross domain are completed, and finally, the corresponding workflow is executed ( 300).

In the cross-domain convergence system 10', the process 200 in which the cross-domain system configuration unit 30' determines the distribution location of each engine component container and distributes it will be described in detail as follows.

First, the initial source of the data required for each engine (the location of the data that the engine needs to collect, e.g., a specific database, sensor location, etc.) and the final destination (e.g., the data source or storage location for other engines) exist in the same domain. It is determined whether or not (210). In this case, the source and destination of data may be an IoT device, a structured data storage such as a database, a file system, or the like, or may be a web service end.

If the source and destination of data exist in the same domain, the resource management unit queries and determines whether a series of engine configurations from the initial data source to the final destination are possible using resources within the domain ( 220 ). If the engine configuration is possible (for example, if all engine components capable of engine configuration exist in the resource registry of the corresponding domain), the workflow can be executed by distributing the engine specification to dynamically configure the engine in the domain (230). let it be

Returning back to step 210, if the data source and destination of the engine do not belong to the same domain, or if it is determined in step 220 whether the configuration of the engine component container is possible using resources within the domain, it is determined that configuration is not possible, the same component The process proceeds to step 240 of searching for other configurable domains (searching for the resource management unit) and determining a group of alternative domains.

When a group of candidate domains is determined, cost estimation is performed to determine an alternative domain among them ( 250 ). In this case, the cost may be calculated by combining one or more of an estimate of a network transmission cost such as a distance on a network topology, a network throughput, and an expected delay time, an amount of available computing resources, and reliability between domains.

Next, an optimal domain to be distributed is selected by applying the distribution domain selection policy(s) with the calculated cost (260). In this case, the domain selection policy may be a fair distribution policy that allocates resources in each domain in the same ratio or the same amount, an optimal energy policy that considers energy efficiency, and a priority policy that allocates priorities for each domain. The order of steps in cost and policy is out of order.

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

In order to understand the cross-domain adaptive workflow engine framework of FIGS. 16 and 17, it will be further described with reference to specific related scenarios and drawings ( FIGS. 18 to 20 ) for explaining the system configuration.

18 is for explaining a scenario for achieving a smart city. First of all, a smart city can be achieved through optimal (smart) public energy supply and demand control, public transportation control, and optimal control in other fields. Among them, the optimal public energy supply and demand control can be achieved through the optimal public energy demand control and supply control according to the public energy supply and demand policy. Here, smart public energy demand control can be achieved through optimal street light control, fog control (eg, control of fog removal device), and other optimal public device control. Among them, the optimal street light control can be achieved by referring to the optimal road traffic control policy according to the predicted traffic volume for each road and predicted weather conditions. Traffic volume prediction by road can be achieved by referring to the traffic volume by road and using it for prediction by referring to the monitoring results.

19 is a cross-domain workflow configured to achieve the smart city of FIG. 18 An embodiment of an engine framework is shown.

First, road traffic monitoring includes an engine that collects sensing data from various traffic sensors, a traffic statistics processing engine that reads the sensing information collected by this collection engine, and processes operations for traffic volume statistics such as total and average, and external requests A target system can be configured by executing in the engine framework through the road traffic monitoring workflow 91 composed of a traffic volume statistics serving engine that responds to the traffic volume statistics processing results.

Next, for the traffic volume prediction by road, the traffic sensor information collection engine of the road traffic monitoring workflow 91 and the collected sensing information are processed in the form of input data necessary for prediction, and machine learning-based prediction is performed by reading the processed data. A target system can be dynamically configured by defining and executing the traffic volume prediction workflow 92 for each road, which is composed of a traffic volume prediction engine that responds to an external request and a traffic volume prediction serving engine that responds to an external request.

Weather forecasting is a weather forecasting workflow consisting of a weather information collection engine that collects and appropriately processes weather information, a weather prediction engine that predicts the weather based on a machine learning model, and a weather prediction serving engine that serves the weather prediction results By defining and executing (93), the desired system can be constructed.

Road traffic control policy is a situation-specific road traffic control that extracts an optimal road traffic control policy using a knowledge base or machine learning through rule-based reasoning or recommendation operation by inputting a context corresponding to a specific situation. By defining and executing a road traffic control workflow 90 including a recommendation engine, a system can be configured to achieve the objective.

Smart street light control is an operation for querying the traffic volume prediction service engine and weather prediction service engine described above for the traffic volume prediction result and the weather prediction result by road, respectively, and provides the results to the road traffic control recommendation engine for each situation. By defining and executing a smart street light control workflow 94 that generates a smart street light control recommendation engine that responds to external requests, including an operation for inferring and obtaining control, a system for achieving the purpose can be configured.

In the scenarios shown in FIG. 18, which are not otherwise described, a system that achieves each purpose can be dynamically configured by configuring each workflow in a similar manner to the above.

20 illustrates an embodiment of a smart street light control recommendation engine configuration in a workflow 94 configuration for smart street light control among the scenarios shown in FIG. 19 . The smart street light control recommendation engine uses a runner component 326 for driving the RESTful Server 325 to respond to an external request, and an operator that inquires the weather forecast result when a request comes in to the RESTful server 325. The operator 323a queries the weather prediction engine 93' and brings the predicted results, and the operator 323c queries the traffic volume prediction engine 92' to query the future traffic volume prediction results for each road. By receiving the obtained result, generating context information, and querying the road traffic control recommendation engine 90' for each situation using the generated context information, traffic control for each road received by the situation is obtained, and the street light control policy is extracted from it It can be composed of an operator 323b that is transmitted to the Server 325 and a Controller 328 that controls the flow relationship of logic between these runners 326 and the operator.

Now, returning to the cross-domain workflow execution procedure of FIG. 17 again, after performing the determination 100 of the required engine component container group for executing a series of workflows, the distribution location for each engine component container and the procedure for distribution In (200), the cost estimation 250 and the optimal candidate domain determination 260, which are the criteria for determining the alternative candidate domain, will be supplemented for each scenario.

In the case of the road traffic control recommendation engine for each situation in the road traffic control workflow 90 , the recommendation result is directly related to the street light control recommendation, so the engine distribution is performed according to the inter-domain reliability priority weighting policy.

For the sensing data collection engine, traffic statistics processing engine, and traffic statistics serving engine in the road traffic monitoring workflow 91, engines are distributed according to the weighting policy of prioritizing network delivery cost and available computing resources when distributing engines for real-time monitoring do.

The traffic volume prediction engine and the traffic volume prediction serving engine of the road traffic volume monitoring workflow of the road traffic volume prediction workflow 92 must perform prediction using the collection results of the collection engine, so the network cost with the domain in which the collection engine is distributed is reduced. First, deploy the engine.

In the weather prediction workflow 93, since weather information is not important information for security, the engine is distributed with the available computing resources first.

In the smart street light control workflow 94 including the smart street light control recommendation engine, since each query target engine is distributed in a different domain and contains important information, the engine is distributed according to the inter-domain reliability priority weighting policy.

Through the above configuration and process, the machine learning model and big data analysis model developed to solve specific problems in real-time analysis services of large data that combine and analyze the Internet of Things, big data, and machine learning are implemented as components. can manage In addition, a single-domain or cross-domain adaptive workflow engine framework that can dynamically reuse the components can be implemented to easily configure an execution platform for solving similar problems in various task or purpose domains.

Claims (20)

a resource management unit for managing resources including a workflow attribute specification component and an engine component required for workflow execution;
a system configuration unit for assembling attribute specification components and combining engine components necessary for workflow execution to configure engine component containers required according to workflow specification to create an engine; and
A system control unit for controlling execution by driving one or more engines generated by the system configuration unit according to a method defined in the workflow attribute specification,
The system configuration unit may include: a workflow attribute specification assembling unit configured to bind a workflow specification to an attribute specification component to generate an attribute specification component; A workflow engine framework comprising a workflow configuration unit that configures an engine through a process of extracting defined engine component information from the assembled property specification component and binding the property specification component and the engine component to configure a workflow execution platform system. The workflow engine framework system of claim 1 , further comprising an execution instance unit in which an engine configured by a combination of engine components generated by the system configuration unit is stored. The method of claim 1, wherein the resource management unit
an attribute specification component management unit that manages an attribute specification component including attribute specification that determines component attributes of a workflow instance; and
A workflow engine framework system comprising an engine component management unit for managing engine components for execution. The method of claim 3, wherein the resource management unit
A workflow engine framework system that further includes a workflow specification instance management unit that manages previously created and saved workflow inventory instances. delete The method of claim 1, wherein the workflow component of the system component
The workflow execution instance in which the engine for executing the workflow by binding the engine component and the property specification component according to the contract of the engine component constituting the workflow and the property specification component defining the parameters determining the characteristics of the engine component is stored. A workflow engine framework system that additionally includes wealth. The system definition editor of claim 1, wherein the workflow specification is defined by a system definition editor and submitted to the system configuration unit.
an engine type selection unit that suggests various engine types and allows a user to select necessary ones among them;
a component selection unit providing a list of various engine components for each component type so that a user can select a component type and an engine component for each type; and
A workflow engine framework system including a component property selection/editing section that presents the properties of the engine component selected in the component selection section and enables the user to select and edit the properties by inquiring the properties. The method of claim 1, wherein the engine,
an input device for retrieving data from one or more data sources;
one or more unit processors for receiving and processing data from the input unit;
one or more output devices for outputting internally processed data to one or more data destinations;
an executor that runs a separate executor or platform for processing input data or manages a session; and
A workflow engine framework system comprising a controller responsible for a series of controls for inputting data through an input device, processing it on an executor, and outputting it. The method of claim 8, wherein the controller,
When the nodes are configured in the order of the input device, the unit processor, and the output device, a sequential processing method for controlling execution by pipelining data sequentially and transferring the data to the next node, a concurrent processing method for executing each node at the same time , and a workflow engine framework system that performs control in any one of a concurrent/sequential manner combining the two. The method of claim 8, wherein the controller
A workflow engine framework system for controlling one or more unit processors to receive data from the input device and sequentially process the data by pipelining, and to drive one or more unit processors to execute simultaneous processing. The workflow engine framework system of claim 8 , wherein one or more workflow execution engines are included in the workflow engine framework system, and in this case, a data transfer path is used to be transmitted between the plurality of engines in a pipelined manner. . The workflow engine framework system of claim 11 , wherein the one or more engines are located in different physical environments and include different types of executors. 12. The system of claim 11, wherein the data transfer path includes one or more different types of data transfer paths. The engine required according to the workflow specification by assembling the resource management unit that manages the resource including the workflow attribute specification component and the engine component required for the execution of the workflow, and the engine component required for assembling the attribute specification component and executing the workflow dynamically A single domain work comprising: a system component configured to configure component containers to create an engine; and a system control unit to control execution by driving one or more engines generated by the system component according to a method defined in a workflow attribute specification flow engine framework system; and
A cross-domain fusion system that is connected to the single domain workflow engine framework system and determines a single domain to distribute an engine required for each single domain included in the cross domain according to the cross domain workflow,
The cross-domain convergence system receives reports of workflow resources from the resource management unit of the single domain workflow engine framework system and updates them, and components and hardware, network information, and device information within the domain available through the resource information received from each domain. a cross-domain resource management unit for updating at least one of; Cross-domain adaptive including a cross-domain system component that divides one cross-domain workflow specification into multiple single-domain workflow specifications to process cross-domain workflow specifications, determines the distribution location of each engine component container, and distributes Workflow engine framework system. delete 15. The method of claim 14, wherein the cross-domain convergence system determines a single domain to distribute an engine required for each single domain included in the cross domain.
1) means for determining whether the source and destination of data required for each engine exist in the same domain;
2) means for determining whether engine configuration is possible using resources within the domain when the source and destination of engine data exist in the same domain;
3) means for distributing the engine specification to configure the engine in the corresponding domain, if possible;
4) If the engine data source and destination do not exist in the same domain as a result of the determination of means 1), or if it is determined that the engine configuration is not possible in means 2), search and replace other domains in which the same engine component configuration is possible means for determining a group of possible candidate domains; and
5) A cross-domain adaptive workflow engine framework system including means for performing cost estimation to determine an alternative domain from among the candidate domain groups when the group is determined, and selecting an optimal domain to be distributed. The method of claim 14, wherein the workflow specification is defined by a system definition editor and submitted to the cross-domain convergence system, wherein the system definition editor
an engine type selection unit that suggests various engine types and allows a user to select necessary ones among them;
a component selection unit providing a list of various engine components for each component type so that a user can select a component type and an engine component for each type; and
A cross-domain adaptive workflow engine framework system including a component property selection/editing section that presents the properties of the engine component selected in the component selection section and enables the user to select and edit properties by inquiring the properties. 15. The method of claim 14, wherein the engine,
an input device for retrieving data from one or more data sources;
one or more unit processors for receiving and processing data from the input unit;
one or more output devices for outputting internally processed data to one or more data destinations;
an executor that runs a separate executor or platform for processing input data or manages a session; and
A cross-domain adaptive workflow engine framework system including a controller responsible for a series of controls for inputting data through an input device, processing it on an executor, and outputting it. A method of assembling a workflow attribute specification component required for the execution of a workflow defined by a user, and dynamically combining engine components necessary for executing a workflow to configure engine component containers to create a workflow execution engine,
receiving a workflow specification as an input and generating, from the input, an attribute specification component instance containing attribute specifications for engine components constituting the engine;
creating an engine component instance by designating the created attribute specification component instance as a constructor parameter of the engine component; and
A method of generating a workflow execution engine, comprising the step of binding to an engine component container and creating an engine by using the engine component container instance as a constructor parameter. A method for determining, by the cross-domain fusion system included in the cross-domain adaptive workflow engine framework system of claim 14, a single domain to distribute an engine required for each single domain included in the cross domain,
1) determining whether the source and destination of data required for each engine exist in the same domain;
2) determining whether an engine configuration is possible using resources in the corresponding domain when the source and destination of engine data exist in the same domain;
3) if the engine configuration is possible, distributing the engine specification to configure the engine in the corresponding domain;
4) If the engine data source and destination do not exist in the same domain as a result of the determination in step 1), or if it is determined that the engine configuration is not possible in step 2), search for other domains in which the same engine component configuration is possible. determining a substitutable candidate domain group; and
5) A method of determining an engine distribution domain, comprising: when a candidate domain group is determined, performing cost estimation to determine an alternative domain among them, and selecting an optimal domain to be distributed.

Images