EP1664954A1

EP1664954A1 - Provision of diagnosis information

Info

Publication number: EP1664954A1
Application number: EP04764423A
Authority: EP
Inventors: Markus Bregulla; Ralph BÜSGEN; Clemens Dinges; Joachim Feld; Daniel Grossmann; Michael Schlereth
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2003-09-19
Filing date: 2004-08-24
Publication date: 2006-06-07
Also published as: WO2005036290A1; DE10343963A1; US20060259243A1; US7774167B2

Abstract

The invention relates to a method for generating a system for providing diagnosis information (1, 2, 3), and to a corresponding system. The aim of the invention is to simplify the provision of information for diagnosing technical installations or technical processes. To this end, components (4) pertaining to an automation system (5) and having diagnosis interfaces for providing diagnosis information (1) for diagnosing the respective components (4) are collected in at least one group (6), and the diagnosis information (2) of the respective group (6) is provided by combining the diagnosis information (1) of the components (4) collected in the respective group (6).

Description

description

Provision of diagnostic information

The invention relates to a method for generating a system for providing diagnostic information and to such a system.

DE 100 08 020 AI describes a diagnostic device in a process control system that uses multivariable control techniques, a diagnostic tool automatically specifying data indicating a control parameter, a mode parameter, a status parameter and a limit value parameter that each of the different devices, circuits or function blocks within one Associated with the process control system, collects and stores the processed data to determine which devices, circles, or functional blocks have problems that result in reduced performance of the process control system, displays a list of detected problems for an operator, and then uses proposes additional, more specific diagnostic tools to further narrow or correct the problems.

The invention has for its object to simplify the provision of information for the diagnosis of technical systems or technical processes.

This object is achieved by a method for generating a system for providing diagnostic information, in which method components of an automation system which have diagnostic interfaces for providing diagnostic information for diagnosing the respective component are combined in at least one group and the provision of diagnostic information for the respective Gen group is provided by linking the diagnostic information of the components summarized in the respective group. This object is achieved by a system for providing diagnostic information, with components of an automation system combined in at least one group, which have diagnostic interfaces for providing diagnostic information for diagnosing the respective component, means for providing diagnostic information for the respective group by linking the diagnostic information of the components summarized in the respective group are provided.

The invention is based on the finding that the proportion of distributed, component-based automation systems is increasing and there is therefore a need to be able to diagnose these systems in the event of faults. This diagnosis must not be limited to individual automation components, but must make it possible to examine the entire automation system or its subsystems, if possible with a uniform, consistent operating paradigm. The engineering effort for the creation of a plant-wide diagnosis for a distributed automation system is usually very high, also due to the fact that the diagnosis system previously had to be created specifically for a specific plant. Up to now, the diagnosis of distributed automation solutions has generally been aimed at the diagnosis of individual components (for example, the diagnosis software is supplied with the respective hardware component) or can only be produced by complex project planning for the respective system. This configuration is usually created manually by automation specialists based on the system layout (paper printout) and the functional description of the system. For this reason, the diagnosis of a component (the diagnostic tool is supplied by the component manufacturer) differs from the diagnosis of the system (is supplied by the system manufacturer). The invention enables both component-based diagnosis and, at the same time, diagnosis of groups comprising components. A Group is also referred to below as a subsystem or diagnostic subsystem. The diagnostic information of the groups can be provided by linking the diagnostic information of the components combined in the respective group. In particular, this offers the possibility of automatically generating the system for the provision of diagnostic information or the provision of diagnostic information. The engineering effort for creating a diagnostic system is reduced considerably.

As described, the invention provides an access path to component diagnostics. On the other hand, the invention also offers the possibility of system diagnosis, system diagnosis being based on a higher level of abstraction than component diagnosis on the one hand, but building on component diagnosis on the other. According to an advantageous embodiment of the invention, subordinate groups or subordinate groups and components are combined in at least one superordinate group, wherein the generation of diagnostic information of the respective superordinate group is provided by linking the diagnostic information of the groups or components combined in the respective superordinate group , The top level of the diagnostic hierarchy thus created is the diagnostic system of the plant or the process, which is thus composed of groups or diagnostic subsystems, whereby these diagnostic subsystems can contain further diagnostic subsystems. A self-similar, fractal system is created. In particular, the fractality includes that the system description and the component description are based on the same interfaces and can therefore be processed directly using existing diagnostic tools developed for component diagnosis or their further developments. This enables uniform, consistent operation, a reduction in costs for system diagnostics tool development and further development. It is advantageous if the interfaces of the automation components, for. B. are described standardized by a specification of PROFInet web integration. Through the standardized interfaces of the components, which also include diagnostic functionality,. A control system can generate a complete diagnostic system for a group of components by linking to the layout information. The diagnostic function of a subsystem is based on the standardized diagnostic functions of the automation components it contains.

According to a further advantageous embodiment of the invention, the components are components of a system layout and. the diagnostic information is linked depending on the information contained in the system layout. A task of the plant diagnosis is the detection of errors that arise from the interaction of the components of the plant. The system manufacturer defines the interaction of the components through the layout planning of the system. The proposed embodiment of the invention makes it possible to derive a system diagnosis from the digital system layout created during the system planning phase by automatic generation. In addition to a reduction in engineering times, this also reduces the probability of errors when creating the diagnostic system. A novel method is thus proposed which makes it possible to automatically derive a diagnostic system for a particularly distributed automation system, including its components, from layout information, this system having the feature of fractality with regard to its diagnostic functions.

The plant components are grouped together in the plant layout in logically related groups, so-called ^ diagnostic subsystems. This process can, for example, correspond to the definition of the technological hierarchy that is often to be defined in the planning phase. In this case, a specific see definition of a hierarchy of diagnostic subsystems based on the layout. Ex ante, however, the diagnostic subsystems do not have to be congruent with the elements of the technological hierarchy (subsystems, units, ...) required for operational management. In particular, completely different aspects, e.g. B. locality, determine the structure of the diagnostic hierarchy. These diagnostic subsystems encapsulate the automation components contained in them and thus reduce the complexity of the diagnosis of the overall system. According to a further advantageous embodiment of the invention, tasks and networking of the components are also predetermined by the system layout.

The fact that the groups belong together to form the superordinate group is advantageous. H. from diagnostic subsystems to the next higher hierarchy level, also definable in the system layout. This corresponds to the combination of related diagnostic subsystems into an encapsulating diagnostic subsystem at a higher level.

According to a further advantageous embodiment of the invention, the diagnostic information is structured semantically in the same way. On the basis of the diagnostic hierarchy defined in the plant layout, a semantically similar diagnostic function can be generated automatically for all elements of the hierarchy. This is based on the following principle: The generated diagnostic function of a component checks its own status when it is called. Depending on the result, the diagnostic function reports an error including a description. At the level of the next higher level, the generated diagnostic function checks e.g. B. a subsystem's own status and calls the diagnostic function of the associated component. Depending on the values received, the diagnostic function may report an error with a description. This means that the purely logical diagnostic subsystems also have a diagnostic function. This principle is applied recursively up to the highest level, ie the diagnostic function of a diagnostic Subsystems are designed in such a way that they call up the diagnostic functions of the directly subordinate subsystems. In addition to this propagation of diagnostic function calls from a higher level to the respective lower level of the diagnostic hierarchy, higher-quality diagnostic functionality can be generated automatically in the sense of induction, including the system logic.

The diagnostic information advantageously contains functions which link input variables - in particular logically link them - and provide at least one output variable as a result of the linking of the input variables. The applicable system or system logic can be divided into two categories. "Single Level Logic" maps the logic of an element of the diagnostic hierarchy. Internal information of the respective element is linked. "Multi Level Logic" maps the logic of a subsystem based on the subordinate "contained" elements. When the diagnostic functions are generated recursively (for example, these are written as a script), the rules are then incorporated into the diagnostic functions. In the case of single level logic, the defined rules are included directly in the diagnostic function. In the case of multi-level logic, the system layout is used to determine which rule is to be used in the given case, since the multi-level logic arises from the interaction of various components. Diagnostic information is thus generated by recursively using a control system that links standardized diagnostic interfaces with layout information.

Consistency rules ("constraints") can be defined for both categories or already exist as a type property of the components or subsystem classes used. When the invention is used, these rules are usually already present as part of a component (for example as a so-called facet) or diagnostic subsystem (for example when reusing the planning information from parts of older systems) his. According to a further advantageous embodiment of the invention, the components and the groups are assigned classes which define functions and properties of the respective component or group. The definition of device classes (related to components and subsystems) with defined functions and properties can be the basis for creating single and multi-level logic. By using the inherent rules or the rules based on them and including the system layout, diagnostic functionality can be automatically derived and generated as outlined above. Due to the fractality, the rules can be applied recursively and, based on smaller component groups, a diagnostic system can be set up for the entire system.

The invention can advantageously be used to provide diagnostic information in a distributed, component-based automation system. In particular, a method for the automatic generation of a functional fractal system diagnostic system for a distributed, component-based automation system from layout information is therefore proposed.

If, according to a further advantageous embodiment of the invention, the components are PROFInet components, the automation functionality is provided by so-called RTAutos, so that diagnostic subsystems encapsulate the associated RTAutos at the lowest level.

Means for visualizing the diagnostic information on the basis of the plant layout are advantageously provided. It is proposed to use the system according to the invention for diagnosing a technical system or a technical process. The invention is described and explained in more detail below on the basis of the exemplary embodiments shown in the figures.

Show it:

1 shows a system for providing diagnostic information,

2 shows a logical diagnosis hierarchy derived from the plant layout,

3 shows the process of generating diagnostic information,

4 shows a diagnostic script function,

5 in. Information contained in the system layout,

6 shows the fractality of the diagnostic functionality,

7 shows the planning of a plant layout with a CAD system,

8 shows a diagnostic network from the system layout,

9 shows the engineering workflow and

10 shows the visualization of diagnostic information.

Figure 1 shows a system for providing diagnostic information. An automation system 5 has components 4, which have diagnostic interfaces for providing diagnostic information 1 for diagnosing the respective diagnosis 4. In the example, the components 4 are combined in two groups 6. The system has means for providing diagnostic information 2 of the respective group pe 6 by linking the diagnostic information 1 of the components 4 combined in the respective group 6. The two groups 6 and a further component 4 are combined in a superordinate group 7. Diagnostic information 3 of the higher-level group 7 is generated by linking the diagnostic information 1, 2 of the groups 6 or component 4 combined in the higher-level group 7. In the example, the system is used to diagnose a technical process 8. The automation system 5 is used to automate the technical process 8.

FIG. 2 shows a logical diagnostic hierarchy derived from a plant layout using the example of PROFInet (more detailed explanation of the PROFInet technology below). A system 10 is divided into so-called physical device objects P (also called PDev). PROFInet defines a runtime object model that every PROFInet device must implement. Each of the objects of the object model is usually implemented by a COM object. The objects in detail are: the physical device object P, which represents the device as a whole. It serves as an entry point for other devices, ie the first contact with a PROFInet device is via this object. The physical device object P represents the physical properties of the respective component. Exactly one instance of the physical device object P exists on each hardware component (for example PLC, drive, PC). The logical device object L (also Called LDev) represents the sequence environment in which the user program is processed. The distinction between physical and logical device objects P and L is generally unnecessary for embedded devices. However, this distinction is important for runtime systems. B. two Soft PLCs can run on one PC. In this case the PC is the physical device, the soft PLC is a logical device. The logical device object L has interfaces for querying the operating status, time, group and detailed diagnosis. So-called runtime automation objects A (also called RT-Auto) represent the actual technological functionality of the device. The interfaces of the objects are therefore dependent on the task that the object performs. An interface can contain data (read and write) as well as methods and events. The concrete properties of a PROFInet device are described by an XML file. This device description contains the interfaces, the methods and data it contains for the different objects of a PROFInet device. In particular, the technical functionality of a device represented by the runtime automation object A can be described in the simplest way. On the basis of the diagnostic hierarchy defined in a plant layout, a semantically similar diagnostic function is automatically generated for all elements of the hierarchy. The principle is illustrated below using the example of PROFInet. A generated diagnostic function of a logical device object L checks its own status when called. Depending on the result, the diagnostic function reports an error including a description. At the level of runtime automation objects A, the generated diagnostic function checks the status of the respective object and calls the diagnostic function of the associated logical device object L. Depending on the values received, the diagnostic function may generate an error message with a description. At the lowest level of the diagnostic subsystems S, the generated diagnostic function of a subsystem S calls the diagnostic functions of the subordinate runtime automation objects A. The purely logical subsystems S thus also have a diagnostic function. This system is used recursively up to the highest level 11, ie the diagnostic function of a diagnostic subsystem S is so developed that it calls up the diagnostic functions of the directly subordinate subsystems S. In addition to this propagation of diagnostic function calls from a higher level to the respective lower level of the diagnostic hierarchy, higher-quality diagnostic functionality can be generated automatically in the sense of induction, including the system logic. The layout of the system, ie the topological arrangement of the components of the distributed automation system, is usually generated in the planning phase of a system. A technological, hierarchical division of the entire system into sub-systems, machines etc. is also carried out (also referred to as "sub-systems"). In the following it is assumed that these technologically based subsystems are congruent with the diagnostic subsystems. FIG 2 illustrates the division of the entire system into subsystems using a system layout.

FIG. 3 shows the process of generating diagnostic information 17, 26. The applicable system or system logic can be divided into two categories. Single level logic maps the logic of exactly one element 12 of the diagnostic hierarchy. Internal information 14 of element 12 is linked. For example, B. the logic of a subsystem of class 13 "gate" that a system error exists if the gate (eg due to a defective sensor) reports "OPEN = 1" and "CLOSE = 1". This logic rule 15 is in an automatic generation step 16 in a diagnostic information 17, z. B. implemented a diagnostic script.

So-called multi-level logic maps the logic of a subsystem based on the subordinate elements 18 and 21 contained therein. Contains a subsystem e.g. B. an element 21 of class 22 "flow meter" and a second element 18 of class 19 "valve", there is a system error if the element 21 reports a "flow>0" while the second element 18 is in the "closed" position "reports. The properties of elements 18, 21 are identified by reference numerals 20 and 23, respectively. As in the examples, consistency rules (constraints) can be defined for both categories or already exist as a type property of the components or subsystem classes used. These rules are usually part of the application of the invention a component (e.g. as a facet) or diagnostic subsystem (e.g. when reusing the planning information from parts of older systems) already exists. When the diagnostic functions are generated recursively (for example, as a script), the rules are then incorporated into the characteristics of the diagnostic functions. In the case of the single level logic, the defined rules are included directly in the diagnostic function, in FIG. 3 the diagnostic function 17. In the case of the multi level logic, the system layout is used to determine which rule is to be used in the given case, since the multi level logic arises from the interaction of different components.

FIG. 4 shows an example of diagnostic information which is implemented as a diagnostic script function.

Figure 5 shows the information contained in the system layout. In the exemplary embodiment according to FIG. 5, information about PROFInet components 30, about the hierarchical structure 31 from a diagnostic point of view and about generic diagnostic functions 32 are contained in the plant layout.

The basis for creating single and multi-level logic is the definition of device classes (components and subsystems) with defined functions and properties. By using the inherent rules or the rules based on them and including the system layout, diagnostic functionality can be automatically generated and derived as outlined above.

Figure 6 shows the fractality of the diagnostic functionality. The diagnostic hierarchy that ultimately emerged thus has the characteristic of self-similarity (fractality) from the plant perspective. This means that all elements of the hierarchy have semantically identical, self-similar diagnostic functionality 38, 40. This also includes subsystems 35, although these purely logical elements cannot be rungsko component 36 are represented. All of the information required for automatic generation can be derived from the system layout 37, 42. Specifically, these are the (e.g. PROFInet) components 36 used, the combination of these components 36 into subsystems 35 and the further diagnostic hierarchy down to the plant level. Information contained in the system layout 37, 42 is used to generate rules 39 and 41 for diagnosing components 36 and subsystems 35 with the aid of diagnostic functions 38 and 40.

Figure 7 shows the planning of a plant layout with a CAD system. Here a subsystem is defined either by the definition of the tree-like plant structure (node is a subsystem, leaves are plant components or again subsystem nodes) or by aggregation. In a CAD system usually used to plan a plant layout, the definition of subsystems for diagnosis can be used, for example. B. by marking the components belonging to a subsystem. In Figure 6, the components belonging to a subsystem are e.g. B. defined by drawing a component including a polygon ("lasso"). A polygon can completely enclose other polygons. These embedded polygons then correspond to the visual definition of subordinate diagnostic subsystems.

FIG. 8 shows a diagnostic network generated from the plant layout. The system layout already contains all the information necessary for the further steps of generating a system for providing diagnostic information, such as For example, the assignment of runtime automation objects 47 to components 45 and thus to subsystems 48. In addition to a topological view (arrangement in the system, dimensions, shape, etc.), the components handled in the planning phase also have a diagnostic view. The connection of the diagnostic view of the components with the hierarchy enables the automatic generation of diagnostic functions as described above. ality. Based on the diagnostics view of the components, diagnostics functions for the enclosing subsystems can be generated in a first step. From this, in the second step, diagnostic functions are recursively generated for further subsystems down to the plant level. The generated diagnostic functions include the already existing for the respective hierarchy level (e.g. as a class property of a component) or explicitly named consistency rules for the single or multi level logic.

FIG. 9 shows the engineering workflow for generating a system for providing diagnostic information. Starting from a system layout 50, an XML config file 52 is automatically generated in a step denoted by reference numeral 51. This XML document contains the information contained in system layout 50 about the PROFInet components used, the hierarchical structure (subsystems) and the automatically generated diagnostic functions in the form of script functions. The XML Config File 52 is e.g. B. loaded and processed by a system diagnostic server 53. The system diagnosis server 53 is then able to execute all diagnosis script functions and thus to diagnose the system, subsystems and components.

FIG. 10 shows a prototypical visualization based on a system diagnosis server. The visualization shown is based on a concept that connects graphic components with the diagnostic subsystems and thus makes it possible to display faults in a subsystem in the system graphics. The implementation consists of the system diagnostics server and a client application for visualization purposes. Communication between client and server takes place via web services and is based on the HTTP protocol. Both the server and the client can be used in a variety of different systems without the need for adjustments, since the server is initialized using the XML document containing the necessary information. The approach described here not only offers the possibility of automatically generating the diagnostic functionality and thus a considerable reduction in the engineering effort required, but also the advantage of an integrated diagnosis concept - this integrated diagnosis concept is not limited to component diagnosis, but is reduced by education of subsystems with diagnostic functionality, the complexity of the overall system, especially for the system operator.

The link between the plant topology and the rule-based diagnostic hierarchy of the subsystems derived therefrom can also be used to directly derive a diagnostic interface according to FIG. 10. The disturbed components and the subsystems surrounding them in the layout can e.g. B. highlighted by colored markings. This can also be done accordingly in the tree view, e.g. B. recursively starting from the faulty component up to the plant node. By directly selecting the component marked as faulty in the layout with a click of the mouse, more detailed, component-related diagnostic information can be called up.

One possible way of executing the automatically generated diagnostic functions is to generate script functions. These script functions can e.g. B. run in a so-called system diagnostic server and work the diagnostic functions. In principle, this concept can also be implemented decentrally, for example in a subsystem diagnostic server that resides in a PDev. This concept also ensures that the approach of automatically generating a system diagnostic system can also be integrated into existing systems without retroactive effects.

In summary, the invention thus relates to a method for generating a system for providing diagnostic information 1, 2, 3 and a corresponding system. Around To simplify the provision of information for the diagnosis of technical systems or technical processes, it is proposed that components 4 of an automation system 5, which have diagnostic interfaces for the provision of diagnostic information 1 for the diagnosis of the respective component 4, are combined in at least one group 6 and that the provision of diagnostic information 2 of the respective group 6 is provided by linking the diagnostic information 1 of the components 4 combined in the respective group 6.

Information on the technical background of the invention is given below. These are based on the specialist articles published by Georg H. Biehler, Wolfram Gierling, on the Internet (http: //www.elektroniknet .de / topics / automatieren / fachthemen /artikel/2001/01018.htm or ... / 01027.htm). "The engineering model" and Joachim Feld, Ronald Lange, Norbert Bechstein, "The runtime model".

The Profibus user organization presented the communication, automation and engineering model PROFInet in August 2000. The growing together of industrial automation with the IT of the higher corporate levels and the global networking of companies at all levels via the Internet is decisive for the fact that the well-known Profibus technology has been expanded vertically. A universal concept for vertical data integration was developed under the term PROFInet. For reasons of consistency, the communication medium Ethernet is used for the higher levels of an automation system, while the consistency with conventional Profibus technology is retained. The PROFInet concept comprises three aspects: A cross-manufacturer engineering concept was defined for the configuration of PROFInet systems. It is based on an engineering object model that can be used not only to develop project planning tools that can use components from different manufacturers, but also with which can also be used to define manufacturer-specific or user-specific functional extensions by means of so-called facets. The clear separation between the manufacturer-specific programming of the individual devices and the plant-wide interconnection with a higher-level engineering tool, the so-called interconnection editor, enables products from different manufacturers to be integrated in one system. PROFInet also specifies an open object-oriented run-time concept. The run-time concept is based on the common mechanisms in the Ethernet sector such as TCP (UDP) / IP. DCOM mechanisms are located above the basic mechanism. Alternatively, an optimized communication mechanism is available for applications with hard real time. The PROFInet components are represented in the form of objects, the communication of which is guaranteed by the mechanisms of the object protocol. The configured interconnections ensure the establishment of communication relationships and the exchange of data between PROFInet nodes. In addition, the term PROFInet is a uniform object-based architecture concept for distributed automation systems from the I / O level to the control level, which seamlessly integrates systems that follow conventional Profibus technology into the overall system. Profibus and other fieldbus systems are integrated into a PROFInet system using proxies. A proxy is a software module that implements the functionality of automation objects for the Profibus participants as well as for the other PROFInet participants on the Ethernet.

By specifying the three aspects mentioned, PROFInet covers all life cycle phases of a distributed automation system. Engineering is the aspect of PROFInet that has the greatest points of contact with users of the technology. This applies equally to the

System designers as well as plant operators. It is also the aspect of PROFInet that has the greatest cost savings potential in the construction and operation of plants, since the costs at the product level have been declining for years and the potential is likely to be largely exhausted. Simplifying handling with the system played an important role in the specification of PROFInet. In this context, engineering tools play an important part. Only with their help can the costs of system builders and operators be significantly reduced. And the engineering of an automation solution with PROFInet actually takes shape

User perspective simple. But the more user-friendly a system is for the user, the more complex it is under the surface. The engineering tool can be expanded dynamically, so that components from any manufacturer can work together smoothly in one engineering tool. A wide variety of engineering aspects such as interconnection, parameterization, testing, commissioning and diagnostics must be made available. Existing (proprietary) programming and engineering tools must continue to be usable. Existing concepts such as OLE for Process Control (OPC) and Fieldbus Device Tool (FDT) must be integrated. PROFInet should interact with other IT processes throughout the company. These include, for example, management information systems (MIS) and enterprise resource planning systems (ERP). Even without special tools, it must be possible to import data into the PROFInet engineering model or to transfer it from the system to other applications such as Excel. Existing fieldbuses, especially Profibus-DP, must be able to be integrated.

Before the properties of the engineering concept are discussed, it is important to present the underlying models. The openness of the system, which is required in many ways, calls for an integrated concept that takes these requirements into account. This is why PROFInet is based on an object-oriented approach - the Component Object Model (COM) from Microsoft. In doing so, self-contained Generates modules whose functionality can be reached externally via clear interfaces, the interfaces of the object. An interface is the combination of a certain set of functions that determine which service should be provided by a server (service provider) for a client (client). In this case one speaks of a component implementing the interface. The type of implementation itself is not prescribed to the creator of a component. Script languages such as Visual Basic for Applications (VBA) can access PROFInet objects via the OLE automation interfaces, which are also standardized by COM. This gives the user a particularly simple way of adapting the functional scope of the PROFInet engineering tool to his specific requirements through his own extensions.

At runtime, a PROFInet automation solution consists of automation objects that communicate with each other, the runtime automation objects, or RT cars for short. These are software components that run on the physical PRO Flnet devices. The interaction of the RT cars must be specified using a project planning tool. For this purpose, the RT cars have correspondences in the project planning tool that contain all the information required for complete project planning: The Engineering System Automation Objects (ES cars). When compiling and loading an application, each ES car becomes a corresponding RT car. So that the configuration tool knows which device an automation object is on, it has a corresponding object in the form of the so-called Engineering System Device (ES device). Strictly speaking, the ES device corresponds to a "logical device". There is also an assignment between "logical" and "physical" devices. Most of the time there is a "1: 1" assignment, which means: Exactly one firmware exists for one hardware (physical device). However, it is also possible for several independent software packages to be to run. Examples of this include devices with free computing power: a PC with slot PLC or a Windows CE device with user interface and PLC component. The term Engineering System Object (ES-Object) is used as a collective name for all objects in the context of the configuration tool. It encompasses everything that the user perceives during configuration and everything that he handles. So it is the "base class" for the engineering objects. The model of the automation solution of a specific system is created by instantiating, interconnecting and parameterizing the ES objects. Triggered by a download, the runtime software is generated by evaluating the engineering model. The PROFInet specification describes an object model that defines the technical framework for the use of ES objects. Based on this, PROFInet-compliant engineering systems can then be implemented. On the other hand, not every manufacturer of PROFInet devices is forced to develop their own project planning tool and thus constantly reinvent the wheel.

The facets represent an important concept for expanding the PROFInet object model. A facet realizes a very specific (partial) range of functions of the ES object and presents itself to the user as a special view of the object. The interconnection facet only looks at the communication relationships of the object to other objects. For the parameterization of the object, the user changes to the parameterization facet. He realizes the assignment of an automation object to a physical device using the device assignment facet. Finally, the interconnection information is downloaded to the devices via the download facet. The PROFInet standard defines several facets. Other facets are application specific. Every component manufacturer who implements automation objects can define their own types of facets. The PROFInet standard ensures that these can be added to the ES object. As an example of such facets diagnostic facets are mentioned which optimally present the specific diagnostic information of the device. The device allocation facet implements the method that determines the devices that are compatible with a certain automation object. This has the advantage that the configuration tool can only display those devices on which the selected automation object can also be run. In the case of devices with fixed functionality, on the other hand, the user can first select the device, whereupon the configuration tool only displays those RT cars that are on it. Device are available.

The PROFInet specification discloses the interface descriptions of a configuration tool, which enables every manufacturer to create their own PROFInet-compliant configuration tool. However, since this tool does not contain any manufacturer-specific implementations, it is possible to use another manufacturer's tool at any time. The engineering tool integrates manufacturer-specific parts via defined interfaces. In line with the basic idea of COM programming, no implementations are prescribed, only defined interfaces are defined. The PROFInet strategy then ensures that communication via the bus functions smoothly, but on the other hand leaves the manufacturers with complete freedom to differentiate themselves from the competition through their own implementations. The advantages of PROFInet are particularly evident in engineering. Since communication no longer has to be programmed, but can be configured, the creation of an automation solution is considerably simplified. The reuse of tested solutions shortens development and commissioning times and can thus contribute to a significant cost reduction.

PROFInet is a universal concept for vertical data integration, deliberately avoiding Profibus-specific communication mechanisms and instead using open ones Standards were set to enable fieldbus-independent communication. The PROFInet concept defines an object model for the engineering system, which is implemented using Microsoft's COM component technology. The specific connection between different components is described by XML (eXtensible Markup Language). The seven layers of the ISO / OSI reference model must be defined for the runtime system. Ethernet with the TCP / IP protocol suite up to layer 4 is suitable for the equal communication of autonomous functional units. These include protocols such as TCP, UDP or ICMP, which are undisputed de facto standards in the IT landscape. But what is layer 7 like? In the PROFInet concept, components ("objects") are formed that can only be reached from the outside via their interfaces ("interfaces"). An interface is the combination of a certain set of functions and thus a kind of contract. It determines which service is to be provided by a server (service provider) for a client (client). In this case one speaks of a component implementing the interface. However, the type of implementation itself is not mandatory for the creator of a component. It therefore makes sense to use an object protocol for communication at runtime between the components. PROFInet uses Microsoft DCOM (Distributed COM) for this. DCOM is the extension of COM technology for distributed applications. It is based on the DCE RPC (Distributed Computing Environment Remote Procedure Call) standard. One of the most important advantages of DCOM is that the same component technology is used for engineering and runtime. So far, DCOM has primarily been implemented on PC architectures. In the embedded area, it is not necessary to implement the entire DCOM, such as within Microsoft Windows. It is sufficient to implement the part that is visible in the network via the so-called DCOM Wire Protocol and has been published as an Internet draft. Programming can be unchanged within embedded devices stay. In particular, no strict COM architecture has to be implemented. All ways of implementing the automation objects as COM objects with appropriate interfaces are permitted, as long as the PROFInet object impression is preserved from the outside. For example, in the case of a control system, the objects are created in the language required for this control system and executed as blocks.

As in engineering, even in runtime mode the syntax is defined by (D) COM technology, but the specific additions for automation technology still have to be defined (semantics). For this purpose, the interfaces of the automation objects in PROFInet can be divided into four categories depending on the functionality they cover:

Mandatory Inter ces: These interfaces define a standard that all resources (devices) of a PROFInet-based automation solution must implement. In addition to the interfaces defined by COM - such as identification - support for data and event interconnection is a mandatory function.

Optional interfaces: These are options that not every device has to provide. However, if this function is to be provided, the interface implementation is mandatory after submission.

Device-specific interfaces: Are the interfaces that enable access to device-specific services. These interfaces cannot be standardized and are usually implemented in firmware. The objects that implement the device-specific interfaces form the device object model.

Application-specific interfaces: Here, the required application-specific automation objects are developed with programming tools, which may be target-system-specific. PROFInet defines a runtime object model that every PROFInet device operated on Ethernet must implement. Each of the available objects is realized by a DCOM object. In detail, these are:

The Physical Device Object (PDev): It represents the device as a whole. It serves as an entry point for other devices, i.e. the first contact with a PROFInet device is via this object. The PDev exposes the physical properties of the component. Exactly one instance of the PDev exists on each hardware component (PLC, drive, PC).

The Logical Device Object (LDev): It represents the actual program carrier, that is, the parts of the device that represent the actual PROFInet nodes. The distinction between physical and logical device is generally unnecessary for embedded devices, but this distinction is important for runtime systems on a PC, since, for example, two SoftPLCs can run on one PC. In this case, the PC is the physical device, and the SoftPLC is a logical device. The logical device has interfaces for querying the operating status, time, group and detailed diagnostics.

Runtime automation objects (RT-Auto): They represent the actual technological functionality of the device. The interfaces of the objects are therefore dependent on the task that the object performs. For example, a lifting table has an interface for moving the table. An interface can contain data (reading, writing) as well as methods and events.

The representatives of LDev and RT-Auto in engineering are the ES device and the ES-Auto described above. The most important object for interaction with other PROFInet devices is the ACCO (Active Control Connec- tion object). This object is used to set up communication relationships between objects. The ACCO implements a consumer provider model. The elements of the RT car interfaces are made available to other devices via the ACCO (provider). The ACCO also registers with ACCOs of other devices and supplies the RTAutos of its device with data or events (consumer). Communication relationships are always established from the consumer side. A data or event interconnection between two objects (for example, two successive conveyor elements) can be easily specified by configuring the connection on the consumer side. The ACCO then independently takes care of the establishment of the communication relationship and the exchange of data. An important aspect of the ACCO is error handling. This includes the transmission of quality code and timestamp with the values as well as the automatic activation of a configured replacement value in the event of an error. Furthermore, the monitoring of the communication partner, the reconnect after loss of connection as well as the diagnosis and test options for interconnections. The transmission with DCOM is event-driven, which means that the provider monitors its data for changes. The underlying layers ensure the connection is secured.

Claims

claims

1. A method for generating a system for providing diagnostic information (1, 2, 3), in which method components (4) of an automation system (5) have, which diagnostic interfaces for providing diagnostic information (1) for diagnosing the respective component (4) , are combined in at least one group (6) and the provision of diagnostic information (2) of the respective group (6) is provided by linking the diagnostic information (1) of the components (4) combined in the respective group (6).

2. The method according to claim 1, characterized in that in at least one higher-level group (7) groups (6) and / or components (4) are combined, the generation of diagnostic information (3) of the respective higher-level group (7) by linking the Diagnostic information (1, 2) of the groups (β) or components (4) combined in the respective superordinate group (7) is provided.

3. The method according to claim 1 or 2, that the components (4) are components of a system layout and that the linking of the diagnostic information (1, 2, 3) takes place as a function of information contained in the system layout.

4. The method according to claim 3, so that the tasks and networking of the components (4) are predetermined by the system layout.

5. The method according to claim 3 or 4, characterized in that the group (β) belongs to the higher-level group (7) in the system layout.

6. The method according to any one of the preceding claims, that the diagnostic information (1, 2, 3) is constructed in a semantically identical manner.

7. The method as claimed in one of the preceding claims, that the diagnostic information (1, 2, 3) contains functions which link input variables and provide at least one output variable as a result of the combination of the input variables.

8. The method according to any one of the preceding claims, characterized in that the components (4) and the groups (6, 7) are assigned classes which define the functions and properties of the respective component (4) or group (6, 7) ,

9. The method according to any one of the preceding claims, d a d u r c h g e k e n n z e i c h n e t that the automation system (5) is a distributed, component-based automation system.

10. The method according to any one of the preceding claims, d a d u r c h g e k e n n z e i c h n e t that the components (4) are PROFInet components.

11. System for providing diagnostic information (1, 2, 3), with components (4) of an automation system (5) combined in at least one group (6), which diagnostic interfaces for providing diagnostic information (1) for diagnosing the respective component (4), whereby means for providing diagnostic information (2) of the respective group (6) by linking the diag- noseinfor ations (1) of the components (4) combined in the respective group (6) are provided.

12. System according to claim 11, characterized in that in at least one higher-level group (7) groups (6) and / or components (4) are combined, means for generating diagnostic information (3) of the respective higher-level group (7) by linking the diagnostic information (1, 2) of the groups (6) or components (4) combined in the respective higher-level group (7) are provided.

13. The system as claimed in claim 11 or 12, that the components (4) are components of a system layout and that the system layout contains information for linking the diagnostic information (1, 2, 3).

14. System according to claim 13, so that the system layout contains specifications regarding tasks and networking of the components (4).

15. System according to claim 13 or 14, so that the groups (6) belonging to the superordinate group (7) are defined in the system layout.

16. System according to one of claims 11 to 15, so that the diagnostic information (1, 2, 3) is structured semantically in the same way.

17. System according to one of claims 11 to 16, characterized in that the diagnostic information (1, 2, 3) contains functions which link input variables and provide at least one output variable as a result of linking the input variables.

18. System according to one of claims 11 to 17, characterized in that the components (4) and the groups (6, 7) are assigned classes which define the functions and properties of the respective component (4) or group (6, 7) ,

19. System according to one of claims 11 to 18, d a d u r c h g e k e n n e e c h n e t that the automation system (5) is a distributed, component-based automation system.

20. System according to one of claims 11 to 19, so that the components (4) are PROFInet components.

21. The system as claimed in one of claims 11 to 20, so that means for visualizing the diagnostic information (1, 2, 3) are provided on the basis of the system layout.

22. Use of the system according to one of claims 11 to 21 for diagnosing a technical system or a technical process (8).