EP1664954A1 - Mise a disposition d'informations de diagnostic - Google Patents

Mise a disposition d'informations de diagnostic

Info

Publication number
EP1664954A1
EP1664954A1 EP04764423A EP04764423A EP1664954A1 EP 1664954 A1 EP1664954 A1 EP 1664954A1 EP 04764423 A EP04764423 A EP 04764423A EP 04764423 A EP04764423 A EP 04764423A EP 1664954 A1 EP1664954 A1 EP 1664954A1
Authority
EP
European Patent Office
Prior art keywords
components
diagnostic
diagnostic information
group
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP04764423A
Other languages
German (de)
English (en)
Inventor
Markus Bregulla
Ralph BÜSGEN
Clemens Dinges
Joachim Feld
Daniel Grossmann
Michael Schlereth
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Publication of EP1664954A1 publication Critical patent/EP1664954A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0243—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model
    • G05B23/0245—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model based on a qualitative model, e.g. rule based; if-then decisions
    • G05B23/0251—Abstraction hierarchy, e.g. "complex systems", i.e. system is divided in subsystems, subsystems are monitored and results are combined to decide on status of whole system
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C3/00—Registering or indicating the condition or the working of machines or other apparatus, other than vehicles

Definitions

  • 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.
  • 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.
  • 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.
  • 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.
  • the invention provides an access path to component diagnostics.
  • 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.
  • 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.
  • 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.
  • 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.
  • ⁇ diagnostic subsystems based on the layout.
  • the diagnostic subsystems do not have to be congruent with the elements of the technological hierarchy (subsystems, units, ...) required for operational management.
  • 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.
  • tasks and networking of the components are also predetermined by the system layout.
  • the diagnostic information is structured semantically in the same way.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • the technical functionality of a device represented by the runtime automation object A can be described in the simplest way.
  • 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.
  • the generated diagnostic function checks the status of the respective object and calls the diagnostic function of the associated logical device object L.
  • the diagnostic function may generate an error message with a description.
  • 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.
  • 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.
  • 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.
  • 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.
  • consistency rules 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.
  • the rules are then incorporated into the characteristics of the diagnostic functions.
  • the defined rules are included directly in the diagnostic function, in FIG. 3 the diagnostic function 17.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the definition of subsystems for diagnosis can be used, for example.
  • B. by marking the components belonging to a subsystem.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • script functions can e.g. B. run in a so-called system diagnostic server and work the diagnostic functions.
  • 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.
  • the invention thus relates to a method for generating a system for providing diagnostic information 1, 2, 3 and a corresponding system.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • PROFInet 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
  • 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.
  • MIS management information systems
  • ERP enterprise resource planning systems
  • PROFInet is based on an object-oriented approach - the Component Object Model (COM) from Microsoft.
  • COM Component Object Model
  • 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.
  • VBA Visual Basic for Applications
  • 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.
  • 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".
  • 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 adopt 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.
  • the user changes to the parameterization facet. He realizes the assignment of an automation object to a physical device using the device assignment facet.
  • 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.
  • 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).
  • 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?
  • 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.
  • 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.
  • 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.
  • 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.
  • the PC is the physical device
  • the SoftPLC is a logical device.
  • the logical device has interfaces for querying the operating status, time, group and detailed diagnostics.
  • Runtime automation objects They represent the actual technological functionality of the device.
  • the interfaces of the objects are therefore dependent on the task that the object performs.
  • 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.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

L'invention concerne un procédé pour créer un système servant à mettre à disposition des informations de diagnostic (1,2,3), ainsi qu'un système correspondant. L'objectif de l'invention est de simplifier la mise à disposition d'informations servant au diagnostic d'installations ou de processus techniques. A cet effet, les composants (4) d'un système d'automatisation (5), qui présentent des interfaces de diagnostic servant à la mise à disposition d'informations de diagnostic (1) utilisées pour le diagnostic des composants respectifs (4), sont réunis au sein d'au moins un groupe (6). En outre, la mise à disposition des informations de diagnostic (2) du groupe respectif (6) est réalisée par combinaison des informations de diagnostic (1) des composants (4) réunis au sein du groupe respectif (6).
EP04764423A 2003-09-19 2004-08-24 Mise a disposition d'informations de diagnostic Withdrawn EP1664954A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10343963A DE10343963A1 (de) 2003-09-19 2003-09-19 Bereitstellung von Diagnoseinformationen
PCT/EP2004/009445 WO2005036290A1 (fr) 2003-09-19 2004-08-24 Mise a disposition d'informations de diagnostic

Publications (1)

Publication Number Publication Date
EP1664954A1 true EP1664954A1 (fr) 2006-06-07

Family

ID=34306027

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04764423A Withdrawn EP1664954A1 (fr) 2003-09-19 2004-08-24 Mise a disposition d'informations de diagnostic

Country Status (4)

Country Link
US (1) US7774167B2 (fr)
EP (1) EP1664954A1 (fr)
DE (1) DE10343963A1 (fr)
WO (1) WO2005036290A1 (fr)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10161114A1 (de) * 2001-12-12 2003-07-03 Siemens Ag System und Verfahren zur Modellierung und/oder Realisierung von Softwareanwendungen, insbesondere MES-Anwendungen
DE102004062432A1 (de) * 2004-12-20 2006-06-29 Abb Research Ltd. System und Verfahren zum automatischen Erstellen, Installieren und Konfigurieren von Erweiterungen der Funktionalitäten in den Systemknoten eines verteilten Netzwerks
DE102005031666A1 (de) * 2005-07-05 2007-01-11 Endress + Hauser Wetzer Gmbh + Co Kg Verfahren zum Betreiben einer Datenspeichereinheit für die Prozessautomatisierungstechnik
EP1999661A1 (fr) 2006-03-28 2008-12-10 Siemens Aktiengesellschaft PROCEDE POUR LA PLANIFICATION D'UNE INSTALLATION TECHNIQUE EN TENANT COMPTE DE LA TOPOLOGIE ET DE specifications DE VISUALISATION
US7975184B2 (en) * 2006-04-03 2011-07-05 Donald Goff Diagnostic access system
DE102006047262A1 (de) 2006-10-04 2008-04-10 Endress + Hauser Gmbh + Co. Kg Verfahren zum Testen einer Elektronikeinheit
US8640056B2 (en) 2007-07-05 2014-01-28 Oracle International Corporation Data visualization techniques
US8910084B2 (en) * 2007-05-07 2014-12-09 Oracle International Corporation Aggregate layout for data visualization techniques
US9477732B2 (en) 2007-05-23 2016-10-25 Oracle International Corporation Filtering for data visualization techniques
US8467913B2 (en) 2007-10-31 2013-06-18 Airbus Operations Gmbh Method and arrangement for providing a fault diagnosis for at least one system
DE102007052139A1 (de) * 2007-10-31 2009-05-20 Airbus Deutschland Gmbh Verfahren und Anordnung zum Bereitstellen einer Fehlerdiagnose für zumindest ein System
AT10302U3 (de) * 2008-08-04 2009-10-15 Avl List Gmbh Erzeugen einer ablauffähigen konfiguration
US8255875B2 (en) * 2008-09-30 2012-08-28 Rockwell Automation Technologies, Inc. Application builder for industrial automation
US9396241B2 (en) 2009-07-15 2016-07-19 Oracle International Corporation User interface controls for specifying data hierarchies
EP2434360B1 (fr) * 2010-09-22 2020-01-08 Siemens Aktiengesellschaft Système de contrôle de mouvement
DE102011005062A1 (de) * 2011-03-03 2012-09-06 Endress + Hauser Process Solutions Ag Verfahren zum Bereitstellen von Daten eines Feldgeräts
KR101243441B1 (ko) * 2011-04-27 2013-03-13 엘에스산전 주식회사 재구성 가능한 컴포넌트 기반의 ｐｌｃ 시뮬레이터
US20130226892A1 (en) * 2012-02-29 2013-08-29 Fluential, Llc Multimodal natural language interface for faceted search
DE102012106477A1 (de) * 2012-07-18 2014-01-23 Endress + Hauser Conducta Gesellschaft für Mess- und Regeltechnik mbH + Co. KG Messsystem
US9600792B2 (en) * 2013-04-11 2017-03-21 Siemens Aktiengesellschaft Method and apparatus for generating an engineering workflow
DE102016107104A1 (de) * 2016-04-18 2017-10-19 Endress + Hauser Process Solutions Ag Verfahren zur Zustandsüberwachung einer Anlage der Prozessautomatisierung
DE102016125349A1 (de) * 2016-12-22 2018-06-28 Endress + Hauser Process Solutions Ag Bereitstellung von Informationen zur Gerätegesundheit von Feldbuskomponenten
WO2020160769A1 (fr) * 2019-02-06 2020-08-13 Siemens Aktiengesellschaft État du diagnostic dépendant de l'utilisation dans les systèmes modulaires
EP3929679A1 (fr) * 2020-06-23 2021-12-29 ABB Schweiz AG Système d'ingénierie pour l'orchestration d'une installation industrielle

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10008020A1 (de) * 1999-02-22 2000-08-24 Fisher Rosemount Systems Diagnosevorrichtung in einem Prozeßsteuersystem, das Mehrgrößen-Regeltechniken verwendet

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
YU31287A (en) 1986-04-16 1989-04-30 Siemens Ag Mutual controlling system
DE59407119D1 (de) * 1993-09-02 1998-11-26 Siemens Ag Datenverarbeitungsanlage zur Überwachung von Betriebszuständen einer technischen Anlage
WO1996020439A1 (fr) * 1994-12-27 1996-07-04 Siemens Aktiengesellschaft Systeme assiste par ordinateur pour detecter l'incident a l'origine d'une panne dans une installation technique
US5963886A (en) * 1996-05-31 1999-10-05 Eskom Selective monitoring system
DE19732046A1 (de) 1997-07-25 1999-01-28 Abb Patent Gmbh Prozeßdiagnosesystem und Verfahren zur Diagnose von Vorgängen und Zuständen eines technischen Prozesses
DE19742448C1 (de) 1997-09-26 1998-12-17 Daimler Benz Ag Diagnosemodul zum Erstellen einer Diagnose für elektrisch ansteuerbare Systeme und Diagnoseeinrichtung zum Erstellen einer Gesamtsystemdiagnose
US6298454B1 (en) * 1999-02-22 2001-10-02 Fisher-Rosemount Systems, Inc. Diagnostics in a process control system
EP1198739B1 (fr) * 1999-07-28 2003-04-02 Siemens Aktiengesellschaft Procede et systeme de diagnostic pour une installation technique
GB2362481B (en) * 2000-05-09 2004-12-01 Rolls Royce Plc Fault diagnosis
DE10133375A1 (de) 2001-07-10 2003-01-30 Daimler Chrysler Ag Verfahren und Vorrichtung zum automatischen Erstellen eines Bayes-Netzwerks
DE10155090A1 (de) 2001-11-09 2003-05-22 Siemens Ag Bereitstellung von Informationen in einem Automatisierungssystem

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10008020A1 (de) * 1999-02-22 2000-08-24 Fisher Rosemount Systems Diagnosevorrichtung in einem Prozeßsteuersystem, das Mehrgrößen-Regeltechniken verwendet

Also Published As

Publication number Publication date
WO2005036290A1 (fr) 2005-04-21
DE10343963A1 (de) 2005-04-14
US7774167B2 (en) 2010-08-10
US20060259243A1 (en) 2006-11-16

Similar Documents

Publication Publication Date Title
WO2005036290A1 (fr) Mise a disposition d'informations de diagnostic
DE112005001031B4 (de) Grafisches Bildschirmkonfigurationsgerüst für vereinheitlichte Prozesssteuerungssystemoberfläche
EP1738236B1 (fr) Reseau d'automatisation a composantes reseau produisant des messages d'etat
EP1454280B1 (fr) Systeme et procede de test et/ou de debogage de systemes d'execution destines a resoudre des problemes mes
EP0852759A1 (fr) Procede de conception pour systemes industriels et systemes de construction, et systeme de planification assiste par ordinateur a utiliser dans le cadre dudit procede
DE10049049A1 (de) System und Verfahren zur Konfiguration einer Prozeßsteuerung zur Verwendung mit einem Profibus-Einrichtungsnetzwerk
DE102016124348A1 (de) System und Mikroservice zum Überwachen einer Anlage der Prozessautomatisierung
DE102010029952A1 (de) Verfahren zum Integrieren von zumindest einem Feldgerät in ein Netzwerk der Automatisierungstechnik
DE10206902A1 (de) Engineeringverfahren und Engineeringsystem für industrielle Automatisierungssysteme
EP1182528A2 (fr) Commande industrielle basée sur des objets technologiques distribués
EP1527554A2 (fr) Reseau informatique comportant des noeuds informatiques de diagnostic
WO2008068333A1 (fr) Système de commande ainsi que procédé pour la configuration d'un système de commande
WO2011138375A1 (fr) Procédé et système de production de paramètres de surveillance dans un environnement industriel se basant sur une architecture orientée services (aos)
EP2042956A2 (fr) Interface entre un système de gestion de la fabrication et un système d'automatisation
EP2718774A1 (fr) Système de simulation, procédé permettant d'effectuer une simulation, système de guidage et produit de programme informatique
EP1137972B1 (fr) Systeme d'automatisation pour la realisation de taches definies dans le cadre de la technique des processus, et procede associe
EP2557464B1 (fr) Procédé destiné au fonctionnement d'un système d'automatisation
EP2718775A1 (fr) Système de simulation, procédé permettant d'effectuer une simulation, système de guidage et produit-programme informatique
EP3652595B1 (fr) Procédé et système pour surveiller une installation de la technologie d'automatisation
DE10354146A1 (de) Verfahren zur Entwicklung und Implementierung eines Modells zur formalen Beschreibung von mehrere verteilte Komponenten aufweisenden kollaborativen Systemen, insbesondere von intelligenten flexiblen Produktionsautomatisierungssystemen
EP1233318A1 (fr) Composants de software d'un système de commande décentralisé
DE10394242T5 (de) Verfahren und Instrument zur Zuweisung von Rechenressourcen in einem verteilten Steuersystem
EP2360540B1 (fr) Support de données doté de graphiques pour la configuration de systèmes d'entraînement et ordinateur doté d'une interface utilisateur graphique
LU500646B1 (de) Technik zur Bereitstellung einer Diagnosefunktionalität für eine auf einer speicherprogrammierbaren Steuerung basierenden Anwendung
DE10033812A1 (de) Verfahren zum Erzeugen von Informationsmodellen

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060316

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB IT

RIN1 Information on inventor provided before grant (corrected)

Inventor name: DINGES, CLEMENS

Inventor name: GROSSMANN, DANIEL

Inventor name: BREGULLA, MARKUS

Inventor name: BUESGEN, RALPH

Inventor name: SCHLERETH, MICHAEL

Inventor name: FELD, JOACHIM

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB IT

17Q First examination report despatched

Effective date: 20070309

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20170203