EP2250557A1

EP2250557A1 - Method for controlling an interaction between modules of a service-oriented component and service-oriented component

Info

Publication number: EP2250557A1
Application number: EP09713697A
Authority: EP
Inventors: Armando Walter Colombo; Joao Marco Mendes
Original assignee: Schneider Electric Automation GmbH
Current assignee: Schneider Electric Automation GmbH
Priority date: 2008-02-29
Filing date: 2009-02-27
Publication date: 2010-11-17
Also published as: JP2011513822A; CN102265260A; WO2009106638A1; CN102265260B; US20110055849A1; DE102008002785A1

Abstract

The invention relates to a method for controlling interaction between modules such as a communication module (KOM-MOD), control module (LC-MOD), device-interface module (GI-MOD) of a service oriented component (SOK). According to the invention, in order to simplify the interaction between modules during different and concurrent processes, the interaction between the modules (KOM-MOD; LC-MOD; GI-MOD) is event based and the modules (KOM-MOD; LC-MOD; GI-MOD) are coupled by an event-router scheduler module (EAS-MOD) for providing an event-router-scheduler for event-based connections and synchronisation of the module (K0M-M0D; LC-MOD; GI-MOD).

Description

description

Method for controlling an interaction between modules of a service-oriented component and a service-oriented component

The invention relates to a method for controlling an interaction between modules such as communication module, control module, device-interface module of a service-oriented component, a service-oriented component such as an automation device and a software component.

Production and automation systems are naturally heterogeneous and consist of different components according to their tasks. It is therefore foreseeable that the specifications of such systems will evolve away from the traditional, centrally-driven approach towards the distributed, corresponding approach, which will accommodate the natural realities and layout of the real system.

Thus, it is promising to have a collection of distributed, autonomous, intelligent, error tolerant, and reusable manufacturing units that work together as a set of cooperating entities. Each unit is capable of dynamic interacting with each other to achieve both local and global manufacturing goals, from the physical machine control level in the factory to higher levels of the factory management system. This new generation of systems is referred to as Intelligent Manufacturing Systems (IMS).

One of the emerging solutions for adapting the multitude of concepts behind IMS into useful principles is Service Oriented Architecture (SOA). The SOA concept has become very important in a few years and will undoubtedly have a major impact in many areas of technology. A service-oriented architecture is a set of architectural theories for building autonomous and interoperable systems. This assumption illustrates one of the challenges of IMS, namely, providing interoperability between autonomous systems.

The adaptation of the service-oriented concept to automation and production "business systems" in the production facility in compliance with the principles of IMS will create a new "community" of service-oriented automation components. Each participant in the system is referred to as a service-oriented component, and in some extensions as a service-oriented automation component, if the component has automatic controllers. Components can have various tasks, such as Production, transport or monitoring and autonomous operation. As services take the lead, these components should have the ability to request services and, conversely, support the request for services from other members of the community. Services themselves are a way of providing resources and actions that may be shared, much like services in real life.

In distributed automation, and in particular in the area of production systems, a set of equipment and other components of the system may under some circumstances be compared to a "living entity." Looking closer at a component, its internal mechatronic Organizations are compared with functional organs that are responsible for specific tasks that provide "living" characteristics capable of meeting those requirements, a central question is how these functional modules or "organs" are integrated and controlled and are able to exchange events between them, thereby forming complex and effective structures.

Service-oriented systems are an approach to specify the environment for heterogeneous "organisms" that require interaction Service business systems are known in the business world and electronic commerce in the field of industrial automation and production systems (especially regarding distributed devices) however, it is a relatively new field of research with promising prospects, and a major starting point was the EU research project SIRENA, which aimed to develop a service infrastructure for embedded real-time network applications. Device Profile Forward Services (DPWS) - Specifications designed to enable communication between resource-dependent embedded devices.

An important point of this system is the arrangement of the controller and how its granularity and distribution are influenced. Since the introduction of standard Programmable Logic Controllers (PLCs), significant advances have been made in research and development with the goal of overcoming the limitations on the centralized use of PLCs. To this end, proposals were submitted in the areas of multi-agent systems, domestic systems and, more recently, service-oriented systems.

Architectures for instrumentation and control software are also in the field of research, typically using ICE 61131-3 languages, IEC61499 distributed control and automation functional blocks, and other control techniques such as Petri nets. For service-oriented distributed devices, the tax It is partly open to any control approach, but should also take into account specific service orientation requirements.

By offering different functionalities, a single service-oriented control device should be ready for a variety of activities; Thus, this requires a specially adapted internal frame structure or a programming framework, referred to below as a framework, which can handle the different and competing processes.

Based on this, the object of the present invention is to further develop a method and a service-oriented component and a software component of the type mentioned at the outset in such a way that the interaction between modules is simplified in the case of different and competing processes.

The object is achieved according to the invention in that the interaction between the modules is event-based, wherein the event-based interaction between the modules and the synchronization of the modules is controlled via an event flow control module (Event Router Scheduler).

For the event-based connection and synchronization of functional modules in service-oriented components, devices and supporting applications, an event sequence control module is provided.

This may be incorporated into modular service-oriented components, e.g. Distributed automation devices support, integrate, and provide a framework for communication between the functional modules that make up the component. The application particularly relates to automation devices for production facilities and supporting software applications.

A service-oriented component is a modular structure composed of various functional modules, including the central event flow control and the required service-oriented communication module, which has the ability to communicate with other components. Because the component is a multi-threaded environment and requires data protection, there must be a mechanism for these tasks that provides each module with an interaction environment.

The invention ensures that the communication of automation control component modules takes place only in the case of events. This is useful for controlling the real-time synchronization of these modules and data overwrite protection. Thus each module becomes independent but complementary. The approach allows the developers to program each module independently and to easily know how to process the received information.

If the control component is made up of several modules that can act asynchronously and use different processes and / or threads, a special module is needed to connect all the modules together and maintain data concurrency. To this end, the "heart" of the puzzle is the Event Router Scheduler module, which provides the following key features:

> Allows event transfer between each module, allowing a complex interaction mechanism to use simple base functions;

> Common event flow control mechanism for integrated functional modules;

> Prioritized buffers for high-occurrence events;

> Thread management and data protection facilities;

> General interface to connect different module types. Real-time applications are becoming more complex day by day. Specifically, machine control applications are created to handle electronic components to send information to a supervisor computer, such as personal computers, to communicate with other controllers, and so forth. The processing of the entire information flow can be very complex; In addition, errors, long-term developments or frequent machine reprogramming should be avoided in industrial automation.

The application achieves the following advantages:

The event router scheduler provides an internal event-driven architecture framework that controls the flow of information for interconnected functional modules.

Simplify functional module definition / separation and integration with the component by using the event router scheduler.

Each module can be programmed independently. This means that it is possible to remove, replace, upgrade (upgrade), add new modules, or just check how information is sent and read.

Support for customized functional modules for every purpose.

The event router scheduler can be applied and integrated into any software component based on the modular and functional architecture. Several areas of application are noted:

> Functional structure for service-oriented integrated devices.

> Development tools that automate access to service-oriented devices and whose internal architecture includes these concepts. > Development of virtual software components for environment simulation.

> Monitor tools and components that collect information from other components.

> Support for the development of software agents and multi-agent systems.

The present invention thus addresses an anatomy-like structure for the development of functional and reusable modules of a component as part of a service-oriented automation system. The central focus is on its internal structure, and in particular on the mechanism that binds together the functional modules, referred to as Event Flow Schedulers or Event Router Schedulers. The event flow control can be compared with the nervous system of a living being in the sense of transport / processing of pulses from and to different organs and thus to maintain the dynamic flow of information. Intelligent behavior can be achieved by connecting these nerves to the "brain," which provides static control based on "work-flow" processes and is also autonomous to respond to unforeseen events, undocumented situations, or internal objectives. Incorporated into a service-oriented environment, communication with other components can only be achieved by providing and requesting services to achieve local and global goals.

For more details, advantages and features of the invention will become apparent not only from the claims, the features to be taken these features - alone and / or in combination - but also from the following description of the drawings to be taken preferred embodiments.

Show it: Figure 1 is a schematic representation of a service-oriented automation component of a service-oriented automation and production system.

FIG. 2 shows a schematic representation of a modular structure of a service-oriented component; FIG.

FIG. 3 a schematic representation of the composition of a service-oriented component with event sequence control; FIG.

4 shows various types of sending event messages through

Module via the event sequence control;

Fig. 5a, b schematic representation of the reading of an event at "locked" module or "open" module;

Fig. 6 is a schematic representation of a service-oriented component of a mechanical arm and its function.

1 shows a schematic representation of a service-oriented component SOK and its integration into an automation and production environment of a production facility FS. The illustrated component SOK represents a physical conveyor F and takes over the transport function (task: transport). Communication to the outside world is through services (service orientation) that are able to request or provide services as needed. Integration into the IT environment is also achieved via service orientation. The component includes a set of functions (tasks: transport, monitoring, etc.) that can be used as services provided by the components.

An interaction between the components follows the two-way principle in the sense of requesting the service and providing the service. It is expected that in production and automation heterogeneous components work together for mutual benefit and achieving the global objective. This can be termed "symbiosis," similar to the interactions between different biological species, but ultimately the global goal must be considered.

In some situations, service-oriented components may be considered software agents.

Moreover, multi-agent systems are of particular interest as these systems evoke the idea of the collaborative agent community in which each of them can take autonomous actions about their environment or about the system they represent. On the other hand, unlike the agent concepts, the true meaning of service orientation is centered on the nature of providing services and the need to request services through a component in the system. The real architecture, environment and objectives of the system are open to the user and thus the system can be adapted to different strategies to meet the requirements.

The specification of an internal anatomy of components, which simplifies their development, remains open. However, because service-oriented components can perform different and sometimes competing activities, it may be helpful to consider a functional and independent structure in favor of reusability and ease of development.

Each service-oriented component SOK can be implemented independently and differently. The only requirement is that the component offer its functions as Services S and that communication protocol and procedures are followed. In order to be able to design and unfold these components in a simple yet functional manner, a "framework" similar to an anatomy is suggested. FIG. 2 shows the schematic structure of a component SOK in an anatomical form, comprising a plurality of "organs" (functional modules) responsible for individual tasks, as shown in FIG. 2: Logic Controller LC-MOD, Decision and exception handlers EAH-MOD, communication K-MOD, device interface GI-MOD and event router scheduler EAS-MOD These modules are included in the SOK control component according to your needs and using It is also possible to develop and integrate other modules MOD for various functionalities, as long as they respect the rules that are respected by the Integration Framework (Event Router Scheduler tasks).

The event flow control EAS and the communication modules KOM-MOD are the "kernel" modules for developing a service-oriented component SOK based on the proposed anatomy, which are responsible for both the main framework of the Component (event-based inter-module interaction and integration) and external communication with other components (service-oriented inter-component communication) Other modules MOD can be added to the structure according to the component requirements.

More specifically, the communication module K0M-M0D provides the necessary functions to offer services from the associated components and to request services from other components. Other functions include, but is not limited to, discovery (discovery) and negotiation (negotiation) mechanisms. The remaining modules of the component may use the communication module K0M-M0D to access these functions through pulses (events) provided by the event flow control module EAS-MOD. As an example, a conveyor may provide the service "transfer" to effect the movement of pallets controlled by the logic controller module LC-MOD and invoked by the device interface module GI-MOD. Transfer "can be used by other components, but the component itself can also call external services when they are needed (eg for connection with other conveyor belts this calls the service "transfer" of another conveyor belt).

A suitable technological solution for implementing the service-oriented communication modules is the use of the web technology and in particular web services. In essence, web service technology is quite simple and was developed to move XML (eXtended Markup Language) documents between service processes using standard Internet protocols. This simplicity helps web services achieve the higher goal of interoperability while also requiring the addition of other technologies to realize complex distributed applications. A profile has been specified to adapt device-level web services, known as Device Profiles for Web Service (DPWS).

The further modules MOD are briefly described in FIG. The aim is to include the further modules to provide a service-oriented automation component SOK which is a "mediator" for any physical equipment with controllability For example, the resulting component SOK of Figure 2 represents a "smart controller" of the conveyor F, by providing several features such as control and access via the physical device, the ability to make decisions in unforeseen and undocumented situations, and also the possibility of service-oriented communication with other components. Another example is a service-oriented PLC-like controller that can interpret control models (e.g., in IEC61131-3 languages) and give other commands necessary calls to these services provided. In this case, device interface modules are not necessary because they do not directly instruct the devices.

Finally, the "nervous system" of the "anatomy" shown in Fig. 2 is managed by the event flow controller EAS (Event Router Scheduler). This will be explained in more detail below. Components and devices that implement several of the illustrated aspects of service orientation require a consistent anatomy to act on the various functional modules (organs) to meet the necessary requirements. Other problems may arise from the asynchronously powered modules, possibly data inconsistencies and competing processes / threads. For this purpose, a mechanism is proposed that provides an impulse (event) transfer and control feature to direct the "impulses" to different modules, thus enabling a synchronized interaction between them Event Flow Control Module (Event Router Scheduler) EAS-MOD.

The EAS-MOD fulfills the following goals:

• shared event flow / control mechanism for interaction and integration of modules;

• Providing some transparent functions for building and managing modules;

• suitable for software applications designed for both traditional PCs and embedded systems;

• high performance, especially in critical situations and targeting "targeting" real-time application;

• use of e.g. C languages, with the aim of balancing performance, portability and characteristics;

• action security and data concurrency management;

• ease of use by developers in building modules and how events are executed.

The function of EAS-MOD is comparable in some parameters to the nervous system of living things, including human beings.

In the case of service-oriented components SOK, the "environment" is detected by specific modules such as communication and device interface modules and mani- puliert. The natural balance of impulses (events) of the individual modules and their integration is achieved with the aid of the event sequence control module EAS-MOD.

The event flow control EAS is an event handler for real-time modules SM, GIM, KM of the same application (see FIG. 3). It's like the central piece of a simple puzzle, with the puzzle pieces being the different software modules of the same program. For the most part, it is intended to handle communication between modules during other activity ("on the fly"), which means that each module can send and receive events from all others without the need for synchronization, information loss, data overwriting LC-MOD, GI-MOD To take care of KOM-MOD and other things.

A component K is implemented in the corresponding device SOK, SOG or the software application after the necessary modules have been connected. In Fig. 3, component K consists of two required modules, namely event flow control module (EAS) and communication module KOM-MOD, but also a device interface module capable of GI-MOD. To read information from the VO of the associated module or to write to the VO.

The main feature is the provision of an event-based interaction between the functional modules and the corresponding scheduling of events (see control and flow of events according to Fig. 4). From a practical standpoint, the internal pulses (events) of the component between its functional modules are managed internally by the event scheduler. The event flow control allows synchronous and asynchronous event calls between all modules, which is very important for real-time applications. It also provides several additional methods for implementing more complex operations, such as events generated by other events and timed events. In its simplest form, a transmitter module only needs to send one event to a specific destination (another module), and this event scheduler routes it to its destination. There are also other options for sending and processing events such as "event expected response" and "multicast" of an event to multiple destination modules, as shown in FIG. An event is a structure that contains all the information a module needs to identify different possible situations. In addition to the default information about the requested action and the associated parameters, the structure may request a response for providing information or have an error message receiver, or an event receiver may check if it is a response. It can also be seen when an event has been sent more than once due to an error.

The event handler uses lists as means for transmitting and sorting events between the modules so that the number of events awaiting processing is limited only by the available memory. The event flow control uses some techniques to avoid memory fragmentation, since data generation and deletion is a very common function in the modules. In some cases, when the number of events is high, the event flow control provides the opportunity to give the events different priorities. An event sent to a particular module will always be passed by all waiting events of that module which have a lower priority than the priority of the sent event.

The system is capable of performing both synchronous and asynchronous operations, with asynchronous operations being managed by threads. The synchronous operations may be either "frozen" or "not frozen" for the recipient. For example, when reading the event, the operation may or may not be a "freeze module." In the case of "freeze mode," the module will freeze until a new event arrives for that module. Subsequently, the module continues the normal process, as shown in Fig. 5a. This is a process with very low CPU resource utilization, which is particularly suitable for embedded devices. However, it does not make sense for real-time multi-tasking modules because these types of modules should not be "frozen." On the other hand, the "non-solidified" event readers always receive an event. However, this can be an invalid event. An invalid Event means that there are no events for the module so that it can continue working with other tasks. If it is a valid event, the module should continue with this. This is shown in Fig. 5b.

Asynchronous event triggering is also possible. Here, callbacks are used to execute this operation type because it must occur when it is called. However, because of privacy, the event is not immediately triggered, and it should only occur if the module activates a Mutual Exclusion (MUTEX) to allow call backs, which may change the module's data. Each module has a MUTEX for this case.

The remaining blocks according to FIG. 4 are responsible for adjacent tasks of the control (scheduling) and the routing of events, in particular for the management of the own module and the further modules. The hardware / software abstraction allows system architecture functional transparency that can be accessed by all modules. Since the event flow control module and other modules are in a multi-functional and concurrent environment, a special EAS block TDK performs simple thread manipulation and data protection. The block is referred to as threading and data consistency block TDK.

Finally, the "Template / Interface for Event-based Modules" block provides T / I with a basis for creating functional modules and links them to the event flow control, each module can be independently programmed, which means that it is possible removing, exchanging, extending or adding new modules makes this very flexible, a program that uses EAS, the module ID, is the identification of the module and unique for each module, which must be known by the other modules sending an event to a specific module, which is similar to the code that the nerves carry to reach certain organs, but it is also possible to do a module based on it of its type such as "controller" or "user interface", since this way is much more convenient for a developer to achieve a module without much information.

Fig. 6 shows by way of example the service-oriented component of a mechanical arm and its operation. The functions provided by the framework for developing and operating the component are shown. The framework consists of the EAS and three modules, the logic controller LC-MOD, the device interface GI-MOD and the communication module KOM-MOD.

The invention provides a framework for the development of service-oriented automation systems, particularly suitable for the mechanism of transmission of events between different functional modules forming the component. The adaptation of this "biologically inspired" modular structure allows the design and development of modules with unique and independent functions, but these are complementary to each other to enable the formation of complex, intelligent and "social" components. The resulting component structure is characterized by a shortened development time and low integration effort into a system.

In summary, automation and production systems are evolving into autonomous and collaborative components that apply the idea of business systems. A single member of this system is responsible for different and competing activities, and thus requires a customized analysis that balances the different requirements. The invention discloses an anatomical structure for the development of functional and reusable modules of service-oriented automation components. The central focus is on the internal structure and mechanism that connects the modules together and is called Event Router Scheduler. The resulting software automation components are custom designed for various applications due to the inclusion and management of the specialized functional modules and provide the ability to operate in a service-oriented automation and production environment.

Claims

A method for controlling an interaction between modules of a service-oriented component and a service-oriented component

1. Method for controlling an interaction between modules such as communication module (KOM-MOD), control module (LC-MOD), device interface module (GI-MOD) of a service-oriented component (SOK), characterized that the interaction between the modules (KOM-MOD; LC-MOD; GI-MOD) is event-based, the modules (K0M-M0D; LC-MOD; GI-MOD) being controlled by an event flow control module ( EAS-MOD) for providing event flow control to the event-based connection and synchronization of the modules (K0M-M0D; LC-MOD; GI-MOD).

2. Method according to claim 1, characterized in that the event-based interaction takes place independently of a synchronization between the modules (K0M-M0D; LC-MOD; GI-MOD) and independently of information loss and data overwriting.

3. The method according to claim 1 or 2, characterized in that the modules (K0M-M0D; LC-MOD; GI-MOD) are coupled together and then used in the service-oriented component (SOK) as automation device or software.

4. The method according to at least one of the preceding claims, characterized in that the event messages are cached according to their priority in a memory.

5. Service-oriented hardware and / or software component (SOK) such as automation device or software application with modular structure, comprising at least one service-oriented communication module (KOM-MOD), a control module (LC-MOD) and a Device Interface Module (GI-MOD), characterized in that the Service Oriented Component (SOK) comprises an Event Flow Control Module (EAS-MOD) which provides a framework for providing an Event Flow Control Mechanism event-based connection and synchronization of the modules (KOM-MOD, LC-MOD, GI-MOD).

6. Service-oriented component according to claim 5, characterized in that the service-oriented component (SOK) has multi-threading capabilities.

Service-oriented component according to claim 5 or 6, characterized in that the modules (K0M-M0D; LC-MOD; GI-MOD) are software modules of the same program.

A service-oriented component according to any one of claims 5-7, characterized in that the service-oriented component (SOK) comprises a piracy-based memory for priority event messages.

A software component having a computer program comprising software means for performing a method according to any of claims 1-8 when the software component is executed in an automation device.