EP1516250A2 - Softwareapplikation, softwarearchitektur und verfahren zur erstellung von softwareapplikationen, insbesondere für mes-systeme - Google Patents

Softwareapplikation, softwarearchitektur und verfahren zur erstellung von softwareapplikationen, insbesondere für mes-systeme

Info

Publication number
EP1516250A2
EP1516250A2 EP03706314A EP03706314A EP1516250A2 EP 1516250 A2 EP1516250 A2 EP 1516250A2 EP 03706314 A EP03706314 A EP 03706314A EP 03706314 A EP03706314 A EP 03706314A EP 1516250 A2 EP1516250 A2 EP 1516250A2
Authority
EP
European Patent Office
Prior art keywords
objects
software
runtime
meta information
software application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP03706314A
Other languages
English (en)
French (fr)
Inventor
Elmar Thurner
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Publication of EP1516250A2 publication Critical patent/EP1516250A2/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G06F8/24—Object-oriented

Definitions

  • the invention relates to software applications, in particular MES applications, with objects that contain and / or reference data and / or attributes and / or behavior, the objects running and / or being stored on at least one computer unit.
  • the invention relates to a software architecture, in particular for MES applications, and a method for creating software applications, in particular for MES systems.
  • the invention further relates to a
  • Software development environment a computer program, a data carrier and a data processing device.
  • Manufacturing Execution Systems From “Software for automation - creating transparency about processes", article by Dirk Kozian in Electronics for Automation 11, November 17, 1999 is known for the automation of production or manufacturing processes so-called Manufacturing Execution Systems (MES) use. These systems integrate the automation level (controls) with the ERP systems (ERP: Enterprise Resource Planning) at the corporate management level.
  • Manufacturing execution systems are systems that, for example, provide information for the optimization of production processes or carry out the coordination or optimization of production processes.
  • the manufacturing execution systems have to supplement the rough planning data of the ERP systems with plant-specific and current detailed planning data and forward them accordingly to the subordinate automation level.
  • they have the task from the automation level to take over production-relevant information, prepare it and report it to the management level.
  • MES systems thus perform, among other things, the task of vertical integration between the company management level and the automation level.
  • Typical individual tasks of MES systems are enterprise asset management, maintenance management, information management, scheduling, dispatching and trace & tracking. These tasks are carried out by MES components or MES applications.
  • Metadata is information about other information, e.g. Information about existing objects themselves. This metadata is in the overall system or in the
  • the object of the invention is to provide software applications, a software architecture and a method for creating software applications which improve the changeability and extensibility of systems.
  • the above-mentioned object for a software application is achieved by the features of claim 1.
  • the meta information assigned to an object describes e.g. which data and functions an object contains, but meta information can also contain descriptions for implementation and operation or include user documentation.
  • meta information can be described using tags or attributes and assigned to the objects. Meta information can also be given a hierarchical structure.
  • An advantage of the invention is that no explicit code generation is required to run a software application.
  • the objects are black boxes with appropriate access mechanisms for reading the metadata.
  • the flow logic and the flow sequence of the software application represented by the tree are determined from the structure of the tree and its networking.
  • the structure of the tree which can be changed manually or automatically at runtime, and the networking of the tree elements determine the operands with which functions are supplied and whether functions are executed sequentially or in parallel.
  • the structure of the tree and the networking of the tree elements e.g. determines which input-sized devices are supplied and how the output values generated by the device are processed.
  • Software development environment is graphically edited by a user of the tree and the networking.
  • the representation of the trees can be different and can be freely selected by the user or application-specific.
  • the hierarchical arrangement in the tree enables the tree elements to be networked or displayed. Networking or demonstrations
  • the tree elements can also be created by referencing or lateral networking to elements of other subtrees edited by the user.
  • the inputs for creating the tree and for establishing networks can be made using input masks, drag & drop mechanisms or via voice input.
  • the implementation of the individual objects is associated with their code and meta information. Because the software application is made up of ready-made objects at runtime (e.g. automatically based on the metadata about the application process), there is no need for an explicit compilation phase to generate the code of the software application to be created. Compilation runs can take a long time. The fact that explicit compilation runs are not required minimizes the time for creating the software application, testing and commissioning.
  • Another major advantage is that programs and data are treated consistently.
  • Data are object trees without functions
  • programs are object trees with functions. All mechanisms in a runtime system for assembling, networking, versioning, storing, transporting etc. of data and programs only have to be implemented once and not once for data and for programs. This also simplifies handling for software developers, commissioning engineers and administrators since they only have to familiarize themselves with these mechanisms once.
  • networking branching or referencing between the objects can take place in a different granularity. For example, networking by referring to physical addresses (using pointers or pointers), which achieves high efficiency (e.g. within the course of a process). Other networking mechanisms are e.g. electronic messages (e.g. email), telephone or fax. Depending on the requirements of the underlying application, the user can choose an appropriate networking mechanism.
  • Objects in the sense of the invention are objects that are used in the creation of the software application, but also runtime objects.
  • Runtime objects are objects that execute the logic of the system at runtime of a system (e.g. an application).
  • the software applications according to the invention are furthermore suitable for solutions for process control systems and production automation systems.
  • a first advantageous embodiment of the present invention for a software application is that the objects and / or referencing mechanisms and / or networking mechanisms and / or implementations of the objects are interchangeable at runtime. Due to the fact that objects are exchanged at runtime for other objects, for example objects with extended functionality or the implementations of objects (for example the new implementations have been corrected or have better performance) or referencing and networking mechanisms the turnaround time for changes is significantly reduced. This increases the flexibility for the user and the operator of a plant and increases the agility of a company. No common compiler is used to evaluate the metadata, but a so-called incremental compiler or an interpreter that is only active locally at the time of the exchange. For the newly inserted object, if necessary, incremental code is generated and the incremental compiler or interpreter adds the newly inserted object (or the
  • Another advantageous embodiment of the present invention for a software application is that services can be added to the objects at runtime.
  • the services use the object-local metadata to generically provide (MES or control) infrastructure functions.
  • Such services can e.g. be: serialization, replication, encryption or access protection.
  • the objects can thus be equipped with so-called "Quality of Services". A user of an object can rely on the execution of these services and abstract from their implementation.
  • Another advantageous embodiment of the present invention for a software application is that implementations of the referencing mechanisms or of the networking mechanisms or of the services for data and for programs can be used.
  • the mechanisms and the services therefore do not have to be implemented separately for data and for programs.
  • meta information can be added to all objects (regardless of whether it is data or programs) in the same way the meta information can be accessed in the same way for all objects.
  • Objects are networked statically and / or dynamically.
  • Networks can be created statically when the tree is created manually, but can also be created automatically on the basis of current information or meta information (e.g. if required).
  • Networking can be done using different mechanisms and
  • OPC E-mail to objects or networking via OPC protocols (OPC stands for OLE for Process Control).
  • OPC protocols are often used in particular in the industrial environment.
  • HTTP Hypertext Transfer Protocol
  • SOAP Simple Object Transfer Protocol
  • Another advantageous embodiment of the present invention for a software application is that the objects physically contain the meta information.
  • an object can also be used on its own for the organization, reorganization or reconfiguration of the software application, depending on which one
  • Meta information (type and scope) is available in the object. This is particularly advantageous for mobile objects, For example, for software agents who move from computer to computer on the Internet (or other networked systems such as intranets) in order to collect high-performance system information, for example, for a maintenance system, for example, locally at the computer.
  • the meta information contains static and / or dynamic object models.
  • object models are e.g. Classes and their relationships, state / event models, activity models, deployment models or domain models (e.g. MES process model in specific industries such as automotive manufacturing, fertilizer production). This is particularly advantageous for generic software development or for software generators.
  • the meta information describes an application or a business process. If the meta information contains not only information about the object itself, but also information about the entire software application, the application environment or the business process (or business logic) to be implemented, then the configuration of the software application is simplified until a Configuration can be done automatically. Reconfigurations (e.g. after a system crash or failure of parts of the system) can also be carried out automatically without human intervention. This increases the agility of a company and the availability of the production plant.
  • each individual object contains the entire meta information about the application or the business process.
  • every single object eg in the smallest day, in every variable or in every operator, ie also in the very finely granular objects
  • each individual object can be used for reorganization, but also for self-organization of the application, the system or the business process. This is very advantageous for system errors, for example, when large parts of the system fail. The system can completely regenerate itself from the smallest still functional part. A maintenance engineer therefore does not have to deal with the procurement and reading of documentation.
  • the invention for a software application is that the trees can be displayed in different views on a display device.
  • the representation of the trees can be different, e.g. using a static explorer-like notation or in the form of workflow or
  • Flowcharts flowcharts, activity diagrams or e.g. in the form of block diagrams (e.g. circuit diagrams) or system plans (e.g. physical system layout, material flow plans).
  • block diagrams e.g. circuit diagrams
  • system plans e.g. physical system layout, material flow plans.
  • the invention for a software application is that in the event of an error, the software application reconfigures itself. If in a software application or in a software system in every single object (e.g. in the smallest day, in every variable or in every operator, ie also in the very finely granular objects) the entire description of the application or even one Business process is included, this information can be used for an automatic reorganization, ie self-healing of the application, the system or the business process. User intervention is no longer necessary and downtimes are minimized. A maintenance engineer therefore does not have to deal with the procurement and reading of documentation.
  • a software architecture is a description of subsystems, components (subsystems and components are represented by objects of different granularity) and the relationships between them. Subsystems and components are typically specified in different perspectives (views) and represent functional and non-functional properties for a software application based on a software architecture.
  • a software architecture must take into account various aspects that are important for a software system or software architecture: structure, function, data, behavior, dynamics, non-functional properties. These aspects can be modeled using different descriptions or forms of presentation. Suitable descriptive means are e.g. UML (Unified Modeling Language) with a lot of different diagram types and description techniques.
  • UML Unified Modeling Language
  • Software architecture can be used, for example, be differentiated into: data elements (data elements that contain information), processing elements (processing elements that process or transform the data elements) and connecting elements (connecting elements that connect the two other component types with each other or with each other) , All the description means and forms of representation represent meta information which, according to the present invention, is present in the objects of the runtime system at runtime or can be used locally at runtime.
  • the present invention in particular has a positive influence on the non-functional properties of software application, such as changeability, efficiency, reliability, testability, reusability, maintainability, recon igurability and self-reorganization e.g. in case of an error.
  • meta information assigned to an object describes e.g. Which data and functions an object contains, but meta information can also contain implementation and operating information or one
  • Meta information can be described using tags or attributes and assigned to the objects. Meta information can also be given a hierarchical structure.
  • the invention resides in the fact that no explicit code generation is necessary in order to run a software application.
  • the objects are black boxes with appropriate access mechanisms for reading the metadata.
  • the flow logic and the flow sequence of the software application represented by the tree are determined from the structure of the tree and its networking.
  • the structure of the tree and the networking of the tree elements determine the operands with which functions are supplied and whether functions are executed sequentially or in parallel.
  • the structure of the tree and the networking of the tree elements determine which ones Input-sized devices are supplied and how the output values generated by the device are processed.
  • the tree and the networking are edited graphically by a user.
  • the representation of the trees can be different and can be freely selected by the user or application-specific.
  • the hierarchical arrangement in the tree enables the tree elements to be networked or displayed. Networking or branching of the tree elements can also be done by referencing or lateral networking to elements of other subtrees edited by the user.
  • the inputs for creating the tree and for establishing networks can be made using input masks, drag & drop mechanisms or via voice input.
  • Their implementation, ie their code and meta information, is assigned to the individual objects. Because the software application is composed of the objects at runtime (eg automatically based on the metadata about the application process), there can be an explicit compilation phase for generating the code of the objects to be created
  • Compilation runs can take a long time. The fact that explicit compilation runs are not required means that the time for creating the software application, testing and commissioning is minimized.
  • Another major advantage is that programs and data are treated consistently. Data are object trees without functions, programs are object trees with functions. All existing in a runtime system
  • Mechanisms for assembling, networking, versioning, storing, transporting etc. of data and programs only have to be implemented once and not once for data and for programs. This also simplifies handling for software developers, commissioning engineers and
  • networking branching or referencing between the objects can take place in a different granularity. For example, networking by referring to physical addresses (using pointers or pointers), which achieves high efficiency (e.g. within the course of a process). Other networking mechanisms are e.g. electronic messages (e.g. email), telephone or fax. Depending on the requirements of the underlying application, the user can choose an appropriate networking mechanism.
  • Objects in the sense of the invention are those objects that are used in the creation of the software application, but also runtime objects.
  • Runtime objects are objects that execute the logic of the system at runtime of a system (e.g. an application).
  • the architecture according to the invention is also suitable for process control systems and production automation systems.
  • a first advantageous embodiment of the present invention for a software architecture is that at runtime the objects and / or referencing mechanisms and / or networking mechanisms and / or implementations the objects and / or communication mechanisms are interchangeable.
  • objects can be replaced by other objects at runtime, e.g. by objects with extended functionality or the implementation of objects (e.g. the new implementations have been corrected or have better performance) or referencing and networking mechanisms, the turnaround time for changes significantly reduced. This increases the flexibility for the user and the operator of a plant and increases the agility of a company.
  • No common compiler is used to evaluate the metadata, but rather an incremental compiler or an interpreter that is only active locally at the time of the exchange.
  • the incremental compiler or interpreter inserts the newly used object (or the referencing mechanism and / or networking mechanism and / or a new implementation of objects) into the tree at runtime, without having to consider other (unaffected) parts of the tree.
  • Another advantageous embodiment of the present invention for a software architecture is that services can be added to the objects at runtime.
  • the services use the object-local metadata in order to provide (MES or control) infrastructure functions generically.
  • Such services can e.g. be: serialization, replication, encryption or access protection.
  • the objects can thus be equipped with so-called "Quality of Services". A user of an object can rely on the execution of these services and abstract from their implementation.
  • Another advantageous embodiment of the present invention for a software architecture is that implementations of the referencing mechanisms or the Networking mechanisms or the communication mechanisms or the services for data and for programs are applicable.
  • the mechanisms and the services therefore do not have to be implemented separately for data and for programs.
  • meta information can be added to all objects (regardless of whether it is data or programs) in the same way and the meta information can be accessed in the same way for all objects.
  • the invention for a software architecture is that the objects are statically and / or dynamically networked.
  • Networks or branches or references
  • Networks can be set up using different mechanisms and implementations: e.g. Pointer to objects,
  • OPC OLE for Process Control
  • OPC protocols are often used in particular in the industrial environment.
  • Other techniques or implementations that can be used for networking or for linking are e.g. MSMQ (Microsoft Message Queue), HTTP (Hypertext Transfer Protocol) or SOAP (Simple Object Transfer Protocol).
  • the invention for a software architecture is that the objects physically contain the meta information. This supports the principle of locality when creating the software application, ie all information (including the meta information) that is important for an object is also physically available on the object. This will make it easier to access this information. Because the Objects that contain meta information physically can also be used to organize, reorganize or reconfigure the software application, depending on which meta information (type and scope) is available in the object. This is particularly advantageous for mobile objects, for example for software agents who move from computer to computer on the intranet (or other networked systems such as intranet) in order to collect, for example, high-performance system information, for example, for a momance system.
  • a further advantageous embodiment of the present invention for a software architecture is that the meta information contains static and / or dynamic object models.
  • object models are e.g. Classes and their relationships, state / event models, activity models, deployment models or domain models (e.g. MES process model in specific industries such as automotive manufacturing, fertilizer production). This is particularly advantageous for genetic software development or for software generators.
  • the meta information describes an application or a business process. If the meta information contains not only information about the object itself, but also information about the entire software application, the application environment or the business process (or business logic) to be implemented, then the configuration of the software application is simplified until a Configuration can be done automatically. Reconfigurations (e.g. after a system crash or failure of parts of the system) can also be carried out automatically without human intervention. This makes agility one
  • each individual object contains the entire meta information about the application or the business process. This means that in a software application or in a software system in every single object (e.g. in the smallest day, in every variable or in every operator, ie also in the very finely granular objects) the entire description of the application or even one
  • the trees can be displayed in different views on a display device.
  • the representation of the trees can be different, e.g. using a static explorer-like notation or in the form of workflow or flow diagrams (flowcharts, activity diagrams) or e.g. in the form of block diagrams (e.g. circuit diagrams) or system plans (e.g. physical system layout, material flow plans).
  • Another advantageous embodiment of the present invention for a software architecture is that in the In the event of an error, the software application based on the software architecture reconfigures itself. If the entire description of the application or a business process is contained in a software application or in a software system in every single object (e.g. in the smallest day, in every variable or in every operator, ie even in the very finely granular objects), this can Information for an automatic reorganization, ie self-healing of the application, the system or the business process can be used. User intervention is no longer necessary and downtimes are minimized. A maintenance engineer therefore does not have to deal with restarting.
  • the above object is for a
  • meta information assigned to an object describes e.g. Which data and functions an object contains, but meta information can also contain descriptions for implementation and operation or include user documentation.
  • meta information can be described using tags or attributes and assigned to the objects. Meta information can also be hierarchical
  • An advantage of the invention is that no explicit code generation is required to run a software application.
  • the objects are black boxes with appropriate access mechanisms for reading the metadata. From the structure of the tree and its
  • Networking determines the flow logic and the sequence of the software application represented by the tree.
  • the structure of the tree which can be changed manually or automatically at runtime, and the networking of the tree elements determine the operands with which functions are supplied and whether functions are executed sequentially or in parallel.
  • the The structure of the tree and the networking of the tree elements determine, for example, which input-sized devices are supplied with and how the output values generated by the device are processed further.
  • the tree and the networking are edited graphically by a user.
  • the representation of the trees can be different and can be freely selected by the user or application-specific.
  • the hierarchical arrangement in the tree enables the tree elements to be networked or displayed. Networking or branching of the tree elements can also be done by referencing or lateral networking to elements of other subtrees edited by the user.
  • the inputs for creating the tree and for establishing networks can be made using input masks, drag & drop mechanisms or via voice input.
  • the implementation of the individual objects is associated with their code and meta information. Because the software application is made up of ready-made objects at runtime (e.g. automatically based on the metadata about the application process), there is no need for an explicit compilation phase to generate the code of the software application to be created. Compilation runs can take a long time. The fact that explicit compilation runs are not required minimizes the time for creating the software application, testing and commissioning.
  • networking branching or referencing between the objects can take place in a different granularity. For example, networking by referring to physical addresses (using pointers or pointers), which achieves high efficiency (e.g. within the course of a process).
  • Networking mechanisms are e.g. electronic messages (e.g. email), telephone or fax. Depending on the requirements of the underlying application, the user can choose an appropriate networking mechanism.
  • the display device that is used to display and create the trees can be divided into different screen areas (window technology).
  • Objects in the sense of the invention are those objects that are used in the creation of the software application, but also runtime objects.
  • Runtime objects are objects that execute the logic of the system at runtime of a system (e.g. an application).
  • the method according to the invention is furthermore suitable for the creation of software applications for process control systems and production automation systems.
  • a first advantageous embodiment of the present invention for a method is that the objects and / or referencing mechanisms and / or networking mechanisms and / or implementations of the objects at runtime are interchangeable. Due to the fact that at runtime objects by other objects, for example by objects with extended functionality or the implementations of objects (for example the new implementations have been corrected or have better performance) or referencing and
  • Networking mechanisms can be exchanged, the turnaround time is significantly reduced in the event of changes. This increases the flexibility for the user and the operator of a plant and increases the agility of a company.
  • No common compiler is used to evaluate the metadata, but rather an incremental compiler or an interpreter that is only active locally at the time of the exchange. For the newly used object, if code is generated incrementally and the incremental compiler or interpreter inserts the newly used object (or the referencing mechanism and / or networking mechanism and / or a new implementation of objects) into the tree at runtime, without having to consider other (unaffected) parts of the tree.
  • Another advantageous embodiment of the present invention for a method is that services are added to the objects at runtime.
  • the services use the object-local metadata to generically provide (MES or control) infrastructure functions.
  • Such services can e.g. be: serialization, replication, encryption or access protection.
  • the objects can thus be equipped with so-called "Quality of Services". A user of an object can rely on the execution of these services and abstract from their implementation.
  • Implementations of the referencing mechanisms or the networking mechanisms or the services for data and for Programs are used.
  • the mechanisms and the services therefore do not have to be implemented separately for data and for programs.
  • meta information can be added to all objects (regardless of whether it is data or programs) in the same way and the meta information can be accessed in the same way for all objects.
  • Networks can be created statically when the tree is created manually, but can also be created automatically on the basis of current information or meta information (e.g. if required). This increases the flexibility for a user.
  • Networks can be set up using different mechanisms and implementations: e.g. Pointer to objects, e-mail to objects or networking via OPC protocols (OPC stands for OLE for Process Control).
  • OPC protocols are often used in particular in the industrial environment.
  • Other techniques or implementations that can be used for networking or for linking are e.g. MSMQ (Microsoft Message Queue), HTTP (Hypertext Transfer Protocol) or SOAP (Simple Object Transfer Protocol).
  • MSMQ Microsoft Message Queue
  • HTTP Hypertext Transfer Protocol
  • SOAP Simple Object Transfer Protocol
  • the objects physically contain the meta information.
  • an object can also be used alone for the organization, reorganization or reconfiguration of the software application are used, depending on which meta information (type and scope) is available in the object.
  • This is particularly advantageous for mobile objects for example for software agents who move from computer to computer on the Internet (or other networked systems such as intranets), for example to collect high-performance system information, for example, for a Mamtenance system.
  • Meta information includes static and / or dynamic object models.
  • object models are e.g. Classes and their relationships, state / event models, activity models, deployment models or domain models (e.g. MES process model in specific industries such as
  • the meta information describes an application or a business process. If the meta information contains not only information about the object itself, but also information about the entire software application, the application environment or the business process (or business logic) to be implemented, then the configuration of the software application is simplified until a Configuration can be done automatically. Reconfigurations (e.g. after a system crash or failure of parts of the system) can also be carried out automatically without human intervention. This increases a company's agility.
  • each individual object contains the entire meta information about the application or includes the business process.
  • the entire description of the application or of a business process is contained in every single object (e.g. in the smallest day, in every variable or in every operator, ie also in the very finely granular objects) ,
  • each individual object can be used for reorganization, but also for self-organization of the application, the system or the business process. This is very advantageous for system errors, for example, when large parts of the system fail. The system can completely regenerate itself from the smallest still functional part. A maintenance engineer therefore does not have to deal with recommissioning.
  • Another advantageous embodiment of the present invention for a method is that the trees are displayed in different views on a display device.
  • the representation of the trees can be different, e.g. using a static explorer-like notation or in the form of workflow or flow diagrams (flowcharts, activity diagrams) or e.g. in the form of block diagrams (e.g. circuit diagrams) or system plans (e.g. physical system layout, material flow plans).
  • a further advantageous embodiment of the present invention for a method is that the software application reconfigures itself in the event of an error. If in a software application or in a software system in every single object (for example in the smallest day, in every variable or in every operator, ie also in the very finely granular objects) the entire description of the application or a business process is included, this information can be used for an automatic reorganization, ie self-healing of the application, the system or the business process. User intervention is no longer necessary and downtimes are minimized. A maintenance engineer therefore does not have to deal with the procurement and reading of documentation.
  • the invention lies in a software development environment which is integrated in the runtime system, with selectable functionalities being accessed via views.
  • the traditional software development environment is thus reduced to representations and editors with which the runtime system can be viewed and changed directly.
  • the advantages of this design principle and this architecture are, in addition to the easier modification of the runtime system, the system and data consistency.
  • the views that e.g. by
  • Editors are implemented, application functions of the runtime system are accessed (operating view) or changes or extensions are made (engineering or maintenance view).
  • Another advantageous embodiment of the present invention is that the software application according to the invention or the method according to the invention and the software development environment are implemented by a computer program. This means that any modifications or adjustments can be made easily.
  • Data carriers are, for example, common computer program products such as floppy disks or CDs.
  • Data processing device is installed. This increases performance.
  • FIG. 2 shows a schematic representation with a conventional software development environment, a runtime system and a technical process to be controlled
  • FIG. 4 shows the tree structure of a software application
  • FIG. 5 shows a representation of a tree
  • FIG. 7 shows a schematic representation with a runtime system and a technical process to be controlled, whereby Functions of the software development environment are integrated in the runtime system and
  • FIG. 8 shows aspects that determine a software architecture in a diagram.
  • the illustration according to FIG. 1 shows a basic overview illustration of the three control levels, as can usually be found in a manufacturing or manufacturing company.
  • the pyramid shape indicates that the information is compressed at the top.
  • the top level is the ERP level (Enterprise Resource Planning).
  • ERP level Enterprise Resource Planning
  • the business and sales tasks are usually carried out in a company (e.g. finance, sales, human resources, reporting). are carried out at this level
  • SAP R / 3 system is an ERP system that is used very frequently at the company management level.
  • the lowest level of the pyramid is the automation level (controls).
  • controls programmable logic controllers
  • PLC programmable logic controllers
  • PLS visualization and process control systems
  • the drives, actuators and sensors of the production and / or manufacturing facilities are directly connected to the systems on this level.
  • the link between the ERP level and the automation level is formed by the MES level.
  • the applications at the MES level thus ensure vertical integration between the ERP level and the automation level.
  • the MES applications have to supplement the rough planning of the ERP systems with production plant-specific detailed planning forward the systems at the automation level; on the other hand, it is the task of the MES applications to record production-related data at the automation level, process it and forward it to the ERP level (company management level) and optimize production processes.
  • Typical MES applications include Quality Management (QM), Ma tenance Management (MM), Performance Analysis (PA), Process Management, Labor Management, Asset Management.
  • QM Quality Management
  • MM Ma tenance Management
  • PA Performance Analysis
  • Process Management Labor Management
  • Asset Management Asset Management.
  • three dots each indicate that further elements (applications, systems, etc.) can be located on one level.
  • MES systems or ERP systems usually contain a so-called runtime system for the temporal sequence control of the components involved (subcomponents, modules, tasks, processes of the operating system, etc.), as well as a so-called engineering system for creating and editing programs that are used for Execution are provided in the runtime system.
  • FIG. 2 shows a schematic representation m t of a conventional software development environment SU, a runtime system RTS and a technical process TP1 to be controlled.
  • Software applications are created methodically and engineering-wise these days. Tools are usually used for this (so-called CASE tools, CASE stands for Computer Aided Software Engineering). These CASE tools support adherence to methods and standards to ensure the productivity of the
  • a software development environment SU supports a software developer in all phases of software development, that is, from the early stages of analysis to the late stages of testing.
  • a developer can use suitable utilities for all phases of software development, such as an editor, compiler, debugger, but also tools for analysis and design.
  • the workstation of a software developer usually consists of a computing unit with processor and memory as well as output units such as a screen, display and input aids such as keyboard and mouse as well as the
  • Software development environments SU in particular the paradigms of object orientation such as the creation of objects, the creation of classes, the creation of superclasses and the representation of inheritance relationships.
  • the objects are linked to meta information using suitable editors, mask input or drag & drop mechanisms, the objects are structured as hierarchical trees and also networked with one another.
  • the software applications created with the help of the software development environment SU must ultimately be executed on a target system or on a target computer in order to e.g. to control a technical process TP1.
  • the target system usually consists of one or more computing units with processors and memory devices as well as an RTS runtime system.
  • Software development environment SU programs are via the information path I to the runtime system RTS loaded.
  • the underlying technical process for example for a
  • RTS runtime system From the RTS runtime system to the technical process TP1, the EA connection EAl e.g. Actuators influenced, from the technical process TP1 back to the runtime system RTS are e.g. via the EA connection EAl Sensor data supplied, which are then further processed in the software application.
  • EA connection EAl e.g. Actuators influenced, from the technical process TP1 back to the runtime system RTS are e.g. via the EA connection EAl Sensor data supplied, which are then further processed in the software application.
  • An RTS runtime system can also be distributed over several computer units.
  • An object is generally an object or an element of a domain or a world of discourse.
  • An object an individual copy of things or things (e.g. robot, car, machine), people (e.g. customer, employee, patent attorney) or terms of the real world (e.g. order order) or the imagination (e.g. legal and natural persons or organizations)
  • An object has a certain defined state and reacts to its surroundings with a defined behavior.
  • each object has an object identity, which distinguishes it from all other objects and which allows access to a specific object.
  • An object can know one or more other objects.
  • the state of an object is determined by its data or attribute values and the respective connections to other objects.
  • the behavior of an object is defined by its set of methods or operations. In object orientation, the type of an object is described by a class.
  • FIG. 3 shows the information or elements that an object usually contains.
  • Data is as simple as a numerical value, but also complex structures such as recipes, orders or archives.
  • Methods represent executable activities in the sense of an algorithm.
  • the set of methods determines the behavior of an object instantiated by this class.
  • the methods of an object can be used or called by other objects comparable to a client-server architecture.
  • Objects can also contain so-called sub-objects that they need to implement their methods.
  • a structural structure of an object is determined by the subobjects.
  • a so-called container is shown hatched on the right side.
  • This container realizes the mechanisms according to the invention for keeping meta information and the mechanisms for accessing this meta information.
  • the containers represent a capsule layer around the object, and all access to an object can only take place via interface 01.
  • the methods and data and the meta information of the object are accessed via interface 01.
  • containers provide infrastructure functions such as data networking, data storage, and data visualization in a uniform manner for all types of objects (eg business objects).
  • objects eg business objects.
  • a double helix comparable to a DNA structure of a human cell is shown schematically in the container. This is intended to clarify that an object has parts or all of the meta information, ie also the structure information and the
  • Logic that e.g. is in a business process.
  • the entire system or the entire application can be organized or reorganized from one object. System downtimes can be minimized and maintenance work can be carried out very efficiently.
  • the infrastructure functions that a container provides include e.g. Trace functions, i.e. who and how long used an object. As already mentioned, the container contains meta information,
  • the representation according to FIG. 4 shows the tree structure of a software application.
  • the objects are shown as double circles.
  • the inner circle schematically represents the structure of an object, as is known from FIG. 3.
  • the left part of an object represents the data methods and subobjects, the right hatched part represents the so-called container, which contains the meta information and provides the infrastructure information for an object.
  • the container represents a capsule layer for the object. Access to the object is only possible via the object interface 01, which is made available by the container.
  • Infrastructure functions include data networking, data storage and data visualization. The container provides these functions in a uniform way for all other objects.
  • Networking is one aspect of the infrastructure. Networking or branching can be very fine-grained, e.g. done via memory pointer. But it can also
  • connection lines between the objects drawn in bold indicate that these objects are laterally connected to one another.
  • a lateral connection can e.g. be connected via OPC (OLE for Procress Control).
  • OPC OPC for Procress Control
  • Such a connection or an infrastructure service can also be implemented using message queue mechanisms. Access to infrastructure services or functionalities is provided via the container and is the same for all objects in a tree, regardless of whether it is a B&B device (operating and monitoring) or a programmable logic controller (PLC). That's why it's very easy to implement one
  • Infrastructure service to change, since the specification remains unchanged.
  • the outer circle of an object thus represents a collection of infrastructure services or infrastructure functions that can be used via a container.
  • Infrastructure service can be used by all objects in the same way.
  • 4 shows a software application in which the objects are structured as a hierarchical tree.
  • the system to be implemented or the software application contains a B&B device with a database DB, the B&B device being supplied by a programmable logic controller (PLC).
  • PLC programmable logic controller
  • the PLC accesses actuators and sensors via input / output functions.
  • the results of the operator control and monitoring device are further processed by an "Execution" object.
  • the algorithm for this further processing is carried out in the "Execution" object is represented by the subtree that hangs under the "Execution” object.
  • a value XI is processed with a function F, the function F receiving the value X2 as the input value.
  • FIG. 4 shows that the results of the postprocessing of "postprocessing 1" are subjected to a further processing step by the "further processing" object.
  • a software system or a software application described in this way can, of course, be part of a superordinate world with other software applications described in this way, shown here in FIG. 4 by the object "World”.
  • the objects can also be linked laterally or horizontally with one another, reflected or displayed. This is shown in FIG 4 by the bold lines.
  • Such displays can be modeled using input masks or created using drag & drop mechanisms.
  • the function that is implemented by a software system or by a software application results from the structure, the hierarchy and the networking of the tree objects.
  • the tree elements ie the objects, are processed and executed.
  • the execution of a software application is comparable to the functioning of a person's nervous system, where the individual neurons are connected to each other via dentrites and synapses and exchange their activities, whereby a stimulus triggers an impulse chain through the body and, depending on the networking of the neurons, such an impulse chain is carried out ,
  • the structure and the networking of the objects that affect the neurons in the human body are comparable to the functioning of a person's nervous system, where the individual neurons are connected to each other via dentrites and synapses and exchange their activities, whereby a stimulus triggers an impulse chain through the body and, depending on the networking of the neurons, such an impulse chain is carried out .
  • Bodies are comparable, an incentive in FIG. 4, e.g. if a sensor sends a PLC an event and this event is recorded via the B&B device and then an execution is started, which in turn triggers "Postprocessing 1" and "Postprocessing 2" for further processing, "Postprocessing 1" after the further processing initiated further processing.
  • Software applications created in this way have very advantageous properties. This means that the objects that are required for an application can only be put together at runtime, which makes these applications very changeable and flexible. If changes are made, an object does not have to be compiled first. An object that is newly introduced into the system and replaces another can be integrated very easily if it has the same interface, the same specification as the object to be replaced and only changes in implementation, e.g. through better performance.
  • 5 shows a form of representation for a tree.
  • 5 shows a display device AZ1 as having the two screen areas BB1 and BB2.
  • a Display device AZ1 can be, for example, a monitor or a display.
  • the display device AZ1 is usually an element of an element of a software development environment (SU; FIG 2). With the help of display devices and input aids such as keyboard or mouse
  • Objects are created on the screen, structured hierarchically as a tree, networked with one another or shown, but provided with meta information or other information. It is conceivable that a display device AZ1 contains further screen areas for the representation of trees, but also for realizing inputs (e.g. menu bars).
  • a software application is made up of objects from a tree at runtime. The structure is important for processing the objects, but also the networking of the objects. If a user (e.g. a system integrator or
  • a tree OB1 with the tree elements K1, K2, K3, K4 is shown, specifically in an exploration-like notation.
  • the representation of a tree, as it is shown in the screen area BB2 corresponds to a notation, such as is used for circuit diagrams.
  • the elements Kl ⁇ and K2 ⁇ shown in the screen area BB2 are represented in a tree structure via input (xl, x2) and output variables (rl, r2), which are each connected with lines.
  • a representation in this form of current flow diagrams is particularly interesting for electricians, because electricians think in current flow plans. about
  • FIG. 6 shows a further possibility of how a tree can be represented on a display device AZ2.
  • the left section of FIG. 6 shows a screen area BB1 'with an object tree 0B2 in an explorer-like structure.
  • the right portion of FIG 6 shows a screen area BB2 ⁇ , where a notation is used for the representation of a tree, which is very advantageous, in particular • for rendering Geticiansab retained.
  • the representation according to FIG. 7 shows a schematic representation with an extended runtime system RTS / SU and a technical process TP2 to be controlled, functions of the software development environment being integrated in the extended runtime system RTS / SU.
  • the functions required are accessed via views.
  • 7 shows views for development (SU view) for operation (operator view) and for maintenance (maintenance view). Three points indicate that additional views may be available.
  • the extended runtime system RTS / SU contains the infrastructure for developing and changing the runtime system.
  • the connection to the technical process TP2 to be controlled is made via input / output connections EA2. It is an essential effect of the invention that the functionality of a conventional
  • Software development environment (SU; FIG 2) is largely covered by the runtime system RTS / SU. Most of the metadata is data that is generated during development. This means that the runtime system and software development environment can, so to speak, merge with one another and no longer have to be designed as separate components.
  • a system that can be changed contains many aspects at runtime that are only available today in development environments (modeling, versioning, compilation, etc.). The traditional software development environment is reduced to representations and editors with which the runtime system can be viewed and changed directly.
  • the representation according to FIG. 8 shows in a diagram the aspects that determine a software architecture SA.
  • Creating software architectures SA requires abstract and conceptual thinking.
  • the architecture proposed according to the invention ensures that no structural break occurs between the analysis phase and the design phase.
  • the objects required for a software architecture are identified, linked with meta information and structured as hierarchical trees. Farther the objects can be laterally and horizontally networked with each other and communicate with each other or with the environment via communication mechanisms.
  • the function of a software application based on a software architecture is determined by the arrangement of the objects in relation to one another.
  • the objects are then put together to form a software application, the software application inherently containing principles that are predetermined by the software architecture. This ensures that there is no design break.
  • a software architecture must take into account different aspects, points of view or so-called views. This includes the function, which is ultimately determined by a
  • the functionality is usually found and in particular in the methods or operations of the objects.
  • the behavior and the dynamics are determined in particular by the interaction of the objects or by the interaction of the operations present in the objects.
  • the data aspect is usually determined via the attributes.
  • the attributes determine the states of an object, the states also being determined by the respective connections to other objects.
  • the structural aspect includes the hierarchical structure of a tree with its objects with respect to an "consists of" relation. In a software architecture, the structural aspect is also brought in by the "is a" relation. Within a software architecture, the
  • Communication aspect very important, because the communication mechanisms used ensure that the objects used for an application can even exchange data with each other, i.e. to be able to communicate. Communication mechanisms are e.g. MQ (Message
  • Non-functional properties are e.g. Modifiability, efficiency, admissibility, testability or reusability.
  • the targeted and explicit use of meta information in a software architecture demands the fulfillment of non-functional properties enormously.
  • the individual objects contain meta information not only about themselves, but also about the applications in which they are used or in the business processes in which they are used, even organizations of a software application can very easily be carried out, i.e. an automatic recovery can take place without human intervention.
  • the aspects mentioned, which are important for a software architecture are usually modeled or edited by a user using CASE tools (computer-aided software engineering) with corresponding program editors. These CASE tools are part of a software development environment (SU; FIG 2).
  • CASE tools computer-aided software engineering
  • Meta information can be linked very cleverly and easily to objects and systems by using markup languages.
  • XML Extended Markup Language
  • XML Extended Markup Language
  • Meta information can be in XML as elements (by a Start tag and an end tag included) or as attributes (integrated directly into a start tag).
  • the invention relates to software applications, software architectures and methods for creating
  • the software application or software development environment according to the invention described above can be implemented as a computer program in languages known therefor.
  • a computer program implemented in this way can also be stored and transported in a known manner via electronic data paths.

Abstract

Objekte (mit Daten, Attributen, Verhalten, Funktionen) für Softwareapplikationen, insbesondere MES-Applikationen, werden mit Metainformationen verknüpft, als hierarchische Bäume (OB1, OB2) strukturiert (wobei unterschiedliche Darstellungsformen wählbar sind) und miteinander verzeigert bzw. vernetzt (lateral und/oder horizontal). Zur Laufzeit werden die Objekte (K1 - K4, K1' - K4') zu Softwareapplikationen zusammengesetzt, wobei sich die Gesamtfunktion der Softwareapplikationen aus der Struktur der hierarchischen Bäume (OB1, OB2) ableitet. Es können Softwareapplikationen für MES-Systeme, für Automatisierungssysteme, für industrielle Steuerungen (auch Bewegungsteuerungen) und für Büroanwendungen (Officebereich) erstellt werden.

Description

Beschreibung
Softwareapplikation, Softwarearchitektur und Verfahren zur Erstellung von Softwareapplikationen, insbesondere für MES- Systeme
Die Erfindung betrifft Softwareapplikationen, insbesondere MES-Applikation, mit Objekten, die Daten und/oder Attribute und/oder Verhalten beinhalten und/oder referenzieren, wobei die Objekte auf mindestens einer Rechnereinheit ablaufen und/oder gespeichert sind.
Des Weiteren betrifft die Erfindung eine Softwarearchitektur, insbesondere für MES-Applikationen, und ein Verfahren zur Erstellung von Softwareapplikationen, insbesondere für MES- Systeme .
Ferner betrifft die Erfindung eine
Softwareentwicklungsumgebung, ein Computerprogramm, einen Datenträger und eine Datenverarbeitungseinrichtung.
Aus "Software für die Automatisierung - Transparenz über die Ablaufe schaffen", Artikel von Dirk Kozian in Elektronik für die Automatisierung 11, 17.11.1999 ist bekannt, für die Auto- matisierung von Produktions- bzw. Fertigungsabläufen so genannte Manufacturing Execution Systems (MES) einzusetzen. Diese Systeme integrieren die Automatisierungsebene (Controls) mit den ERP-Systemen (ERP: Enterprise Resource Planning) der Unternehmensleitebene. Manufacturing Execution Systems sind Systeme, die z.B. Informationen zur Optimierung von Produktionsabläufen bereitstellen bzw. die Koordination oder Optimierung der Produktionsabläufe durchfuhren. Zum einen müssen die Manufacturing Execution Systems die groben Planungsdaten der ERP-Systeme um anlagenspezifische und aktuelle Feinplanungsdaten erganzen und diese entsprechend an die unterlagerte Automatisierungsebene weiterleiten, zum anderen haben sie die Aufgabe, aus der Automatisierungsebene produktionsrelevante Informationen zu übernehmen, diese aufzubereiten und an die Unternehmensleitebene weiterzumelden. MES-Systeme erfüllen somit u.a. die Aufgabe einer vertikalen Integration zwischen der Unternehmensleitebene und der Automatisierungsebene. Typische Einzelaufgaben von MES-Systemen sind Enterprise Asset Management, Maintenance Management, Information Management, Schedu- ling, Dispatching und Trace & Tracking . Diese Aufgaben werden jeweils von MES-Komponenten bzw. MES-Applikationen ausge- fuhrt.
In den klassischen Programmiersprachen (z.B. Pascal oder Fortran) , die in den 80er Jahren für die Softwareerstellung verwendet wurden, waren Daten und Funktionen getrennt. Erst im Zuge des Paradigmas der Objektorientierung wurden Daten und Funktionen zu Objekten zusammengeführt. Innerhalb der 90er Jahre wurden vereinzelt und ansatzweise Metadaten den Objekten zugeordnet. Metadaten sind Informationen über andere Informationen, z.B. Informationen über vorhandene Objekte selbst. Diese Metadaten sind zwar im Gesamtsystem bzw. im
Gesamtkontext vorhanden, sie sind aber weder physikalisch in einem Objekt hinterlegt, noch enthalten sie Wissen über die zu realisierende Applikation oder über den zu realisierenden Geschaftsprozess .
Von D.E. Perry und A.A. Wolf wurde in "Foundations for the study of Software Architecture" , ACM SIGSOFT, Software Engineering Notes, Vol. 17, No . 4. Pp. 40 - 52, October 1992, der Begriff "architectural style" eingeführt. Darin wird u.a. auf die Konsequenzen und Einflüsse einer Architektur auf eine auf die Architektur basierenden Applikation hingewiesen. Es ist aber nicht beschrieben, wie durch den gezielten Einsatz von Metainformationen in einer Softwarearchitektur Vorteile hinsichtlich der Erstellung, der Konfigurierung, der Reorganisation oder der Anderbarkeit von Softwareapplikationen erreicht werden. Aufgabe der Erfindung ist es Softwareapplikationen, eine Softwarearchitektur und ein Verfahren zur Erstellung von Softwareapplikationen zur Verfugung zu stellen, das die Anderbarkeit und Erweiterbarkeit von Systemen verbessert.
Gemäß der Erfindung wird die oben genannte Aufgabe für eine Softwareapplikation durch die Merkmale des Anspruchs 1 gelost. Die einem Objekt zugeordneten Metainformationen beschreiben z.B. welche Daten und Funktionen ein Objekt enthält, Metainformationen können aber auch Beschreibungen zur Implementierung- und Bedienung beinhalten oder eine Benutzerdokumentation umfassen. In Auszeichnungssprachen wie HTML oder XML können Metainformationen über sogenannte Tags oder über Attribute beschrieben und den Objekten zugeordnet werden. Metainformationen können auch mit einer hierarchischen Struktur versehen werden. Ein Vorteil der Erfindung liegt darin, dass keine explizite Code-Erzeugung notig ist, um eine Softwareapplikation ablaufen zu lassen. Die Objekte sind Black Boxes mit entsprechenden Zugriffsmechanismen zum Lesen der Metadaten. Aus der Struktur des Baumes und seiner Vernetzung wird die Ablauflogik und die Ablaufreihenfolge der durch den Baum repräsentierten Softwareapplikation festgelegt. Die zur Laufzeit manuell oder automatisch anderbare Struktur des Baumes und die Vernetzung der Baumelemente bestimmt, mit welchen Operanden Funktionen versorgt werden und ob Funktionen sequentiell oder parallel ausgeführt werden. Bei industriellen Anlagen wird durch die Struktur des Baumes und die Vernetzung der Baumelemente z.B. bestimmt, mit welchen Eingabegroßen Gerate versorgt werden und wie die vom Gerat erzeugten Ausgabewerte weiterverarbeitet werden. An einer
Softwareentwicklungsumgebung wird von einem Benutzer der Baum und die Vernetzung grafisch editiert. Die Darstellungsform der Baume kann unterschiedlich sein und vom Benutzer frei bzw. anwendungsspezifisch gewählt werden. Die Vernetzung oder Verzeigerung der Baumelemente kann durch die hierarchische Anordnung im Baum erfolgen. Vernetzungen oder Verzeigerungen der Baumelemente können aber auch durch vom Anwender editierte Referenzierungen oder laterale Vernetzungen zu Elementen anderer Teilbaume erfolgen. Die Eingaben zur Erstellung des Baumes und zur Etablierung von Vernetzungen kann über Eingabemasken, Drag&Drop-Mechanismen oder über Spracheingabe erfolgen.
Den einzelnen Objekten ist ihre Implementierung, d.h. ihr Code und Metainformation zugeordnet. Dadurch, dass die Softwareapplikation zur Laufzeit aus vorgefertigten Objekten zusammengesetzt wird (z.B. automatisch anhand der Metadaten über den Anwendungsprozess) kann auf eine explizite Kompilierphase zur Erzeugung des Codes der zu erstellenden Softwareapplikation verzichtet werden. Kompilierlaufe können sehr lange dauern. Dadurch, dass explizite Kompilierlaufe nicht benotigt werden, wird die Zeit zur Erstellung der Softwareapplikation, des Testens und der Inbetriebnahme minimiert .
Ein weiterer wesentlicher Vorteil liegt darin, daß Programme und Daten einheitlich behandelt werden. Daten sind Objektbaume ohne Funktionen, Programme sind Objektbaume mit Funktionen. Alle in einem Runtimesystem vorhandenen Mechanismen zum Zusammensetzen, Vernetzen, Versionieren, Speichern, Transportieren etc. von Daten und Programmen müssen nur einmal implementiert werden und nicht je einmal für Daten und für Programme. Dies erleichtert auch die Handhabung für Softwareentwickler, Inbetriebsetzer und Administratoren da sie sich nur einmal in diese Mechanismen einarbeiten müssen.
Ein weiterer Vorteil liegt darin, dass Änderungen sehr leicht durchfuhrbar sind. Teilbaume können jederzeit hinzugefugt, geändert oder entfernt werden, ohne dass die gesamte Baumstruktur geändert werden muss. Die Agilität eines Unternehmens wird dadurch erhöht, da auf veränderte Marktbedurfnisse schneller reagiert werden kann. Dies ist insbesondere dann wichtig, wenn die Softwareapplikationen für die Steuerung von Automatisierungssystemen, Produktionsanlagen oder MES-Systemen eingesetzt wird. Die erfindungsgemaßen Softwareapplikationen können aber auch im Burobereich (Officebereich) vorteilhaft eingesetzt werden.
Die Vernetzung, Verzeigerung oder Referenzierung zwischen den Objekten kann in einer unterschiedlichen Granularitat stattfinden. So kann eine Vernetzung z.B. durch den Verweis auf physikalische Adressen (durch Zeiger bzw. Pointer) erfolgen, wodurch eine hohe Effizienz (z.B. innerhalb des Ablaufs eines Prozesses) erreicht wird. Andere Vernetzungsmechanismen sind z.B. elektronische Nachrichten (z.B. E-Mail), Telefon oder Fax. Je nach Anforderung der zugrundeliegenden Applikation kann vom Anwender ein entsprechender Vernetzungsmechanismus gewählt werden.
Objekte im Sinne der Erfindung sind solche Objekte, die bei der Erstellung der Softwareapplikation verwendet werden, aber auch Laufzeit-Objekte. Laufzeit-Objekte sind Objekte, die zur Laufzeit eines Systems (z.B. einer Applikation) die Logik des Systems ausfuhren.
Die erfindungsgemaßen Softwareapplikationen eignen sich weiterhin für Losungen für Prozessleitsysteme und Fertigungsautomatisierungssysteme .
Eine erste vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass zur Laufzeit die Objekte und/oder Referenzierungsmechanismen und/oder Vernetzungsmechanismen und/oder Implementierungen der Objekte austauschbar sind. Dadurch, dass zur Laufzeit Objekte durch andere Objekte, z.B. durch Objekte mit erweiterter Funktionalitat oder die Implementierungen von Objekten (z.B. die neuen Implementierungen sind fehlerbereinigt oder haben eine bessere Performance) oder Referenzierungs- und Vernetzungsmechanismen ausgetauscht werden können, wird die Turnaround-Zeit bei Änderungen deutlich reduziert. Dadurch wird die Flexibilität für den Anwender und den Betreiber einer Anlage erhöht und die Agilität eines Unternehmens erhöht. Für die Auswertung der Metadaten wird kein üblicher Compiler verwendet, sondern ein so genannter mkrementeller Compiler oder ein Interpreter, der nur zum Zeitpunkt des Austauschens objektlokal aktiv ist. Für das neu eingesetzte Objekt, wird, wenn notig inkrementell Code erzeugt und der inkrementelle Compiler oder Interpreter fugt das neu eingesetzte Objekt (bzw. den
Referenzierungsmechanismus und/oder Vernetzungsmechanismus und/oder eine neue Implementierung von Objekten) zur Laufzeit in den Baum wieder ein, ohne andere (nicht betroffene) Teile des Baumes berücksichtigen zu müssen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass den Objekten zur Laufzeit Dienste hinzufugbar sind. Die Dienste verwenden die objektlokalen Metadaten um (MES-, bzw. Control- ) Infrastrukturfunktionen generisch zur Verfugung zu stellen. Solche Dienste können z.B. sein: Serialisierung, Replikation, Verschlüsselung oder Zugriffsschutz. Die Objekte können dadurch mit sogenannten "Quality of Services" ausgestattet werden. Ein Benutzer eines Objektes kann sich auf die Ausfuhrung dieser Dienste verlassen und von ihrer Realisierung abstrahieren.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass Implementierungen der Referenzierungsmechanismen oder der Vernetzungsmechanismen oder der Dienste für Daten und für Programme anwendbar sind. Die Mechanismen und die Dienste müssen somit nicht jeweils für Daten und für Programme separat implementiert werden. Weiterhin können Metainformationen allen Objekten (egal, ob es sich um Daten oder Programme handelt) in gleicher Weise zugefugt werden und es kann in gleicher Weise bei allen Objekten auf die Metainformationen zugegriffen werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass die
Objekte statisch und/oder dynamisch vernetzt sind.
Vernetzungen (bzw. Verzeigerungen oder Referenzierungen) können statisch bei einer manuellen Erstellung des Baumes erfolgen, aber auch automatisch aufgrund von aktuellen Informationen oder Metainformationen erstellt werden (z.B. bei Bedarf) .
Dadurch wird die Flexibilität für einen Anwender erhöht.
Vernetzungen können über unterschiedliche Mechanismen und
Implementierungen eingerichtet werden: z.B. Zeiger auf Objekte,
E-Mail an Objekte oder Vernetzung über OPC-Protokolle (OPC steht für OLE for Process Control) . Insbesondere im industriellen Umfeld werden OPC-Protokolle häufig verwendet.
Weitere Techniken bzw. Implementierungen die für Vernetzungen oder für Verknüpfungen einsetzbar sind, sind z.B. MSMQ
(Microsoft Message Queue) , HTTP (Hypertext Transfer Protocol) oder SOAP (Simple Object Transfer Protocol) .
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass die Objekte die Metainformation physikalisch enthalten. Dadurch wird bei der Erstellung der Softwareapplikation das Prinzip der Lokalitat unterstutzt, d.h. alle Informationen (auch die Metainformationen) , die für ein Objekt wichtig sind, sind auch physikalisch am Objekt vorhanden. Der Zugriff auf diese Informationen wird dadurch erleichtert. Dadurch, dass die Objekte die Metainformationen physikalisch enthalten, kann auch ein Objekt für sich alleine zur Organisation, Reorganisation oder Rekonfigurierung der Softwareapplikation verwendet werden, in Abhängigkeit davon, welche
Metainformationen (Typus und Umfang) im Objekt vorhanden sind. Dies ist insbesondere für mobile Objekte von Vorteil, z.B. für Softwareagenten die sich im Internet (oder anderen vernetzten Systemen wie z.B. Intranet) von Rechner zu Rechner bewegen um z.B. jeweils rechnerlokal hochperformant Anlageninformation z.B. für ein Maintenancesystem zu sammeln.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass die Metainformation statische und/oder dynamische Objektmodelle beinhaltet. Solche Objektmodelle sind z.B. Klassen und deren Beziehungen, State/Event-Modelle, Activity-Modelle, Deployment -Modelle oder Domain-Modelle (z.B. MES Prozessmodell in spezifischen Branchen wie z.B. Automobilherstellung, Dungemittelproduktion) . Dies ist insbesondere für die generische Softwareentwicklung bzw. für Softwaregeneratoren von Vorteil.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass die Metainformation eine Applikation oder einen Geschaftsprozess beschreibt. Wenn die Metainformation nicht nur Informationen über das Objekt selbst, sondern auch Informationen über die gesamte Softwareapplikation, über die Einsatzumgebung oder über den zu realisierenden Geschaftsprozess (bzw. Business Logik) beinhaltet, dann wird dadurch die Konfigurierung der Softwareapplikation vereinfacht, bis dahin, dass eine Konfigurierung automatisch erfolgen kann. Auch Rekonfigurierungen (z.B. nach Systemabsturzen oder Ausfall von Teilen des Systems) können ohne menschlichen Eingriff automatisch erfolgen. Dadurch wird die Agilität eines Unternehmens und die Verfügbarkeit der Produktionsanlage erhöht .
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass jedes einzelne Objekt die gesamte Metainformation über die Applikation oder den Geschaftsprozess beinhaltet. Das bedeutet, dass in einer Softwareapplikation bzw. in einem Softwaresystem in jedem einzelnen Objekt (z.B. im allerkleinsten Tag, in jeder Variable oder in jedem Operator, d.h. auch in den ganz fein granulären Objekten) die gesamte Beschreibung der Applikation oder auch eines Geschaftsprozesses enthalten ist. Durch diese Informationen kann jedes einzelne Objekt zu einer Reorganisation, aber auch Selbstorganisation der Applikation, des Systems oder des Geschaftsprozesses verwendet werden. Dies ist z.B. bei Systemfehlern sehr vorteilhaft wenn große Teile des Systems ausfallen. Das System kann sich aus dem kleinsten noch funktionsfähigen Teil selbst vollständig regenerieren. Ein Wartungsingenieur muss sich somit nicht aufwendig mit dem Beschaffen und Lesen von Dokumentationen beschäftigen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden
Erfindung für eine Softwareapplikation liegt darin, dass auf einer Anzeigevorrichtung die Baume in unterschiedlichen Ansichten darstellbar sind. Die Darstellung der Baume kann unterschiedlich sein, z.B. durch eine statische Explorer ahnliche Notation oder in Form von Workflow- bzw.
Ablaufdiagrammen (Flowcharts, Activitydiagramme) oder z.B. in Form von Blockschaltbildern (z.B. Stromlaufplane) oder Anlagenplanen (z.B. physikalisches Anlagenlayout, Materialflussplane) . Dadurch wird die Flexibilität für einen Anwender sehr erhöht, denn er kann eine seinem Wissensstand adäquate Notation bzw. Visualisierung auswählen, um die im Laufzeitsystem vorhandene Metainformation einzusehen. Es kann auch zwischen den Darstellungsformen gewechselt werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden
Erfindung für eine Softwareapplikation liegt darin, dass im Fehlerfall die Softwareapplikation sich selbst rekonfiguriert. Wenn in einer Softwareapplikation bzw. in einem Softwaresystem in jedem einzelnen Objekt (z.B. im allerkleinsten Tag, in jeder Variable oder in jedem Operator, d.h. auch in den ganz fein granulären Objekten) die gesamte Beschreibung der Applikation oder auch eines Geschaftsprozesses enthalten ist, können diese Informationen zu einer automatischen Reorganisation, d.h. Selbstheilung der Applikation, des Systems oder des Geschaftsprozesses verwendet werden. Benutzereingriffe sind nicht mehr erforderlich und die Stillstandzeiten werden minimiert. Ein Wartungsingenieur muss sich somit nicht aufwendig mit dem Beschaffen und Lesen von Dokumentationen beschäftigen.
Gemäß der Erfindung wird die oben genannte Aufgabe für eine Softwarearchitektur durch die Merkmale des Anspruchs 12 gelost. Eine Softwarearchitektur ist eine Beschreibung von Subsystemen, Komponenten (Subsysteme und Komponenten werden durch Objekte unterschiedlicher Granularitat repräsentiert) und der Beziehungen zwischen ihnen. Subsysteme und Komponenten werden typischerweise in unterschiedlichen Betrachtungsweisen (Views) spezifiziert und stellen funktioneile und nicht-funktionelle Eigenschaften für eine auf einer Softwarearchitektur basierenden Softwareapplikation dar. Eine Softwarearchitektur soll als vorteilhaft erkannte Softwareentwurfsprinzipien (Lokalitatsprinzip, enge Bindung, lose Kopplung etc.) manifestieren. Eine Softwarearchitektur muss unterschiedliche Aspekte, die für ein Softwaresystem bzw. eine Softwarearchitektur von Bedeutung sind berücksichtigen: Struktur, Funktion, Daten, Verhalten, Dynamik, nicht funktionale Eigenschaften. Diese Aspekte können durch teilweise unterschiedliche Beschreibungsmittel oder Darstellungsformen modelliert werden. Geeignetes Beschreibungsmittel ist z.B. UML (Unified Modeling Language) mit einer Menge von unterschiedlichen Diagrammtypen und Beschreibungstechniken. Die Komponenten, die in einer
Softwarearchitektur verwendet werden, können z.B. unterschieden werden in: Datenelemente (Data Elements, die Informationen beinhalten) , Verarbeitungselemente (Processing Elements, die die Datenelemente verarbeiten bzw. transformieren) und Verbindungselemente (Connecting Elements, die die beiden anderen Komponenttypen miteinander bzw. untereinander verbinden) . All die Beschreibungsmittel und Darstellungsformen repräsentieren Metainformationen die gemäß der dargestellten Erfindung zur Laufzeit in den Objekten des Laufzeitsystems vorhanden sind, bzw. und zur Laufzeit objektlokal verwendet werden können.
Durch die explizite und gezielte Verwendung von Metainformationen in der einer Softwareapplikation zugrundeliegenden Softwarearchitektur werden durch die vorliegende Erfindung insbesondere die nicht- funktionalen Eigenschaften (non-functional properties) von Softwareapplikation positiv beeinflusst, wie Anderbarkeit , Effizienz, Zuverlässigkeit, Testbarkeit, Wiederverwendbarkeit, Wartbarkeit, Rekon igurierbarkeit und Selbstreorganisation z.B. im Fehlerfall.
Die einem Objekt zugeordneten Metainformationen beschreiben z.B. welche Daten und Funktionen ein Objekt enthalt, Metainformationen können aber auch Implementierungs- und Bedieninformationen beinhalten oder eine
Benutzerdokumentation umfassen. In Auszeichnungssprachen wie HTML oder XML können Metainformationen über sogenannte Tags oder über Attribute beschrieben und den Objekten zugeordnet werden. Metainformationen können auch mit einer hierarchischen Struktur versehen werden. Ein Vorteil der
Erfindung liegt darin, dass keine explizite Code-Erzeugung notig ist, um eine Softwareapplikation ablaufen zu lassen. Die Objekte sind Black Boxes mit entsprechenden Zugriffsmechanismen zum Lesen der Metadaten. Aus der Struktur des Baumes und seiner Vernetzung wird die Ablauflogik und die Ablaufreihenfolge der durch den Baum repräsentierten Softwareapplikation festgelegt. Die Struktur des Baumes und die Vernetzung der Baumelemente bestimmt, mit welchen Operanden Funktionen versorgt werden und ob Funktionen sequentiell oder parallel ausgeführt werden. Bei industriellen Anlagen wird durch die Struktur des Baumes und die Vernetzung der Baumelemente z.B. bestimmt, mit welchen Eingabegroßen Geräte versorgt werden und wie die vom Gerat erzeugten Ausgabewerte weiterverarbeitet werden. An einer Softwareentwicklungsumgebung wird von einem Benutzer der Baum und die Vernetzung grafisch editiert. Die Darstellungsform der Baume kann unterschiedlich sein und vom Benutzer frei bzw. anwendungsspezifisch gewählt werden. Die Vernetzung oder Verzeigerung der Baumelemente kann durch die hierarchische Anordnung im Baum erfolgen. Vernetzungen oder Verzeigerungen der Baumelemente können aber auch durch vom Anwender editierte Referenzierungen oder laterale Vernetzungen zu Elementen anderer Teilbaume erfolgen. Die Eingaben zur Erstellung des Baumes und zur Etablierung von Vernetzungen kann über Eingabemasken, Drag&Drop-Mechanismen oder über Spracheingabe erfolgen. Den einzelnen Objekten ist ihre Implementierung, d.h. ihr Code sowie Metainformation zugeordnet. Dadurch, dass die Softwareapplikation zur Laufzeit aus den Objekten zusammengesetzt wird (z.B. automatisch anhand der Metadaten über den Anwendungsprozess) , kann auf eine explizite Kompilierphase zur Erzeugung des Codes der zu erstellenden
Softwareapplikation verzichtet werden. Kompilierlaufe können sehr lange dauern. Dadurch, dass explizite Kompilierlaufe nicht benötigt werden, wird die Zeit zur Erstellung der Softwareapplikation, des Testens und der Inbetriebnahme minimiert.
Ein weiterer wesentlicher Vorteil liegt darin, daß Programme und Daten einheitlich behandelt werden. Daten sind Objektbaume ohne Funktionen, Programme sind Objektbaume mit Funktionen. Alle in einem Runtimesystem vorhandenen
Mechanismen zum Zusammensetzen, Vernetzen Versionieren, Speichern, Transportieren etc. von Daten und Programmen müssen nur einmal implementiert werden und nicht je einmal für Daten und für Programme. Dies erleichtert auch die Handhabung für Softwareentwickler, Inbetriebsetzer und
Administratoren da sie sich nur einmal in diese Mechanismen einarbeiten müssen. Ein weiterer Vorteil liegt darin, dass Änderungen sehr leicht durchfuhrbar sind. Teilbaume können hinzugefugt, geändert oder entfernt werden, ohne dass die restliche Baumstruktur geändert werden muss. Die Agilität eines Unternehmens wird dadurch erhöht, da auf veränderte Marktbedurfnisse schneller reagiert werden kann. Dies ist insbesondere dann wichtig, wenn die Softwareapplikationen für die Steuerung von Automatisierungssystemen, Produktionsanlagen oder MES- Systemen eingesetzt wird. Die erfindungsgemaßen
Softwareapplikationen können aber auch im Burobereich (Officebereich) vorteilhaft eingesetzt werden.
Die Vernetzung, Verzeigerung oder Referenzierung zwischen den Objekten kann in einer unterschiedlichen Granularitat stattfinden. So kann eine Vernetzung z.B. durch den Verweis auf physikalische Adressen (durch Zeiger bzw. Pointer) erfolgen, wodurch eine hohe Effizienz (z.B. innerhalb des Ablaufs eines Prozesses) erreicht wird. Andere Vernetzungsmechanismen sind z.B. elektronische Nachrichten (z.B. E-Mail), Telefon oder Fax. Je nach Anforderung der zugrundeliegenden Applikation kann vom Anwender ein entsprechender Vernetzungsmechanismus gewählt werden.
Objekte im Sinne der Erfindung sind diejenigen Objekte, die bei der Erstellung der Softwareapplikation verwendet werden, aber auch Laufzeit -Objekte . Laufzeit -Ob ekte sind Objekte, die zur Laufzeit eines Systems (z.B. einer Applikation) die Logik des Systems ausfuhren.
Die erfindungsgemaße Architektur eignet sich weiterhin für Prozessleitsysteme und Fertigungsautomatisierungssysteme .
Eine erste vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass zur Laufzeit die Objekte und/oder Referenzierungsmechanismen und/oder Vernetzungsmechanismen und/oder Implementierungen der Objekte und/oder Kommunikationsmechanismen austauschbar sind. Dadurch, dass zur Laufzeit Objekte durch andere Objekte, z.B. durch Objekte mit erweiterter Funktionalitat oder die Implementierungen von Objekten (z.B. die neuen Implementierungen sind fehlerbereinigt oder haben eine bessere Performance) oder Referenzierungs- und Vernetzungsmechanismen ausgetauscht werden können, wird die Turnaround-Zeit bei Änderungen deutlich reduziert. Dadurch wird die Flexibilität für den Anwender und den Betreiber einer Anlage erhöht und die Agilität eines Unternehmens erhöht. Für die Auswertung der Metadaten wird kein üblicher Compiler verwendet, sondern ein so genannter inkrementeller Compiler oder ein Interpreter, der nur zum Zeitpunkt des Austauschens objektlokal aktiv ist. Für das neu eingesetzte Objekt, wird, wenn notig inkrementell Code erzeugt und der inkrementelle Compiler oder Interpreter fugt das neu eingesetzte Objekt (bzw. den Referenzierungsmechanismus und/oder Vernetzungsmechanismus und/oder eine neue Implementierung von Objekten) zur Laufzeit in den Baum wieder ein, ohne andere (nicht betroffene) Teile des Baumes berücksichtigen zu müssen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass den Objekten zur Laufzeit Dienste hinzufugbar sind. Die Dienste verwenden die objeklokalen Metadaten um (MES-, bzw. Control-) Infrastrukturfunktionen generisch zur Verfugung zu stellen. Solche Dienste können z.B. sein: Serialisierung, Replikation, Verschlüsselung oder Zugriffsschutz. Die Objekte können dadurch mit sogenannten "Quality of Services" ausgestattet werden. Ein Benutzer eines Objektes kann sich auf die Ausfuhrung dieser Dienste verlassen und von ihrer Realisierung abstrahieren.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass Implementierungen der Referenzierungsmechanismen oder der Vernetzungsmechanismen oder der Kommunikationsmechanismen oder der Dienste für Daten und für Programme anwendbar sind. Die Mechanismen und die Dienste müssen somit nicht jeweils für Daten und für Programme separat implementiert werden. Weiterhin können Metainformationen allen Objekten (egal, ob es sich um Daten oder Programme handelt) in gleicher Weise zugefugt werden und es kann in gleicher Weise bei allen Objekten auf die Metainformationen zugegriffen werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden
Erfindung für eine Softwarearchitektur liegt darin, dass die Objekte statisch und/oder dynamisch vernetzt sind. Vernetzungen (bzw. Verzeigerungen oder Referenzierungen) können statisch bei einer manuellen Erstellung des Baumes erfolgen, aber auch automatisch aufgrund von aktuellen Informationen oder Metainformationen erstellt werden (z.B. bei Bedarf) . Dadurch wird die Flexibilität für einen Anwender erhöht. Vernetzungen können über unterschiedliche Mechanismen und Implementierungen eingerichtet werden: z.B. Zeiger auf Objekte,
E-Mail an Objekte oder Vernetzung über OPC-Protokolle (OPC steht für OLE for Process Control) . Insbesondere im industriellen Umfeld werden OPC-Protokolle häufig verwendet. Weitere Techniken bzw. Implementierungen die für Vernetzungen oder für Verknüpfungen einsetzbar sind, sind z.B. MSMQ (Microsoft Message Queue) , HTTP (Hypertext Transfer Protocol) oder SOAP (Simple Object Transfer Protocol) .
Eine weitere vorteilhafte Ausgestaltung der vorliegenden
Erfindung für eine Softwarearchitektur liegt darin, dass die Objekte die Metainformation physikalisch enthalten. Dadurch wird bei der Erstellung der Softwareapplikation das Prinzip der Lokalitat unterstutzt, d.h. alle Informationen (auch die Metainformationen) , die für ein Objekt wichtig sind, sind auch physikalisch am Objekt vorhanden. Der Zugriff auf diese Informationen wird dadurch erleichtert. Dadurch, dass die Objekte die Metainformationen physikalisch enthalten, kann auch ein Objekt für sich alleine zur Organisation, Reorganisation oder Rekonflgurierung der Softwareapplikation verwendet werden, in Abhängigkeit davon, welche Metainformationen (Typus und Umfang) im Objekt vorhanden sind. Dies ist insbesondere für mobile Objekte von Vorteil, z.B. für Softwareagenten die sich im Intranet (oder anderen vernetzten Systemen wie z.B. Intranet) von Rechner zu Rechner bewegen um z.B. jeweils rechnerlokal hochperformant Anlageninformation z.B. für ein Mamtenancesystem zu sammeln.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass die Metainformation statische und/oder dynamische Objektmodelle beinhaltet. Solche Objektmodelle sind z.B. Klassen und deren Beziehungen, State/Event -Modelle, Activity-Modelle, Deployment -Modelle oder Domain-Modelle (z.B. MES Prozessmodell in spezifischen Branchen wie z.B. Automobilherstellung, Dungemittelproduktion) . Dies ist insbesondere für die genensche Softwareentwicklung bzw. für Softwaregeneratoren von Vorteil.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass die Metainformation eine Applikation oder einen Geschaftsprozess beschreibt . Wenn die Metainformation nicht nur Informationen über das Objekt selbst, sondern auch Informationen über die gesamte Softwareapplikation, über die Einsatzumgebung oder über den zu realisierenden Geschaftsprozess (bzw. Business Logik) beinhaltet, dann wird dadurch die Konfigurierung der Softwareapplikation vereinfacht, bis dahin, dass eine Konfigurierung automatisch erfolgen kann. Auch Rekonflgurierungen (z.B. nach Systemabsturzen oder Ausfall von Teilen des Systems) können ohne menschlichen Eingriff automatisch erfolgen. Dadurch wird die Agilität eines
Unternehmens und die Verfügbarkeit der Produktionsanlage erhöht . Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass jedes einzelne Objekt die gesamte Metainformation über die Applikation oder den Geschaftsprozess beinhaltet. Das bedeutet, dass in einer Softwareapplikation bzw. in einem Softwaresystem in jedem einzelnen Objekt (z.B. im allerkleinsten Tag, in jeder Variable oder in jedem Operator, d.h. auch in den ganz fein granulären Objekten) die gesamte Beschreibung der Applikation oder auch eines
Geschaftsprozesses (bzw. Business Logik) enthalten ist. Durch diese Informationen kann jedes einzelne Objekt zu einer Reorganisation, aber auch Selbstorganisation der Applikation, des Systems oder des Geschaftsprozesses verwendet werden. Dies ist z.B. bei Systemfehlern sehr vorteilhaft wenn große Teile des Systems ausfallen. Das System kann sich aus dem kleinsten noch funktionsfähigen Teil selbst vollständig regenerieren. Ein Wartungsingenieur muss sich somit nicht aufwendig mit Wiederinbetriebssetzen beschäftigen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass auf einer Anzeigevorrichtung die Baume in unterschiedlichen Ansichten darstellbar sind. Die Darstellung der Bäume kann unterschiedlich sein, z.B. durch eine statische Explorer ahnliche Notation oder in Form von Workflow- bzw. Ablaufdiagrammen (Flowcharts, Activitydiagramme) oder z.B. in Form von Blockschaltbildern (z.B. Stromlaufplane) oder Anlagenplanen (z.B. physikalisches Anlagenlayout, Materialflussplane) . Dadurch wird die Flexibilität für einen Anwender sehr erhöht, denn er kann eine seinem Wissensstand adäquate Notation bzw. Visualisierung auswählen, um die im Laufzeitsystem vorhandene Metainformation einzusehen. Es kann auch zwischen den Darstellungsformen gewechselt werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass im Fehlerfall die auf der Softwarearchitektur basierende Softwareapplikation sich selbst rekonfiguriert. Wenn in einer Softwareapplikation bzw. in einem Softwaresystem in jedem einzelnen Objekt (z.B. im allerkleinsten Tag, in jeder Variable oder in jedem Operator, d.h. auch in den ganz fein granulären Objekten) die gesamte Beschreibung der Applikation oder auch eines Geschaftsprozesses enthalten ist, können diese Informationen zu einer automatischen Reorganisation, d.h. Selbstheilung der Applikation, des Systems oder des Geschaftsprozesses verwendet werden. Benutzereingriffe sind nicht mehr erforderlich und die Stillstandzeiten werden minimiert . Ein Wartungsingenieur muss sich somit nicht aufwendig mit Wiederinbetriebsetzen beschäftigen.
Gemäß der Erfindung wird die oben genannte Aufgabe für ein
Verfahren zur Erstellung von Softwareapplikationen durch die Merkmale des Anspruchs 23 gelost. Die einem Objekt zugeordneten Metainformationen beschreiben z.B. welche Daten und Funktionen ein Objekt enthalt, Metainformationen können aber auch Beschreibungen zur Implementierung- und Bedienung beinhalten oder eine Benutzerdokumentation umfassen. In Auszeichnungssprachen wie HTML oder XML können Metainformationen über sogenannte Tags oder über Attribute beschrieben und den Objekten zugeordnet werden. Metainformationen können auch mit einer hierarchischen
Struktur versehen werden. Ein Vorteil der Erfindung liegt darin, dass keine explizite Code-Erzeugung notig ist, um eine Softwareapplikation ablaufen zu lassen. Die Objekte sind Black Boxes mit entsprechenden Zugriffsmechanismen zum Lesen der Metadaten. Aus der Struktur des Baumes und seiner
Vernetzung wird die Ablauflogik und die Ablaufreihenfolge der durch den Baum repräsentierten Softwareapplikation festgelegt. Die zur Laufzeit manuell oder automatisch anderbare Struktur des Baumes und die Vernetzung der Baumelemente bestimmt, mit welchen Operanden Funktionen versorgt werden und ob Funktionen sequentiell oder parallel ausgeführt werden. Bei industriellen Anlagen wird durch die Struktur des Baumes und die Vernetzung der Baumelemente z.B. bestimmt, mit welchen Eingabegroßen Gerate versorgt werden und wie die vom Gerat erzeugten Ausgabewerte weiterverarbeitet werden. An einer Softwareentwicklungsumgebung wird von einem Benutzer der Baum und die Vernetzung grafisch editiert. Die Darstellungsform der Baume kann unterschiedlich sein und vom Benutzer frei bzw. anwendungsspezifisch gewählt werden. Die Vernetzung oder Verzeigerung der Baumelemente kann durch die hierarchische Anordnung im Baum erfolgen. Vernetzungen oder Verzeigerungen der Baumelemente können aber auch durch vom Anwender editierte Referenzierungen oder laterale Vernetzungen zu Elementen anderer Teilbaume erfolgen. Die Eingaben zur Erstellung des Baumes und zur Etablierung von Vernetzungen kann über Eingabemasken, Drag&Drop-Mechanismen oder über Spracheingabe erfolgen.
Den einzelnen Objekten ist ihre Implementierung, d.h. ihr Code und Metainformation zugeordnet. Dadurch, dass die Softwareapplikation zur Laufzeit aus vorgefertigten Objekten zusammengesetzt wird (z.B. automatisch anhand der Metadaten über den Anwendungsprozeß) , kann auf eine explizite Kompilierphase zur Erzeugung des Codes der zu erstellenden Softwareapplikation verzichtet werden. Kompilierlaufe können sehr lange dauern. Dadurch, dass explizite Kompilierlaufe nicht benotigt werden, wird die Zeit zur Erstellung der Softwareapplikation, des Testens und der Inbetriebnahme minimiert .
Ein weiterer Vorteil liegt darin, dass Änderungen sehr leicht durchfuhrbar sind. Teilbaume können jederzeit hinzugefugt, geändert oder entfernt werden, ohne dass die gesamte Baumstruktur geändert werden muss. Die Agilität eines Unternehmens wird dadurch erhöht, da auf veränderte Marktbedurfnisse schneller reagiert werden kann. Dies ist insbesondere dann wichtig, wenn die Softwareapplikationen für die Steuerung von Automatisierungssystemen, Produktionsanlagen oder MES-Systemen eingesetzt wird. Die erfindungsgemaßen Softwareapplikationen können aber auch im Burobereich (Officebereich) vorteilhaft eingesetzt werden.
Die Vernetzung, Verzeigerung oder Referenzierung zwischen den Objekten kann in einer unterschiedlichen Granularitat stattfinden. So kann eine Vernetzung z.B. durch den Verweis auf physikalische Adressen (durch Zeiger bzw. Pointer) erfolgen, wodurch eine hohe Effizienz (z.B. innerhalb des Ablaufs eines Prozesses) erreicht wird. Andere
Vernetzungsmechanismen sind z.B. elektronische Nachrichten (z.B. E-Mail), Telefon oder Fax. Je nach Anforderung der zugrundeliegenden Applikation kann vom Anwender ein entsprechender Vernetzungsmechanismus gewählt werden.
Durch geeignete Softwareentwicklungsumgebungen wird das Verfahren unterstutzt. So können in einem Repository bereits erstellte Objekte vorhanden sein, die über Drag&Drop oder andere Eingabehilfsmittel (z.B. Tastatur, Lichtgriffel) in den Baum eingefugt werden können. Weiterhin ist es von
Vorteil, wenn die Anzeigevorrichtung, die zum Darstellen und zum Erstellen der Baume verwendet wird, in unterschiedliche Bildschirmbereiche aufteilbar ist (Fenstertechnik) . Objekte im Sinne der Erfindung sind diejenigen Objekte, die bei der Erstellung der Softwareapplikation verwendet werden, aber auch Laufzeit-Objekte. Laufzeit-Objekte sind Objekte, die zur Laufzeit eines Systems (z.B. einer Applikation) die Logik des Systems ausfuhren.
Das erfindungsgemaße Verfahren eignet sich weiterhin für die Erstellung von Softwareapplikationen für Prozessleitsysteme und Fertigungsautomatisierungssysteme .
Eine erste vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass zur Laufzeit die Objekte und/oder Referenzierungsmechanismen und/oder Vernetzungsmechanismen und/oder Implementierungen der Objekte austauschbar sind. Dadurch, dass zur Laufzeit Objekte durch andere Objekte, z.B. durch Objekte mit erweiterter Funktionalitat oder die Implementierungen von Objekten (z.B. die neuen Implementierungen sind fehlerbereinigt oder haben eine bessere Performance) oder Referenzierungs- und
Vernetzungsmechanismen ausgetauscht werden können, wird die Turnaround-Zeit bei Änderungen deutlich reduziert. Dadurch wird die Flexibilität für den Anwender und den Betreiber einer Anlage erhöht und die Agilität eines Unternehmens erhöht. Für die Auswertung der Metadaten wird kein üblicher Compiler verwendet, sondern ein so genannter inkrementeller Compiler oder ein Interpreter, der nur zum Zeitpunkt des Austauschens objektlokal aktiv ist. Für das neu eingesetzte Objekt, wird, wenn notig inkrementell Code erzeugt und der inkrementelle Compiler oder Interpreter fugt das neu eingesetzte Objekt (bzw. den Referenzierungsmechanismus und/oder Vernetzungsmechanismus und/oder eine neue Implementierung von Objekten) zur Laufzeit in den Baum wieder ein, ohne andere (nicht betroffene) Teile des Baumes berücksichtigen zu müssen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass den Objekten zur Laufzeit Dienste hinzugefugt werden. Die Dienste verwenden die objektlokalen Metadaten um (MES-, bzw. Control - ) Infrastrukturfunktionen generisch zur Verfugung zu stellen. Solche Dienste können z.B. sein: Serialisierung, Replikation, Verschlüsselung oder Zugriffsschutz. Die Objekte können dadurch mit sogenannten "Quality of Services" ausgestattet werden. Ein Benutzer eines Objektes kann sich auf die Ausführung dieser Dienste verlassen und von ihrer Realisierung abstrahieren.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass
Implementierungen der Referenzierungsmechanismen oder der Vernetzungsmechanismen oder der Dienste für Daten und für Programme verwendet werden. Die Mechanismen und die Dienste müssen somit nicht jeweils für Daten und für Programme separat implementiert werden. Weiterhin können Metainformationen allen Objekten (egal, ob es sich um Daten oder Programme handelt) in gleicher Weise zugefugt werden und es kann in gleicher Weise bei allen Objekten auf die Metainformationen zugegriffen werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass die Objekte statisch und/oder dynamisch vernetzt werden. Vernetzungen (bzw. Verzeigerungen oder Referenzierungen) können statisch bei einer manuellen Erstellung des Baumes erfolgen, aber auch automatisch aufgrund von aktuellen Informationen oder Metainformationen erstellt werden (z.B. bei Bedarf). Dadurch wird die Flexibilität für einen Anwender erhöht. Vernetzungen können über unterschiedliche Mechanismen und Implementierungen eingerichtet werden: z.B. Zeiger auf Objekte, E-Mail an Objekte oder Vernetzung über OPC- Protokolle (OPC steht für OLE for Process Control) .
Insbesondere im industriellen Umfeld werden OPC-Protokolle häufig verwendet. Weitere Techniken bzw. Implementierungen die für Vernetzungen oder für Verknüpfungen einsetzbar sind, sind z.B. MSMQ (Microsoft Message Queue), HTTP (Hypertext Transfer Protocol) oder SOAP (Simple Object Transfer Protocol) .
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass die Objekte die Metainformation physikalisch enthalten. Dadurch wird bei der Erstellung der Softwareapplikation das Prinzip der Lokalitat unterstutzt, d.h. alle Informationen (auch die Metainformationen), die für ein Objekt wichtig sind, sind auch physikalisch am Objekt vorhanden. Der Zugriff auf diese Informationen wird dadurch erleichtert. Dadurch, dass die Objekte die Metainformationen physikalisch enthalten, kann auch ein Objekt für sich alleine zur Organisation, Reorganisation oder Rekonfigurierung der Softwareapplikation verwendet werden, in Abhängigkeit davon, welche Metainformationen (Typus und Umfang) im Objekt vorhanden sind. Dies ist insbesondere für mobile Objekte von Vorteil, z.B. für Softwareagenten die sich im Internet (oder anderen vernetzten Systemen wie z.B. Intranet) von Rechner zu Rechner bewegen, um z.B. jeweils rechnerlokal hochperformant Anlageninformation z.B. für ein Mamtenancesystem zu sammeln.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass die
Metainformation statische und/oder dynamische Objektmodelle beinhaltet. Solche Objektmodelle sind z.B. Klassen und deren Beziehungen, State/Event-Modelle, Activity-Modelle, Deployment -Modelle oder Domain-Modelle (z.B. MES Prozessmodell in spezifischen Branchen wie z.B.
Automobilherstellung, Dungemittelproduktion) . Dies ist insbesondere für die generische Softwareentwicklung bzw. für Softwaregeneratoren von Vorteil .
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass die Metainformation eine Applikation oder einen Geschaftsprozess beschreibt. Wenn die Metainformation nicht nur Informationen über das Objekt selbst, sondern auch Informationen über die gesamte Softwareapplikation, über die Einsatzumgebung oder über den zu realisierenden Geschaftsprozess (bzw. Business Logik) beinhaltet, dann wird dadurch die Konfigurierung der Softwareapplikation vereinfacht, bis dahin, dass eine Konfigurierung automatisch erfolgen kann. Auch Rekonfigurierungen (z.B. nach Systemabsturzen oder Ausfall von Teilen des Systems) können ohne menschlichen Eingriff automatisch erfolgen. Dadurch wird die Agilität eines Unternehmens erhöht.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden
Erfindung für ein Verfahren liegt darin, dass jedes einzelne Objekt die gesamte Metainformation über die Applikation oder den Geschaftsprozess beinhaltet. Das bedeutet, dass in einer Softwareapplikation bzw. in einem Softwaresystem in jedem einzelnen Objekt (z.B. im allerkleinsten Tag, in jeder Variable oder in jedem Operator, d.h. auch in den ganz fein granulären Objekten) die gesamte Beschreibung der Applikation oder auch eines Geschaftsprozesses enthalten ist. Durch diese Informationen kann jedes einzelne Objekt zu einer Reorganisation, aber auch Selbstorganisation der Applikation, des Systems oder des Geschaftsprozesses verwendet werden. Dies ist z.B. bei Systemfehlern sehr vorteilhaft wenn große Teile des Systems ausfallen. Das System kann sich aus dem kleinsten noch funktionsfähigen Teil selbst vollständig regenerieren. Ein Wartungsingenieur muss sich somit nicht aufwendig mit dem Wiederinbetriebsetzen beschäftigen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass auf einer Anzeigevorrichtung die Bäume in unterschiedlichen Ansichten dargestellt werden. Die Darstellung der Baume kann unterschiedlich sein, z.B. durch eine statische Explorer ahnliche Notation oder in Form von Workflow- bzw. Ablaufdiagrammen (Flowcharts, Activitydiagramme) oder z.B. in Form von Blockschaltbildern (z.B. Stromlaufplane) oder Anlagenplanen (z.B. physikalisches Anlagenlayout, Materialflussplane) . Dadurch wird die Flexibilität für einen Anwender sehr erhöht, denn er kann eine seinem Wissensstand adäquate Notation bzw. Visualisierung auswählen, um die im Laufzeitsystem vorhandene Metainformation einzusehen. Es kann auch zwischen den Darstellungsformen gewechselt werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass im Fehlerfall die Softwareapplikation sich selbst rekonfiguriert. Wenn in einer Softwareapplikation bzw. in einem Softwaresystem in jedem einzelnen Objekt (z.B. im allerkleinsten Tag, in jeder Variable oder in jedem Operator, d.h. auch in den ganz fein granulären Objekten) die gesamte Beschreibung der Applikation oder auch eines Geschaftsprozesses enthalten ist, können diese Informationen zu einer automatischen Reorganisation, d.h. Selbstheilung der Applikation, des Systems oder des Geschaftsprozesses verwendet werden. Benutzereingriffe sind nicht mehr erforderlich und die Stillstandzeiten werden minimiert. Ein Wartungsingenieur muss sich somit nicht aufwendig mit dem Beschaffen und Lesen von Dokumentationen beschäftigen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden
Erfindung liegt in einer Softwareentwicklungsumgebung, die ins Laufzeitsystem integriert ist, wobei über Sichten auf auswahlbare Funktionalitaten zugegriffen wird. Die traditionelle Softwarentwicklungsumgebung wird somit reduziert auf Darstellungen und Editoren mit denen direkt das Laufzeitsystem betrachtet und verändert werden kann. Vorteile dieses Konstruktionsprinzips bzw. dieser Architektur sind neben der einfacheren Anderbarkeit des Laufzeitsystems auch die System- und Datenkonsistenz. So kann über die Sichten, die z.B. durch
Editoren realisiert werden, auf Anwendungsfunktionen des Laufzeitsystems zugegriffen werden (Bedienungssicht) oder aber auch Änderungen bzw. Erweiterungen vorgenommen werden (Engineering- oder Wartungssicht) .
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung liegt darin, dass die erfindungsgemaße Softwareapplikation oder das erfindungsgemaße Verfahren und die Softwareentwicklungsumgebung durch ein Computerprogramm implementiert sind. Dadurch können eventuelle Modifizierungen bzw. Anpassungen leicht durchgeführt werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung liegt darin, dass das Computerprogramm für das erfindungsgemaße Verfahren bzw. für die
Softwareentwicklungsumgebung auf einem Datenträger gespeichert ist. Dadurch ist das Verfahren bezuglich der Logistik und Verteilung leicht handhabbar. Datenträger sind z.B. übliche Computerprogrammprodukte wie z.B. Disketten oder CDs.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung liegt darin, dass das Computerprogramm für das erfindungsgemaße Verfahren bzw. für die Softwareentwicklungsumgebung auf einer
Datenverarbeitungseinrichtung installiert ist. Dadurch wird die Performance erhöht.
Weitere Vorteile und Details der Erfindung ergeben sich anhand der nun folgenden Beschreibung vorteilhafter Ausfuhrungsbeispiele und in Verbindung mit den Figuren. Soweit in unterschiedlichen Figuren Elemente mit gleichen Funktionalitaten beschrieben sind, sind diese mit gleichen Bezugszeichen gekennzeichnet.
Es zeigen:
FIG 1 in einer prinzipiellen Ubersichtsdarstellung die "Unternehmenspyramide" mit drei Steuerungsebenen,
FIG 2 eine Schemadarstellung mit einer herkömmlichen Softwareentwicklungsumgebung, einem Laufzeitsystem und einem zu steuerndem technischen Prozess,
FIG 3 die Schemadarstellung eines Objektes,
FIG 4 die Baumstruktur einer Softwareapplikation, FIG 5 eine Darstellungsform eines Baumes,
FIG 6 eine weitere Darstellungsform eines Baumes,
FIG 7 eine Schemadarstellung mit einem Laufzeitsystem und einem zu steuernden technischen Prozeß, wobei Funktionen der Softwareentwicklungsumgebung ins Laufzeitsystem integriert sind und
FIG 8 in einem Schaubild Aspekte, die eine Softwarearchitektur bestimmen.
Die Darstellung gemäß FIG 1 zeigt in einer prinzipiellen Ubersichtsdarstellung die drei Steuerungsebenen, wie sie üblicherweise in einem produzierenden bzw. fertigenden Unternehmen zu finden sind. Durch die Pyramidenform wird ausgedruckt, dass nach oben hin eine Verdichtung der Informationen stattfindet. Die oberste Ebene ist die ERP- Ebene (Enterprise Ressource Planning. Auf dieser Unternehmensleitebene werden üblicherweise die betriebswirtschaftlichen und vertrieblichen Aufgaben in einem Unternehmen durchgeführt (z.B. Finanzwesen, Vertriebswesen, Personalwesen, Berichterstattung) . Aber auch produktionsanlagenubergreifende logistische Aufgaben (z.B. Auftrags- und Materialverwaltung) werden auf dieser Ebene durchgeführt. Das System SAP R/3 ist ein ERP-System, das auf der Unternehmensleitebene sehr häufig verwendet wird.
Die unterste Ebene der Pyramide ist die Automatisierungs- Ebene (Controls) . Auf dieser Ebene kommen üblicherweise speicherprogrammierbare Steuerungen (SPS) in Verbindung mit Visualisierungs- und Prozessleitsystemen (PLS) zum Einsatz. Die Antriebe, Aktoren und Sensoren der Produktions- und/oder Fertigungseinrichtungen stehen direkt mit den Systemen dieser Ebene in Verbindung.
Das Verbindungsglied zwischen der ERP-Ebene und der Automatisierungs-Ebene wird durch die MES-Ebene gebildet. Die Applikationen der MES-Ebene sorgen somit für eine vertikale Integration zwischen der ERP-Ebene und der Automatisierungs- Ebene. Die MES-Applikationen müssen einerseits die Grobplanungen der ERP-Systeme um produktionsanlagenspezifische Feinplanungen erganzen und an die Systeme der Automatisierungs-Ebene weiterleiten, andererseits ist es Aufgabe der MES-Applikationen produktionsrelevante Daten der Automatisierungs-Ebene aufzunehmen, aufzubereiten und an die ERP-Ebene (Unternehmensleitebene) weiterzuleiten sowie die Ablaufe in der Produktion zu optimieren.
Typische MES-Applikationen sind u.a. Quality Management (QM) , Ma tenance Management (MM) , Performance Analysis (PA) , Process Management, Labor Management, Asset Management. Durch jeweils drei Punkte wird in FIG 1 ausgedruckt, dass sich auf einer Ebene weitere Elemente (Applikationen, Systeme etc.) befinden können.
MES-Systeme bzw. ERP-Systeme enthalten in der Regel ein so genanntes Laufzeitsystem zur zeitlichen Ablaufsteuerung der beteiligten Komponenten (Teilkomponenten, Module, Tasks, Prozesse des Betriebssystems etc.), sowie ein so genanntes Engineeringsystem zum Erstellen und Editieren von Programmen, welche zur Ausfuhrung im Laufzeitsystem vorgesehen sind.
Die Darstellung gemäß FIG 2 zeigt eine Schemadarstellung m t einer herkömmlichen Softwareentwicklungsumgebung SU, einem Laufzeitsystem RTS und einem zu steuernden technischen Prozess TP1. Softwareapplikationen werden heutzutage methodisch und ingenieurmaßig erstellt. Dazu werden üblicherweise Werkzeuge (so genannte CASE-Werkzeuge, CASE steht für Computer Aided Software Engineering) verwendet. Durch diese CASE-Werkzeuge wird die Einhaltung von Methoden und Standards unterstutzt, um die Produktivität der
Softwareentwickler, aber auch um die Qualltat der erstellten Software zu erhohen. Die CASE-Werkzeuge werden den Softwareentwicklern über eine Softwareentwicklungsumgebung SU zur Verfugung gestellt. Diese Softwareentwicklungsumgebung SU ist Teil des Arbeitsplatzes für einen Softwareersteller . Eine Softwareentwicklungsumgebung SU unterstutzt einen Softwareersteller in allen Phasen der Softwareentwicklung, d.h. von den frühen Phasen in der Analyse bis zu den spaten Phasen des Testens. Für alle Phasen der Softwareentwicklung stehen einem Entwickler geeignete Dienstprogramme, wie z.B. Editor, Compiler, Debugger, aber auch Werkzeuge für die Analyse und für den Entwurf zur Verfugung.
Der Arbeitsplatz eines Softwareentwicklers besteht üblicherweise aus einer Recheneinheit mit Prozessor und Speicher sowie Ausgabeeinheiten wie Bildschirm, Display und Eingabehilfsmittel wie Keyboard und Maus sowie den
Hilfsprogramme, die zur Softwareentwicklung benotigt werden (Editor, Compiler, etc.). Über eine geeignete Softwareentwicklungsumgebung SU können diese Hilfsprogramme von einem Softwareentwickler sehr leicht aufgerufen werden und bedient werden. Moderne Softwareentwicklungsumgebungen SU ermöglichen weiterhin einen Zugriff auf Konfigurationsmanagement -Werkzeuge und auf Anderungsmanagement-Werkzeuge .
Heutzutage unterstutzen moderne
Softwareentwicklungsumgebungen SU insbesondere die Paradigmen der Objektorientierung wie die Erstellung von Objekten, die Erstellung von Klassen, die Erstellung von Oberklassen sowie die Darstellung von Vererbungsbeziehungen. Über geeignete Editoren, Maskeneingabe oder über Drag&Drop-Mechanismen werden die Objekte mit Metainformationen verknüpft, werden die Objekte als hierarchische Baume strukturiert und auch miteinander vernetzt. Die mit Hilfe der Softwareentwicklungsumgebung SU erstellten Softwareapplikationen müssen auf einem Zielsystem bzw. auf einem Zielrechner letztendlich ausgeführt werden, um z.B. einen technischen Prozess TP1 zu steuern. Das Zielsystem besteht üblicherweise aus einer bis mehreren Recheneinheiten mit Prozessoren und Speichereinrichtungen sowie einem Laufzeitsystem RTS . Die mit Hilfe der
Softwareentwicklungsumgebung SU erstellten Programme werden über den Informationspfad I auf das Runtimesystem RTS geladen. Über Ein-/Ausgabeverbindungen EAl wird der zugrunde liegende technische Prozess z.B. für eine
Automatisierungslosung oder eine MES-Losung gesteuert. Vom Laufzeitsystem RTS zum technischen Prozess TP1 werden über die EA-Verbindung EAl z.B. Aktoren beeinflusst, vom technischen Prozess TP1 zurück zum Laufzeitsystem RTS werden über die EA-Verbindung EAl z.B. Sensordaten geliefert, die dann in der Softwareapplikation weiterverarbeitet werden. Em Laufzeitsystem RTS kann auch auf mehrere Rechnereinheiten verteilt sein.
Die Darstellung gemäß FIG 3 zeigt die Schemadarstellung eines Objektes mit einem Objektinterface 01. Ein Objekt ist allgemein ein Gegenstand oder ein Element einer Domäne bzw. einer Diskurswelt. In der objektorientierten
Softwareentwicklung ist ein Objekt ein individuelles Exemplar von Dingen oder Sachen (z.B. Roboter, Auto, Maschine), Personen (z.B. Kunde, Mitarbeiter, Patentanwalt) oder Begriffen der realen Welt (z.B. Bestellauftrag) oder der Vorstellungswelt (z.B. juristische und naturliche Personen oder Organisationen) . Ein Objekt besitzt einen bestimmten definierten Zustand und reagiert mit einem definierten Verhalten auf seine Umgebung. Außerdem besitzt jedes Objekt eine Objektidentitat , die es von allen anderen Objekten unterscheidet und die es erlaubt, auf ein bestimmtes Objekt zuzugreifen. Ein Objekt kann ein oder mehrere andere Objekte kennen. Zwischen Objekten, die sich kennen, bestehen Verbindungen oder Verzeigerungen bzw. Vernetzungen. Der Zustand eines Objekts wird durch seine Daten bzw. Attributwerte und die jeweiligen Verbindungen zu anderen Objekten bestimmt. Das Verhalten eines Objekts wird durch seine Menge von Methoden bzw. Operationen definiert. In der Objektorientierung wird durch eine Klasse der Typ eines Objektes beschrieben. Aus dieser Typbeschreibung können konkrete Inkarnationen bzw. Instanzen, die dann ein konkretes programmiersprachliches Objekt darstellen, erzeugt werden. Mit Hilfe von Objektdiagrammen lassen sich Objekte und ihre Verbindungen graphisch darstellen. Die Editoren für Objektdiagramme sind Teil der Softwareentwicklungsumgebung (SU; FIG 2) . UML (Unified Modeling Language) bietet eine Reihe von Notationen zur graphischen Darstellung objektorientierter Konzepte (Geschaftsprozessdiagramm,
Zustandsdiagramm, Aktivitatsdiagramm, Kollaborationsdiagramm, Sequence Diagramm, Klassendiagramme, etc.). Diese Diagramme können von einem Anwender mit der
Softwareentwicklungsumgebung (SU; FIG 2) editiert und bearbeitet werden.
Der linke Teil von FIG 3 zeigt die Informationen bzw. Elemente, die ein Objekt üblicherweise enthalt. Daten sind so einfache Dinge wie ein Zahlenwert oder aber auch komplexe Strukturen wie Rezepte, Bestellungen oder Archive. Methoden (oft auch als Operationen bezeichnet) repräsentieren ausfuhrbare Tätigkeiten im Sinne eines Algorithmus. Die Menge der Methoden bestimmt das Verhalten eines von dieser Klasse instantiierten Objektes. Die Methoden eines Objektes können von anderen Objekten vergleichbar einer Client-Server- Architektur verwendet bzw. aufgerufen werden. Weiterhin können Objekte so genannte Subobjekte beinhalten, die sie für die Realisierung ihrer Methoden benotigen. Durch die Subobjekte wird ein struktureller Aufbau eines Objektes bestimmt.
In der Darstellung von FIG 3 ist auf der rechten Seite schraffiert ein so genannter Container dargestellt. Durch diesen Container werden die der Erfindung entsprechenden Mechanismen für die Metainformationshaltung und die Mechanismen des Zugriffs auf diese Metainformationen realisiert. Die Container stellen eine Kapselschicht um das Objekt dar, und alle Zugriffe auf ein Objekt können nur über die Schnittstelle 01 erfolgen. Über die Schnittstelle 01 wird auf die Methoden und Daten und auf die Metainformation des Objektes zugegriffen. Bei einem Zugriff auf die Daten, die Methoden oder auf die Metainformationen kann somit ein Benutzer von der Realisierung von Datenmethoden und Metainformationen abstrahieren. Alle Zugriffe auf ein Objekt erfolgen über die Schnittstelle 01. Dadurch ist die Wiederverwendbarkeit und die Austauschbarkeit von Objekten sehr leicht möglich. In einem auch komplexen System, z.B. Softwaresystem, kann somit immer auf dieselbe Art und Weise auf Objekte zugegriffen werden. Insbesondere stellen die so genannten Container Infrastrukturfunktionen wie Datenvernetzung, Datenspeicherung, Datenvisualisierung in einheitlicher Weise für alle Arten von Objekten (z.B. Businessobjekten) zur Verfugung. In dem Container ist schematisch eine Doppelhelix vergleichbar einer DNA-Struktur einer menschlichen Zelle dargestellt. Dadurch soll verdeutlicht werden, dass ein Objekt Teile oder die gesamte Metainformation, d.h. auch die Aufbauinformation und die
Logik, die z.B. in einem Geschaftsprozess steckt, enthalt. Dadurch kann aus einem Objekt das gesamte System oder die gesamte Applikation organisiert werden bzw. reorganisiert werden. Dadurch können Ausfallzeiten eines Systems minimiert werden und Wartungsarbeiten sehr effizient durchgeführt werden.
Zu den Infrastrukturfunktionen, die ein Container zur Verfugung stellt, gehören z.B. Trace-Funktionen, d.h. wer und wie lange hat ein Objekt verwendet. Wie schon erwähnt, enthalt der Container Metainformationen,
Selbstbeschreibungsinformationen für das Objekt. Dadurch können auch Messungen, aber auch Security-Mechanismen eingefugt werden.
Die Darstellung gemäß FIG 4 zeigt die Baumstruktur einer Softwareapplikation. Die Objekte sind dabei als Doppelkreise dargestellt. Der innere Kreis stellt schematisch den Aufbau eines Objektes dar, wie es aus FIG 3 bekannt ist. Der linke Teil eines Objektes stellt dabei wieder die Datenmethoden und Subobjekte dar, der rechte schraffierte Teil repräsentiert den so genannten Container, der die Metainformationen enthalt und die Infrastrukturinformationen für ein Objekt zur Verfugung stellt. Der Container stellt eine Kapselschicht für das Objekt dar. Ein Zugriff auf das Objekt ist nur über die Objektschnittstelle 01 möglich, die vom Container zur Verfugung gestellt wird. Infrastrukturfunktionen sind z.B. Datenvernetzung, Datenspeicherung und Datenvisualisierung. Durch den Container werden diese Funktionen in einer einheitlichen Wiese für alle anderen Objekte zur Verfugung gestellt .
Die Außenkreise um die Objekte stellen dar, dass die Objekte in die Infrastruktur eines Systems letztendlich eingebettet sind. Ein Aspekt der Infrastruktur ist die Vernetzung. Eine Vernetzung oder Verzeigerung kann sehr feingranular, z.B. über Speicherpointer erfolgen. Sie kann aber auch ubers
Internet, über E-Mail oder über Telefonverbindungen erfolgen.
In der Darstellung gemäß FIG 4 wird durch die fett eingezeichneten Verbindungslinien zwischen den Objekten dargestellt, dass diese Objekte lateral miteinander verbunden sind. So eine laterale Verbindung kann im industriellen Umfeld z.B. eine Verbindung über OPC sein (OLE for Procress Control) . So eine Verbindung bzw. ein Infrastrukturdienst kann auch über Message Queue-Mechanismen realisiert werden. Der Zugriff auf Infrastrukturdienste oder -funktionalitaten wird über den Container dargeboten und ist für alle Objekte in einem Baum gleich, egal, ob es sich um ein B&B-Gerat (Bedienen und Beobachten) oder über eine speicherprogrammierbare Steuerung (SPS) handelt. Deshalb ist es auch sehr einfach, die Implementierung eines
Infrastrukturdienstes zu andern, da die Spezifikation unverändert bleibt. Der äußere Kreis eines Objektes stellt also eine Sammlung von Infrastrukturdiensten oder Infrastrukturfunktionen dar, die über einen Container verwendet werden können. Ein einmal realisierter
Infrastrukturdienst kann von allen Objekten in der gleichen Weise verwendet werden. Die Darstellung gemäß FIG 4 zeigt eine Softwareapplikation, bei der die Objekte als hierarchischer Baum strukturiert sind. Das zu realisierende System bzw. die Softwareapplikation enthalt ein B&B-Gerat mit einer Datenbank DB, wobei das B&B-Gerat von einer speicherprogrammierbaren Steuerung (SPS) versorgt wird. Die SPS greift über Ein- /Ausgabefunktionen auf Aktoren und Sensoren zu. Die Ergebnisse des Bedien- und Beobacht-Gerates werden von einem Objekt "Execution" weiterverarbeitet. Der Algorithmus, für diese Weiterverarbeitung im Objekt "Execution" erfolgt, wird durch den Teilbaum dargestellt, der unter dem Objekt "Execution" hangt. Dabei wird ein Wert XI mit einer Funktion F bearbeitet, wobei die Funktion F als Eingabewert den Wert X2 erhalt. Nach dem Ausfuhren dieser Execution-Komponente werden weitere Nachbearbeitungen durchgeführt, dargestellt durch die Objekte "Postprocessmg 1" und "Postprocessing 2". Dabei kann es sich z.B. um Verdichtungs- oder Anzeigefunktionen handeln. In FIG 4 ist dargestellt, dass die Ergebnisse der Nachbearbeitung von "Postprocessing 1" durch das Objekt "Weiterverarbeitung" einem weiteren Verarbeitungsschritt unterzogen werden. Ein auf diese Weise beschriebenes Softwaresystem bzw. eine Softwareapplikation kann naturlich mit weiteren auf diese Art und Weise beschriebenen Softwareapplikationen Teil einer übergeordneten Welt sein, hier in FIG 4 dargestellt durch das Objekt "World" .
Neben der hierarchischen Strukturierung, wie sie durch die Struktur des Baumes vorgegeben wird, können die Objekte auch lateral bzw. horizontal miteinander vernetzt, reflexiert oder verzeigert werden. Dies ist in FIG 4 dargestellt durch die fetten Linien. Solche Verzeigerungen können über Eingabemasken modelliert werden oder auch über Drag&Drop- Mechanismen hergestellt werden. Die Funktion, die von einem Softwaresystem bzw. von einer Softwareapplikation realisiert wird, ergibt sich aus der Struktur, aus der Hierarchie und aus der Vernetzung der Baumobjekte. In Abhängigkeit von einem zugrunde zu legenden Traversierungsalgorithmus werden die Baumelemente, d.h. die Objekte, abgearbeitet und ausgeführt. Die Ausfuhrung einer Softwareapplikation ist der Funktionsweise des Nervensystems eines Menschen vergleichbar, wo die einzelnen Neuronen über Dentriten und Synapsen miteinander verbunden sind und ihre Aktivitäten untereinander austauschen, wobei ein Reiz eine Impulskette durch den Korper auslost und je nach Vernetzung der Neuronen eine solche Impulskette ausgeführt wird. Im erfindungsgemaßen System bzw. Softwareapplikation oder auch Softwarearchitektur wird auch durch die Struktur und die Vernetzung der Objekte, die den Neuronen im menschlichen
Korper vergleichbar sind, einem Anreiz in FIG 4, z.B. wenn ein Sensor eine SPS ein Ereignis weiterliefert und dieses Ereignis über das B&B-Gerat erfasst wird und dann eine Execution gestartet wird, die wiederum "Postprocessing 1" und "Postprocessing 2" zu einer Weiterverarbeitung anstoßt, wobei "Postprocessing 1" nach der Weiterverarbeitung noch eine Weiterverarbeitung initiiert. Auf diese Art und Weise erstellte Softwareapplikationen haben sehr vorteilhafte Eigenschaften. So können die Objekte, die für eine Applikation benotigt werden, erst zur Laufzeit zusammengesetzt werden, wodurch die Anderbarkeit und die Flexibilität diese Applikationen sehr groß ist. Bei Änderungen muss ein Objekt nicht erst kompiliert werden. Ein neu in das System eingebrachtes Objekt, das ein anderes ersetzt, ist sehr einfach integrierbar, wenn es die gleiche Schnittstelle, die gleiche Spezifikation wie das zu ersetzende Objekt besitzt und sich nur in der Implementierung ändert, z.B. durch eine bessere Performance.
Die Darstellung gemäß FIG 5 zeigt eine Darstellungsform für einen Baum. In FIG 5 ist eine Anzeigevorrichtung AZ1 als mit den beiden Bildschirmbereichen BB1 und BB2 dargestellt. Eine Anzeigevorrichtung AZl kann z.B. ein Monitor oder ein Display sein. Die Anzeigevorrichtung AZl ist üblicherweise ein Element einer Element einer Softwareentwicklungsumgebung (SU; FIG 2) . Mit Hilfe von Anzeigevorrichtungen und Eingabehilfsmitteln wie z.B. Tastatur oder Maus werden
Objekte auf dem Bildschirm erzeugt, hierarchisch als Baum strukturiert, miteinander vernetzt oder verzeigert, aber mit Metainformationen oder anderen Informationen versehen. Es ist vorstellbar, dass eine Anzeigevorrichtung AZl weitere Bildschirmbereiche enthalt zu der Darstellung von Bäumen, aber auch, um Eingaben zu realisieren (z.B. Menüleisten). Eine Softwareapplikation wird zur Laufzeit aus den Objekten eines Baumes zusammengesetzt. Für die Abarbeitung der Objekte ist die Struktur wichtig, aber auch die Vernetzung der Objekte. Wenn ein Benutzer (z.B. ein Systemintegrator oder
Wartungsingenieur) Änderungen einbringen will, dann benotigt er eine Darstellung des Baumes, die seinen entsprechenden Anforderungen und Bedurfnissen entgegenkommt. In der Darstellung, wie sie im Bildschirmbereich BB1 auf der linken Seite von FIG 5 dargestellt ist, wird ein Baum OBl mit den Baumelementen Kl, K2 , K3 , K4 gezeigt, und zwar in einer explorerahnlichen Notation. Die Darstellung eines Baumes, wie sie im Bildschirmbereich BB2 gezeigt wird, entspricht einer Notation, wie sie z.B. für Stromlaufplane verwendet wird. Die im Bildschirmbereich BB2 dargestellten Elemente Kl λ und K2 Λ sind über Ein- (xl, x2) und Ausgabevariablen (rl, r2), die jeweils mit Linien miteinander verbunden sind, zu einer Baumstruktur dargestellt. Eine Darstellung in dieser Form von Stromablaufplanen ist besonders für Elektriker interessant, denn Elektriker denken in Stromlaufplanen. Über
Eingabehilfsmittel ist es möglich, die Reprasentierung eines Baumes zu andern und jeweils für die Usergruppe die praktischste Darstellung zu wählen. Usergruppen sind z.B. Wartungsingenieure, Systemintegratoren, Entwickler, aber auch Marketing- und Vertriebsleute. Die Darstellung gemäß FIG 6 zeigt eine weitere Möglichkeit, wie ein Baum an einer Anzeigevorrichtung AZ2 dargestellt werden kann. Der linke Abschnitt von FIG 6 zeigt einen Bildschirmbereich BB1 ' mit einem Objektbaum 0B2 in einer explorerahnlichen Struktur. Der rechte Teil von FIG 6 zeigt einen Bildschirmbereich BB2 λ , in welchem für die Darstellung eines Baumes eine Notation verwendet wird, die insbesondere • für die Darstellung von Geschaftsablaufen sehr vorteilhaft ist. Menschen in der Buchhaltung oder im Management des Unternehmens denken in solchen Geschaftsprozessablaufen
(Businessablaufen) . Die Benutzerfreundlichkeit und auch die Effizienz bei der Erstellung von Bäumen oder beim Andern von Bäumen wird durch die Möglichkeit, dass zwischen unterschiedlichen Darstellungsformen gewechselt werden kann, sehr erhöht. Em Benutzer kann dadurch von der internen Reprasentierung oder Implementierung eines Baumes abstrahieren. Bei der Erstellung eines Baumes oder bei der Änderung eines Baumes muss nichts neu programmiert werden, sondern alles kann projektiert werden. Dies ist vorteilhaft für die Effizienz bei der Erstellung von
Softwareapplikationen, aber auch für die Erstellung von Softwarearchitekturen .
Die Darstellung gemäß FIG 7 zeigt eine Schemadarstellung mit einem erweiterten Lau zeitsystem RTS/SU und einem zu steuernden technischen Prozeß TP2, wobei Funktionen der Softwareentwicklungsumgebung im erweiterten Laufzeitsystem RTS/SU integriert sind. Über Sichten (sog. Views) wird auf die jeweils benotigten Funktionen zugegriffen. In FIG 7 sind Sichten für die Entwicklung (SU-view) für die Bedienung (Operator view) und für die Wartung (Wartungs view) dargestellt. Durch drei Punkte ist angedeutet, dass weitere views vorhanden sein können. Das erweiterte Laufzeitsystem RTS/SU beinhaltet die Infrastruktur für die Entwicklung und Veränderung des Laufzeitsystems . Die Verbindung zum zu steuernden technischen Prozeß TP2 erfolgt über Ein- /Ausgabeverbindungen EA2. Es ist ein wesentliche Auswirkung der Erfindung, dass die Funktionalitat einer herkömmlichen
Softwareentwicklungsumgebung (SU; FIG 2) zu großen Teilen durch das Laufzeitsystem RTS/SU abgedeckt wird. Metadaten sind großteils Daten die bei der Entwicklung sowieso anfallen. Somit können Laufzeitsystem und Softwareentwicklungsumgebung sozusagen miteinander verschmelzen und müssen nicht mehr als separate Komponenten ausgebildet werden. Ein System, das anderbar ist, beinhaltet zur Laufzeit viele Aspekte die heute nur in Entwicklungsumgebungen vorhanden sind (Modellierung, Versionierung, Compilierung etc) . Die traditionelle Softwarentwicklungsumgebung wird reduziert auf Darstellungen und Editoren mit denen direkt das Laufzeitsystem betrachtet und verändert werden kann.
Vorteile dieses Konstruktionsprinzips bzw. dieser Architektur sind neben der einfacheren Anderbarkeit des Laufzeitsystems auch die Systemkonsistenz. Alle Komponenten, die die Metadaten beinhalten bzw. referenzieren, beschreiben sich selbst. Die Zusammensetzung der Komponenten ergeben eine gesamte Systembeschreibung. D.h. wie auch immer das System geändert wird (z. Baugruppen stecken oder ziehen) die Sichten (Engineeringviews) sind in der Lage immer das aktuell vorhandene System zu zeigen. UML Diagramme, Business Prozess- Abbildungen, Stromlaufplane, Anlagenbilder sind immer aktuell .
Die Darstellung gemäß FIG 8 zeigt in einem Schaubild die Aspekte, die eine Softwarearchitektur SA bestimmen. Die
Erstellung von Softwarearchitekturen SA erfordert abstraktes und konzeptionelles Denken. Die erfindungsgemaß vorgeschlagene Architektur stellt sicher, dass zwischen der Analysephase und der Designphase kein Strukturbruch auftritt. In einer Analysephase werden die für eine Softwarearchitektur benotigten Objekte identifiziert, mit Metainformationen verknüpft und als hierarchische Baume strukturiert. Weiterhin können die Objekte lateral und horizontal miteinander vernetzt werden und über Kommunikationsmechanismen untereinander oder mit der Umgebung kommunizieren. Die Funktion einer Softwareapplikation, die auf einer Softwarearchitektur beruht, wird durch die Anordnung der Objekte zueinander bestimmt. Zur Laufzeit werden dann die Objekte zu einer Softwareapplikation zusammengesetzt, wobei die Softwareapplikation Prinzipien, die durch die Softwarearchitektur vorgegeben werden, inherent beinhaltet. Dadurch ist sichergestellt, dass kein Designbruch stattfindet .
Eine Softwarearchitektur muss unterschiedliche Aspekte, Gesichtspunkte bzw. so genannte Views berücksichtigen. Dazu gehört die Funktion, die letztendlich durch eine
Softwareapplikation erreicht werden soll, die auf der Architektur basiert. Die Funktionalitat findet sich üblicherweise und insbesondere in den Methoden bzw. Operationen der Objekte. Das Verhalten und die Dynamik werden insbesondere durch das Zusammenspiel der Objekte bzw. durch das Zusammenspiel der in den Objekten vorhandenen Operationen bestimmt. Der Datenaspekt wird üblicherweise über die Attribute bestimmt. Weiterhin bestimmen die Attribute die Zustande eines Objektes, wobei die Zustande auch durch die jeweiligen Verbindungen zu anderen Objekten bestimmt werden. Der Strukturaspekt beinhaltet den hierarchischen Aufbau eines Baumes mit seinen Objekten bezuglich einer "besteht aus"- Relation. In einer Softwarearchitektur wird der Strukturaspekt aber auch durch die "is a" -Relation mit eingebracht. Innerhalb einer Softwarearchitektur ist der
Kommunikationsaspekt sehr wichtig, denn durch die verwendeten Kommunikationsmechanismen wird sichergestellt, dass die Objekte, die verwendet werden für eine Applikation, überhaupt miteinander Daten austauschen können, d.h. kommunizieren können. Kommunikationsmechanismen sind z.B. MQ (Message
Queues) , so genannte Middleware-Plattformen wie COM, DCOM oder CORBA oder auch darauf aufsetzenden Schichten wie das OPC-Protokoll (OLE for Process Control) . Die Auswahl von Kommunikationsmechanismen hat einen ganz entscheidenden Einfluss auf eine Softwarearchitektur. Auch Synchronisationsmechanismen und die Fähigkeit zur Nebenlaufigkeit wird dadurch beeinflusst.
Für aktuelle Softwarearchitekturen und für
Softwareapplikationen, die auf ihnen beruhen, wird der Aspekt der nicht funktionalen Eigenschaften immer wichtiger. Nicht funktionale Eigenschaften sind z.B. Anderbarkeit, Effizienz, Zulassigkeit , Testbarkeit oder Wiederverwendbarkeit. Die gezielte und explizite Verwendung von Metainformationen in einer Softwarearchitektur fordert die Erfüllung von nicht funktionalen Eigenschaften enorm. Dadurch, dass die einzelnen Objekte Metainformationen nicht nur über sich selbst beinhalten, sondern auch über die Applikationen, in denen sie verwendet werden, oder in den Geschaftsprozessen, in denen sie verwendet werden, können sehr leicht selbst Organisationen einer Softwareapplikation durchgeführt werden, d.h. ein automatisches Recovery kann erfolgen, ohne dass ein Mensch eingreifen muss. Die genannten Aspekte, die für eine Softwarearchitektur wichtig sind, werden üblicherweise durch CASE-Werkzeuge (Computer-Aided Software-Engineering) mit entsprechenden Programmeditoren von einem Benutzer modelliert bzw. editiert. Diese CASE-Werkzeuge sind Bestandteil einer Softwareentwicklungsumgebung (SU; FIG 2). Für die Beschreibung einer Softwarearchitektur, wie sie in der Erfindung vorgeschlagen wird, eignen sich u.a. die Diagramme, die die Methode UML (Unified Modeling Language) zur Verfugung stellt.
Metainformationen lassen sich durch die Verwendung von Auszeichnungssprachen (Markup Language) sehr geschickt und einfach an Objekte und auch Systeme koppeln bzw. einbringen. Insbesondere XML (Extended Markup Language) bietet
Möglichkeiten, um Metainformationen leicht zu formulieren. Metainformationen können in XML z.B. als Elemente (durch ein Start-Tag und ein End-Tag eingeschlossen) oder als Attribute (direkt in eine Start-Tag integriert) hinterlegt werden.
Zusammenfassend betrifft die Erfindung Softwareapplikationen, Softwarearchitekturen und Verfahren zur Erstellung von
Softwareapplikationen, insbesondere für MES-Systeme, wobei Objekte (mit Daten, Attributen, Verhalten, Funktionen) für Softwareapplikationen, insbesondere MES-Applikationen, mit Metainformationen verknüpft werden, die Objekte als hierarchische Baume strukturiert werden (wobei unterschiedliche Darstellungsformen wahlbar sind) und die Objekte miteinander verzeigert bzw. vernetzt (lateral bzw. horizontal) werden. Zur Laufzeit werden die Objekte zu Softwareapplikationen zusammengesetzt, wobei sich die Gesamtfunktion der Softwareapplikationen aus der Struktur der hierarchischen Baume ableitet. Es können
Softwareapplikationen oder Softwarearchitekturen für MES- Systeme, für Automatisierungssysteme, für industrielle Steuerungen (auch Bewegungsteuerungen) und für Buroanwendungen (Officebereich) erstellt werden.
Die oben beschriebene erfindungsgemaße Softwareapplikation bzw. Softwareentwicklungsumgebung lasst sich als Computerprogramm in dafür bekannten Sprachen implementieren. Ein derartig implementiertes Computerprogramm kann in ebenfalls bekannter Weise über elektronische Datenwege abgespeichert und transportiert werden.

Claims

Patentansprüche
1. Softwareapplikation, insbesondere MES-Applikation, mit Objekten, die Daten und/oder Attribute und/oder Verhalten beinhalten und/oder referenzieren, wobei die Objekte auf mindestens einer Rechneremheit ablaufen und/oder gespeichert sind, d a d u r c h g e k e n n z e i c h n e t, dass
- die Objekte (Kl - K4, Kl Λ - K4 Λ ) zur Laufzeit mit Metainformation verknüpft sind,
- die Objekte (Kl - K4 , Kl λ - K4 λ ) zur Laufzeit als hierarchische Baume (OBl, OB2) strukturiert sind,
- die Objekte (Kl - K4, Kl λ - K4 λ ) zur Laufzeit lateral und/oder horizontal vernetzt und/oder referenziert sind und
- die Softwareapplikation zur Laufzeit aus den Objekten (Kl - K4, Kl λ - K4 λ ) zusammengesetzt wird, wobei sich die Gesamtfunktion der Softwareapplikation aus der Struktur der hierarchischen Baume (OBl, OB2) sowie der Vernetzung der Objekte in den Bäumen ableitet.
2. Softwareapplikation nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t, dass zur Laufzeit die Objekte (Kl - K4 , Kl Λ - K4 Λ ) und/oder Referenzierungsmechanismen und/oder Vernetzungsmechanismen und/oder Implementierungen der Objekte austauschbar sind.
3. Softwareapplikation nach Anspruch 1 oder 2, d a d u r c h g e k e n n z e i c h n e t, dass den Objekten (Kl - K4 , Kl Λ - K4 λ ) zur Laufzeit Dienste h zufugbar sind.
4. Softwareapplikation nach einem der Ansprüche 1 bis 3, d a d u r c h g e k e n n z e i c h n e t, dass Implementierungen der Referenzierungsmechanismen oder der Vernetzungsmechanismen oder der Dienste für Daten und für Programme anwendbar sind.
5. Softwareapplikation nach einem der Ansprüche 1 bis 4, d a d u r c h g e k e n n z e i c h n e t, dass die Objekte (Kl - K4 , Kl λ - K4 Λ ) statisch und/oder dynamisch vernetzt sind.
6. Softwareapplikation nach einem der Ansprüche 1 bis 5, d a d u r c h g e k e n n z e i c h n e t, dass die Objekte (Kl - K4 , Kl Λ - K4 λ ) die Metainformation physikalisch enthalten.
7. Softwareapplikation nach einem der Ansprüche 1 bis 6, d a d u r c h g e k e n n z e i c h n e t, dass die Metainformation statische und/oder dynamische Objektmodelle beinhaltet.
8. Softwareapplikation nach einem der Ansprüche 1 bis 7, d a d u r c h g e k e n n z e i c h n e t, dass die Metainformation eine Applikation oder einen Geschaftsprozess beschreibt.
9. Softwareapplikation nach einem der Ansprüche 1 bis 8, d a d u r c h g e k e n n z e i c h n e t, dass jedes einzelne Objekt (Kl - K4 , Kl Λ - K4 ) die gesamte Metainformation über die Applikation oder den Geschaftsprozess beinhaltet.
10. Softwareapplikation nach einem der Ansprüche 1 bis 9, d a d u r c h g e k e n n z e i c h n e t, dass auf einer Anzeigevorrichtung (AZl, AZ2) die Baume (OBl, OB2) in unterschiedlichen Ansichten darstellbar sind.
11. Softwareapplikation nach einem der Ansprüche 1 bis 10, d a d u r c h g e k e n n z e i c h n e t, dass im Fehlerfall die Softwareapplikation sich selbst rekonfiguriert .
12. Softwarearchitektur, insbesondere für MES-Applikationen, mit Objekten, die Daten und/oder Attribute und/oder Verhalten beinhalten und/oder referenzieren, wobei die Objekte auf mindestens einer Rechnereinheit ablaufen und/oder gespeichert sind, d a d u r c h g e k e n n z e i c h n e t, dass
- die Objekte (Kl - K4 , Kl λ - K4 λ ) zur Laufzeit mit Metainformation verknüpft sind,
- die Objekte (Kl - K4, K1Λ - K4Λ) zur Laufzeit als hierarchische Baume (OBl, OB2) strukturiert sind,
- die Objekte (Kl - K4, Kl - K4 λ ) zur Laufzeit lateral und/oder horizontal vernetzt und/oder referenziert sind,
- die Objekte (Kl - K4 , Kl Λ - K4 Λ ) zur Laufzeit untereinander und/oder mit der Umgebung durch Kommunikationsmechanismen kommunizieren und
- die Softwareapplikation zur Laufzeit aus den Objekten (Kl - K4 , Kl λ - K4 Λ ) zusammengesetzt wird, wobei sich die Gesamtfunktion der Softwareapplikationen, die auf der Softwarearchitektur beruhen, aus der Struktur der hierarchischen Baume sowie der Vernetzung der Objekte in den Bäumen bestimmt.
13. Softwarearchitektur nach Anspruch 12, d a d u r c h g e k e n n z e i c h n e t, dass zur Laufzeit die Objekte (Kl - K4 , Kl Λ - K4 λ ) und/oder
Referenzierungsmechanismen und/oder Vernetzungsmechanismen und/oder Implementierungen der Objekte und/oder Kommunikationsmechanismen austauschbar sind.
14. Softwarearchitektur nach Anspruch 12 oder 13, d a d u r c h g e k e n n z e i c h n e t, dass den Objekten (Kl - K4 , Kl λ - K4 ) zur Laufzeit Dienste hinzufügbar sind.
15. Softwarearchitektur nach einem der Ansprüche 12 bis 14, d a d u r c h g e k e n n z e i c h n e t, dass Implementierungen der Referenzierungsmechanismen oder der Vernetzungsmechanismen oder der Kommunikationsmechanismen oder der Dienste für Daten und für Programme anwendbar sind.
16. Softwarearchitektur nach einem der Ansprüche 12 bis 15, d a d u r c h g e k e n n z e i c h n e t, dass die Objekte (Kl - K4 , Kl λ - K4 λ ) statisch und/oder dynamisch vernetzt sind.
17. Softwarearchitektur nach einem der Ansprüche 12 bis 16, d a d u r c h g e k e n n z e i c h n e t, dass die Objekte (Kl - K4, Kl λ - K4 λ ) die Metainformation physikalisch enthalten.
18. Softwarearchitektur nach einem der Ansprüche 12 bis 17, d a d u r c h g e k e n n z e i c h n e t, dass die Metainformation statische und/oder dynamische Objektmodelle beinhaltet.
19. Softwarearchitektur nach einem der Ansprüche 12 bis 18, d a d u r c h g e k e n n z e i c h n e t, dass die Metainformation eine Applikation oder einen Geschaftsprozess beschreibt.
20. Softwarearchitektur nach einem der Ansprüche 12 bis 19, d a d u r c h g e k e n n z e i c h n e t, dass jedes einzelne Objekt (Kl - K4, Kl Λ - K λ ) die gesamte Metainformation über die Applikation oder den Geschaftsprozess beinhaltet.
21. Softwarearchitektur nach einem der Ansprüche 12 bis 20, d a d u r c h g e k e n n z e i c h n e t, dass auf einer Anzeigevorrichtung (AZl, AZ2) die Baume (OBl, 0B2) in unterschiedlichen Ansichten darstellbar sind.
22. Softwarearchitektur nach einem der Ansprüche 12 bis 21, d a d u r c h g e k e n n z e i c h n e t, dass im Fehlerfall die auf der Softwarearchitektur basierende Softwareapplikation sich selbst rekonfiguriert.
23. Verfahren zur Erstellung von Softwareapplikationen, insbesondere für MES-Systeme, basierend auf mindestens einer Rechnereinheit mit Eingabehilfsmittel, Ausgabehilfsmittel, sowie mindestens einer Anzeigevorrichtung, g e k e n n z e i c h n e t d u r c h folgende Schritte: - Erstellen von Objekten (Kl - K4 , Kl - K4 λ ) , die Einheiten der Softwareapplikation repräsentieren, mit den Eingabehilfsmitteln und der Anzeigevorrichtung,
- Zuordnen von Metainformationen zu den Objekten (Kl - K4 , Kl λ - K4 λ ) , mit den Eingabehilfsmitteln und der Anzeigevorrichtung,
- Strukturieren der Objekte (Kl - K4 , Kl λ - K4 ) als hierarchische Bäume (OBl, OB2) mit den Eingabehilfsmitteln und der Anzeigevorrichtung (AZl, AZ2),
- Vernetzen der Objekte (Kl - K4 , Kl - K4 λ ) mit den Eingabehilfsmitteln und der Anzeigevorrichtung (AZl, AZ2),
- automatisches Zusammensetzen der Objekte (Kl - K4, Kl λ - K4 ) zur Laufzeit zu einer Softwareapplikation,
- automatisches Ableiten der Funktion der Softwareapplikation aus der Struktur der hierarchischen Bäume, der Vernetzung der Objekte in den Bäumen, sowie der zugeordneten Metainformationen.
24. Verfahren nach Anspruch 23, d a d u r c h g e k e n n z e i c h n e t, dass zur Laufzeit die Objekte (Kl - K4, Kl λ - K4 λ ) und/oder
Referenzierungsmechanismen und/oder Vernetzungsmechanismen und/oder Implementierungen der Objekte austauschbar sind.
25. Verfahren nach Anspruch 23 oder 24, d a d u r c h g e k e n n z e i c h n e t, dass den Objekten (Kl - K4 , Kl - K4 v ) zur Laufzeit Dienste hinzugefügt werden.
26. Verfahren nach einem der Ansprüche 23 bis 25, d a d u r c h g e k e n n z e i c h n e t, dass Implementierungen der Referenzierungsmechanismen oder der Vernetzungsmechanismen oder der Dienste für Daten und für Programme verwendet werden.
27. Verfahren nach einem der Ansprüche 23 bis 26, d a d u r c h g e k e n n z e i c h n e t, dass die Objekte (Kl - K4 , Kl - K4 Λ ) statisch und/oder dynamisch vernetzt werden.
28. Verfahren nach einem der Ansprüche 23 bis 27, d a d u r c h g e k e n n z e i c h n e t, dass die Objekte (Kl - K4 , Kl - K4 λ ) die Metainformation physikalisch enthalten.
29. Verfahren nach einem der Ansprüche 23 bis 28, d a d u r c h g e k e n n z e i c h n e t, dass die Metainformation statische und/oder dynamische Objektmodelle beinhaltet.
30. Verfahren nach einem der Ansprüche 23 bis 29, d a d u r c h g e k e n n z e i c h n e t, dass die Metainformation eine Applikation oder einen Geschaftsprozess beschreibt.
31. Verfahren nach einem der Ansprüche 23 bis 30, d a d u r c h g e k e n n z e i c h n e t, dass jedes einzelne Objekt (Kl - K4 , Kl Λ - K4 ) die gesamte Metainformation über die Applikation oder den Geschaftsprozess beinhaltet.
32. Verfahren nach einem der Ansprüche 23 bis 31, d a d u r c h g e k e n n z e i c h n e t, dass auf einer Anzeigevorrichtung (AZl, AZ2) die Baume (OBl, OB2) in unterschiedlichen Ansichten dargestellt werden.
33. Verfahren nach einem der Ansprüche 23 bis 32, d a d u r c h g e k e n n z e i c h n e t, dass im Fehlerfall die Softwareapplikation sich selbst rekonfiguriert.
34. Softwarentwicklungsumgebung (SU) zur Ausfuhrung eines Verfahrens nach einem der Ansprüche 23 bis 33, d a d u r c h g e k e n n z e i c h n e t, dass die Softwareentwicklungsumgebung (SU) ins Laufzeitsystem (RTS, RTS/SU) integriert ist, wobei über Sichten auf auswahlbare Funktionalitaten zugegriffen wird.
35. Computerprogramm, das eine Softwareapplikation nach einem der Ansprüche 1 bis 11 oder ein Verfahren nach einem der Ansprüche 23 bis 33 oder eine Softwareentwicklungsumgebung nach Anspruch 34 implementiert.
36. Datenträger, auf dem ein Computerprogramm nach Anspruch 35 gespeichert ist.
37. Datenverarbeitungseinrichtung, auf der ein Computerprogramm nach Anspruch 35 installiert ist
EP03706314A 2002-02-19 2003-02-12 Softwareapplikation, softwarearchitektur und verfahren zur erstellung von softwareapplikationen, insbesondere für mes-systeme Ceased EP1516250A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10206903 2002-02-19
DE10206903A DE10206903A1 (de) 2002-02-19 2002-02-19 Softwareapplikation, Softwarearchitektur und Verfahren zur Erstellung von Softwareapplikationen, insbesondere für MES-Systeme
PCT/DE2003/000412 WO2003071417A2 (de) 2002-02-19 2003-02-12 Softwareapplikation, softwarearchitektur und verfahren zur erstellung von softwareapplikationen, insbesondere für mes-systeme

Publications (1)

Publication Number Publication Date
EP1516250A2 true EP1516250A2 (de) 2005-03-23

Family

ID=27674737

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03706314A Ceased EP1516250A2 (de) 2002-02-19 2003-02-12 Softwareapplikation, softwarearchitektur und verfahren zur erstellung von softwareapplikationen, insbesondere für mes-systeme

Country Status (5)

Country Link
US (1) US7581226B2 (de)
EP (1) EP1516250A2 (de)
CN (1) CN100397342C (de)
DE (1) DE10206903A1 (de)
WO (1) WO2003071417A2 (de)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9171100B2 (en) * 2004-09-22 2015-10-27 Primo M. Pettovello MTree an XPath multi-axis structure threaded index
DE102005008136A1 (de) * 2005-02-21 2006-08-24 Siemens Ag Entwicklungssystem für Prozessleitsysteme sowie zugehöriges Verfahren und Computerprogrammprodukt
EP1699005A1 (de) 2005-03-01 2006-09-06 Siemens Aktiengesellschaft Integration von MES- und Controls-Engineering
US7664742B2 (en) 2005-11-14 2010-02-16 Pettovello Primo M Index data structure for a peer-to-peer network
US7755646B2 (en) * 2006-10-17 2010-07-13 Hewlett-Packard Development Company, L.P. Image management through lexical representations
AT10302U3 (de) * 2008-08-04 2009-10-15 Avl List Gmbh Erzeugen einer ablauffähigen konfiguration
US20100131916A1 (en) * 2008-11-21 2010-05-27 Uta Prigge Software for modeling business tasks
US8631028B1 (en) 2009-10-29 2014-01-14 Primo M. Pettovello XPath query processing improvements
DE102009054112A1 (de) 2009-11-20 2011-05-26 Kuka Roboter Gmbh Verfahren und Vorrichtung zur Planung und/oder Steuerung einer Roboterapplikation
CN102479348A (zh) * 2010-11-23 2012-05-30 上海宝信软件股份有限公司 面向代码重用的mes业务建模系统及方法
US9588503B2 (en) 2011-11-15 2017-03-07 Rockwell Automation Technologies, Inc. Routing of enterprise resource planning messages
US9953280B2 (en) 2011-11-15 2018-04-24 Rockwell Automation Technologies, Inc. Industry-specific workflows in a manufacturing execution system with premier integration
US9551983B2 (en) 2011-11-15 2017-01-24 Rockwell Automation Technologies, Inc. Activity set management in a Manufacturing Execution System
EP2639753A1 (de) * 2012-03-13 2013-09-18 Siemens Aktiengesellschaft Steuerung eines Herstellungsverfahrens
US10068031B2 (en) 2013-03-15 2018-09-04 Bullet Point Network, L.P. Tabular data manipulation system and method
CN104598211B (zh) * 2013-10-30 2019-05-24 北大方正集团有限公司 管理维护软件程序的方法及装置
WO2015150184A1 (de) * 2014-04-04 2015-10-08 Harting Kgaa Fertigungsmanagementsystem und verfahren
EP3267270B1 (de) * 2016-07-05 2022-01-19 Siemens Aktiengesellschaft Fehlersicheres automatisierungssystem
CN106325242B (zh) * 2016-08-16 2019-09-24 苏州朋泰智能科技有限公司 一种基于模块化的控制单元的mes系统
US10263807B2 (en) * 2016-12-19 2019-04-16 Ciena Corporation Hierarchical statistics acceleration
US10409852B2 (en) 2016-12-30 2019-09-10 Atlassian Pty Ltd Method, apparatus, and computer program product for user-specific contextual integration for a searchable enterprise platform
CN110390185B (zh) * 2018-04-20 2022-08-09 武汉安天信息技术有限责任公司 重打包应用检测方法、规则库构建方法及相关装置

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5410703A (en) 1992-07-01 1995-04-25 Telefonaktiebolaget L M Ericsson System for changing software during computer operation
US5526358A (en) * 1994-08-19 1996-06-11 Peerlogic, Inc. Node management in scalable distributed computing enviroment
US5812394A (en) * 1995-07-21 1998-09-22 Control Systems International Object-oriented computer program, system, and method for developing control schemes for facilities
US5872973A (en) * 1995-10-26 1999-02-16 Viewsoft, Inc. Method for managing dynamic relations between objects in dynamic object-oriented languages
US5862052A (en) * 1996-04-12 1999-01-19 Fisher-Rosemount Systems, Inc. Process control system using a control strategy implemented in a layered hierarchy of control modules
US6351775B1 (en) * 1997-05-30 2002-02-26 International Business Machines Corporation Loading balancing across servers in a computer network
US5983021A (en) * 1998-05-27 1999-11-09 Sun Microsystems Dynamically switching statically bound function calls to dynamically bound function calls without recompilation
IE981057A1 (en) * 1998-06-17 1999-12-29 Tellabs Res Ltd A Telecommunications System Controller Framework
US6427230B1 (en) * 1998-11-09 2002-07-30 Unisys Corporation System and method for defining and managing reusable groups software constructs within an object management system
US6757720B1 (en) * 1999-05-19 2004-06-29 Sun Microsystems, Inc. Profile service architecture
US6785882B1 (en) * 1999-05-24 2004-08-31 Unisys Corporation Process-driven tool interface for an object management system
US6799207B1 (en) * 2000-04-10 2004-09-28 International Business Machines Corporation Method and system for downloading software managed trees in a network processing system
US6832263B2 (en) * 2000-04-27 2004-12-14 Hyperion Solutions Corporation Method and apparatus for implementing a dynamically updated portal page in an enterprise-wide computer system
EP1311980B1 (de) * 2000-05-25 2006-05-24 ManyWorlds, Inc. Netzwerkverwaltungs- und zugriffssystem für unscharfe inhalte
US6675227B1 (en) * 2000-06-05 2004-01-06 International Business Machines Corporation Method for providing a service implementation for both EJB and non-EJB environments
WO2002037261A2 (en) 2000-11-03 2002-05-10 Wilde Technologies Limited A software development process
US20040031015A1 (en) * 2001-05-24 2004-02-12 Conexant Systems, Inc. System and method for manipulation of software
US7246358B2 (en) * 2002-04-09 2007-07-17 Sun Microsystems, Inc. Methods, system and articles of manufacture for providing an extensible serialization framework for an XML based RPC computing environment
US7475384B2 (en) * 2004-10-19 2009-01-06 Microsoft Corporation Binding to types

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO03071417A2 *

Also Published As

Publication number Publication date
CN100397342C (zh) 2008-06-25
DE10206903A1 (de) 2003-09-04
WO2003071417A3 (de) 2005-01-27
US7581226B2 (en) 2009-08-25
US20050160412A1 (en) 2005-07-21
CN1717655A (zh) 2006-01-04
WO2003071417A2 (de) 2003-08-28

Similar Documents

Publication Publication Date Title
WO2003071455A2 (de) Engineeringverfahren und engineeringsystem für industrielle automatisierungssysteme
EP1516250A2 (de) Softwareapplikation, softwarearchitektur und verfahren zur erstellung von softwareapplikationen, insbesondere für mes-systeme
DE102007040823A1 (de) Editier- und Berichts-Tool für Grafische Programmiersprachenobjekte
WO2015044374A1 (de) Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung
EP1917611A2 (de) System für den maschinengestützten entwurf technischer vorrichtungen
EP1561180A2 (de) Vorrichtung und verfahren zur erzeugung eines abarbeitungs-werkzeugs
EP2648094B1 (de) Verfahren und system zum erzeugen eines quellcodes für ein computerprogramm zur ausführung und simulation eines prozesses
EP1634130B1 (de) Vorrichtung und verfahren zur programmierung und/oder ausführung von programmen für industrielle automatisierungssysteme
EP1137972B1 (de) Automatisierungssystem zur lösung einer prozesstechnischen aufgabenstellung und verfahren hierzu
EP1497714A2 (de) System und verfahren zur projektierung von transformationen von objektb umen
DE102008047238A1 (de) Frameworkbasierte Steuerung für Automatisierungssysteme
EP1347376B1 (de) Software zur Visualisierung hierarchisch stufbaren Objekten
EP2479664A1 (de) System und Verfahren zum Erzeugen eines Quellcodes für ein Computerprogramm
WO2004003798A2 (de) Informationserzeugungssystem für die produktentstehung
DE19831651C1 (de) Verfahren zum Erzeugen eines regel- und anpassbaren Netzwerkes von Modellen von Verhaltensmustern einschließlich Software-Systemen
DE102016121788A1 (de) Konfiguration einer Automatisierungsanlage
EP2093663A1 (de) Engineering-System für die Entwicklung eines Projektes und Verfahren
DE102021004346A1 (de) Verfahren zum Aufbau und zur Pflege einer Fahrzeugtypbibliothek
EP4270124A1 (de) Verfahren zum betreiben einer fertigungsanlage, computerprogramm und elektronisch lesbarer datenträger
DE202021106310U1 (de) Computerimplementiertes Prozessmodul
EP1926019A1 (de) Datenaustauschverfahren und Steuerverfahren zwischen Softwarebausteinen sowie wiederverwendbare Softwarebausteine
AT4146U1 (de) System zur entwicklung und planung einer industriellen anlage
DE102010001765A1 (de) Verfahren und System zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur
EP2575034A1 (de) Verfahren für einen Identitätsnachweis zwischen einer Mehrzahl von in einer Baumstruktur organisierten Instanzobjekten und zumindest einem Typobjekt
DE20220657U1 (de) Vorrichtung zur Erzeugung eines Abarbeitungs-Werkzeugs

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040630

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT SE SI SK TR

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20091113