WO2002019044A2

WO2002019044A2 - Device and method for the integrated monitoring, control and regulation of complex technical process flows

Info

Publication number: WO2002019044A2
Application number: PCT/EP2001/009842
Authority: WO
Inventors: Markus Gillich; Roland Dirks
Original assignee: Markus Gillich; Roland Dirks
Priority date: 2000-08-28
Filing date: 2001-08-27
Publication date: 2002-03-07
Also published as: WO2002019044A3; EP1314070A2

Abstract

The invention relates to a device for the integrated monitoring, control and regulation of complex technical process flows. Said device comprises at least one central kernel with an integrated access control, a separate control for the management of tasks, threads, memories and network capacities and a hierarchic object-tree management structure comprising functions for the program-controlled or manual accumulation and distribution of data elements, the management and communication of services and central kernels, together with their corresponding data structures.

Description

Device and method for integrated monitoring, control and regulation of complex technical processes

The present invention relates to a device and a method for modeling, integrated monitoring, control, regulation and data storage of preferably multi-part devices and complex technical processes. The invention also relates to the use of the devices mentioned for complex technical processes.

It is known and customary in the process automation of complex automated industrial plants for operation, observation and information to form virtual components of real devices and to link them within one or more networked data processing systems of a distributed data processing system by means of a superordinate model structure to an overall model. The resulting overall model then forms an image of the real industrial plant on the data processing systems mentioned. Furthermore, it is known that by coupling the model to the real system with the aid of information transmission and reception devices, the technical system can be operated and observed, and a control and regulation system for the industrial system is thus created. Furthermore, it is known that cross-references, which implement the real technical links of the industrial plant, can be used to navigate sensibly in the model formed in accordance with the technical / physical effects. In addition, it is known that the control system can be supplied with additional information (for example, documentation) via further local or global data (for example, via the Internet) "hooked" into the model structure. It is also known that the models formed in this way can be used an Internet connection can be operated from anywhere in the world. A corresponding prior art is, for example, the publication with the number DE 19834456. As an example of a distributed data processing system with a central control module for processing technical processes, reference is made to the published patent application DE 19741959A1.

The disadvantages of the prior art described lie essentially in the largely centralized structures. Due to the supposedly simpler and clear administration, security and manageability compared to completely decentralized systems, the model formed is usually formed on only one or a few data processing systems and with the tasks of visualization, operation, observation, data storage, information transfer and sometimes also with control and control tasks for the entire complex automation system. All essential functions are only offered at one or a few nodes, but are not provided at a decentralized point on the automation system itself. The scalability of the model and the services used on it is severely restricted by the technical performance limits of the central system. The disadvantages of the central nodes continue to be that fast and powerful and therefore very expensive data processing systems with a high storage capacity are required. In addition, a high load on the network infrastructure in the area of the central data processing systems is the result, especially with fast sampling rates of the monitoring. This makes the efficient use of conventional systems on widely distributed slow networks, such as the worldwide Internet, almost impossible at a reasonable cost. One example is the integrated monitoring, control and regulation of several thousand wind turbines within a virtual one Large power plant called.

The failure probabilities of a few highly stressed systems are significantly higher compared to many decentralized systems. With centralized systems, the information required is essentially only at a few locations, but not at the machines on site, where it is frequently used (e.g. for control processes and for maintenance and repair work). This results in frequent, actually unnecessary data transfers. The consequences of a failure of central structures are much higher than with distributed structures. This starts with the possibility of extensive data loss in the event of damage to data carriers, extends to the loss of accessibility in the event of damage to the network infrastructure and can result in the total failure of the entire automation system should central IT structures fail or need maintenance. Damage to the central data processing systems must not only be caused by the systems themselves, but can also be caused by external influences in systems connected to the Internet. Frequently recurring attacks of various kinds on large central web servers with sometimes devastating effects (total failure of the affected systems) have become the rule on the Internet as the exception. Complex industrial plants with centralized data processing functions are at risk in the same way if the central data processing systems communicate with each other and with users via the Internet. Further disadvantages lie in the fact that large central models can only be administered centrally, which is very labor-intensive and extremely complex. Central administration does not allow a quick and easy decentralization of the models to large structural changes. The successive interconnection of several models is generally excluded. Central models also do not allow Information and operating structure (e.g. global, area and local overview) adapted to the respective location on the technical systems on site, but generally only allow a single standard view of the model. In addition, it is not common to integrate other DV systems (e.g. process controls) that are decentralized in the automation system into a decentralized, virtually centralized visualization and management principle, and to design operating and monitoring systems and other services for differentiated multi-user operation.

The object of the present invention is to achieve the performance features of the known prior art on distributed data processing systems, while avoiding the disadvantages mentioned above. In addition, the invention is intended to offer additional performance features which exceed the current state of the art and, above all, relate to the automation and organization of distributed technical systems in large numbers.

The invention relates to a device for integrated monitoring, control, regulation, analysis and data storage of complex technical processes based on individual measurement

Analysis, control, operating and monitoring and

Storage devices.

This object is achieved by a device which has at least one central kernel, each with an integrated access control, separate control for the management of tasks, threads, memory, network capacities and a hierarchically structured object tree management with integrated function for program-controlled or manual collection and distribution of data elements, Administration and communication of services and other central kernels including associated data structures (MetaOS nodes). The device can have spatially and / or thematically related physical or logical devices or further central kernels as clients or server services of the MetaOS node, which can simultaneously communicate with the object tree management of the central kernel if required, and at least one service of the device can have external interfaces for operating and monitoring the distributed Have data processing system. The device can furthermore be designed such that a local central kernel is expanded during operation by any data services and further central kernels as required, and any data services and further central kernels are removed as required. Other external central kernels and the services of a central kernel have object trees assigned and standardized, hierarchically structured object trees which are assigned to the respective prophetic individual devices. The object trees of the services or their parts are assigned to the object tree management of the central kernel at any point (mounted) and via an optional program-controlled projection procedure based on sequences, priorities, filters and operators to a resulting object tree with elements that are combined from objects of several services , merged (synchronized) and saved. Each element of the object trees of services and central kernels can consist of any data object and optionally any number of metadata objects assigned to the data object and a hierarchically structured tree of header data objects can be assigned to each data and metadata object. All object tree elements of all data services, central kernel and header data objects of the distributed data processing system always have an identical one Basic structure on.

Objects, metadata objects and header data objects of an element of the central kernel can continue to be projected into the element in any combination with the basic projection method from the services of the central kernel and from further central kernels. The header data objects of each data and metadata object of a central kernel can contain timing information for synchronization, information about resources the local location (CPU, memory, network capacities), log and error information, information on user management and authentication, security, transport, popularity and priority properties and status of the data object, as well as complete information on the type and current status of the operator control and monitoring devices and

Contain description information about the objects and summarized information about hierarchically lower-lying object structures, which are mounted and projected from various specialized data services and further central kernels into a common header object structure of the element.

The same information types of the header data objects from any central kernel can also be projected onto a common header data object by mounting and program-controlled synchronization.

Data, metadata or header data objects from object trees, which are mounted by different data services and other central kernels in the same location in the object directory of the central kernel, can be synchronized with the central kernel using projection priorities and syntactic, semantic, logical and numerical program-controlled filters and operators get saved. Finally, any objects, elements and substructures can be one Central kernel with any objects, elements and substructures of other local data services, user interfaces or central kernels and with any objects, elements and structures of your own central kernel with the help of a common command language for all brushes and communication processes between objects, elements and structures mounted, filtered, with operators linked and synchronized. If required, data, metadata and header data objects of hierarchically higher-level as well as subordinate tree elements can be mounted and synchronized by specifying relative mount marks.

An index of synchronized object directories, data objects and metadata objects is also created in each central kernel of the data processing system.

The invention also relates to methods for integrated monitoring, control, regulation, analysis and data storage of preferably multi-part complex technical processes by any participant in the distributed data processing device, wherein individual information, information lists and hierarchically organized information structures from data, status and function interfaces of the individual measurement , Analysis, storage, regulating, operating and monitoring devices and from central kernels can be encapsulated by program-controlled information projection as required in the respective object trees of the assigned services. According to the invention, any services mounting the central kernel and further central kernel can read, observe and analyze about the information projected and stored in the central kernel from all devices assigned to the central kernel and the global and regional directory, and can describe and thus describe the opposite process with information operate, observe and regulate.

Furthermore, each data object and metadata object of a data service or central kernel can encapsulate time-variable information from the technical devices by program-controlled synchronization

The program-controlled synchronization of object structures and objects can be controlled by schedulers in the data services, which take their timing information from the header data objects of the object trees. Starting from an initially individual central kernel, a logically linked hierarchy of central kernels can be formed from distributed object holdings, so that each central kernel of the hierarchy is given access to a resulting, uniformly global, a different regional and a locally private object tree from decentralized services and elements, in that each node forms a mounting scheme, so that each node synchronizes local data services into a local private and a local public directory, mounts and synchronizes a fixed global directory of the hierarchically higher directory to the root element of its own central core, and public local object holdings to the public object holdings of the parent Mounts and synchronizes nodes in the local global directory and mounts public regional object holdings of the subordinate nodes to its own regional object tree. In addition, each central kernel synchronizes databases of the virtual center and databases of other central kernels and simulates temporarily inactive failed central kernels with these synchronized databases for the period of the failure. Furthermore, to increase the structural stability, each central kernel in the network mounts and synchronizes all directories of all other central kernels from a logically connected group of central kernels Group in a range directory defined for the entire group and thus forms a “symbiosis”. According to the invention, timing information for synchronization, information about resources of the local location (CPU, memory, network capacities), log and error information stored decentrally in the header objects of services , Information on user administration and authentication, security, transport, popularity and priority properties and status of the data objects, as well as information on the type and status of the operating and monitoring devices as well as description information on the objects and summarized information on hierarchically lower-level object structures in their own private directories , regional area directories and uniform global directories for all central kernels are always synchronized Changes to data objects, metadata objects and header data objects in the object trees v on Data services and central kernels can be noted in the header data objects of the respective elements and the change note can be successively transmitted to hierarchically higher-level object hierarchies and hierarchically subordinate object hierarchies can regularly request changes in hierarchically higher elements, so that object and element changes in all global, regional and private ones Object tree directories are noticed. The invention also relates to a device for operating and monitoring, which is formally characterized in that a group of two- or three-dimensional, interactive components of a graphical user interface a- .. a _m lying in a two- or three-dimensional area, again consisting of Sets br..bm- of two- or three-dimensional interactive graphical user interfaces generated in local and decentralized locations, in the Each user interface of the set b contains an associated set of cL.cn graphical basic elements that is specific to you and optionally a set of freely definable additional graphical elements and the design of at least one of the basic elements of each set c is such that at least one additional graphical user interface is of the set type a or b or at least one user interface of at least one element of the set of user interfaces b can be completely mapped in a sub-area of c, and the elements of sets a and b serve as external operating and observation interfaces of the elements of one or more data services in the distributed data processing system by synchronizing and presenting data through the interfaces from the data service. At least one of the basic elements of each set c represents its own operating and monitoring interface with object explorer, an object bar of selected objects and a visualization interface for objects.

Preferably, the directory structures, data objects, metadata objects and header data objects and indices that are exchanged between the object trees can be encrypted and, if requested, the transmission channels can also be encrypted during the transmission.

The invention serves to convert a dynamically changing multitude of different distributed technical devices, events, and assigned documents and applications into a structured, technically organizational unit (the distributed one)

Data processing system) to merge efficiently and to organize, administrate and program-controlled this unit safely, efficiently and dynamically, as well as to optimize it technically and organizationally, as well as manually. In addition, are assigned by means of decentral generated virtual devices technical devices and associated documents, as well as hybrid forms of both efficiently visualized, managed and influenced using program-controlled technical (application of mechanical forces, influencing currents and technical control devices etc.) and non-technical measures. The invention maps all basic requirements for distributed real technical devices in a virtually centralized model of any distributed logically related information by means of a single basic method and is used for modeling, administration, operation and monitoring of the control and regulation techniques of these devices including the optimized organization, communication and distribution of documents necessary for the optimal functioning of the real device. The invention is used in particular for the safe, uniform influencing and control of distributed technical processes, for example a large amount of globally distributed automation systems (for example distributed industrial systems, wind farms, thermal and electrical solar cells, combined heat and power plants, biogas plants, coal-fired power plants, oil-fired power plants, gas turbine plants, nuclear power plants, fuel cell plants, hydropower plants and other energy supply plants, also in mixed operation, for mobile radio stations, networked operating and monitoring devices, pipeline networks, power networks, building automation in urban areas and administration of technical infrastructures etc.) or complex industrial plants with the help of the Internet. The managed and controlled processes of the real devices and the associated documents can be of any complexity, installed on data processing devices, distributed on different computers and dynamically changing in number. Any number of authorized users can influence the real processes and documents different rights of equipped users and automated services, at any time and from any place. Data transfer, graphical user interfaces and management of all services and information are summarized in a standardized, secure, platform and location-independent, resource-saving, analysis, mapping, networking, operating and organizational method. The structured control of a large number of real processes along with the associated documents is improved with the help of meta-object-based knowledge management, distribution and search methods, expanded with the necessary additional communication channels and linked with already thematically related internet-compatible applications to more organized application categories. Due to the low core complexity and simplicity of the invention, due to high modularization and scalability, the very low resource consumption of the invention at the process level and a complete decentralization of all basic functions of the distributed data processing system, which are required for the modeling, control and management of the technical devices, as well as the safe operation on insecure networks, the invention is suitable not only for the control and management of any complex distributed industrial processes, but also for the networked, efficient and elegant management of a large number of widely distributed small technical applications.

The invention provides a secure, robust, resource-saving, efficient design solution for a device and a method for secure, virtually centralized modeling, operation and observation, organization, as well as for the exchange and handling of a large number of distributed, complex internet-based information and processes based on real The system according to the invention consisting of central kernels with central control, assigned services and access control is called "MetaOS" in the following. The information to be processed is essentially based on rapidly changing technical process and status information of any structure, but can also contain database and directory information etc., technical and organizational documents, but also any new and existing Internet-based applications and administration information. The bundling of the services, information and applications mentioned in a higher-level, decentralized, organizational and

Communication principle for technical devices, as well as the networking of several of these bundles forms a "MetaOS primary network" that represents a distributed data processing device with the focus on decentralized technical process control and monitoring. This surrounds all contained data objects by means of a single operating, visualization and administration principle. Bundling processes can be done on any number of technical, logical and administrative levels and enable location-independent uniform access to all basic functions of the distributed system. In addition, the MetaOS primary network should easily provide information provided by FTP and web servers, which can also include time-varying process data of a technical device , into the virtual device. The entirety of the data objects that are transmitted by such servers exclusively via standard FTP and HTTP commands is stored in the hereinafter referred to as the "MetaOS secondary network". The task of the secondary network is to integrate databases of small technical applications, for example widely distributed systems in building automation, into the primary network. The virtual device should be able to be used from the smallest process controls with HTTP and FTP servers to the management levels of complex, distributed industrial and administrative processes. It should be easy to insert into existing infrastructures and be able to Get to grips with sudden increases in structured and unstructured information from a variety of self-sufficient, unrelated sources and evaluate them in a useful way. MetaOS networks made up of primary and secondary networks form a unifying, compact intermediate layer that can be latched into almost any operating system groups that serve to control and administer technical devices. These can be specialized small operating systems for process controls, but also complex server operating systems. MetaOS fits indiscriminately into existing heterogeneous computer landscapes. MetaOS networks should enable uniform modeling, mapping, management, optimization, networking, mixing and user-specific expansion of any existing local and internet-based services and documents from process levels to management and administration levels.

With the help of a number of differently grouped, distributed object trees with a common command language, which will be called MetaOS nodes (Fig. 1), different data services and applications of local, technical and non-technical sub-processes are mapped to a common data structure (Fig. 2) or generated own services. The common data structure of a MetaOS node is a virtual, dynamically generated, hierarchically organized, variable object tree (Fig. 6) with an integrated meta and header object concept (Fig. 12, 13, 16). Data objects of a MetaOS node are virtually formed from the various information from the services of one or more MetaOS nodes (FIGS. 5, 7, 8, 11, 12). The type of information supplied is arbitrary. In addition to data services from the process world (e.g. via OPC or directly from an AD / DA converter card), simple file services, mail, news and FTP services, Multimedia services but also software components, which in turn are based on other information services or communicate via command strings, as well as complex directory and network services are mapped within a single object structure (Fig. 11). In addition, data services and the central kernel can contain their own program-controlled control and regulation instructions and process and change the data objects supplied in the virtual object tree. The mapping of different services on MetaOS nodes, the dynamic networking of several MetaOS nodes during the runtime and the interaction of the objects with each other enables the formation of a time-varying network of integrated multifunction gateways. Due to the possibility of partial or complete location-dependent “covering” (hereinafter referred to as “mounting”) identical and similar subsets of virtually formed structures of the various MetaOS nodes (FIG. 4.5), for example, different data service structures can be formed in such a way that larger ones Physical, technical and organizational relationships of distributed, changing real technical devices depending on the location of the user (operator, administrator, etc.) are virtually structured and meaningfully merged, displayed and interact with each other (Fig. 52-55) a fluctuating information network that is dependent on time and location and can be used to efficiently manage large quantities of technical systems. The integration of a decentralized, integrated cache and routing method in the information network replicates and distributes information s the information network automatically in regions in which you are in demand and thus increases the performance of the entire virtual device (Fig. 26).

Through the successive formation of groups, sub-models, sub-models up to the formation of models for the complete mapping of the real Devices including the associated organizational, analysis and administrative structures, all technical devices from distributed companies and production facilities are to be gradually mapped from simple components using complete information technology and constantly adapted to be accessible from any location. The resulting virtual technical-organizational complex should navigate and work differently or uniformly, depending on the location and perspective, in the various information stocks, i.e. the technical system can be influenced, as well as efficiently search for any static and dynamic information using search mechanisms and this if necessary can be changed. Operating and observation models of technical devices can contain mixed forms of location-describing, technically component-based and classic data structures (eg file manager structures) in flat and spatial form. A scalable dynamic meta and header object concept built into each node that interacts with the cache, routing and search functions, with the possibility of creating arbitrary classification information, cross-references to your own information structure as well as to external data structures, extends the virtual data structure with technical skills organizational information and knowledge management beyond a previously created, decentrally generated framework and improves the application and control knowledge of the real technical devices. The meta-object concept is particularly efficient on weak networks with low transmission capacity on which large documents in connection with process data are to be shared.

The dynamic meta and header object concept is intended to simplify and optimize organizational and administrative forms Optimization of the data transmission, simplified information extraction from the real and virtual devices and thus ultimately the optimization of the functioning of the technical devices. Further improvements are achieved by manually "hooking" suitable additional information sources, by linking related information by means of filtered synchronization in the MetaOS network and by using the cache and routing functions. Arbitrary search requests to the meta objects and data objects of the networked virtual device generate structured subsets of information of the total data set. Search results are distributed, evaluated, condensed and processed in areas with high demand and can in turn be inserted at any point in the hierarchical virtual information structures of MetaOS nodes. The "network knowledge" thus obtained from superordinate data can be used to optimize the local real processes , The representation of data objects is carried out by a n-dimensional group formed from decentralized components and using the virtual data objects, in some basic properties more uniform but generally only similar, hierarchical graphical user interfaces that can be arbitrarily layered and projected. Each user interface represents the associated subset of information from MetaOS nodes on a unified directory. The graphical objects of the user interfaces can be related to each other and enable the simple visual merging of the most diverse distributed technical, organizational and syntactically / semantically similar information on thematically related information objects on different organizational levels. The structure and arrangement of the user interfaces are intended to manage and structure data references, complex data hierarchies and time significantly improve successive operating sequences. The possibility of largely distributing the computing load for the construction and operation of the user interfaces to the computers that present the user interfaces (FIG. 7, 8) is intended to ensure the operation of MetaOS nodes even on very poorly performing data service servers.

The basic components of the distributed data processing system are essentially known from various areas of technology and information technology, the efficient and user-friendly way of integrated interaction, the simple possibility of linking all basic components and the application to technical devices enable the high performance and user-friendliness of the MetaOS network and thus exceed the current state of the art.

All electronic and computer-controlled systems required for the operation, observation, control, analysis, management and data storage of the automation system (s) are expanded to form a cross-platform network, the MetaOS network (Fig. 52, 53, 54, 55, 56), that Depending on the size and complexity of the technical device (s) can consist of any number of network nodes and additional network elements (the secondary network) (Fig. 30 component 334, 338) (Fig. 32 component 352, 353, 354) Individual MetaOS nodes that in addition to the control and administration of the technical device by coupling with the real technical device, any general and specialized tasks in the network can be automatically integrated into the MetaOS structure by means of autoconfiguration (see also Fig. 18 .relative synchronization of objects via different Central kernel) or any inhomogeneous network. Any MetaOS node can at least one special service is assigned to the visualization service (Fig. 1 component 7, (Fig. 5 component 73, Fig. 8 component 116). Visualization services take over the graphic representation of data objects in the network. The identical basic structure of all nodes and services in the network, which allows all network users to perform all the tasks required in the network, allows the network or its parts to be optimized with regard to robustness, ease of use, security, simple navigation and administration. Depending on the function and performance to be carried out, an electronic individual system of a technical device becomes the primary or assigned to the secondary network (FIG. 30), objects, meta objects, header objects, elements, data services, MetaOS nodes, MetaOS networks (primary and secondary networks) and

Visualization services in a MetaOS network are created with the help of uniform object, .metaobject, header structures,

Visualization principles and a uniform command language are so closely linked that MetaOS networks made up of different elements appear to users as a single, uniform structure in which all services can be used. The complexity of the network is hidden. In addition, the linking strategy of the MetaOS nodes fulfills all basic requirements for efficiency and robustness.

A MetaOS node for modeling, integrated monitoring, control, regulation, analysis and data storage of complex technical process sequences consists of a compact central kernel, each with an integrated rudimentary access control, separate control for the management of tasks, threads, memory, network capacities and one hierarchical structured object tree management with integrated function for program-controlled or manual collection and distribution of data elements, administration and communication of services and central kernels including associated data structures and a collection of any specialized data services (components 4-10), which physically or logically related devices or other central kernels as client or server services of the MetaOS node and communicate with the object tree management of the central kernel at the same time if required. At least one service of a MetaOS node can have external interfaces for operating and monitoring the distributed data processing system. If necessary, a local central kernel is expanded during operation by any data services and further central kernels, and any data services and further central kernels are removed if necessary. All data services assigned to the central kernel appear to the central kernel like other central kernels in the MetaOS network (FIG. 10 component 125). Users, systems, applications and other MetaOS nodes can communicate with the data services via the central kernel, onto which the data objects of the data services are projected. The central kernel and data services have a common command language. Boot processes of a MetaOS node, as well as the administration of tasks, threads, memory areas and network usage of the node are managed by a separate control entity (FIG. 6 component 89). The data services of the MetaOS node take over communication with any external logical or technical services (e.g. file systems, OPC servers for process control, network services etc.) in the form of gateways, regulate access control to external services or provide the central kernel with its own services available (eg process controls of technical sub-areas of the technical system) (Fig. 11 component 138-140,142). The data services of a MetaOS node are above that In addition, services for secure user authentication (FIG. 1 component 6), access rights (FIG. 1 component 5), network administration and user communication are available. Depending on the performance and information technology equipment of the individual systems, a MetaOS node can run completely on a single computer or data services can be distributed over several computers (Fig. 7,8).

Each data service of a MetaOS node is divided into two parts. The first part of the service, for example, accesses externally generated data objects and converts or encapsulates them into a format valid for MetaOS nodes or vice versa (FIG. 10). Depending on the functionality, the second part forms a client and / or server structure for the central kernel of the MetaOS node (FIG. 10, component 126). The second part appears to the central kernel as another central kernel with which it can communicate (FIG. 10 component 125). In the simplest case, a data service provides the central kernel with, for example, simple values or files, in the most general case with complex time-variant data objects and metadata objects and / or receives them. If necessary, data objects from the data services are called up and used via the central kernel. Data services and the central kernel provide data elements, which can also contain time-variant process data and multimedia files, in the form of a standardized, hierarchically organized object tree assigned to the respective proprietary individual devices (a breakdown of the interface information into simple elementary objects for the central kernel). Individual information, information lists and hierarchically organized information structures from data, status, and function interfaces of the individual measuring, analysis, storage, control, operating and monitoring devices are encapsulated for this purpose by program-controlled information projection as required in the respective object trees of the assigned services. Each In the most general case, elements of these object trees are additionally assigned an arbitrarily definable set of time-variant meta and a hierarchically structured tree of header data objects (FIG. 12).

The header objects contain decentralized timing information for synchronization, information about resources of the local location (CPU, memory, network capacities), log and error information, information about user management and authentication, security, transport, popularity and priority properties and the state of the data objects, as well as Information about the type and condition of the operating and monitoring devices as well as description information about the objects and summarized information about hierarchically lower-lying object structures etc. are synchronized. In the simplest case, object trees or their subsets with the elements of the data services are simply assigned to, or projected onto, a central, virtual, hierarchically organized object tree, the roule element of which forms the central kernel (FIG. 14). Optionally, this process is program-controlled with the help of filter lemens and operators. This process, which defines the mapping logic of the data services on the central object tree, is called "mount" in the following.

Virtual "means that the central object tree in the central kernel serves as a structuring framework for passing through the objects and metadata objects of the data services and temporary cache memory for the elements of the data services. Initially, only the mount points of the data services are entered in the object structure of the central kernel, data objects are initially not transferred Manual or automated navigation in the virtual object tree then successively transfers structural data, metadata objects and data objects into the virtual object tree. This mapping process is called "synchronization" in the following. The opposite process of "Distribution" of data written by a user in the central object tree and written in one or more mounted data services is carried out in an analogous manner. In addition, objects can be inserted into the virtual hierarchical object tree of the central kernel that refer to form the positions of other objects in the form of symbolic links in the virtual object tree. The objects themselves store the positions of the references in the header data objects assigned to them. If the position of a target object in the virtual file tree changes, the target positions of the references are adjusted by the central kernel The symbolic links refer back to the target object.Time variant data that are to be read from data services or written to data services are stored in the virtual object tree by means of refresh cycles manually controlled by the user or alternatively program-controlled by a scheduler (Fig. 19 ) which gets its data from the header data objects of the object trees updated. Several data services of a MetaOS node can be mounted in the same place in the virtual object tree.

In this case, the object trees of several data services are merged with one another by virtue of virtual transparent "superimposition", ie by projection according to different priorities and optionally using syntactic, semantic, logical and numerical program-controlled filters and operators, ie different data objects from different data services same position in the respective local object trees in the central object tree in the elements of a directory, and different objects of the same elements in the same

Positions in various data services also in the central

Object tree can be merged into one element and saved. The merging of objects, metadata objects and Header data objects of an element of the central kernel are made in any combination with the basic projection method from the services of the central kernel and from other central kernels. The information of the header data objects of each data and metadata object of a central kernel are, for example, mounted and synchronized from different specialized data services and further central kernels into a common header object structure of the element.

Access to identical objects seen from the central Kemel in different data services is regulated via priorities assigned to the data services. From several different data services of a MetaOS node, a standardized, ordered data structure is mapped on the central kernel, which is made available in full or in part by the visualization services in the MetaOS network. The procedure applies in addition to the described read operations from the data services, in the same way for write operations and execution operations of program code on the data services, taking into account any write, read and execution rights. In addition, various object trees can also be synchronized using syntactic / semantic operators (e.g. using placeholders in the object names (Fig. 23)) or any other operator (see also chapter Information search in MetaOS networks), so that syntactically / semantically similar object folders from Data services can be merged into a single object folder and addressed. Data services are programmed in such a way that they can be inserted (mounted) into the node and removed again at runtime of a MetaOS node. A MetaOS primary network is an arbitrary combination of any number of MetaOS nodes in which the central kernel and associated data services communicate with one another directly or via other MetaOS node chains (proxy chains) (FIG. 4). Networking and communication in the primary network follow the same principles as networking and communication between data services and the central kernel. The differences are that, unlike a data service that can only communicate within a MetaOS node with the central kernel and with the other data services to a limited extent, each central kernel can communicate with all other central kernels in the MetaOS primary network, with simultaneous communication with several others Nodes and local data services is allowed (Fig. 3,4). In addition, in contrast to data services, which can only mount object trees from other data services at the root element of your own object tree, each MetaOS node can mount and synchronize any data objects at any location from the central kernel of every other MetaOS node (Fig. 11). In this way, data objects from external data services can be taken over or data objects of any MetaOS nodes can be easily structured and merged. Since data objects are cached on the central kernel of the target node during synchronization, there is generally no need to move or copy data records in a targeted manner. In addition to the technical, structured management of the technical systems in the network, the mechanisms of the primary network are used in the same way for the purposes of central and decentralized authentication, access management, administration and for data replication to increase the performance and robustness of the network. A primary network is formed by a logically linked hierarchical network of central kernels from an initially individual central kernel as a virtual center with further central kernels distributed object holdings is mounted, so that each central kernel of the hierarchy has access to a resulting, uniform network-wide global directory (virtual centralization), a different regional directory of logically related elements and a local directory formed from the decentralized services and elements Node forms a mounting scheme with other nodes, so that each node synchronizes local data services into a local private and, if desired, a local public area directory of logically related elements, mounts and synchronizes a defined global directory of a hierarchically higher central kernel to the root element of its own central kernel and public local Range directories are mounted and synchronized to the public range directories of the parent node in the local global directory and public region all area directories of subordinate nodes are mounted to their own regional object directory. For synchronized data sets (object directories, elements, data objects and metadata objects) on individual central kernels, an index of all known local and synchronized area data per central kernel is also created. These are also virtually interconnected to form a global index. Changes to data objects, metadata objects and header data objects in the object trees of data services and central kernels are noted in the header data objects of the respective elements. Change notes are successively transmitted to hierarchically higher-level object hierarchies and hierarchically lower-level object hierarchies regularly ask for change notes in hierarchically higher elements. Object and element changes are noticed in all global, regional and private object tree directories, with these Databases work. Central kernel in the network synchronize data sets of the virtual center and its local environment (hierarchically higher and lower environment) as standard. If a central kernel in the network fails, these cached, synchronized datasets are used to simulate temporarily inactive failed central kernels for the period of the failure

In practice, due to existing technical structures and structural simplicity, it is common in many cases to set up the physical and logical networks for controlling and monitoring technical facilities in the form of distributed hierarchical, tree-like structures. Network users can thus work on a single structure. With a changing high number of widely distributed technical systems that are also partly operated on unsecured networks, this networking strategy is problematic with regard to data security, reliability, central administration options and performance (formation of bottlenecks on sections of the network). If individual connections, fast transmission links or individual MetaOS nodes fail, entire sub-areas can drop out of the network or can no longer be used due to bandwidth problems. Central user-friendly administration and security concepts for the network in the form of directory services cannot be used in such cases. A targeted manual establishment of redundant connections between MetaOS nodes is very difficult with very large networks in terms of workload, structural clarity and maintainability. In order to be able to guarantee stability, robustness, security and central administrability under the described boundary conditions even in hierarchically structured MetaOS networks, the possibility is integrated in every MetaOS node to "symbiose" with other nodes in the network, (cooperating groups) whose stability and speed exceed the individual nodes.

A "symbiosis" is a group of MetaOS nodes that form the smallest functional subset in the MetaOS network with options for central administration, authentication, user and resource management under the constraints of high performance and robustness. However, "symbioses" do not necessarily consist of geographically neighboring groups of MetaOS nodes, but of logically related MetaOS nodes and can be arranged scattered over the MetaOS network and impress stable areas of distributed, logically related elements on the MetaOS network. The elements of resource management, performance and robustness are considered below. Each central kernel of a MetaOS node from a logically connected group of further central kernels mounts and synchronizes all directories of all other central kernels in the group in a range directory defined for the entire group and thus forms a symbiosis (Fig. 28, 29). In this way, a uniform view of all the data in the symbiosis is created on every node of the symbiosis. Moving data objects and directories from one node of the symbiosis to another, or copying processes remain completely transparent to the user of the symbiosis. There are no changes in the arrangement of the data objects on the area object tree of the symbiosis and there is no need to change mount points in order to access shifted data objects. Individual nodes of a symbiosis can be maintained very easily in that data records are temporarily relocated to neighboring nodes during maintenance and are still available to the user in the same place. The directories with the data objects available locally on the respective nodes are marked separately in the header objects in order to facilitate an overview of the original data objects on the nodes. If data objects of the symbiosis are requested from an external node or a user on an account of the symbiosis, the symbiosis node first looks in its own databases and in the cache of the central kernel. If these are not available in your own databases, but in other nodes of the symbiosis, the local data objects are synchronized with those of the target computer, and a copy of the data objects as well as source references and information about the expiry periods of the data objects and metadata objects are stored in the cache of the central core , Requested data records are replicated within a symbiosis, and the performance of a symbiosis regarding inquiries increases. This is especially true for frequent searches on databases. If the target computer or its data objects are temporarily not or only poorly accessible, for example due to high processor load, the other nodes of the symbiosis are requested for copies of the data records in the cache (FIG. 31). The original data record is only used for parts of the data copy whose expiry date has passed. A symbiosis of MetaOS nodes thus fulfills basic requirements for a distributed object directory with dynamic objects. As with all other administration processes, the mount and synchronization options of the individual MetaOS nodes are used to obtain the information. Other nodes in the network that do not belong to the symbiosis, but which mount a node of a symbiosis (eg hierarchically higher nodes), automatically receive all other addresses of the symbiotic members. Should the mounted symbiosis node fail, another node of the symbiosis will be automatically replaced instead. Access to all remaining data objects of the symbiosis including the copies in the Caches of the central kernel are therefore preserved. The described structure of a symbiosis enables a very user-friendly access to data objects of a symbiosis, with a relatively simple and clear mounting scheme, with massive use of redundancies and only local short-term additional load on the network by generating local data copies in the symbiosis. In addition, the described method can be used to create robust areas in global mount hierarchies.

A secondary MetaOS network consists of a number of FTP and web servers that are assigned to the primary network. In contrast to the primary network, the elements of the secondary network are unable to communicate with MetaOS nodes and other primary network elements in the language of the primary network. The metadata objects of any data objects of the primary network can, however, be adjusted by means of additional data files on the FTP and web servers so that MetaOS nodes of the primary network are able to visualize data objects from the secondary network without conversion via an FTP or HTTP-capable data service. to read and write back to the secondary network. Since secondary network elements, as well as primary network elements, have their own visualization service, which is transmitted to the user via the network (see chapter »How the graphical user interfaces work«), and metadata objects on the primary and secondary network can be managed in a structurally identical manner Elements of the primary and secondary network are shown in an identical manner. The data elements of the secondary network can also be independently visualized and edited due to the own user interface.

Operating a MetaOS network indicates an efficient

Use of large MetaOS networks with several thousand MetaOS nodes and a large number of users from anywhere in the world Network to ensure some special properties.

Each node of the primary network as well as the secondary network can be the carrier of at least one of its own user interfaces. This is designed as a data service and is treated by the central kernel like another central kernel, i.e. it has its own virtual object tree and communicates with the central kernel using the uniform command language. The user interface is transmitted to the users when required and can represent any subsets of all local and locally mounted data objects by mounting and synchronizing data objects from the central kernel. In addition, each element can save all the information it needs to display it in its header data. The user interface is therefore an integral part of a MetaOS node. The user is therefore generally provided with all the data objects relevant to this node or the associated symbiosis at each node without a complex database query.

The user interfaces of all nodes work on the same operating and visualization principle. differences between

User interfaces only consist of a few freely definable design elements, e.g. to to visually identify different technical areas.

The datasets of several mounted MetaOS nodes one

MetaOS networks can be communicated with

Adjacent nodes can be queried via the user interface of a MetaOS node.

In order to enable comfortable and fast work on the user interfaces, changes in the user interface are generated by the visualization service in the client itself and not by MetaOS nodes. This property also allows the operation of the graphical user interfaces on the secondary network.

All basic mount, synchronization and filter mechanisms of the central kernel can also be applied to the data stocks of the user interfaces. The user interfaces allow the view of one or more data objects including metadata objects in various standard views and in views freely definable by the user or by header data.

Standard views: \ Object overview:

In the object overview, subsets of the structural data (e.g. directory structures and contained files) of a MetaOS node including mounted MetaOS objects are shown. This type of representation essentially corresponds to the representation of a file manager or file explorer

Zoom function. Selecting an object switches to the view of the corresponding sub-hierarchy ^" or to a default view of an object itself.

X Meta object explorer: The meta object explorer extends the object overview with the tabular view. Preview and editing of freely definable and selectable meta object groups. \ Object view:

In the object view (Fig. 39) the content of a data object is displayed without its metadata objects. The object view contains the possibility of displaying data objects within a "browser". A "browser" is understood to mean a functional unit which. Data at least the

Descriptive language HTML 3.2 or a comparable one Can interpret and display language or an extended version or XML 1.0, master a script language such as Javascript 1.0, Phyton or a comparable language, master a programming language according to at least the Java 1.0 specification or a comparable language, master the display of frames and an interface comparable to the Contains Netscape LiveConnetct standards or a comparable standard, and can manage extension modules in the browser.

\ View object manager:

The "Object manager" view (Fig. 40) is the most important view for the efficient use of large MetaOS networks. The »Object manager« view contains the

»Element overview« view, an at least two-dimensional object overview (Fig. 40 Component 394) that can manage symbols and graphic objects with symbolic links in your own element hierarchy and an object bar of all selected or active elements in the desktop. By

When you select an object in the element overview or the element bar, objects appear on the desktop that present the content of the selected object (e.g. contents of files and directories). Individual desktop objects can temporarily enlarge the entire graphic

Fully occupy the control surface, ie they lay like a sheet over the current object manager and can be presented in the view of a new object manager. This is due to the special property of the desktop objects that they in turn in all possible views of the used graphical user interface can be displayed. In this way, a graphic zoom effect can be implemented in the data tree. In addition, a mechanism is implemented that allows the graphical user interfaces of the secondary network and others in the desktop objects

Show MetaOS-Koten (Fig. 32 component 353). In the example described, a desktop object can therefore display the object overview, meta object explorer, object view and object manager views as standard views in addition to the freely defined views. With the help of the object overview it is possible to nest any number of object managers into each other as often as required and thus to present a graphical presentation of parts of the object trees (Fig. 43, 44). By temporarily increasing the size, any number of object managers can be stacked on top of one another. It can be on this

In this way, several "batches" of object managers can be created on one user interface. By reducing the size to the original size of the objects, the nestings can be displayed completely graphically on one level. References between individual open data objects are retained for the user. Since all status data for the graphical representation are stored in the displayed objects themselves, all mount and

Synchronization processes of the MetaOS network are applied and these are projected to a resulting desktop. In generalized formal language, a user interface is characterized in that a group of two- or three-dimensional, interactive components of a graphical user interface ai .. a _m , which are located in a two- or three-dimensional area, consist again from sets br..b _{m '} of two- or three-dimensional interactive graphical user interfaces generated at local and decentralized locations, in which each user interface of set b contains an associated set of basic graphic elements as well as optionally a set of freely definable ones contains additional graphic elements and the design of at least one of the basic elements of each set c is such that at least one further graphical user interface of the type of sets a or b or at least one user interface of at least one

Elements of the set of user interfaces b can be completely mapped in a sub-area of c, and the elements of sets a and b serve as external control and monitoring interfaces of the elements of one or more data services in the distributed data processing system by synchronizing data through the interfaces from the data service , distributed and presented.

You can navigate through the history of each open desktop object using the buttons for backward and forward operation. An up button allows you to »climb« in the element trees. With the help of the described object desktops, which can be assigned to each object in the element tree, links to other relevant objects can be placed in the object tree. The nesting and zoom technology of the object manager in combination with the local history functions enables efficient navigation in large data sets without losing orientation in the network. The problem of the »Lost in

Space «, which is created for example by web browsers when navigating the Internet, is completely eliminated. The opened desktop objects are automatically arranged in the desktop and can be accessed via the object bar can be temporarily minimized (as in a conventional user interface). The automatic arrangement and the possibility to minimize extensive slaughtered data structures in the object bar facilitate navigation in the data objects.

With symbolic links from the object hierarchy to any URLs and IP addresses, in addition to native information, e.g. also external internet-based applications e.g. displayed and edited in the object manager (e.g. the secondary network).

The command language is the flexible, uniform basis for everything that happens within a MetaOS network. Based on their simple, efficient structure, communication is based on the object trees of a MetaOS central kernel with the data services in the same way as with the graphical user interfaces and, furthermore, the communication of the central kernel in the MetaOS network including the self-confϊguring configuration of symbioses and global directory trees and the communication of elements and objects. It is characterized in that any objects, elements and substructures of a central kernel with any objects, elements and substructures of other local data services, user interfaces or central kernels and with any objects, elements and structures of its own central kernel are mounted, filtered, linked with operators and synchronized and distributed and that data, metadata and header data objects of hierarchically higher as well as subordinate tree elements are mounted, synchronized and distributed by specifying relative mount marks

The access language, user communication and administration are also added to the command language of all services in the network. The power of the command language can be explained by the fact that all elements available in the MetaOS network are mapped onto simple structurally identical object trees with objects and meta objects, which in turn have the same structure. All internal and externally connected services that are important for distributed networks can be mapped onto such object trees as a common basis and interconnected as required. This creates a uniform object environment, on the efficient manipulation and organization of which a command language can be very easily optimized in addition to a few other basic functions. All elements that cannot be directly mapped to the command language "non-essential", such as user management,

Knowledge management methods and special forms of communication with external services are transported (tunneled) via the meta objects assigned to the objects and are only interpreted in the specialized data services.

In order to use large, widely distributed MetaOS networks with many users on insecure networks efficiently and securely, a flexible, data-technically efficient user, rights management and authentication strategy that is adaptable to different requirements is required. The requirements with regard to security and manageability can vary greatly depending on the type of system to be controlled and the security measures required for this in different areas of a network. Central administration is technically and economically unprofitable. For this reason, user and rights management and the authentication strategies are only integrated in a rudimentary form locally into the central kernels of nodes, and further services are provided by the special mount and synchronization options of the MetaOS nodes of special local data services or others MetaOS node mounted to the elements in the object tree. MetaOS nodes can thus be adapted to different requirements. In addition, decentrally implemented users, rights and authentication strategies, which are assigned to the individual elements in the object trees by mount and

Synchronization processes using filters in global and regional directory trees are structured and virtually centralized, making them easily accessible from any location.

A MetaOS node in the basic state, consisting only of the central kernel and optionally the graphical user interface, has no fixed user administration and is designed as a local single-user system. Every user who logs on to a node is classified as a default user and has full access to all data available in the MetaOS node. Possible access restrictions only exist on mounted external data services whose access restrictions are passed on to the central Kemel via metadata objects. After dialing in, the only user known to a MetaOS node, the default user, can assign a password that is stored encrypted on the central kernel. After assigning a password for the default user, other users have only access to data objects from special public default directories released by the central kernel (eg a global directory and a regional directory) after logging on with any name. This also allows users who are not logged in and authenticated to navigate in MetaOS networks. If the public directory is blocked by the default user, access to the node is completely blocked for other users. Every user logged on to a MetaOS node with any name is entered by the central kernel in a constantly updated user list, which is in the object trees of the central kernel itself is saved. All user lists of a MetaOS network can be virtually centralized using a corresponding global mounting scheme and made accessible to every node.

The default user can integrate access management suitable for several users into the basic structure of a MetaOS node. In such a system, the default user administered in the central kernel takes on the task of the administrator. User management is first integrated by generating one or more special data services (this method is essentially used for the network related to the primary network, hereinafter referred to as "gatekeeper") or by supplementing data objects on data services and secondary network elements with special key files

(Gatekeeper files) with meta-object entries that enable individual data and objects for specified users. The gatekeeper services, which manage freely definable access control lists in the form of metadata objects in your object structure and decide on access, are then mounted by the central kernel and fully synchronized with the data stocks there in the header data of the elements. It does not matter whether the central kernel mounts a gatekeeper from its own node, from administration nodes of its symbiosis or from any node in the network. Each element can be assigned its own user management. With a global mounting scheme, the user administration can then be virtually centralized. In addition, there is the option of implementing location or access-dependent user management with the help of gatekeeper services, in that a gatekeeper not only manages the user management of a single MetaOS node, but also manages access to several mounted MetaOS nodes on which no user management is installed is (indirect user management). eg special access options for ensure specified locations. Outsourcing the access management of a MetaOS node to gatekeeper services with subsequent synchronization of the administration data to the individual elements thus enables differentiated, arbitrarily simple or complex management of the access options of MetaOS nodes in a MetaOS network.

The user authentication process is as follows. If a user (not the default user of the central kernel) logs on to the MetaOS node, the central kernel first checks whether there is a synchronized gatekeeper service for the user in the central kernel. If this is the case, when attempting to access the data stocks, the header object entries of the respective gatekeeper are always checked first, or the key files on the data services and secondary network elements. Only objects in the central kernel that have a corresponding user ID in a gatekeeper assigned to the user or in the key files are made available to the user. The authentication takes place with the help of the metadata objects of the gatekeeper, which takes over the authentication of the user as representative for the services to be used in the central kernel and any authentication method, eg Kerberos version 5 with a central server for authentication. (This procedure guarantees high security even on insecure networks.) The administration of the network structure and the user administration as well as the user-friendly navigation in the networks without authentication and the user-friendliness in large networks can be facilitated without neglecting the security in the network. Because of the outsourced administrative structures described, everyone can Administration server can be operated with security-relevant data at external, specially secured locations.

The possibility of information research is integrated in any MetaOS central core and data services of a MetaOS network in the form of filter modules. Filter modules programmatically use the mount and synchronization options of a MetaOS node provided by the basic command language. Results of a search query are saved anywhere in the virtual object tree of the respective local central core and, depending on the type of search query, completely or in the form of subsets of the searched structural data, metadata objects and / or data objects and optionally displayed in any view available for the respective object , Search results are not only viewed as collected data objects, but are also displayed in a time-varying form after being specified in the search query and after evaluating the expiry date of the search results or by specifying refresh cycles.

A search query within a MetaOS node is carried out by setting one or more mount points (possibly in combination with scripts) anywhere in the central kernel, specifying various filter criteria directly in the central kernel or for different data services (for data structures, metadata objects and data objects) for central kernel and Data services, the specification of the search area (e.g. object directories, number of maximum objects of a type to be synchronized, time limits etc.) and the display requests as well as the specification of the services or central kernel to be searched. All information for the search process is assigned to an element in the central kernel (called a mount point) as metadata objects and thus becomes part of the object itself. In this way, search queries are retained in the object tree over the long term and can change Conditions can be easily adjusted and refined. A complete search process is started by starting a full synchronization process (synchronizing the specified

Object directory including all subdirectories). In contrast, when navigating in the object trees, only the selected object directory is synchronized. During the search and synchronization process, the data objects specified by the filter criteria are synchronized and, if necessary, displayed. Other data objects are ignored. Since several mount points for an object can be assigned in the form of a mount list or mount scripts, data objects searched for can be extracted from several object directories, collected in one directory and synchronized into a result directory by "stacking". Since search results are seamlessly inserted into the virtual object directory and graphically displayed as object trees using the mount and synchronization principle, searches can also be carried out successively by manually navigating in the object tree and results that are not of interest can be deleted manually from the tree. Search results in the object tree can be refreshed either by manually navigating and re-synchronizing the partial search results or by completely re-synchronizing changed data. At points of interest in the object tree, the search result is further restricted by further specifying search queries. Further associated data objects can be added to search results by further insertion of mount points or scripts. This can be, for example, the superordinate object directories of the data objects found or other related data from the search results (see Knowledge Management in MetaOS networks). A search query in other nodes, for example in the local node assigned symbiosis or in the entire MetaOS network is carried out in the same way as in the local object directory. Differences exist on the one hand in the extension of the filter criteria to external MetaOS nodes and on the other hand in that search parameters are passed on to external MetaOS nodes and are executed there locally, so that individual MetaOS nodes and local networks are not too strong with search and synchronization processes to charge. Searches in MetaOS nodes using the described method are therefore only special cases of the general mount and synchronization and filter principles. In order to be able to carry out long-term investigations of certain criteria and process values in the individual nodes with the help of the search query, search queries can be carried out indefinitely and cyclically in the nodes to be searched by restarting cyclically after the end of a search run. If search criteria are met during a run (eg process value outside a specified tolerance range), the search results are returned to the request location. In order to increase the efficiency of the search processes, each data record in the data services and in the central kernel is provided with a unique search mark during the search process. If a search is repeated, only unmarked data objects are taken into account and synchronized. In the event of changes in parts of the marked data records or when expiry dates expire, the corresponding search marks are deleted. This ensures that updated areas of records are considered for repeated searches. Search results, like any other part of the central object tree of a MetaOS node, can in turn be fully or partially mounted by other nodes in the network and distributed in this way (e.g. for distribution of information in work groups that search results must share) The distribution of information in MetaOS networks largely corresponds to the process of searching for information. The difference is that found elements from all services assigned to the central kernel as well as devices assigned to the global and regional directory in the MetaOS network are not synchronized with the local central kernel, but are described with user-defined data (Fig. 25). In this way, for example, in a simple case, a larger number of specially defined machine components can be started or stopped synchronously by a user according to certain determined criteria. Depending on the type of objects sent, any actions can be carried out (for example, writing mount scripts in an external central kernel) and any control processes can be implemented through program-related synchronization and distribution of information. As with searches, long-term, cyclically repeating program-controlled distribution processes are also possible.

Due to the similarity of the methods of information search and information distribution, information search and distribution in a mount point can be used together (eg within mount scripts). For example, a larger number of distributed machine components can be activated with the aid of a programmed distribution process, and the result of the activation can then be verified by a search process. In this way, users can be granted defined control options via machine components in the entire network via the global object tree or in defined areas (regional object tree) of the MetaOS network using the search and distribution processes. The basic mechanisms of mounting, synchronizing, distributing, filtering and projecting dynamic data objects, metadata objects and header data object structures in MetaOS nodes with the help of scripts on a virtual global object tree enable the support of various forms of communication distributed over the network in addition to the mechanisms described so far in any powerful form. Means of communication can be distributed over a MetaOS network and used from anywhere in the network. Static news groups can be mounted, for example, in the form of a data service in the object structure of each MetaOS node (for example, in the form of hierarchical object structures as well as a metadata element for news texts and information type). The same rules apply to news groups as to all other objects in the object trees. Decentralized newsgroups can be fully or partially mounted and synchronized by other nodes in the network, equipped with user administration and authentication procedures, centrally managed in the form of virtually centralized object directories and used anywhere in the network. On the other hand, for example, a news network can be set up so that an administrator can set up, manage and monitor all news groups in a network, while on-site technical service staff can only see and edit small sections of the entire news network at specified points in the network, which the administrator can access local MetaOS node was mounted. Since the news system is fully integrated into the object list, the general options for information search and distribution also apply to the news groups.

Since a file tree in the central kernel only knows general objects, in which between directories, files, news groups and others If there is no fundamental difference between data objects, news groups can be attached to directories and files and any other objects. On the other hand, directories and files attached to news groups can be viewed in a news system, for example as (if necessary dynamic) attachments, which can significantly improve the quality of a news discussion.

In a comparable way, hierarchically arranged and provided with user administration dynamic chats, instant messaging services, as well as technical coordination processes of technical plant groups can be integrated in MetaOS nodes and made available in defined areas of the network or globally. The main difference to a new system is that information in such services has to be refreshed in a cyclically fast sequence.

The following advantages are essentially achieved by the invention: • A unified system of distributed, networkable data processing systems with projected dynamic meta objects and user interfaces from decentrally generated, structured and grouped, model-based components and associated methods for operating, observing and managing a number of distributed technical systems, documents and applications.

• Up to now, centralized data processing systems have been used to operate, monitor and manage complex technical processes. This process requires expensive, powerful computing systems, is sensitive to failures and due to the high network load, especially in slow networks, can only be used and scaled to a limited extent due to centralized data transmission. The procedure is for decentralized control and administration of widely distributed technical systems not suitable. The new decentralized system and process avoids these disadvantages and simplifies the control and organization of complex technical networks. Process links, applications, data transfer, user interfaces, access management and documents are summarized using organized dynamic data objects and associated metadata objects in a unifying, secure, resource-saving, analysis, mapping, networking, operating and organizational method. By means of a uniform command language, the physically decentralized system is combined to form a logical, virtual, global unit, which can be used in a unified manner from each decentralized location by means of a user interface that can be constructed from various decentralized components. «The system enables secure, standardized control and management of large quantities of globally distributed automation systems (e.g. distributed wind farms, mobile radio networks, electricity networks, pipeline networks, building automation, management of technical city infrastructures etc.) and is also suitable for efficient and elegant management due to its low complexity and simplicity a big one

Number of widely distributed small technical applications.

The invention forms a unifying structuring framework for object transfers and object caching with universal application options for successive location-independent bundling and structuring of various data services, documents and applications and forms of communication for distributed and concentrated technical devices within a single modular information structure on the Internet. All services going beyond the basic functionality, including important system services, are included in decentralized data services are therefore flexibly adaptable to different network requirements, can also be virtually centralized and can be used completely transparently throughout the network.

Only a single protocol is used for communication within MetaOS nodes, in the MetaOS network (primary and secondary network) with its various services, in symbioses and for structuring directory services. Any network configurations can be created very easily.

The possibility of modularization of the invention in the smallest units while simultaneously using all locally required ones

Communication options and the mapping to a common data structure maximize the number of possible degrees of freedom for optimal adaptation to the real device and minimize the complexity of the overall device. The complexity of the overall device adapts to the complexity of the technical devices.

Each MetaOS node in the network can, if necessary, fulfill all tasks in the network and make services available to external nodes.

Since the search functions and information distribution functions are special forms of the basic functions of a MetaOS network, the search results are completely transparently integrated into a MetaOS network and you can navigate and work in them just like in normal object trees. Almost any communication requirements such as news services, chats, instant messaging services etc. can be made possible with the basic mechanisms of a Meta-OS network at any point in the network and can be equipped with any user rights and authentication.

Any objects in an object tree can be attached to one another as required and their functions can complement one another.

Virtual generated models and devices of complex distributed technical process and organizational structures are simply successively formed by the step-by-step networking / coverage of MetaOS objects or sub-objects, since model data can be stored and updated decentrally (if necessary, but also centrally) (in contrast for publication DE 19834456A). The organization of the sub-models (a networked group of MetaOS nodes) to superordinate models (e.g. the entire MetaOS network) is based on the widely distributed interaction (mounting and synchronization) of the many components of the model. Central virtual models can be derived from the decentralized model by searching and collecting the model data if necessary. In addition, a central model can be distributed across a MetaOS network.

The elements of a MetaOS object model can be operated independently of one another on different process and master computers. Several MetaOS nodes can be used on one hardware. It is possible to add MetaOS nodes and services for technical and organizational processes dynamically to a model (in contrast to the publication DE 19834456A). Significantly reduced administration effort in the construction and operation of the networked virtual devices, since all network functions of a MetaOS network (mounting, caching) can be configured completely decentralized and are nevertheless accessible globally and in a structured form from every node of the network thanks to virtual centralization.

MetaOS networks are based on long-known internet technologies and can therefore be used universally.

The invention is due to the decentralized essentially self-sufficient and equal structures and the distribution of information on the one hand via MetaOS proxy chains and on the other hand the possibility of direct access very robust against disruptions in individual process and control computers (in contrast to the publication DE 19834456A).

The possibility of distributing the total information available in the primary and secondary network to any number of decentralized databases of the primary and secondary network, as well as an easy to implement, arbitrary and targeted distribution of individual information across the entire network, minimizes the risk of data loss.

Metadata objects of any complexity assigned to the process model elements enable optimized management, organization and distribution of a large number of different distributed services in the MetaOS network. From simple yet not optimal organizational principles, improved principles can gradually crystallize and stabilize (addition and change of the mount lists over longer periods). The user interface can be used independently of operating system-specific window managers on various operating systems and enables simultaneous work with MetaOS nodes from different parts of the network.

Since each MetaOS node has its own user interface, any part of the network can be accessed regardless of the networking of the MetaOS nodes.

The combination of the basic properties of MetaOS nodes, the meta-object concept and the graphical user interface to form an integrated overall concept enables a significantly improved cross-platform work with distributed complex technical process structures and extends technical models to include the organizational cooperation of operators, service personnel, controllers, etc.

The distributed data structure and the replication of data records ensures an improved distribution of the data transfer on the network and reduces the data traffic to a necessary minimum. Models can therefore be operated on very weak networks and are always up-to-date even at a decentralized location.

The distribution of frequently requested information in the entire network, over several MetaOS nodes with similar information (regarding syntax / semantics and metadata objects) in network areas with high demand increases the performance of the MetaOS network.

The decentralized data model can easily be changed from any decentralized location. The structure of the overall virtual model can change dynamically in a decentralized manner without the intervention of a central administrator.

Various decentralized virtual devices can be seamlessly combined and combined to form overall structures.

1. Mount, synchronize and filter data structures to an overall data structure. 2. Stacking of data structures to merge distributed properties of data objects. 3. Linking different data structures in a directory with the help of the analysis of syntactic / semantic relationships between the data structures.

Very simple update options for MetaOS networks, since software modules generally only have to be updated on certain computers at certain points. There is no need to update different client software because each MetaOS node stores its visualization service locally.

Sub-models still work if a higher-level administration fails, and data copies can still be accessed if their source has failed.

Since each computer part can hold a part of the model, there is a very close interlocking of the model with reality, and the virtual model is highly up-to-date. Since each computer node holds the part of the virtual model that the computer controls and monitors in reality, the component model and the entire history of a component model (values, status, documents, statistics, etc.) are retained when a component is repaired or exchanged with computer systems. A machine passport accompanying the runtime can thus be created from each real sub-device.

Very user-friendly handling thanks to a uniform operating principle on all levels and the possibility of using slightly different operating elements for different components and subnetworks.

The arbitrary nesting of graphical user interfaces enables high-performance comparisons of node contents through simple navigation processes without extensive programming and improves the overview of the overall system.

The level of complexity in navigation is reduced by using only a few basic graphic structural elements.

Simplified maintenance of the decentralized system, since the function of individual nodes can be replaced in a simple manner without loss of data.

Working on virtual databases in the central kernel of a MetaOS node increases security and reduces the risk of data loss since there is no need to work directly on the object services of a MetaOS object. Automatically built, staggered decentralized index and caching mechanisms in the primary network and secondary network (creation of a Access index) significantly improve the network's response times for searches and data access.

Since searches take place on decentralized databases that are constantly updated, searches always deliver current results. It is therefore also possible to search for rapidly changing dynamic data records in real devices.

You can search for any data records, processes, applications, documents (including multimedia documents) and their content, which are provided by object services anywhere in the entire network. Search results can be structured and clearly displayed due to the meta-object structures (generation of global overviews according to special conditions and contents). Decentralized evaluations can be initiated via information distribution requests, processes can be located, which should be started or stopped, and parameters can be transferred to found processes.

Individual nodes, which regulate a technical system, for example, can access all current process information of the entire network for local process control

The meta-object principle enables the search for special information to form current structured information topologies of any data records.

The networkable Kemel cluster allows in combination with the virtual ones

Information objects a common decentralized process and information management of any technical data objects and Documents on the real device. This happens within a single, platform-independent structure.

Due to the multi-core approach in the form of data services and the use of the existing system services for process control, MetaOS nodes are flexible, compact, fast, robust and economical. The required development work and the computing load by MetaOS nodes is very low.

MetaOS nodes enable parallel acquisition and distribution of various data services in the form of multifunction gateways. The way it functions as a gateway enables resource and computing power-saving implementation of complex service objects, since existing data services can be used predominantly. This leads to a very simple overall system with little complexity.

By implementing and mapping almost any

Interfaces and existing web applications in general

Object trees can be used to protect existing software investments.

A common command language for the communication of all object services allows any Loka-I and remote linking of all objects and can be mapped directly or indirectly to many other protocols (e.g. HTTP, FTP, Telnet, Mail, TCP / IP direct etc.). The control of real devices can thus take place via almost any communication channels.

Individual components of a MetaOS node can be easily adapted and expanded. Distributed services (eg administration services) in the network can be grouped into hierarchical groups and act as a directory service.

Missing object properties of an information object on a MetaOS node are automatically searched for in other mounted objects. Object properties can thus be distributed over several objects and, if necessary, put together like a puzzle. In this way, data objects can largely be left on the sources.

When searching in MetaOS nodes, not only addresses can be returned, but completely decentralized applications and databases can be immediately synchronized and started as a response. The way data records are displayed can be defined locally.

Automated distribution of any database. e.g. models and values for mapping real devices and organizations can first be formed centrally, and then distributed to a MetaOS network.

The virtual interconnection of identical and similar structural data from several MetaOS nodes to form a virtual total database in the form of symbioses increases the clarity in the network.

Services can be distributed across multiple computers.

The outsourcing of access authorization and authentication Data services enable access-dependent user management and authentication in MetaOS networks. Any user management and authentication modules can be used in different network areas.

Nodes with administrative functions can be operated in secure locations and still be fully integrated in the MetaOS network.

The formation of symbioses increases the conductivity of node groups with regard to computing load and data transfers through load balancing and the robustness of MetaOS subnets, since each node can act as a server for all data objects of the symbiosis.

Each node in the symbiosis holds the same object tree, consisting of all data objects in the symbiosis.

Symbiosis enable the user to move data objects transparently to the symbiosis nodes.

The browser-integrated graphical user interfaces of MetaOS nodes combine the advantages of pure Java clients, with the possibilities of browser plugins and ActiveX X components, freely definable HTML and XML masks, existing Java and web applications and allow the real ones for each group and component Device an optimal representation.

The control of the real devices, the efficient navigation, and the acquisition of knowledge with the help of the distributed stored information from an otherwise unmanageable variety of offers becomes clear compared to conventional methods improved.

The performance of the user interfaces automatically increases with the performance of the imaging technologies used in the browser components.

Since the visualization service that generates the graphical user interfaces is itself part of the MetaOS node and all work tools, i.e. The visualization service itself and all other required components can be fetched directly from the Internet from the object tree of the MetaOS node, which results in a greatly simplified application and administration of the overall system. The use of special, permanently installed clients is also possible.

Due to the reusability of most GUI components, the possibility of nesting the partial views that can be represented from different aspects (the elements of the virtual database) enables the creation of low-resource user interfaces that are very efficient even on weak network connections. The basic elements of the GUI are e.g. Also usable on mobile networks, as a user interface for thin clients in low-performance public networks and for applications under difficult conditions in which heat development in the computer systems plays a role.

The design for optimal use of the screen surface by partially automated optimization of window arrangements and sizes, the use of very few controls and the use of an automated window layer model for the controlled automatic layering of graphical user interfaces allows the use of very small displays (eg for low-cost solutions) to display all important information on just one screen page without restrictions on the clarity.

Since each information object can be displayed in addition to many other display and editing functions in the form of its own window manager with desktop, taskbar and windows, but also as a complete, independent browser, the GUI combines the advantages of classic window managers with modern browser technologies.

The dynamic nesting technique used, which arranges components of the interaction objects in the different hierarchy levels along the different directions of the display area, manages relationships and hierarchies of data elements of the real device and of external information components with one another much better than completely freely movable window techniques. In addition, it is easier for the user to keep an overview of the real and virtual devices.

Data objects in the virtual device and data records embedded therein can be selectively processed in the browser using freely definable graphic control elements.

An alternative text or graphic-based navigation in the hierarchical elements of the virtual information systems dynamically forms order groups during navigation, forms global and local temporal navigation sequences for all elements and thus significantly facilitates navigation compared to other techniques.

By integrating the browser-based display in Cross-platform office packages (e.g. Star-Office 5.x) offer the possibility of extended data type visualization and simultaneous further processing by integrated office and groupware components on a variety of operating systems. In this way, technical data objects can be inserted very easily into business-relevant documents. This method also saves switching between applications and saves a great deal of time when it comes to gathering and processing information.

Secondary networks included as essential elements only visualization services including interaction objects and additions for searching and writing metadata objects on web servers and FTP servers. The visualization service makes it easy to query, edit and search for and restructure data objects on web and FTP servers. The secondary network is ideally suited for the integration of small technical modules into the overall network. It allows the client-side networking of highly organized small-scale applications of a technical, commercial and documentary nature with other secondary networks (e.g. based on FTP services and web servers) as well as the optically seamless client-side integration into the primary network in a comprehensive organizational principle with minimal use of resources (running on the server side only the FTP or the web server). In addition, substructures of web. or FTP servers can be virtually superimposed by internal mounting and in this way data objects with different properties can be formed. The FTP or web servers serve as outsourced decentralized databases (the contents of which can of course also contain dynamic process values), the meta object sets of which can be queried cyclically from the primary network. The secondary network enables the controlled dynamic expansion of the entire database with the simplest Systematic means. Technical and economic difficulties in the installation and maintenance of classic databases are eliminated.

The server systems are hardly loaded due to the predominant use of the client's computing capacity.

There is no need for virtual Java machines or similar complex processes in secondary networks. These are unsuitable for devices that only pass on status information or are intended to perform relatively simple functions.

By dynamically generating links from meta-object components in the virtual information objects, a virtual restructuring of the interaction objects can take place and in this way facilitate navigation even in secondary networks.

I. The figures individually represent the following:

Drawing 1: Communication kernel central kernel data services

1 central kernel with object directory

2 directions of communication

3 Kernel structure data service

4 Data service external interface (e.g. nntp) 5 Data service external user management

6 Kerberos authentication service

7 Data service operation and monitoring (for operating an operator panel)

8 Data service IEEE-488 (measuring device with built-in analysis devices) 9 Snmp data service

10 OPC data service (with connected control system)

11 Adjacent central kernel

Drawing 2: Example diagram of data structure integration

12 Human function area (operation and monitoring)

13 Analysis functional area

14 Functional area technology

15 PDA GUI 16 Internet browser interface

17 real-time database

18 statistical data analysis

19 Real time data analysis

20 Operation via office software 21 Wind farm router

22 WKA process (IEC-1131-3)

23 WKA early warning system

24 Internet browser connection

25 Connection PDA surface 26 XML connection

27 Connection to SNMP system management

28 OPC connection

29 Propierary interface

30 Real-time analysis connection 31 Statistical evaluation connection

32 Database connection

33 common data structure visualization

34 common data structure data analysis

35 common data model real-time data 36 common data structure for all services 37 shared data structures from visualization and analysis services

38 proprietary data structure data service

Drawing 3: Logical communication options of the central kernel on a physical network:

39 Internet

40 central kernel on the Internet

41 Intranet 42 Central kernel in the intranet

43 central kernel in a wind turbine 1 (communication takes place via the power grid)

44 network router

45 central kernel in a wind turbine 2 (communication takes place via the power grid)

46 All central kernels can communicate bidirectionally with all central kernels in the network, with several connections being held simultaneously.

47 A central kernel with a communicable environment that it currently knows

48 A central kernel with another communicable currently known to it

Surroundings

Drawing 4: Data transfer scheme and centralizing principle of operation of the MetaOS data model

49 central kernel 1 with integrated databases of neighboring nodes and

Analysis interfaces, technical interfaces as well as operating and monitoring interfaces 50 central kernel 2 with integrated databases of neighboring nodes and

Analysis interfaces, technical interfaces as well as operating and

Observation interfaces 51 central kernel 3 with integrated databases of neighboring nodes and

Analysis interfaces, technical interfaces as well as operating and

Monitoring Interface

52 Central Kernel 4 with integrated databases of neighboring nodes and

Analysis interfaces, technical interfaces as well as operating and monitoring interfaces

53 central kernel 5 with integrated databases of neighboring nodes and analysis interfaces, technical interfaces as well as operating and

Monitoring Interface

54 central kernel 6 with integrated databases of neighboring nodes and

55 central kernel 7 with integrated databases of neighboring nodes and

Analysis interfaces, technical interfaces as well as operating and observation interfaces 56 external functional unit a

57 external functional unit b

58 external functional unit c

59 external functional unit d

60 external functional unit e 61 external functional unit f 62 external functional unit g

63 external functional unit h

64 external functional unit i

65 Physical model of distributed overlapping data structures 66 Interfaces map different data on a uniform local data structure

67 Virtual logical model with a uniform data structure (virtual centralization)

Drawing 5: Allocation of spatially or thematically related data services to central structures of technical devices

68 Wind farm-specific data services

69 Data service external user management wind farm 70 Kerberos authentication service wind farm

71 Data service network status of wind farm

72 Data service for wind farm performance

73 Service operation and monitoring WKA 1

74 Service analysis of measurement data WKA 1 75 Data service Snmp WKA 1

76 Data service regulation WKA 1

77 Data monitoring network monitoring WKA 1

78 Service operation and monitoring WKA 2

79 WKA 2 measurement analysis service 80 Snmp WKA 2 data service

81 Data service regulation WKA 2

82 Data monitoring network monitoring WKA 2

83 WKA 2

84 WKA 1 85 central kernel WKA 1 86 Spatially and / or logically related services for WKA 1

87 logically related services for WKA 2

Drawing 6: Functional areas central kernel 88 Virtual object tree

89 Command processor

90 User management -Defaultuser -Gastuser

91 Communication

92 OPC value 93 NFS files

94 Nntp Elemetn

95 analog values A / D converter

Figure 7: Distributed MetaOS node of logically related data

96 Linux / GNU system

97 central kernel

98 IEEE 488 service

99 NFS service 100 QNX real-time OS

101 Proprietary interface control system 1

102 Java Virtual Machine

103 Control system 2 with OPC server 104 OPC service 105 Measuring system with IEEE 488 interface 106 NFS server 107 Control system 1

Drawing 8: Distributed MetaOS node of logically related data using the example of a wind turbine 108 wind turbine

109 Java Virtual Machine 110 OPC service

111 Linux / GNU system 112 Laptop operating system

113 Control system 1 with OPC server

114 Control system 2 with proprietary interface 115 NFS server

116 Operator control and monitoring device 117 Service control system 2 NFS service

118 NFS service

119 control cabinet

Figure 9: Mix of hardware and software services 120 central kernel 121 LDAP service 122 LDAP server

123 Analog converter data service

124 AD / DA wall (he card

Drawing 10: Data service figure data source on

Object tree

(Encapsulation in data objects)

125 Type-converted object tree area 126 Proprietary interface area

127 process values

128 hierarchically organized log files

129 Transformed process values

130 Transformed log files 131 Offset path specification process values 132 Offset path specification process values

133 Communication central kernel

Drawing 11: Mount example of data services on central kernel 134 Central kernel with mounted synchronized object trees

135 Data service 1 with type-converted data

136 Data service 2 with type-converted data

137 Data service 3 with type-converted data

138 0PC client 139 NFS client

140 IRC client

141 Data service 4 can synchronize the entire tree of the central kernel

142 Control unit for all data of the entire tree

143 Another central kernel in the network with mounted and synchronized

Total tree.

Drawing 12: Structure element obiect tree

144 total element with embedded data objects and metadata objects.

145 data object

146 metadata object 1

147 metadata object 2

148 metadata object 3 149 header of metadata object 1

150 user data of metadata object 1

151 Data object and metadata object grouped to group a

152 metadata object 1 and metadata object 2 grouped to group b (overlay with group a) 153 metadata object 1 and metadata object 2 grouped to group c (Overlay with group b)

Drawing 13: Structure of a data object or metadata object

154 Tree structure of the header data of an object header 155 Useful data of the data object

Drawing 14: Layering of information of a data element on the central kernel

156 Merged data element from several elements of different

Data services on the central kernel in the order data service 1, data service 2, data service 3

157 meta objects from data service 3 158 objects and meta objects from data service 2

159 Object from data service 1

160 projection result from synchronization in the order objects from data service

1 and then data service 2 (sequence projection) 161 object not synchronized, since object from layer data service 1 is already synchronized

162 meta object from data service 2 (synchronized)

163 Meta object from data service 2 (synchronized) 164 Unsynchronized meta object, since meta object from layer data service 2 is already synchronized

165 meta object from data service 3 (synchronized)

166 Meta-objects projected in the central kernel Drawing 15: Example header use

167 data object

168 Header of the data object

169 User data 170 Timing information for synchronization

171 Local site resources (CPU, memory, network capacity)

172 Log and error information

173 Information on administration, security and transport properties

174 popularity and priority characteristics

175 Information on the type and condition of the operating and monitoring devices

176 Description information for the objects 177 Summarized information about hierarchically lower and higher

object structures

178 State of the data object

Drawing 16: relative synchronization

179 Central kernel with data elements in a hierarchical arrangement

180 relative synchronization of user data of a data object over a hierarchy level

181 relative synchronization of user data of a data object across two hierarchy levels

182 Relative synchronization of user data of a data object across three hierarchy levels

183 Inheritance of header data over several layers, through repeated relative synchronization 184 relative or absolute synchronization of user data from different

Meta objects of different hierarchy levels and the optional link at the destination.

Drawing 17: Use of the synchronization for the analysis (feeding) of data.

185 central kernel 186 OPC data service with connected technical control

187 Data service with connected technical analysis unit

188 data service implemented as operating and monitoring unit

189 Data service element contains technical process values

190 Data service element analyzed after relative synchronization of technical

Process values with the help of the data service the technical data

191 Element for data service prepares the after relative synchronization of the analysis data

Analysis results for presentation.

Drawing 18: Auto configuration through synchronization of information from hierarchically higher central kernels

192 Central Kernel 1

193 hierarchically subordinate central kernel 2 194 element with configuration data of a node becomes hierarchically lower

Central kernel synchronized.

Drawing 19: Schedulinq of data and metadata objects (synchronization) in the central kernel 195 Element 1 with timing information

196 Element 2 with timing information

197 Element 3 with timing information

198 Scheduler initiates the synchronization of objects based on timing information

199 database with timing information (designed as a data object)

Drawing 20: Synchronization example of data services with priority-controlled overlay of data stocks on a graphical quantity scheme.

200 central kernels

201 Data service 1 with priority 1 202 Data service 2 with priority 2

203 Data service 3 with priority 3

204 databases of data service 1

205 Sub-database 1 data service 1

206 partial database 2 data service 1 207 database data service 2

208 partial data 1 data service 2

209 partial database 2 data service 2

210 databases of data service 3

211 Sub-database 1 data service 3 212 Sub-database 2 data service 3

213 Synchronized databases from data service 1

214 Synchronized databases from data service 2

215 inserted partial databases from data service 1

216 inserted partial data sets from data service 3 217 overlay data sets identified as identical different

Datasets with different priorities 218 metadata from data service 1, which are not available in data service 3, are displayed by the projection mechanism since they are not overlaid by the metadata from data service 3.

Drawing 21: 219 central kernel WKA

220 data service process values

221 Data service log files

222 data service nntp

223 control cabinet 224 synchronization paths

Figure 22: Property stratification (mounting) (meta objects and header objects) in the central kernel

225 Root of the virtual object tree of the central kernel 226 Virtual file system data service

227 element a

228 element b

229 element b '

230 properties element b (objects, meta objects) 231 properties element b '

232 element c

233 element d

234 element c '

235 elements d '236 properties x1, x2 237 properties y1

238 properties x3.x4

239 properties y2

240 Root of the resulting virtual object tree of the central kernel 241 Element a

242 element b

243 Properties element a

244 element c

245 Element d 246 properties x1, x2, x3, x3

247 properties y1, y2

Drawing 23: Example for the use of operators during the projection layering of syntactically similar element trees.

248 Root of the virtual object tree of the central kernel

249 Virtual file system data service

250 element a

251 Element Artist 252 Element Artist

253 Element y with property y1

254 element b

255 properties x3, x4

256 element y '257 properties y2

258 Root of the virtual object tree of the central kernel

259 element a

260 Element Artist *

261 element y 262 properties y1, y2 263 element b

264 properties x3, x4

Figure 24: Access to objects in the MetaOS node Access to element Karl, property y2. Element is cached in the central kernel

265 Root of the virtual object tree of the central kernel with request based on

Central kernel 266 virtual file system data service

267 element a

268 Element b to which a data is not mounted

269 element Karl

270 properties y1 271 element b '

272 element c

273 properties x3, x4

274 element Karl '

275 properties y2

Drawing 25: Mirroring and distribution of data objects Writing the property x to elements Artist in various data services

276 Virtual file system data service 1 with priority 1 277 Root of the virtual object tree of the central kernel

278 Virtual file system data service 2 with priority 2

279 Element Artist '

280 Properties Element Artist

281 Element a 282 Element Artist 283 Element Artist "

284 Properties Element Artist "

285 Mount structure data service 1

286 Mount structure data service 2

Figure 26: Replication of data along the transport route of elements in the central kernels

287 Root of the virtual object tree of central kernel 1

288 Root of the virtual object tree of the central kernel 2 289 Root of the virtual object tree of the central kernel 3

290 element a with properties

291 Element b with properties

292 element b 'with properties

293 Element b 'with properties 294 Element c with properties x3, x4

295 Copy of element c from node 3 with properties x3, x4

296 Element d with properties x1, x2

297 Copy of element c from node 2 with properties x3, x4

298 Copy of element d from node 2 with properties x1, x2 299 Copy direction

300 mount structure

Drawing 27: Separate management of different meta objects in different data services 301 Virtual file system data service OPC

302 Root of the virtual object tree of central kernel 1

303 Virtual filesystem data service SQL

304 element a

305 element b 306 element c 307 property x1

308 property x2

309 property x3

310 property x4

Drawing 28: Formation of a symbiosis (additive layering) node 2 and node 3 mount directories corresponding to node 1

311 Root of the virtual object tree of node 1 312 Root of the virtual object tree of node 2

313 Root of the virtual object tree of node 3

314 Self-mount objects from object tree 1

315 Mount objects from object tree 2

316 Mount objects from object tree 3 317 Folders for all directories from the symbiosis

Drawing 29:

318 Root central kernel WKA 1

319 Root central kernel WKA 2 320 Root central kernel WKA 3

321 Mount data stocks WKA 1

322 Mount data stocks WKA 2

323 Mount data stocks WKA 3

324 Starting point total data pool 325 WKA 1

326 WKA 2

327 WKA 3

328 control cabinet WKA 1

329 control cabinet WKA 2 330 control cabinet WKA 3 Drawing 30: Example coupling primary network and secondary network in the user interface

331 OPC server of the WKA control system 332 Nntp server

333 primary network nodes with data services

334 Electrical switching device with HTTP server

335 control cabinet wind turbine

336 wind turbine 337 internet

338 Secondary network user interface

339 User interface of the primary network

Drawing 31: Contacting a symbiosis of 340 nodes 1

341 node 2

342 node 3

343 node 4

344 Virtual mount node 1 345 Virtual mount node 3

346 Direct mount node 2

Drawing 32:

347 OPC service 348 Nntp service

349 primary network nodes

350 Virtual object tree

351 User interface primary network

352 Secondary network node (eg Http or FTP server) 353 User interface secondary network 354 Symiink secondary network (starts user interface secondary network)

Figure 33: Coupling data stocks secondary network in primary network central kernel 355 OPC service

356 Nntp service

357 primary network nodes

358 Virtual object tree

359 secondary network service 360 secondary network nodes (e.g. web or FTP server)

Drawing 34: Visualization via a data service (e.g. as a Java client)

361 calculator 1 362 central kernel

363 Telnet service

364 FTP service

365 IMAP service

366 User interface on computer 2 367 Object tree structure data service

368 Graphics output part data service

Figure 35: Visualization using separate client software

369 computers 1 370 central kernel

371 NFS service

372 OPC service

373 Corba service

374 User interface on computer 2 375 Object tree structure data service 376 Proprietary part of data service

377 Graphics output part data service

Figure 36: Object tree explorer 378 Explorer basic operating bar

379 structuring folder

380 objects from data service 1

381 objects from data service 2

382 objects from data service 3 383 objects from data service 4

Figure 37: Object tree explorer with metadata objects

384 Predefined display patterns for metadata groups (encrypted in the headers of the metadata)

385 Explorer basic control bar

386 Object of the virtual object tree

387 meta-objects of the tree objects

Drawing 38: predefined object view (symbol view)

388 Explorer basic control bar

389 objects

Drawing 39: Predefined object view encrypted in metadata (Real view)

390 Explorer basic control bar

391 HTML page with embedded metadata or Java applet

Drawing 40: Object view Object Manager 392 Explorer basic control bar 393 Object 1 (visible)

394 Object overview

395 Object in task bar

396 Object2 in taskbar (active, but only visible in taskbar) 397 Object3 in taskbar (active, but only visible in taskbar)

398 Object4 in taskbar (active, but only visible in taskbar)

399 Object δ in taskbar (active, but only visible in taskbar)

400 Object6 in taskbar (active, but only visible in taskbar)

Drawing 41: Representation of several objects

401 Explorer basic control bar (information from WKA1 and WKA2 have been synchronized, for example, by external nodes)

402 Object wind turbine 1 view real 403 Object wind turbine 2 view real

404 Object overview

405 Taskbar representation WKA 1

406 Taskbar representation WKA 2

407 basic operating bar WKA 1 408 basic operating bar WKA 2

Figure 42: Integration of external information

409 Explorer basic control bar

410 Object 1 (visible) (e.g. wind turbine 1) 411 Object 2 (visible)

412 Object overview

413 desktop (e.g. with geographic information system)

414 Basic control bar inner Explorer 1

415 Basic control bar inner Explorer 2 Figure 43: Nesting of window managers

416 Explorer basic control bar

417 outer desktop

418 Basic control bar inner Explorer 1 419 Basic control bar inner Explorer 2

420 Object overview

421 Inner Desktop 1

422 Inner Desktop 2

Figure 44: Nesting of window managers using the example of wind turbines

423 Explorer basic control bar

424 External desktop with visualization of wind turbines in a wind farm (e.g. as a statistical overview)

425 Basic control bar inner Explorer 1

426 Basic control bar inner Explorer 2

427 Object overview

428 Inner desktop 1 with WKA 1 429 Inner desktop 2 with WKA 2

430 partial data 1 WKA 2

431 Partial database 2 WKA 2

432 subcomponent 1 partial data consisted of 2 WKA 2

433 Subcomponent 2 sub-database 2 WKA 2 434 sub-database 1 WKA 1

435 Sub-database 2 WKA 2

436 Taskbar representation WKA 1

437 Taskbar representation WKA 2

Drawing 45: decoupling a subset of the virtual MetaOS node file tree

438 Explorer basic control bar

439 Outer desktop

440 Basic operating bar object 1 441 Basic operating bar object 2

442 View of object 1

443 Desktop object 2

444 Object 2.1 Real view

445 Object 2.2 Real view 446 Object overview

447 Object overview from perspective of object 1

448 Taskbar representation object 1

449 Taskbar representation object 2

Figure 46: Graphical separation of the central kernel in the partial data of the data services

450 Basic operating bar, central kernel

451 (part) database of the central kernel

452 Basic operating bar data service 1 453 (part) data stock data service 1

454 Basic operating bar data service 2

455 (part) database data service 2

456 Basic operating bar data service 3

457 (part) database data service 3

Figure 47: Multiple subsets

458 Explorer basic control bar

459 Outer desktop

460 Basic control bar inner explorer 461 Object overview inner explorer. 462 View of object 1

463 Uncoupled object 1

464 Uncoupled object 2

465 Uncoupled object 3

Drawing 48: Object manager in three-dimensional space

466 Object Manager 1

467 Object Manager 2

468 Object Manager 3

Drawing 49: Object manager in three-dimensional representation

469 Object Manager 1

470 Object Manager 2

471 Object Manager 3 472 Object Manager 4

Drawing 50: A number of abstracted object managers in three-dimensional representation

473 Object Manager 1 474 Object Manager 2

475 Object manager 3

476 Object Manager 4

477 Object manager 4.1

478 Object Manager 4.1.1 479 Object Manager 4.1.2

480 object manager 4.1.3

Drawing 51: Three-dimensional object manager with wind power attachments

481 Representation of wind farm 1 482 Representation of wind farm 2 483 Representation of wind farm 3

484 Representation of wind farm 4 with sub-objects

485 Representation of wind farm section 4

486 Representation of wind farm 4, plant 1 487 Representation of wind farm 4, plant 2

488 Representation of wind farm 4, plant 3

Figure 52: Logical basic structure of the MetaOS network

489 Virtual center consisting of hierarchically highest nodes 490 proprietary interface structures

491 Mount structure of the central kernel to form a basic logical hierarchy.

492 external data service 1 node A

493 external data service 2 nodes A 494 external data service 3 nodes A

495 external data service 4 nodes A

496 external data service 5 nodes A

497 external data service 6 nodes A

498 external data service 1 node B 499 external data service 1 node B

500 external data services 1 node B

501 external data service 1 node B

502 external data service 1 node B

503 external data service 1 node B

Drawing 53: Mounting scheme for a decentralized globally uniform object tree

504 Top hierarchy (virtual center) consisting of a symbiosis of three nodes 505 nodes with static data 506 hierarchy level 1

507 hierarchy level 2

508 hierarchy level 3

509 hierarchy level 4 510 data tree with external interfaces (dynamic data)

511 external interface 1

512 external interface 2

513 external interface 3

514 external interface 4 515 external interface 5

516 external interface 6

517 Hierarchy 3 consists of a symbiosis of two nodes

518 Synchronization of the global tree from hierarchy 2 for uniform access to the global network from every node

519 Synchronization of the lower hierarchies to local databases to form a

Regional tree

520 Synchronization of the global tree from the top hierarchy (top hierarchies can be simulated after synchronization of lower hierarchies and do not necessarily have to exist)

521 Formation of regional tree at top hierarchy 522 local databases are made available globally

Drawing 54: Example of a logical link with wind turbines and solar modules

523 Virtual center of the entire network 524 Server with rough structural data for the entire network, which is sent to everyone Nodes are inherited

525 servers with additional structural data for the wind farm network.

526 servers with additional structural data for the solar network, which are passed on to all cells

527 knots WKA 1

528 data services in the tower head of WKA 1

529 nodes WKA 2 530 data services in the tower head of WKA 2

531 solar cell 1

532 data services in solar module 1

533 node solar module 1

534 Data service controller solar module 1 535 Data service analysis solar module 1

536 solar cell 2

537 data services in solar module 2

538 node solar module 2

539 Data service for control of solar module 2 540 Data service for analysis of solar module 2

Figure 55: Knot knowledge of the entire network and communication

541 node 1

542 Known Local Environment Node 1 543 Node 2

544 Known Local Environment Node 2

545 external service a node 1

546 external service b node 1

547 external service c node 1 548 external service d in the learned environment of node 1 549 external services in a learned environment from node 1

550 external service f in the learned environment of node 1

551 Direct communication of all external services with learned environment via central kernel node 1

552 overlap area of known local environments (increase the robustness of the

Forest)

553 "logical" framework for global data tree (mounted and synchronized

Basic structures)

554 known global environment for all nodes including nodes 1 and 2 (virtual center).

Drawing 56: Communication with a familiar environment

555 knots 1

556 Mount structure of the nodes

557 Known Environment Node 2

558 simultaneous communication possibility of node 1 with all known nodes

Figure 57: Indices and change reports

559 Change message from node 3 to node 2

560 Node 1 561 Change message to higher-level hierarchy

562 Change message over two hierarchy levels

563 known environment node 1

564 Known Environment Node 2

565 symbiosis of two nodes 566 index structure nodes as objects or meta objects 567 Node 2 asks for changes across two hierarchy levels

568 Node 2 asks for changes in the parent structure

569 nodes 2

570 nodes 3

II. Embodiments

A collection of spatially or thematically related services, called a MetaOS node (Fig. 1), is held together by a compact central kernel with an integrated command processor, which defines the communication within a node, structures and organizes the services centrally, caches object data and a rudimentary one Provides access control (Fig. 6). All communication of the services is coordinated via the central kernel.

All central kernels can communicate bidirectionally with all central kernels in the network, with several connections being held simultaneously (FIG. 3).

Services of the MetaOS node run on different, decentralized underlying physical or logical machines, for example on a QNX real-time computer, a Linux computer and a Java virtual machine (FIG. 7).

8 shows an example of a distributed MetaOS node using the example of a wind turbine.

Services implement file systems, network services, device drivers etc. or provide them via a gateway. FIG. 5 shows an assignment example of data services to central kernels in wind power plants

In contrast to classic microkernel-based kemel clusters of operating systems, which only have to provide resources for their own hardware in the form of interfaces, a MetaOS node also ensures the provision of more organized logical resources of their own and third-party hardware and operating systems. A service of a Meta-OS object therefore does not differentiate between hardware and software resources (Fig. 9).

Examples of services:

- Process gateways (e.g. OPC)

- Network file systems (NFS, WebNFS, Samba etc.) - Directory protocols and network services (Jini, LDAP)

- Object-oriented or relational database drivers.

- Mail and news clients

- Internet Relay Chat (IRC)

- Each service of a MetaOS node is divided into two parts. Part of the service accesses data objects and services located outside of MetaOS nodes (or forms a server for external clients), the other part forms a server structure for the central kernel. In the simplest case this is a simple value, in the most general case dynamically changing object structures (FIG. 10). - The various data services of a node are attached (mounted) at any point to a virtual hierarchical object structure (element / cluster tree) of the central kernel. For the central kernel, the structure of the mounted services looks exactly like the own virtual object tree (Fig. 11). A wide variety of data structures are combined into one Structure integrated on the central kernel (Fig. 2)

Fig. 21 illustrates the attachment of data services in the central kernel of a wind turbine. Multiple central kernels will continue to be in a forest of all

Central kernel integrated (Fig. 4).

- Mount processes can be carried out at various points in the virtual object tree, but also in such a way that several services with partially identical and named file trees are virtually superimposed on top of each other starting at a mount point

(Fig. 22).

- Object trees can also be mounted using "syntactic / semantic logic" or other logical object folders, so that syntactically / semantically similar object folders are each merged into a single object folder (FIG. 23).

Object trees can also be synchronized by relative mount specifications across one or more hierarchies (Fig. 16). 17 illustrates the possible uses when analyzing data.

By means of relative synchronization, configuration data from individual central kernels can also be passed on across several hierarchy levels, thus configuring additional nodes. If configuration data is available in several nodes, this is aggregated by the projection mechanism.

Examples of superimposed properties of mounted services:

The basic structure of a data element on the central kernel is shown in FIG.

(2) and Fig. (3)

Lesezuqriff: If an object property in the object tree of the central kernel cannot be accessed, the central kernel tries to gain access to the object property via other services responsible for this object. Responsible services can be local object services of the same or a higher position in the object tree, but also further, mounted MetaOS nodes (FIG. 24). The order of the search access to the various services is determined by the order of the mount points in the mount lists of the objects. (Figure 14) shows a scheme for layering information from multiple data services. The same applies to the headers of the data objects (FIG. 15)

Properties for the layering and projection of information such as for the user data.

The synchronization sequences of the elements and data objects in the central kernel are determined by a scheduler in the central kernel, which works with the timing information from the headers. (Fig. 19)

20 shows an example of synchronization of data services with priority-controlled

Data overlay existed on a graphical set scheme. Each data set represents a (sub) data tree of the data services

Mirroring and distribution of data objects:

- One or more databases can be attached to each MetaOS node that store data objects from other object services or write data objects to data services. When writing to an element of a central kernel, the central kernel also tries to write to all other mounted elements (FIG. 29).

- Requested data objects are replicated by default along the transport route (Fig. 26). Data and metadata objects:

Separate management of data objects and metadata objects in different data services (Fig. 27).

Mount examples for central kernel:

- symbiosis:

Merging and matching of virtual MetaOS information objects of a group of MetaOS nodes in one folder »Total«. The complete information object of all clusters is available in addition to the local data objects on each individual computer of this object (FIG. 13).

29 shows the interconnection of three wind turbines to form a virtual one

Overall process.

- Mount symbioses through additional MetaOS nodes (Fig. 31). Node 4 also receives node addresses and further information from the metadata of nodes 1 and 3 as loose mount nodes to improve structural stability.

Networking of primary network and secondary network:

- Networking of primary network and secondary network via the client (Fig. 32 and Fig. 30) secondary network is in the user interface of the

Primary network integrated.

- Networking of primary network and secondary network with the help of a MetaOS node (Fig. 33).

User interface: A MetaOS node communicates with a user via visualization services. Visualization services are themselves components of MetaOS nodes and communicate with the command processor like the other nodes of the object. A MetaOS node can manage several visualization services on different machines. Each visualization service can generate several user interfaces.

Example 1:

Meta-OS nodes with different visualization services on one on one node (operation via Telnet, FTP or IMAP mail client) (Fig. 34) (361-365).

Example 2:

Meta-OS node with a visualization service and web server on two machines. It is operated via a web browser and pagereload. The computing power of the client is not used. The visualization service is provided with its own window manager that is scalable in terms of performance, the graphic resources of which are provided by the web browser (FIG. 35).

Embodiment 3: In order to increase the speed of the user interface, a Meta-OS node can be mapped with a modular visualization service as a JavaApplet / JavaBean / ActiveX component, for example in a web browser. The user interface is generated entirely on the client side and implemented in the web browser by HTML / XML elements (Fig. 34 366-368). a) Representation of some basic two-dimensional representations (Fig. 19).

Fig. 36 Object overview Fig. 37 Object overview in detail Fig. 38 Symbol Fig. 39 Real Fig. 40 Object manager

The selection of an object opens the respective object in the Explorer window, or according to information that is in the header of the object itself. b) Comparison mode of several wind turbines (Fig. 40). c) Integration of external information (geographic information system, VRML, robot visualization) (Fig. 42). d) Nesting forms of representation of an object manager e.g. Object manager in the object manager (Fig. 43). An example with

Fig. 44 shows wind turbines e) decoupling subsets d1) decoupling subsets while maintaining the reference point (2 * object manager one nested) (Fig. 45)

Graphical separation of the central kernel data into partial data sets of the data services (Fig. 46). The data stocks in the central kernel are displayed assigned to the data service sources. d2) Multiple decoupling of subsets (Fig. 47). Closing the

Objects overview also closes all decoupled, hierarchically subordinate windows d) Interaction room 3-dimensional d1) Object manager stacked in the room (Fig. 48) d2) Window manager in 3d mode in a ring with cubes Sub-elements (Fig. 49) d5) 2 ^* Multiple decoupling from the window manager in the ring while maintaining the references (Fig. 50)

If one of the basic elements (element 1) is closed, all subordinate elements are also closed

An example with wind farms and wind turbines shows (Fig: 51)

Otherwise, the same elements are available in the 3d space as in the two-dimensional surface.

Example of a four-dimensional image:

The mapping of a four-dimensional structure onto a 3-dimensional space results in groups of different structures. If you consider e.g. navigation through the virtual information object (time) as a fourth dimension, one step back from every open window can change larger three-dimensional structural representations (e.g. closing entire subtrees in three-dimensional space).

The corresponding visualization service is automatically sent to the client with the required resources. In addition to the structure data of the virtual information object, the visualization service also contains a structure description of a scalable browser manager and a browser in the browser. The minimum requirements for the visualization service in example 3 are for the programming language Java Javal .0 / Live Connect / Javascript 1.0 / HTML 3.2 with frame extensions, (important for mobile devices). Since the visualization service only transmits minimal graphic structures, it is very compact and can be transported quickly via cables. By default, nodes are linked in a logical tree shape to form a basic structure (Fig. 52)

The detailed linking logic shows the hierarchical mounting diagram in FIG. 53 for the construction of a decentralized, globally uniform object tree, whereby individual nodes can themselves represent symbioses. The mounting scheme creates a uniform global data tree in each node, as well as a regional data area, starting with the local data stocks in which the local data stocks are synchronized with the local data stocks of the lower hierarchies. After the synchronization, higher hierarchy levels can be simulated by lower hierarchy levels and do not have to exist in real life, i.e. They can fail temporarily without endangering the structure of the network.

Fig. 54 shows an example game application of the network with decentralized energy systems, in which the virtual center manages the structural data for the network, the uppermost hierarchy the rough structure of the entire network, and structural data supplementing the lower hierarchies. The lower hierarchies synchronize the structural data of the higher hierarchies and combine them with the local structural data

Fig. 55 illustrates the basic knowledge of each individual node about the entire network after entering the network and the learning process via the network by navigation. When entering the network, the node first learns the structure of the local environment and the structure of the virtual center through synchronization processes. Due to the overlapping of the synchronized, known environments, individual nodes can fail without the basic structure of the network being impaired.

Fig. 56 illustrates the simultaneous bidirectional Communication options of a node with the known environment

Figure 57 illustrates the distribution of indexes across the network and describes how changes in the network are propagated across the network. At higher hierarchy levels, changes in the object trees are reported event-oriented, hierarchically lower levels independently ask for changes in higher hierarchy levels by fetching change flags through relative synchronization.

Claims

claims

1.

Device for modeling, integrated monitoring, control, regulation, analysis and data storage of complex technical processes based on individual measurement, analysis, control, operating. Observation and storage devices, characterized in that the device has at least one central kernel, each with an integrated Access control, separate control for the administration of tasks, threads, memory, network capacities and a hierarchically structured object tree management with integrated function for program-controlled or manual collection and distribution of data elements, administration and communication of services and other central kernels including associated data structures.

Second

Device according to claim 1, characterized in that the device has spatially and / or thematically related physical or logical devices or further central kernels as clients or server services of the MetaOS node, which simultaneously communicate with the object tree management of the central kernel if necessary and at least one service of the device external Can have interfaces for operation and monitoring of the distributed data processing system.

Third

Device according to one of claims 1 or 2, characterized in that a local central kernel during the

Operation is expanded by any data services and additional central kernel if required and any data services and further central kernels can be removed if necessary.

4th

Device according to one of claims 1 to 3, characterized in that further external central kernel and the

Services of a central kernel to the respective proprietor

Individual devices assigned and standardized, hierarchically structured

Have object trees.

5th

Device according to one of claims 1 to 4, characterized in that the object trees of the services or their

Parts of the object tree management of the central kernel are assigned at any point (mounted) and via an optional program-controlled, based on sequences, priorities, filters and operators

Projection method for a resulting object tree with elements that are combined from objects of several services, combined (synchronized) and saved.

6th

Device according to one of claims 1 to 5, characterized in that each element of the object trees of

Services and central kernels consist of any data object and optionally any number of metadata objects assigned to the data object and a hierarchically structured tree of header data objects is assigned to each data and metadata object and all object tree elements of all data services, central kernels and header data objects of the distributed data processing system have an identical basic structure. Device according to one of claims 1 to 6, characterized in that objects, metadata objects and

Header data objects of an element of the central kernel in any combination with the projection method according to claim 5 from the

Services of the central Kermel and from other central kernels in the

Element are projected and the header data objects of each data, and

Metadata object of a central kernel Timing information for

Synchronization, information on resources of the local location (CPU, memory, network capacities), log and error information, information on user management and authentication, security, transport, popularity and priority properties and status of the data object, as well as complete information on the type and current status of the Operating and observation devices as well as description information about the objects and summarized information about hierarchically lower-lying object structures, which are mounted and projected from different specialized data services and further central kernels into a common header object structure of the element.

8th

Device according to one of claims 1 to 7, characterized in that the same information types of the

Header data objects from any central kernel by mounting, and program-controlled synchronization to a common one

Header data object are projected.

Device according to one of claims 1 to 8, characterized in that data, metadata or

Header data objects of object trees, which are of different Data services and other central kernels can be mounted in the same location in the object directory of the central core, synchronized and saved with the central kernel using projection priorities and syntactic, semantic, logical and numerical program-controlled filters and operators.

10th

Device according to one of claims 1 to 9, characterized in that any objects, elements and substructures of a central kernel with any objects, elements and substructures of other local data services, user interfaces or central kernels and with any objects, elements and structures of your own central kernel with the aid of a for all description and communication processes between objects, elements and structures of the same command language are mounted, filtered, linked with operators and synchronized and that data, metadata and header data objects of hierarchically higher as well as subordinate tree elements are mounted and synchronized by specifying relative mount marks.

11th

Device according to one of claims 1 to 10, characterized in that in each central kernel

Data processing system an index of synchronized object directories, data objects and metadata objects is created.

12th

Device according to one of claims 1 to 11, characterized in that a group two- or three-dimensional, more interactive in a two- or three-dimensional Area components of a graphical user interface ai .. a _m , again consisting of sets br..bm _' of two- or three-dimensional interactive graphical user interfaces generated at local and decentralized locations, in which each user interface of set b contains a set that is specific to you c1..cn contains graphic basic elements and optionally a set of freely definable additional graphic elements and the design of at least one of the basic elements of each set c is such that at least one further graphical user interface of the type of sets a or b or at least one user interface of at least one element of the Set of user interfaces b can be completely mapped in a sub-area of c, and the elements of sets a and b serve as external control and monitoring interfaces of the elements of one or more data services in the distributed data processing system according to claims 1-11, in which data is synchronized and presented through the interfaces from the data service.

13th

Device according to one of claims 1 to 12, characterized in that at least one of the basic elements of each set c represents its own operating and observation surface with object explorer, an object bar of selected objects and a visualization surface for objects.

14th

Method for integrated monitoring, control, regulation, analysis and data storage of preferably multi-part complex technical processes by any participant of the distributed data processing device, characterized in that individual information, information lists and hierarchically organized information structures from data, status and function interfaces of the individual measuring, analysis, storage, control, operating and observation devices and from central kernels are encapsulated by program-controlled information projection as required in the respective object trees of the assigned services.

15th

A method according to claim 14, characterized in that each data object and metadata object of a data service or central kernel by program-controlled

Synchronization of time-varying information from the technical

Encapsulates devices.

16th

Method according to Claim 14 or 15, characterized in that the program-controlled synchronization of object structures and objects is controlled by schedulers in the data services, which take their timing information from the header data objects of the object trees

17th

Method according to Claims 14 to 16, characterized in that, starting from an initially individual central kernel as a virtual center with further central kernels, a logically linked hierarchical network of central kernels from distributed object inventories is mounted, so that each central kernel of the hierarchy has access to a resultant, uniform, network-wide global (virtual centralization) directory, a different regional directory of logically related elements and a local directory receives the decentralized services and elements by each node forming a mounting scheme with other nodes, so that each node synchronizes local data services into a local private and, if desired, a local public area directory of logically related elements, a fixed global directory of a hierarchically higher central kernel to the Mount and synchronize the root element of its own central kernel and mount and synchronize public local area directories to the public area directories of the higher-level node in the local global directory and mount public regional area directories of subordinate nodes to its own regional object directory.

18. The method according to claim 14 to 17, characterized in that each central kernel synchronizes databases of the virtual center and databases of other central kernel and simulate temporarily inactive failed central kernel with these synchronized databases for the period of failure.

19th

Method according to Claims 14 to 18, characterized in that search processes in the network are implemented by using the device according to Claim 9

20th

Method according to Claims 14 to 19, characterized in that any one mounting the central kernel Services and other central kernels can read, observe and analyze the information projected and stored in the central kernel from all devices assigned to the central kernel as well as the global and regional directory, and can use the opposite process to describe and operate information, monitor and regulate in this way.

21st

Method according to Claims 14 to 20, characterized in that each central kernel from a logically connected group of central kernels mounts and synchronizes all directories of all other central kernels in the group in a range directory defined for the entire group and forms a symbiosis with them

22nd

Method according to Claims 14 to 21, characterized in that a set of FTP and HTTP servers via FTP and HTTP capable data services is assigned to the network and feeds data into it.

23rd

Method according to Claims 14 to 22, characterized in that timing information for synchronization, information about resources of the local location (CPU, memory, network capacities), log and error information, information about user administration and authentication, security, transport information, is stored decentrally in the service header objects. , Popularity and priority properties and status of the data objects, as well as information about the type and status of the operating and Observation devices as well as description information about the objects and summarized information about hierarchically lower-lying object structures can be synchronized according to the method in claim 17 into their own private directories, regional area directories and global directories that are always uniform for all central kernels.

24th

Method according to Claims 14 to 23, characterized in that changes in data objects, metadata objects and header data objects in the object trees of data services and central kernels are noted in the header data objects of the respective elements and the change note is successively transmitted to hierarchically superordinate object hierarchies and hierarchically subordinate object hierarchies regularly in change hierarchies Ask hierarchically higher elements so that object and element changes are noticed in all global, regional and private object tree directories.

25th

Use of the device according to one of claims 1-13 for integrated, virtual centralized modeling, monitoring, control, regulation and storage of complex process sequences

26th

Use of the device according to claim 25 for systems arranged at a spatial distance from one another

27. Use of the device according to claim 26 for spaced-apart industrial plants, wind farms, Solar cells, combined heat and power plants, biogas plants, hydropower plants, coal power plants, oil power plants, gas turbine plants,

Nuclear power plants, fuel cell plants and others

Energy supply systems, also in mixed operation, for mobile radio stations, operating and monitoring devices, pipeline networks, electricity networks, building automation in urban areas and administration of technical infrastructures.