Connection of interfaces and / or data points of application programs
Patent Information
- Authority / Receiving Office
- EP · EP
- Patent Type
- Applications
- Current Assignee / Owner
- SIEMENS SCHWEIZ AG
- Filing Date
- 2024-07-05
- Publication Date
- 2026-05-27
AI Technical Summary
The planning and commissioning of building automation systems, such as HVAC systems, are hindered by the lack of a model that allows for automatic coordination of functions and devices across different communication technologies, leading to high engineering and configuration efforts due to manual data point mapping and limited communication technology independence.
A computer-implemented method automatically links logical output data points of one application program with logical input data points of another by enriching data points with semantic information, using context data and a rules engine to evaluate and assign these points for data exchange, adhering to standards like DIN EN50090-6-2 for semantic ontology.
This approach significantly reduces the planning and engineering effort by enabling automatic data point linking and configuration across diverse communication technologies, enhancing reliability and efficiency in building automation systems.
Smart Images

Figure EP2024068976_23012025_PF_FP_ABST
Abstract
Description
[0001] LINKING INTERFACES AND / OR DATA POINTS OF APPLICATION PROGRAMS
[0002] The invention relates to a computer-implemented method for automatically linking logical output data points of a first application program with logical input data points of a second application program for data exchange. Furthermore, the invention relates to a computer program and a computer-readable storage medium containing instructions which, when executed by a computer, cause the computer to execute the method. Furthermore, the invention relates to a data processing device and a commissioning tool for implementing the method.
[0003] The invention particularly relates to the planning and commissioning phase of HVAC systems in buildings. For example, in building automation, HVAC systems are controlled and automated using flexible application functions that run in programmable controllers and interact with sensors, actuators, and other devices.
[0004] In the past, the planning of building services (e.g., HVAC functionality) or building automation typically involved manual assignment and binding of the provided data points for each instance. In particular, the assignment or mapping of addresses is usually done manually.
[0005] In conventional systems, the linking of identifiers or unique names between consumers and producers is partly carried out by discovery and instance ID mapping.
[0006] A conventional KNX application and group architecture allows functions to be bound to devices by assigning group addresses. However, the intended binding is only covered at the execution and instance levels and is not communication technology-independent.
[0007] Runtime models such as OPC UA platforms cover some aspects of an interworking platform that supports multiple communication paradigms and technology stacks, but they do not provide a common model that describes how functions and devices work together and that can also be used on a template basis.
[0008] The planning and design effort for a building is high, especially since a model that allows functions and devices of the building services to be automatically coordinated is still lacking. Devices that provide data points and functions that provide and consume data points, which can be based on different communication technologies (IO, fieldbus, HTTP, CoAP, etc.), are therefore difficult to configure and commission.
[0009] The object of the present invention is to provide a method and corresponding data processing means which significantly reduce the planning and engineering effort for the engineering and commissioning of the building equipment of a building or a building automation system.
[0010] The problem is solved by a computer-implemented method for automatically linking logical output data points of a first application program with logical input data points of a second application program for data exchange, wherein the output data points and the input data points are each provided with corresponding semantic information; wherein the output data points of the first application program are assigned to the respectively associated input data points of the second application program by evaluating the semantic information; and wherein output data points of the first application program are data-linked to the input data points of the second application program for data exchange. The method can be used in particular during the planning and / or commissioning phase of an automation system, for example in a building.Data points are enriched with semantic information, e.g., by assigning tags, attributes, or metadata. The semantic information includes, for example, information about the functionality to be achieved or the context of devices or application programs. The semantic information is evaluated by suitable software (e.g., an analysis or rules engine) to automatically link interfaces or to automatically link output data points with input data points of corresponding application programs.
[0011] A data point is a unit / quantity of information (e.g. measured value, temperature value, humidity). In a statistical or analytical context, a data point is usually derived from a measurement or investigation and can be displayed or represented numerically and / or graphically. Data points can be physical and logical (virtual). Physical (or real) data points refer to digital or analog inputs and outputs of a directly connected system. Here, hardware inputs / outputs are occupied or directly connected.
[0012] Logical (virtual) data points are software-based and are sometimes referred to as fictitious data points. They are the result of processing or describe the setup of a system or a device in another system. Examples are calculated values, operating hour counters, event counters, command outputs, setpoint outputs, etc. A virtual data point is a type of calculated data point that is created from one or more current or real data points. Virtual data points can be used, for example, as a substitute for the actual sensor data when the real sensor data is not available for a particular application. Virtual data points can be calculated or derived from one or more current data points (e.g. real time series values).
[0013] A "thing description" can be used as a possible form of describing semantic information. A "thing description" describes the interfaces and their metadata of an aspect of a system. An aspect is an abstraction of a physical or virtual entity. A physical entity can be a sensor or actuator, or a virtual entity can be a functionality of the system.
[0014] Logical input data points and logical output data points represent interfaces that interact during runtime of the corresponding application programs. Logical data points are, for example, point interfaces according to DIN standard EN50090-6-2.
[0015] A first advantageous embodiment of the invention is that the semantic information comprises: information about the functionality of the application functions and / or the application programs and / or semantic information about the interface of the application functions and / or the application programs. For example, which function blocks of an application program are required for a specific HVAC functionality; on which controller are the required function blocks hosted; can an interface be controlled directly or are converters required?
[0016] A further advantageous embodiment of the invention is that, for the assignment of the output data points of the first application program to the respective corresponding input data points of the second application program, context data of the data points is also evaluated. Semantic context assignment thus automatically links data points. Application programs can, for example, be implemented using respective function blocks.
[0017] A further advantageous embodiment of the invention is that the context data defines the context in which a respective data point is located. A context can, for example, be that the data points are located in the same local environment (e.g., location, room, corridor). However, a context can also represent a functionality or a functional relationship (e.g., heat control or ventilation control).
[0018] A further advantageous embodiment of the invention is that the context data comprise aspect information and / or location positions (e.g. room, corridor, floor) and / or functionality (heating, ventilation, cooling) and / or device information (actuator, sensor, or combination device (actuator and sensor)).
[0019] A further advantageous embodiment of the invention is that the context data comprises one or more of the following information: EquipmentType and / or Locality and / or LocationUsage and / or Origin and / or PhenomenonType and / or PointFunctionType and / or PointInterface and / or PointOperation and / or QuantityKind and / or StateType and / or Trade. The more context data or information is available, the more secure and reliable an automatic linking of logical output data points of a first application program with logical input data points of a second application program for data exchange is possible.
[0020] A further advantageous embodiment of the invention is that the semantic information and context data are defined according to DIN standard EN50090-6-2. DIN EN50090-6-2 is a standard for electrical systems engineering for homes and buildings (HBES). Part 6-2 describes, among other things, a semantic ontology model for IoT (Internet of Things).
[0021] A further advantageous embodiment of the invention is that the evaluation of the semantic information and the context data is carried out by an analysis engine, in particular a rules engine. The evaluation of the semantic information and the context data, as well as the assignment (linking) of logical output data points to logical input data points, is advantageously carried out by a suitable analysis engine or a rules engine. The services of the analysis engine or rules engine are advantageously provided by an appropriately configured server or by a corresponding cloud infrastructure.
[0022] Further advantageous embodiments of the invention lie in a computer program and a computer-readable storage medium, each containing instructions which, when executed by a computer, cause the computer to carry out the method according to the invention. The computer (e.g. server, controller) is equipped for this purpose with corresponding hardware (processor, memory, input / output means, communication means) and software. Further advantageous embodiments of the invention lie in a data processing device and a commissioning tool, each set up to carry out the method according to the invention. The data processing device and the commissioning tool are equipped for this purpose with corresponding hardware (processor, memory, input / output means, communication means) and software.
[0023] The invention and advantageous embodiments of the present invention are explained using the example of the following figure. It shows:
[0024] FIG 1 shows a first example of a link between logical output data points of a first application program or a function block and logical input data points of a second application program or a function block for data exchange,
[0025] FIG 2 shows a second example of a link between logical output data points of a first application program and logical input data points of a second application program for data exchange, and
[0026] FIG 3 shows an exemplary flow chart for a method for automatically linking logical output data points of a first application program with logical input data points of a second application program for data exchange.
[0027] Figure 1 shows a first example of linking logical output data points of a first application program API with logical input data points of a second application program AP2 for data exchange. The application programs API and AP2 are each assigned to technical devices G1, G2 for an automation system (e.g., for implementing HVAC functionality).
[0028] The example device Gl (Device) comprises the first application program API. The first application program API is implemented, for example, with a single function block (FunctionalBlock). The first application program API comprises an input interface Einl (Inputs) and an output interface Ausl (Outputs). The input interface Einl comprises the logical data point PI (as input data point). The logical data point PI is set up to receive logical parameters (Logical Parameter), logical inputs (Logical Input) and sensor data (from a sensor S) via a hardwired input / output interface (Hardwired I / O). The example device Gl (Device) is a combination device (actuator and sensor).
[0029] The output interface Ausl includes the logical data point P2 (as an output data point). The logical data point P2 is configured to output logical diagnostic data (Logical Diagnostic), logical outputs (Logical Output), and commands (to an actuator A) via a hardwired input / output interface (Hardwired I / O).
[0030] The example device G2 (Device) is an actuator. The example device G2 (Device) includes the second application program AP2. The second application program AP2 can also be implemented, for example, with just one function block (FunctionalBlock). The second application program AP2 includes an input interface Ein2 (Inputs) with the logical data point P3. The logical data point P3 is configured to receive I / O operations sent from data point P2 of the application program API. The I / O operation is assigned from data point P2 of the application program API to data point P3 of the application program AP2 via a data link DTV.
[0031] The data linking DTV is carried out by a computer-implemented method for automatically linking logical output data points P2 of a first application program API with logical input data points P3 of a second application program AP2 for data exchange (e.g. I / O operation), wherein the output data points P2 and the input data points P3 are each provided with corresponding semantic information; wherein by evaluating the semantic information the output data points P2 of the first application program API are assigned to the respectively associated input data points P3 of the second application program AP2; wherein output data points P2 of the first application program API are linked to the input data points P3 of the second application program AP2 for data exchange in terms of data technology (DTV).
[0032] It is advantageous to use a "thing description" to describe the semantic information. A thing description describes the metadata and interfaces of things, where a thing is an abstraction of a physical or virtual entity that enables or participates in interactions with the Web of Things.
[0033] Logical input data points and logical output data points represent interfaces that interact during runtime of the corresponding application programs. Logical data points are, for example, point interfaces according to DIN standard EN50090-6-2.
[0034] A first advantageous embodiment of the invention is that the semantic information comprises: information about the functionality of the application function or the application programs (e.g. which function blocks or data points are required for a specific HVAC functionality; on which controller are the required function blocks or the application programs hosted) and / or semantic information about the interface (can an interface be controlled directly or are converters required) of the function blocks or the application programs.
[0035] A further advantageous embodiment of the invention is that, for the assignment of the output data points of the first application program to the corresponding input data points of the second application program, context data of the data points is also evaluated. Semantic context assignment thus automatically links data points.
[0036] A further advantageous embodiment of the invention is that the context data defines the context in which a respective data point is located. A context can, for example, be that the data points are located in the same local environment (e.g., location, room, corridor). However, a context can also represent a functionality or a functional relationship (e.g., heat control or ventilation control).
[0037] A further advantageous embodiment of the invention is that the context data comprise aspect information and / or location positions (e.g. room, corridor, floor) and / or functionality (heating, ventilation, cooling) and / or device information (actuator, sensor, or combination device (actuator and sensor)).
[0038] A further advantageous embodiment of the invention is that the context data comprises one or more of the following information: EquipmentType and / or Locality and / or LocationUsage and / or Origin and / or PhenomenonType and / or PointFunctionType and / or PointInterface and / or PointOperation and / or QuantityKind and / or StateType and / or Trade. The more context data or information is available, the more secure and reliable an automatic linking of logical output data points of a first application program with logical input data points of a second application program for data exchange is possible.
[0039] A further advantageous embodiment of the invention is that the semantic information and context data are defined according to DIN standard EN50090-6-2. DIN EN50090-6-2 is a standard for electrical systems engineering for homes and buildings (HBES). Part 6-2 describes, among other things, a semantic ontology model for IoT (Internet of Things).
[0040] A further advantageous embodiment of the invention is that the evaluation of the semantic information and the context data is carried out by an analysis engine, in particular a rules engine. The evaluation of the semantic information and the context data, as well as the assignment (linking) of logical output data points to logical input data points, is advantageously carried out by a suitable analysis engine or a rules engine. The services of the analysis engine or rules engine are advantageously provided by an appropriately configured server or by a corresponding cloud infrastructure.
[0041] The present invention solves the problem of automatically connecting points (e.g., interfaces or data points) to one another using data technology (e.g., I / O operations) based on semantic information at the points. Advantageously, the semantic information also allows the connection between the points in the context of an aspect or location, etc., to be used for further system analyses.
[0042] The devices Gl, G2 can come from different eco-systems (KNX, OMS, BACnet, Matter, etc.) or they can be manufacturer-specific proprietary data points and yet points or I / O operations can be automatically linked to one another so that they can exchange data.
[0043] It is advantageous to define the semantic information and rules in such a way that linking between points can be reliably established. Alternatively, additional links can be suggested, which may then need to be manually confirmed.
[0044] For data exchange, the inputs and outputs of function blocks are connected to each other.
[0045] Previously, this had to be done either manually or by means of ID mapping (e.g., using mapping tables) using a commissioning tool. The present invention disclosure enables automatic mapping of the inputs and outputs of function blocks for a data connection.
[0046] It is advantageous if the inputs and outputs of the data points have a semantic description that the manufacturer has defined, for example, in a product database for data points or other interfaces for a device type or service.
[0047] The semantic description of data points or interfaces describes the properties of the data point and its interaction with the environment. The concepts according to DIN Standard EN50090-6-2, for example, are used as a basis for the semantic description.
[0048] The DIN standard EN50090-6-2 includes the following basic concepts: o Aspect: An aspect is a general grouping concept of points that reflects a specific view or functionality of the system. An aspect can be, for example, an application function, such as airCtrl, waterCtrl or lightingCtrl, etc. o Location: A location is a physically named geographical location used to identify a position, area or space, e.g. inside or outside a building. o Device: A device can be, for example, any electronic device with a certain amount of computing power that has firmware, optionally with input and output (I / O) ports, an application program that provides a set of points as an interface for the I / O operations, and parameter values that control the behavior of the I / O operations at runtime.o Functionality: A functionality represents a concrete piece of software and a set of interfaces (mainly points) needed to perform a task for which a device or service is designed. A functionality can be implemented, for example, by one or more functional blocks (FunctionalBlocks), etc. o Point: A point is a means of interacting with a functionality of a device or service and provides an interface to data in the system. A point can be implemented, for example, as a simple data point or as an action point with a data structure, etc. o Tag (label, marking, annotation): A tag is information that describes the data or content to which it is assigned. Tags are usually non-hierarchical keywords.o TagSet (set of tags): A TagSet combines different tags in a sentence to express a common concept with a specific semantic meaning.
[0049] Aspect, Location, and Functionality or Device define the context in which the point is located. Points are thus grouped based on a context. Location describes the geographical or Aspect context, and Functionality describes the functional context in which a point is located.
[0050] Tags semantically describe the points or context. This means that aspects, locations, points, etc., can be annotated with semantically defined keywords.
[0051] The DIN standard EN50090-6-2 describes the following tag concepts and tag categories: o EquipmentType: This tag category describes tangible and / or movable devices that can be actively measured or adjusted as part of the control system. o Locality: This tag category describes the location-related context for a measurement or adjustment of a device or an observation / activation of a phenomenon or condition. o Locationusage: This tag category describes the purpose for which a location is used. o Origin: This tag category describes a specific data source for the application of a point, which is used in cases where the input of a point is influenced by a higher-level application control (instead of the general control loop).o PhenomenonType: This tag category describes a phenomenon (including substances) that can only be observed or influenced indirectly as part of the control system. o PointFunctionType: This tag category describes the role of a point in the control loop of an application function. o PointInterface: This tag category describes the interworking interface type of a point at runtime. o PointOperation: This tag category describes how a point value must be interpreted (mathematically or logically) to influence the behavior of the system (e.g. control system for HVAC applications). o QuantityKind: The tag category describes the numerical quantity of the measurement / setting (device) or observation / action (phenomenon). o StateType (state type): This tag category describes certain state types in the control loop of an application function.o Trade (trade, industry): This tag category describes the specific area of application / operation in which a point, an application function or a function point is used.
[0052] TagSets are a collection of several tags to describe points or a context semantically even better.
[0053] The DIN standard EN50090-6-2 describes the following tag set concepts: o OperationKind (Operation Kind): An OperationKind describes how the quantity type value of a particular type of interest from a QualityKind or the state type value is used. An OperationKind expresses various properties from the tag model, each with its semantic meaning:
[0054] - the role in the control loop of an application function (Point-FunctionType),
[0055] - the operation type in the control loop of an application function (PointOperation),
[0056] - the origin in the control loop of an application function (Origin). o QualityKind (Quality Kind): A QualityKind describes a specific "kind of interest" related to a value with a continuous, measurable physical quantity.
[0057] - The value is measured or set by a sensor or an actuator (EquipmentType) that observes or reacts to a specific physical phenomenon (PhenomenonType).
[0058] - The measured, adjusted, observed, or actuated quantity. A generic locality describes the (logical or location-related) context of the device / phenomenon.
[0059] The previously described concepts from EN50090-6-2 are used to advantage for the assignment to a context and for the definition of rules for the automatic connection of data points.
[0060] Examples of context-based rules:
[0061] - At least two data points must be in the same context. A context can be that the data points are in the same location or in the same aspect.
[0062] - If only the location of the data points is known (e.g. via the device location), then the aspect can be filtered per data point based on the possible aspects predefined by the manufacturer.
[0063] - The trade is optional and only needs to match the trade of the aspect if there are still several options or data points and the assignment is therefore not clear (e.g. setpoint for heating or cooling).
[0064] - The functionality (e.g., FunctionBlocks) is optional but necessary if the device has multiple identical points and one or another group of points on a device needs to be assigned to a context. For example, a device may represent multiple room temperature sensors via analog inputs on different points or FunctionBlocks. A functionality or point can be assigned to a context by manual selection.
[0065] Examples of mapping rules between data points ( Point
[0066] Matching Rules ) (Precondition : The points are in the same
[0067] Context ): - In order for linking to be secure, one data point must be a logical input and the other data point must be a logical output (see Point Interface).
[0068] - In order for linking to be secure, the logical input and output must have the same logical or mathematical value content (see PointOperation).
[0069] - In order to make linking safe, the «State Type» must be checked during enumeration (PointOperation) (see StateType) and must be the same.
[0070] - To ensure linking, the "type of interest" or the QualityKind must be the same for numeric types (e.g., absoluteValue or relativeValue). The PhenomenonType or EquipmentType and the Quantity must match. The Locality is optional and only needs to match if there are still multiple options or data points, making the assignment ambiguous.
[0071] Figure 2 shows a second example of linking logical output data points of a first application program with logical input data points of a second application program for data exchange. In the example according to Figure 2, a heating control system for a room (443) is created. Two devices are assigned to the context Conti (emissionCtrl). This means that the function blocks including points (data points) Pointl, Point2 of the respective devices are also automatically assigned to the context Conti. The application (e.g. the commissioning tool) can now link the points Poinl and Point2 with one another based on the semantic information and the defined rules, e.g. according to context rules and / or point matching rules VR. The application (e.g. the commissioning tool) does not use a data point ID (e.g. knx : dpa . 321 .51) but a multitude of semantic information for linking points or for assigning points to a context. A data point ID normally represents a multitude of semantic information. This semantic information is best broken down into its individual components using tags and tag sets. This makes it possible to find potential links or possible alternatives. Either the most important tags match or a link can be found between the input or output. If a clear assignment cannot be made, then at least the user can be given a suggestion as to which links are potentially possible and sensible. With this suggestion, a user (e.g. commissioning engineer) can use a suitable tool to make the assignment manually or complete it very quickly and easily.
[0072] Figure 3 shows an exemplary flowchart for a computer-implemented method for automatically linking logical output data points of a first application program with logical input data points of a second application program for data exchange,
[0073] (VS 1 ) wherein the output data points and the input data points are each provided with corresponding semantic information;
[0074] (VS2 ) whereby, by evaluating the semantic information, the output data points of the first application program are assigned to the respective corresponding input data points of the second application program;
[0075] (VS3) whereby output data points of the first application program are linked to the input data points of the second application program for data exchange. The method can be used in particular during the planning and / or commissioning phase, for example of HVAC systems in a building. Data points are enriched with semantic information, e.g. by assigning tags, attributes or metadata. The semantic information includes, for example, information about the functionality to be achieved or the context of devices or application programs. The semantic information is evaluated by suitable software (e.g. analysis or rules engine) for the automatic linking of interfaces or for the automatic linking of output data points with input data points of corresponding application programs.
[0076] An advantageous embodiment of the invention is that the semantic information comprises: information about the functionality of the application function or the application programs (e.g. which function blocks or data points from an application program are required for a specific HVAC functionality; on which controller are the required function blocks or the application programs hosted) and / or semantic information about the interface (can an interface be controlled directly or are converters required) of the function blocks or the application programs.
[0077] A further advantageous embodiment of the invention is that, in order to assign the output data points of the first application program to the respectively associated input data points of the second application program, context data of the data points is also evaluated. A semantic context assignment thus results in automatic linking of data points. A further advantageous embodiment of the invention is that the context data defines the context in which a respective data point is located. A context can, for example, be that the data points are in the same local environment (e.g. location, room, corridor). A context can, however, also represent a functionality or a functional relationship (e.g. heat control or ventilation control).
[0078] A further advantageous embodiment of the invention is that the context data comprise aspect information and / or location positions (e.g. room, corridor, floor) and / or functionality (heating, ventilation, cooling) and / or device information (actuator, sensor, or combination device (actuator and sensor)).
[0079] A further advantageous embodiment of the invention is that the context data comprises one or more of the following information: EquipmentType and / or Locality and / or LocationUsage and / or Origin and / or PhenomenonType and / or PointFunctionType and / or PointInterface and / or PointOperation and / or QuantityKind and / or StateType and / or Trade. The more context data or information is available, the more secure and reliable an automatic linking of logical output data points of a first application program with logical input data points of a second application program for data exchange is possible.
[0080] A further advantageous embodiment of the invention is that the semantic information and context data are defined according to DIN standard EN50090-6-2. DIN EN50090-6-2 is a standard for electrical systems engineering for homes and buildings (HBES). Part 6-2 describes, among other things, a semantic ontology model for IoT (Internet of Things).
[0081] A further advantageous embodiment of the invention is that the evaluation of the semantic information and the context data is carried out by an analysis engine, in particular a rules engine. The evaluation of the semantic information and the context data, as well as the assignment (linking) of logical output data points to logical input data points, is advantageously carried out by a suitable analysis engine or a rules engine. The services of the analysis engine or rules engine are advantageously provided by an appropriately configured server or by a corresponding cloud infrastructure.
[0082] Further advantageous embodiments of the invention lie in a computer program and a computer-readable storage medium, each containing instructions that, when executed by a computer, cause the computer to carry out the inventive method. The computer (e.g., server, controller) is equipped with appropriate hardware (processor, memory, input / output means, communication means) and software for this purpose.
[0083] Further advantageous embodiments of the invention include a data processing device and a commissioning tool, each configured to implement the method according to the invention. The data processing device and the commissioning tool are equipped with appropriate hardware (processor, memory, input / output means, communication means) and software.
[0084] A further advantageous embodiment of the invention lies in a commissioning tool configured to initiate the method according to the invention. A computer-implemented method and data processing system for automatically linking logical output data points of a first application program with logical input data points of a second application program for data exchange.
[0085] Reference sign
[0086] Pl - P3, Pointl, Point2 data point API, AP2 application program
[0087] Gl, G2 device
[0088] DTV data link
[0089] Input, Input2 input interface
[0090] Output interface S Sensor
[0091] A actuator
[0092] Conti Context
[0093] VR linking rule
[0094] VS1 - VS3 process step
Claims
Patent claims 1. Computer-implemented method for automatically linking logical output data points (P2, Pointl) of a first application program (API) with logical input data points (P3, Point2) of a second application program (AP2) for a data exchange (DTV), (VS1) wherein the output data points (P2, Pointl) and the input data points (P3, Point2) are each provided with corresponding semantic information; (VS2) wherein, by evaluating the semantic information, the output data points (P2, Point1) of the first application program (API) are assigned to the respective associated input data points (P3, Point2) of the second application program (AP2); (VS3) whereby output data points (P2, Pointl) of the first application program (API) are linked to the input data points (P3, Point2) of the second application program (AP2) for data exchange using data technology (DTV).
2. The method according to claim 1, wherein the semantic information comprises: information about the functionality of the application functions and / or the application programs (API, AP2) and / or semantic information about the interface (Inl, In2, Ausl) of the application functions and / or the application programs (API, AP2).
3. Method according to claim 1 or 2, wherein context data (Conti) of the data points are also evaluated for the assignment of the output data points (P2, Pointl) of the first application program (API) to the respectively associated input data points (P3, Point2) of the second application program (AP2).
4. The method according to claim 3, wherein the context data (Conti) defines the context in which a respective data point is located.
5. The method according to one of claims 3 or 4, wherein the context data (Conti) comprises aspect information and / or location positions and / or functionality and / or device information.
6. The method according to one of claims 3 to 5, wherein the context data (Conti) comprise one or more of the following information: EquipmentType and / or Locality and / or LocationUsage and / or Origin and / or PhenomenonType and / or PointFunctionType and / or PointInterface and / or PointOperation and / or QuantityKind and / or StateType and / or Trade.
7. Method according to one of claims 3 to 6, wherein the semantic information and the context data (Conti) are defined according to DIN standard EN50090-6-2.
8. Method according to one of the preceding claims, wherein the evaluation of the semantic information and the context data (Conti) is carried out by an analysis engine, in particular a rules engine.
9. A computer program comprising instructions which, when the computer program is executed by a computer, cause the computer to carry out a method according to any one of claims 1 to 8.
10. A computer-readable storage medium containing instructions which, when executed by a computer, cause the computer to perform a method according to any one of claims 1 to 8.
11. Data processing device configured to carry out a method according to one of claims 1 to 8.
12. Commissioning tool configured to carry out a method according to one of claims 1 to 8.
13. Commissioning tool configured to initiate a method according to one of claims 1 to 8.