EP1664954A1 - Bereitstellung von diagnoseinformationen - Google Patents
Bereitstellung von diagnoseinformationenInfo
- 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
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
Description
Claims
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 (de) | 2003-09-19 | 2004-08-24 | Bereitstellung von diagnoseinformationen |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1664954A1 true EP1664954A1 (de) | 2006-06-07 |
Family
ID=34306027
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP04764423A Withdrawn EP1664954A1 (de) | 2003-09-19 | 2004-08-24 | Bereitstellung von diagnoseinformationen |
Country Status (4)
Country | Link |
---|---|
US (1) | US7774167B2 (de) |
EP (1) | EP1664954A1 (de) |
DE (1) | DE10343963A1 (de) |
WO (1) | WO2005036290A1 (de) |
Families Citing this family (24)
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 |
WO2007110005A1 (de) | 2006-03-28 | 2007-10-04 | Siemens Aktiengesellschaft | Verfahren zum projektieren einer technischen anlage unter berücksichtigung von topologie und visualisierungsvorgaben |
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 |
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 |
US8640056B2 (en) | 2007-07-05 | 2014-01-28 | Oracle International Corporation | Data visualization techniques |
DE102007052139A1 (de) * | 2007-10-31 | 2009-05-20 | Airbus Deutschland Gmbh | Verfahren und Anordnung zum Bereitstellen einer Fehlerdiagnose für zumindest ein System |
US8467913B2 (en) | 2007-10-31 | 2013-06-18 | Airbus Operations Gmbh | Method and arrangement for providing a fault diagnosis for at least one 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 (de) * | 2010-09-22 | 2020-01-08 | Siemens Aktiengesellschaft | Bewegungssteuerungssystem |
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 | 엘에스산전 주식회사 | 재구성 가능한 컴포넌트 기반의 plc 시뮬레이터 |
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 (de) * | 2019-02-06 | 2020-08-13 | Siemens Aktiengesellschaft | Nutzungsabhängiger diagnosestatus in modularen anlagen |
EP3929679A1 (de) * | 2020-06-23 | 2021-12-29 | ABB Schweiz AG | Engineering-system für orchestration einer industrieanlage |
Citations (1)
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)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
YU31287A (en) | 1986-04-16 | 1989-04-30 | Siemens Ag | Mutual controlling system |
EP0643345B1 (de) * | 1993-09-02 | 1998-10-21 | Siemens Aktiengesellschaft | Datenverarbeitungsanlage zur Überwachung von Betriebszuständen einer technischen Anlage |
WO1996020439A1 (de) * | 1994-12-27 | 1996-07-04 | Siemens Aktiengesellschaft | Rechnergestützte einrichtung zur erkennung einer einen störfall auslösenden störfallursache in einer technischen anlage |
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 (de) * | 1999-07-28 | 2003-04-02 | Siemens Aktiengesellschaft | Diagnoseverfahren und diagnosesystem für eine technische anlage |
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 |
-
2003
- 2003-09-19 DE DE10343963A patent/DE10343963A1/de not_active Withdrawn
-
2004
- 2004-08-24 US US10/570,003 patent/US7774167B2/en not_active Expired - Fee Related
- 2004-08-24 WO PCT/EP2004/009445 patent/WO2005036290A1/de active Application Filing
- 2004-08-24 EP EP04764423A patent/EP1664954A1/de not_active Withdrawn
Patent Citations (1)
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 |
---|---|
US7774167B2 (en) | 2010-08-10 |
DE10343963A1 (de) | 2005-04-14 |
WO2005036290A1 (de) | 2005-04-21 |
US20060259243A1 (en) | 2006-11-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2005036290A1 (de) | Bereitstellung von diagnoseinformationen | |
DE112005001031B4 (de) | Grafisches Bildschirmkonfigurationsgerüst für vereinheitlichte Prozesssteuerungssystemoberfläche | |
EP1738236B1 (de) | Automatisierungsnetzwerk mit zustandsmeldenden netzwerkkomponenten | |
EP1454280B1 (de) | System und verfahren zum testen und/oder debuggen von laufzeitsystemen zur lösung von mess-aufgaben | |
EP0852759A1 (de) | Entwurfsverfahren für die anlagentechnik und rechnergestütztes projektierungssystem zur verwendung bei diesem verfahren | |
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 (de) | Industrielle Steuerung auf der Basis verteilbarer Technologischer Objekte | |
WO2004014022A2 (de) | Rechnernetzwerk mit diagnoserechnerknoten | |
EP2567297A1 (de) | Verfahren und system zur bereitstellung von monitoring-kenngroessen in einem soa-basierten industriellen umfeld | |
WO2008068333A1 (de) | Steuerungssystem sowie verfahren zur konfiguration eines steuerungssystems | |
EP2042956A2 (de) | Schnittstelle zwischen einem Fertigungsmanagementsystem und einem Automatisierungssystem | |
EP2718774A1 (de) | Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt | |
WO2012168214A1 (de) | Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt | |
AT412131B (de) | Automatisierungssystem zur lösung einer prozesstechnischen aufgabenstellung und verfahren hierzu | |
EP2557464B1 (de) | Verfahren zum Betrieb eines Automatisierungssystems | |
WO2012168217A1 (de) | Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt | |
WO2024046817A1 (de) | Dds-fähiger controller | |
EP3652595B1 (de) | Verfahren und system zum überwachen einer anlage der automatisierungstechnik | |
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 (de) | Softwarekomponente für ein verteiltes Kontrollsystem | |
DE10394242T5 (de) | Verfahren und Instrument zur Zuweisung von Rechenressourcen in einem verteilten Steuersystem | |
EP2360540B1 (de) | Datenträger mit Schaubildern zur Konfiguration eines Antriebssystems und Rechner mit graphischer Benutzerschnittstelle |
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 |