KR20090092203A - A task-based approach to generate software-architecture - Google Patents

Abstract

A task-based approach to generate software-architecture is provided to efficiently manage restricted resources through the optimization and reduce complexity of the task performance. Sub architecture including components performing the same function is searched. The components having the similar function between the components of the sub architecture inside is integrated into one sub architecture. It is maintained in the memory that only components required for the action to be currently executed.

Description

A task-based approach to generate software-architecture

The present invention relates to a task-based software architecture creation method, and more particularly, to reduce the complexity of task execution by efficiently selecting and executing the appropriate architecture at the time of execution of the task, and efficiently manage the limited resources through the optimization of the architecture It's about how to do it.

The technologies related to intelligent service robots are largely divided into resource-based computing and task-based computing. Among them, resource-based computing uses the data-based component monitoring to determine its suitability. They use static-based rules or policies to deal with the complexity of dynamic user tasks. Inadequate Examples include Odyssey (1996, CMU), which controls resource utilization based on application diversity and consistency, and Puppeteer (1999, Rice University), which applies application-specific policies.

Task-based computing includes architecture-based, ontology-based, and model-based methods, which can be used in robotic environments where dynamic software must be dynamically constructed using limited resources without consideration of resources. Not suitable below. Examples include Aura (2002, CMU), an architecture-based reconfiguration framework, and Giga (2002, UIUC), which enables functional decomposition and dynamic reconfiguration using ontology.

However, for the intelligent service robot, it is necessary to consider many factors such as surrounding environment, changing user requirements, and resource constraints in order to provide more reliable and intelligent service. Most existing intelligent service robot control software is controlled and executed by a series of actions for task execution by calling functions corresponding to it. However, such a task-based control system does not focus on controlling these resource elements even though intelligent service robots have limited resources such as limited power, memory space, and network bandwidth. Because, considering these factors at task creation time, the complexity of the plan for performing the task will probably be unmanageably complex.

Thus, robots operate by overcoming the limitations of traditional task-based or resource-based computing by reducing the occurrence of resource-related problems in service robots that must dynamically configure software for various environments, changing situations, as well as unexpected problems. There has been a demand for an improvement in reliability.

SUMMARY OF THE INVENTION The present invention has been made to solve the above problems, and is intended to provide a method for generating a software architecture through optimized subarchitecture / component selection, integration and execution for task execution using a task-based approach.

The present invention reduces the complexity of task execution by efficiently selecting and executing an appropriate architecture at the execution time of the task, and efficiently manages limited resources through the optimization of the architecture.

The task-based software architecture generation method according to the present invention is a global optimization step of searching for a sub-architecture including the components that perform the same function as much as the search for the sub-architecture performing the actions constituting the task. When integrating subarchitectures to create a single architecture, a topological optimization step of measuring functional similarities between components in the subarchitecture and integrating components with similar functions into a subarchitecture; When executed in sequence, it includes a temporal optimization step that keeps in memory only the components needed for the current action to be performed.

At this time, the search and the integration of the sub-architecture are performed by the architecture broker, and the search of the components is performed by the component broker.

The task-based software architecture generation method according to the present invention is achieved by searching for and integrating a candidate group of subarchitectures capable of performing an action using a subarchitecture ontology. In particular, the sub-architecture specification for sub-architecture ontology specifies the components and connection relationships between the components necessary for performing the sub-architecture, describes quality attributes to provide better quality services to users, and It is desirable to connect to the component ontology for the selection of the components. The component specification for component ontology describes the information for resource optimization with general information about the component, input / output data of the component, preconditions and postconditions for the component execution, and whether the input / output connection ports between the components are compatible with each other. It is desirable to have port information that can be determined.

The phase optimization step of the task-based software architecture generation method according to the present invention is preferably performed on the principle that high-level component functions can include their low-level functions by comparing inclusion relationships using component ontology.

The temporal optimization of the task-based software architecture generation method according to the present invention preferably uses a count in which components in a sub-architecture performed in units of actions should be executed.

According to the present invention, it is possible to reduce the probability of malfunction due to lack of resources that can occur when including a variety of functions in the service robot operating with a finite resource, it is possible to accommodate the addition of sub-architecture or components with more efficient resource utilization You can increase your chances. Therefore, it is possible to improve the reliability of the robot operation by reducing the occurrence of resource-related problems in the service robot, which must dynamically configure the software for various environments and changing situations as well as for unexpected problems.

FIG. 1 is an exemplary diagram for describing generating one large architecture that can be performed by integrating various subarchitectures searched for performing an action.

2 is a diagram illustrating an ontology model for a subarchitecture specification defined in the present invention;

3 shows a specification of a subarchitecture according to an embodiment of the present invention;

4 is an exemplary diagram for explaining global optimization of selecting a subarchitecture including as many components as possible for resource-optimized subarchitecture selection.

5 is an exemplary diagram for illustrating a regional optimization technique;

6 is an example of an algorithm for topological optimization,

7 is an example of an algorithm for temporal optimization,

8 and 9 are diagrams for explaining an application example of applying a task-based software architecture generation method to a robot according to the present invention.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. However, the following embodiments are provided to those skilled in the art to fully understand the present invention, and may be modified in various forms, and the scope of the present invention is limited to the embodiments described below. It will be described in detail with reference to the accompanying drawings as follows.

The present invention relates to a method of dynamically selecting and executing an appropriate software architecture at the execution time of a robot task, thereby reducing the complexity of task execution and optimizing the software architecture to efficiently use and manage the limited resources inside the robot. will be.

FIG. 1 is an exemplary diagram for describing generating one large architecture that can be performed by integrating various subarchitectures searched for performing an action.

In FIG. 1, a plan for performing a task is composed of unit actions, and a set of software components for performing each action is defined as a sub-architecture. That is, a reusable unit that can support the actions required to perform a robot task is called a sub-architecture, and the sub-architecture specifies components that are unit functions for performing the architecture.

The task-based subarchitecture selection process consists of three steps. As shown in FIG. 1, three steps are involved: searching for subarchitecture, consolidation of selected subarchitectures, and creation of an actual executable architecture.

In the search phase of the subarchitecture, subarchitectures that perform the actions A1, A2, A3, A4, and A5 constituting the task are searched. When searching, you should search for a sub-architecture with as many identical components as possible, because you need to reduce the number of components that need to be loaded and executed in the robot's internal memory. When searching for subarchitectures in this way, it is a global optimization method to reduce the number of components to be loaded by searching for subarchitectures including components that perform the same function.

After global optimization, local optimization is performed for more efficient resource optimization. Regional optimization includes topological optimization at architecture integration and generation time, and temporal optimization at runtime of architecture. In other words, in the integration stage of sub-architectures, we use topological optimization that measures similarity of semantic functions between components and integrates similar functions into one sub-architecture.

Finally, in the executable architecture generation stage, the software components to be executed are selected and bound to the integrated architecture.

Afterwards, the components bound to the unified architecture are executed in the order of actions. A temporal optimization method that saves internal resources of the robot by using only components necessary for the current action to be performed is used.

In FIG. 1, in order to search and integrate a subarchitecture, discovery and inference are performed using an ontology-based abstraction technique, and components constituting the subarchitecture are also abstractly represented. Thus, the role of searching for candidates of appropriate subarchitecture through semantic search and integrating resource optimized subarchitecture from them is performed by the architecture broker. The component broker serves to search for unit components for performing subarchitecture, and the brokering process of the component broker proceeds similarly to the architecture broker.

2 illustrates an ontology model for the subarchitecture specification defined in the present invention, which is three types of "action", "subarchitecture", and "component" ontology.

Action ontology describes the unit actions for robot task execution, and actions are performed by sub-architecture. The subarchitecture ontology is a functional unit whose name is defined as an attribute, and the subarchitecture specification must specify components and configuration relationships between components for performing the subarchitecture. In addition, the sub-architecture can describe quality attributes in order to provide better quality services to users. The attributes, such as performance, security, and reliability, are typical quality attributes in the robot domain. You can have

The subarchitecture must be connected to the component ontology for the selection of components, which are the unit functions that perform it. Components can have their name and classpath (class_path) for execution and component description (component description) as their attributes.In the component specification, general information about the component, input / output data of the component, prerequisites for the component execution, and after The condition can have that value. In addition, the component may describe information on resources, which are information for resource optimization, and may have memory, bandwidth, and CPU usage, which are representative resource information, as its attributes. Lastly, since the components are connected to each other and executed, the components may have port information for determining whether the input / output connection ports are compatible with each other.

 3 shows a specification of a subarchitecture according to an embodiment of the present invention. In the specification, abstracted components for performing subarchitecture are described as Uniform Resource Indentifiers (URIs), and port information for connecting each component is described. The "ports {...}" section lists these ports. The URIs described are passed to the input of the component broker to select the component instance to be bound and executed. For example, the URI of the first component, 'Coordinator', is "http://sembots.icu.ac.kr/Components#Coordinator". The subarchitecture specification describes information about connectors, which are used to connect components that do not match input / output ports. Finally, the "Attachments" field describes the connection of the ports and connectors described.

FIG. 4 is an exemplary diagram for explaining global optimization for selecting a subarchitecture including as many components as possible for resource-optimized subarchitecture selection.

A candidate group of subarchitectures capable of performing one action may be searched using a subarchitecture ontology specified according to the model of FIG. 2. However, as shown in FIG. 4, one action may be performed in one of several subarchitectures. For example, subarchitecture 1 (Sa1) or subarchitecture 2 (Sa2) may be selected to perform action 1 (A1). At this time, the most suitable subarchitecture from the candidate group is selected by measuring quality attributes and resource consumption of user requirements. When searching for a component to perform the architecture, a similar procedure is used to extract the candidate group.

Using global optimization in FIG. 4, components C4 and C7 are included in the subarchitectures 2, 4, and 6, and Sa2, Sa4, and Sa6 are selected. In other words, global optimization can be used to reduce the number of components that must be loaded into memory to perform the architecture.

After global optimization, local optimization is performed for more efficient resource optimization. Regional optimization can be divided into topological optimization at architecture creation time and temporal optimization at architecture execution time.

5 is an exemplary diagram for illustrating a regional optimization technique. First, topological optimization minimizes component redundancy by comparing functional similarities between components in subarchitectures. Functional similarity comparisons are based on the principle that high-level component functions in a component ontology can encompass their low-level functions. For this comparison, we use the component ontology to compare the containment relationships. We use the rule that components in low-level classes provide more specific functionality than those in high-level classes. That is, they represent parent-like paths on the component ontology hierarchy. In FIG. 5, assuming that C11 belongs to a higher level class on a component ontology than C21, C21 may be satisfied by performing a C11 component. Similarly, C22 is selected because it can be inferred that C33's function can be satisfied by performing C22 through judging the functional similarity of C22 and C33. This similarity determination reduces the number of components that perform similar functions and creates an integrated architecture. 6 shows an example of an algorithm for topological optimization.

Next, tasks are performed by binding the actual components based on the integrated architecture. A method for performing resource optimization during the runtime of this architecture is a temporal optimization technique. To do this, the temporal optimization technique keeps only the components that are essential for the current action. In FIG. 5, the components C22 and C23 for the action 2 are loaded into the memory in advance when the action 1 is performed, and the components C12 and C13 which are no longer needed when performing the action 2 are removed from the memory. Using this preloading and unloading method, time resource optimization can be achieved by ensuring that only the components necessary for the memory are loaded. 7 shows an example of an algorithm for temporal optimization.

Temporal optimization may use a reference count in which components in a subarchitecture performed on a per-action basis should be executed in order to preload the components for the next action into memory and remove components that are no longer needed. For example, in the case of C12 and C13 in FIG. 5, the count is 1 since it is a component necessary only in action 1, and the count is 2 since C11 should be performed for action 1 and action 2.

8 and 9 are diagrams for explaining an application example of applying a task-based software architecture generation method to a robot according to the present invention.

If the user tells the robot to "take water from the kitchen," the task manager creates a sequence of actions and delivers them to the architecture broker. The architecture broker searches for subarchitectures to perform the actions described in this task plan. As shown in FIG. 8, three subarchitectures are selected: "Laser-based navigation", "Vision-based navigation", and "Manipulation". "Laser-based navigation" is a sub-architecture for general driving, and "Vision-based navigation" is a sub-architecture for judging objects through image processing. In this scenario, a refrigerator, a refrigerator handle, a kettle, a water cup, etc. It is used to image things. And "Manipulation" is a sub-architecture that operates the arm of a robot, which is used to open the actual refrigerator door, hold a kettle, pour water, and so on.

Referring to FIG. 8, "Laser-based navigation" consists of components of "localizer", "pathplanner", "mapbuilder", and "coordinator", and "Vision-based navigation" means "vision", "localizer", It consists of 'pathplanner', 'mapbuilder', 'coordinator', and 'vision_edge' components. "Manipulation" consists of 'Arm_contoller', 'Recognizer' and 'vision_common' components.

9 shows the integration of the same components 'localizer', 'pathplanner', 'mapbuilder' and 'coordinator' components in "Laser-based navigation" and "Vision-based navigation" through global optimization. Through optimization, the 'vision_common' and 'vision_edge' components, which function similarly in "Vision-based navigation" and "Manipulation", are integrated into the "vision_edge" through the similarity judgment. After this integration, the actual component instances are selected and bound through the component broker and executed in a sequence of actions.

Claims (7)

In the task-based software architecture generation method, A global optimization step of searching for a subarchitecture that includes as many components as possible to perform the same function when searching for the subarchitectures performing the actions constituting the task; A topological optimization step of incorporating the searched subarchitectures to create a single architecture, measuring functional similarities between components in the subarchitecture and integrating components having similar functions into a subarchitecture; And when the components of the unified architecture are executed in a sequence of actions, retaining in memory only the components necessary for the action to be performed at present. The method of claim 1, wherein the search and integration of the subarchitecture is performed by an architecture broker and the search of components is performed by a component broker. The method of claim 1, wherein the candidate architecture of the subarchitecture capable of performing an action using the subarchitecture ontology is searched and integrated. 4. The subarchitecture specification for subarchitecture ontology specifies the components necessary for performing the subarchitecture and connection relationships between the components, and describes quality attributes to provide better quality service to users. And connecting to a component ontology for selecting components that are unit functions. The method of claim 4, wherein the component specification for component ontology has information on resource optimization, having general information about the component, input / output data of the component, preconditions and postconditions for executing the component, and describing input / output connection between components. And having port information for determining whether the ports are compatible with each other. The method of claim 1, wherein in the phase optimization step, A method characterized by the fact that high-level component functions can subsume their low-level functions by comparing inclusion relationships using component ontology. The method of claim 1, wherein the components in the subarchitecture performed on a per-action basis for temporal optimization use a count to be executed.