Method and engineering system for configuring and parameterizing fieldbus users

Abstract

The present invention relates to a method for configuring and parameterizing fieldbus users (Ctr, Dev), the fieldbus users being connected to each other via a fieldbus (F), wherein at least one first fieldbus user (Dev) is designed to provide and / or receive process data (IO), and a second fieldbus user (Ctr) is designed to run an application (AP), wherein, in a first step (S1), a topology (Topo) with configuration parameters (CP) of the fieldbus users (Ctr, Dev) is determined in a configuration file (CD) by means of a configuration tool (CT), and in a second step (S2), the first fieldbus user (Dev) is parameterized to subsequently communicate via the fieldbus (F) with at least one configuration data set (Dconf), the configuration data set comprising at least a first part (GDI) of the configuration file (CD), wherein, in a third step (S3), an object-oriented class (class) with elements (E) and functions (f) is generated from the configuration file (CD) originating from a program library (PB) and other code parts (C1, ..., C5) for communication between the second fieldbus user (Ctr) and the first fieldbus user (Dev), wherein, in a fourth step (S4), the class (class) is instantiated in the application (AP) of the second fieldbus user (Ctr), and the function (f) is used for communication when the application (AP) is executed, so as to enable access (Z) to the process data (IO).

Description

Field of the Invention

[0001] The present invention relates to a method for configuring and parameterizing fieldbus users, which are connected to each other via a fieldbus, wherein at least one first fieldbus user is designed to provide and / or receive process data, and a second fieldbus user is designed to run an application program. In a first step, a topology with configuration parameters of the fieldbus users is determined in a configuration file using a configuration tool. In a second step, the first fieldbus user is parameterized to subsequently communicate via the fieldbus with at least one configuration data set, which includes at least a first part of the configuration file.

[0002] The present invention further relates to an engineering station for configuring and parameterizing fieldbus users, which are connected to each other via a fieldbus, wherein at least one first fieldbus user is designed to provide and / or receive process data, and a second fieldbus user is designed to run an application program. The engineering station includes: a configuration tool, which is designed to determine a topology with configuration parameters of the fieldbus users in an editor using a configuration file; a parameterization tool, which is designed to parameterize and load the first fieldbus user to subsequently communicate via the fieldbus with at least one configuration data set, which includes at least a first part of the configuration file. Background Art

[0003] An engineering system for parameterizing automation components is known from EP 1 752 896 B1.

[0004] EP 2 482 148 B1 also describes a method for planning and / or programming a multifunctional component of an industrial automation device.

[0005] US 6 473 824 B1 shows a method for configuring and parameterizing fieldbus users, wherein a user-oriented method is used.

[0006] DE 10 2015 108 053 A1 shows a method for automatically detecting the topology of a fieldbus network.

[0007] US 6 449 715 B1 discloses a method and a system for configuring fieldbus (Profibus) devices.

[0008] For example, the TIA Portal of Siemens AG is also known as the engineering station. The TIA Portal is an automation framework for the CPU series of Simatic SPS. "TIA" stands for "Total Integrated Automation". In the TIA Portal, all necessary software tools are integrated in the user interface. The TIA Portal enables full access from digital planning to transparent operation via integrated engineering across the entire digitalized automation plant. System integrators, machine manufacturers, and plant operators all benefit from the demonstrated feasibility. Therefore, the TIA Portal is the perfect way to access automation plants in the digitalized automation world.

[0009] Using the TIA Portal, a plant can be planned, which includes configuration and parameterization, as well as programming and control of, for example, distributed peripheral systems. Of course, it is felt to be disadvantageous that, for example, if only a small plant is to be configured or parameterized, the TIA Portal describes software components that are too powerful and are too demanding, especially for inexperienced commissioning engineers, for a "small" solution. Summary of the Invention

[0010] Therefore, the object of the present invention is to provide a solution, in particular a solution for parameterizing decentralized peripheral devices, which simplifies parameterization, configuration, and subsequent commissioning.

[0011] This object is achieved by the features of the present invention. A third step is performed after the described first step and the described second step, wherein an object-oriented class with elements and functions for communication between a second fieldbus user and a first fieldbus user is generated from a configuration file and other code portions originating from a program library, and wherein, in a subsequent fourth step, the class is instantiated in the application of the second fieldbus user, and the functions are used for communication when the application is executed, thereby enabling access to process data. Thus, the class represents a small "code snippet" that can be easily embedded in the application and instantiated using corresponding O++ commands.

[0012] Particularly in the parameterization of Profinet fieldbus users, the fieldbus users are divided into at least two of the following types, namely the IO controller type and the IO device type. Among them, the IO controller type is the type of device that undertakes control tasks and runs application programs therein, and the IO device type is the type of device that receives data from the industrial process or outputs data to the industrial process as a field device, where the device is controlled by a device of the IO controller type. Among them, the existing fieldbus is used to build a mesh network architecture with multiple such devices, and a configuration tool is used to determine the mesh network topology with configuration parameters of the fieldbus users in the network configuration file, and among them, the generation of classes is divided into the generation of server classes and the generation of client classes, and two classes are instantiated in the application program in the fieldbus users of the IO controller type, and at least the server class is instantiated in the fieldbus users of the IO device type. Among them, when the corresponding application program is executed in the corresponding fieldbus user, two-way communication between the fieldbus users of the IO controller type is now also performed through the additional server class and the additional client class, so that the "cross-traffic" between the controllers becomes feasible. Fully networked, that is, each talking to each, thus simply parameterizing for the existing Ethernet network. Therefore, a novel network architecture is obtained, which is particularly related to the communication and parameterization feasibility of the scattered peripheral users so far. In principle, the smart grid is now feasible for the communication connections of all users in the fieldbus system.

[0013] It has proven advantageous for generating object-oriented classes with elements and functions that: the first source code part includes code and compilation options for operating different second fieldbus users, where the second fieldbus users are designed as target platforms with different hardware specifications; the second source code part includes code for the interface description of the first fieldbus user; the third source code part includes code for the interface description of the IO mapping class of the first fieldbus user; the fourth source code part includes code for the description of the device type, IO module type, or IO sub-module type in the association between the configuration or parameterization of all fieldbus users and the above-mentioned code parts; the fifth source code part includes code for the description of different protocol tags for different types of fieldbus communication.

[0014] The previously described code portions preferably derive their configuration parameters from the device master data files for the respective fieldbus users. "GSD" or "GSD file" also means an XML-based form. Based on the GSD file, with the introduction of GSDML (General Station Description Markup Language), the XML-based document can form the characteristics of an arbitrary hierarchical structure, which is used to map the hierarchical device model. The GSD file or GSDML schema file is created, maintained by the PNO (Profinet User Organization) working group, and provided for download via the PNO web server. Preferably, the existing GSDML file can be supplemented with information for code generation by means of the present invention, from which a GSDSMLe, i.e., an extended file, is generated, which is extended to class C for communication.

[0015] Preferably, the embedding and instantiation of the generated program code are performed by means of a software development environment. The software development environment is also referred to as an integrated development environment (IDE). For example, Eclipse can be used as a feasible software development environment. Eclipse is an open-source programming tool for developing various types of software. Initially, Eclipse was used as an integrated development environment (IDE) for the Java programming language, but due to its scalability, it is now also used for many other development tasks. That is, for example, here it is used to embed and instantiate the generated program code into the corresponding fieldbus users with a running application.

[0016] According to this method, it is also advantageous that: when determining the topology (topo), on the one hand, the parallel and independent access of at least two different fieldbus users of the IO controller type to the process data of the same fieldbus user of the IO device type is considered, and on the other hand, the free allocation of the process data of any fieldbus user of the IO device type to the fieldbus user of the IO controller type is considered, and a network configuration file is formed from the consideration and determination (configuration), and server classes and client classes with corresponding access rights and access paths are generated by means of the network configuration file.

[0017] In terms of programming techniques, it has proven advantageous that: for the generated classes or when generating subclasses, the following structural and performance characteristics are generated for the classes, where the classes are preferably shown in C++ notation:

[0018] Class: User Interface

[0019] The user interface is available at least once for each fieldbus user. The user interface includes all access feasibility to the IO modules / submodules of the fieldbus user, including functions that allow access via clear symbols across the entire station or via module slot positions as a whole or also at bit granularity, and where a link to the runner can also be executed.

[0020] Class: IO-mapped user interface

[0021] The user interface is available at least once for each fieldbus user and includes the address data of the fieldbus user, and the user interface controls the data exchange between the user interface class and the communication stack class.

[0022] Class: Communication stack

[0023] The communication stack performs calls to the functions or communication methods of the protocol stack, thereby undertaking the communication construction with the fieldbus user.

[0024] Class: Network stack

[0025] The network stack is generated once for each fieldbus and can be used equally by all the above classes, preferably capable of embedding other communication stack classes therein.

[0026] Another class to be considered is the analog class.

[0027] The class is available once for each fieldbus device type / IO module type / sub-module type. The class includes the behavior of each fieldbus device type / IO module type / sub-module type. In the fieldbus network / route, for example, the PWM function or cam function of the DQ component or the simple on / off operation at the terminals of the IO module. The analog class replaces the use of the user interface class for IO mapping and the communication stack class for analog user data and terminal values. The analog class is combined upward with the user interface class. The analog class is combined downward with the process simulation environment to be provided by the user.

[0028] The object mentioned at the beginning is also achieved by an engineering station for configuring and parameterizing fieldbus users, which are connected to each other via a fieldbus. Here, according to the invention, the engineering station includes, in addition to the already known configuration tools and known parameterization tools, a program code generator, which is designed to generate object-oriented classes with elements and functions for the communication between a second fieldbus user and a first fieldbus user from a configuration file and other code parts originating from a program library, wherein an installation tool is also provided, which is designed to instantiate the class in the application program of the second fieldbus user, so that the function is used for communication when the application program is executed, and access to the process data is achieved through this communication.

[0029] In an engineering station, the program library has at least one of the following source code parts: a first source code part, the first source code part including code and compilation options for operating different second fieldbus users, wherein the second fieldbus users are designed as target platforms with different hardware specifications; a second source code part, the second source code part including code for the interface description of a first fieldbus user; a third source code part, the third source code part including code for the interface description of the IO mapping class of a first fieldbus user; a fourth source code part, the fourth source code part including code for the description of device types, IO module types or IO sub-module types in the association between the configuration or parameterization of all fieldbus users and the above-mentioned code parts; a fifth source code part, the fifth source code part including code for the description of different protocol stacks for different types of fieldbus communication.

[0030] It is also regarded as particularly advantageous that there is now a source code part that describes a fieldbus user. If the fieldbus user is designed as a target platform with different hardware specifications, for example, fieldbus users of the Siemens brand such as IoT 2040, traditional PCs, single-board computers, Arduino, or any hardware components for communication in the fieldbus can be trained according to the generated program parts or generated C++ classes to communicate at the fieldbus.

[0031] It is advantageous for the engineering station that the program library includes device master data files for each fieldbus user, and the device master data files describe the unique communication characteristics of the fieldbus users.

[0032] The engineering station is designed to parameterize and configure fieldbus users of the IO controller type or IO device type. Brief Description of the Drawings

[0033] The method according to the present invention and an embodiment of the engineering station according to the present invention will be explained in more detail below with reference to the drawings. Shown here are:

[0034] Figure 1 A schematic flow chart showing method steps,

[0035] Figure 2 A block diagram showing the operation of the method and the parameterization of fieldbus users,

[0036] Figure 3 Showing the principle of the parameterization process in the case of using different target platforms and adding server-client functions,

[0037] Figure 4 Showing the construction of a mesh network architecture of a large number of fieldbus users, wherein the network has a mesh network topology,

[0038] Figure 5 Shows the basic structure of the GSD file, and

[0039] Figure 6 shows the structure of a modular field device with its affiliated modules. Detailed implementation mode

[0040] According to Figure 1 shows the method flow for configuring and parameterizing fieldbus users Ctr, Dev (see Figure 2 ). With the aid of the configuration tool CT (see Figure 2 ), in the first step S1, the topology Topo of the configuration parameters CP with fieldbus users Ctr, Dev is determined in the configuration file CT by means of the configuration tool CT. The configuration tool CT understands the structure of the fieldbus users Ctr, Dev with the aid of the first device master data file GSD1, the second device master data file GSD2 and the third device master data file GSD3.

[0041] In the second step S2, the first fieldbus user Dev is parameterized to subsequently communicate via the fieldbus F with at least one configuration data set D conf , where the configuration data set includes at least one first part CD1 of the configuration file CD. The specific configuration data set D for the first fieldbus user Dev conf is loaded into the first fieldbus user Dev via the download DL.

[0042] In the third step S3, an object-oriented class Clas with elements E and functions F is generated from other code parts C1, C2, C3, C4, C5 from the program library PB and the configuration file CD for communication between the second fieldbus user Ctr and the first fieldbus user Dev. In the third step S3, the program code generator PCG generates the generation code G, which is designed to generate an object-oriented class Class with elements E and functions F from other code parts C1,..., C5 from the program library PB and the configuration file CD for generating communication between fieldbus users.

[0043] In the fourth step S4, the class Class is instantiated in the application program AP of the second fieldbus user Ctr, and the function F is used for communication when the application program AP is executed, thereby enabling access Z to the process data IO. For example, in order to instantiate the class, the C++ command "newclass" is called in the application program.

[0044] Figure 2A block diagram showing the generation of an object-oriented class Class by means of a program code generator PCG, wherein the program code generator PCG becomes active only when, by means of a configuration tool CT, the topology Topo of configuration parameters CP having fieldbus users Ctr, Dev has been determined in a configuration file CD. In the case of using a program library PB and different device master data files GSD1, GSD2, the future topology Topo and configuration of the fieldbus users Ctr, Devl, Dev2 are determined. The configuration file CD includes a first source code section C1, a second source code section C2, a third source code section C3, a fifth source code section C4, and a fourth source code section C5. From the source code sections C1, ..., C5 and the configuration file CD, the program code generator PCG generates generated code G including the class Class.

[0045] The first source code section C1 includes code and compilation options for operating different second fieldbus users Ctr, where the second fieldbus users Ctr can have completely different hardware specifications as the target platform. The second source code section C2 includes an interface description of the first fieldbus device Dev. The third source code section C3 includes an interface description of the IO mapping class of the first fieldbus device Dev. The fourth source code section C4 includes code for describing the association between the configuration or parameterization of all fieldbus users Ctr, Dev and the above-mentioned code sections, regarding the device type, IO module type, or IO sub-module type. The fifth source code section C5 includes descriptions of different protocol stacks for different types of fieldbus communication.

[0046] The generated code G or the class Class is embedded into the application program AP of the fieldbus user Ctr via the loading 21 of the generated code G. The configuration data set D conf is loaded into the fieldbus user Devl via the download 20.

[0047] Since the class that particularly implements the communication function has now been instantiated and run in the application program AP, the communication between the two fieldbus users Ctr and Devl can be achieved by accessing the process data IO Z.

[0048] According to Figure 3Shows a configuration of an extended fieldbus F with different fieldbus users Ctr. The special feature of this configuration is that there are now two types of fieldbus users Ctr, Dev. The first type is the IO controller type, and the second type is the IO device type. The IO controller type is the type of device that undertakes control tasks and runs the application program AP therein. Therefore, there are a programmable logic controller CPU with a first application program API, a personal computer PC with a second application program AP2, a microprocessor μP (single-board computer, such as Arduino) with a third application program AP3, and an arbitrary hardware component AHB (any hardware) with a fourth application program AP4.

[0049] The second type of device, i.e., the IO device type, is the type of device that receives industrial data IO from the industrial process as a field device or outputs data to the industrial process, where the device is controlled by the device of the IO controller type. The mentioned field devices are designed as a first interface module IM1, a second interface module IM2, and a third interface module IM3. The interface modules IM1, IM2, IM3 are designed as decentralized peripheral field devices, and the peripheral field devices have input / output modules and sub-modules for process data IO.

[0050] Through a special type formed by classes, i.e., a mesh network topology Masch-Topo with configuration parameters CP of fieldbus users Ctr, Dev, can now be determined in the network configuration file mCD using a configuration tool CT (see Figure 4 ). And by extension, the generation of classes Class is divided into the generation of server classes SC and the generation of client classes CC, and in particular, the two classes SC, CC are instantiated in the fieldbus users of the IO controller type in the application programs AP1,..., AP4. To some extent, networked communication with each user's networking is feasible. Therefore, the fieldbus users of the IO controller type include client functions C and server functions S. The fieldbus users of the IO device type can also obtain client functions C and server functions S respectively, such as seeing the third interface module IM3, but usually only parameterized using the server function S.

[0051] The configuration and parameterization of the programmable logic controller CPU are carried out via the TIA portal TIA, the configuration of the PC is executed with the help of the Windows development environment MSVS, the configuration of the microprocessor μP is carried out with the help of the cross-platform development system ANDST, the configuration of any hardware AHW is carried out with the help of the C++ development environment Ecli, and the configuration of the interface modules IM1, IM2, IM3 is carried out with the help of the multi-functional configuration tool MFCT. The file management tool GIT covers all the mentioned configuration tools or the generated code G therefrom.

[0052] The interface modules IM1, IM2, and IM3 are divided into a first sub-module SM1, a second sub-module SM2, a third sub-module SM3, a fourth sub-module SM4, and a fifth sub-module SM5. The user can now configure the following settings with the aid of a configuration tool. The settings consist of the number and type of IO modules / sub-modules required for their facilities, such as DI8, DI16, DQ8, DQ32, analog input AI or analog output AQ, or special modules TM, MPU, etc. When interacting with the generated classes, the user interface class now allows the user to access the module plug-in positions and their data structures from the application program, such as bits, bytes, words, double words, transmitter structures (e.g., 5-byte IEEE analog values).

[0053] Using Figure 4 The diversity of methods is now shown. Thus, it is now possible for each fieldbus user to communicate with each other. A mesh network topology MaschTopo is constructed using the configuration tool CT. The generation of the network configuration file mCD and the server class SC and client class CC included therein allows for corresponding access paths. Each fieldbus user now has a server class SC and a client class CC.

[0054] Figure 5 The principle structure of the GSD file is shown. The configuration file of the device master data file GSD is determined by the ISO 15745 standard. The configuration file Hader is equipped with a Profinet device configuration file and specifications. The configuration file body includes the actual data of the field device and is divided into three parts. The device identification includes information for identifying the field device, and the device function includes data describing the function. The application process is the main part of the description file and the "ApplicationProcess". This is the main part of the description file. The following subsections list the most important sections in the application process block.

[0055] Device Access Point List

[0056] The sections include descriptions of the individual device access points (network access points). As mentioned before, the GSD file can include descriptions for any number of interface modules. Then, the sum of all device access points forms a device series. The degree of expansion of the DAP can be configured in the modular field device. Different modules (components) can be assigned to each DAP.

[0057] Module List

[0058] The sections include descriptions of the individual modules of the field device. The modules can be pluggable (in the case of a modularly constructed field device) or fixedly integrated into the field device.

[0059] Sub-module List

[0060] The section includes descriptions of the individual sub - modules of the field device. The sub - modules can be pluggable (in the case of a modularly constructed field device) or fixedly integrated into the field device.

[0061] Value list

[0062] The section includes a value list for the individual parameters of the field device. In addition to the parameter name, it includes the assignment between the specific values and the associated text.

[0063] Channel diagnostic list

[0064] The section includes a channel diagnostic list. The channel diagnostic list describes the assignment between the channel errors of the field device and the corresponding text.

[0065] Unit diagnostic type list

[0066] The section includes a unit diagnostic type list and describes the structure construction of the general diagnostic messages of the field device.

[0067] Log entry list

[0068] The log entry list describes the meaning of the log entries.

[0069] Graphic list

[0070] The section includes references to graphical representations of the field device.

[0071] Category list

[0072] The section includes the assignment of modules to specific categories (such as digital input, analog output, etc.). The assignment is used for division and better search within the module catalog of the engineering tool.

[0073] External text list

[0074] The section includes the "External text list" of GSDML. Here, all texts that can be referenced by other sections are stored. For more information on this, see the "Foreign language integration" chapter.

[0075] Existing GSD files are usually used, and the files are suitable for the field device itself. For example, the sample files of PNO are the basis. The sample files are attached to the GSDML specification and the Profinet XLM specification.

[0076] Figure 6Specifically shows the construction types of the interface modules IM1, IM2, and IM3. The interface module taking the first interface module IM1 as an example has a fieldbus interface FS. Among them, the first segment of the interface module can be referred to as Slot 0, and then subsequently there are other slots: Slot 1, Slot 2, Slot 3. In the slots, for example, in Slot 1, the sub-slots: SubSlot 1, SubSlot 2, SubSlot 3, SubSlot 4 can be parameterized again. However, Slot 2 can also only include one SubSlot 1, or Slot 3 can only include one SubSlot 4 and one SubSlot 6.

Claims

1. A method for configuring and parameterizing fieldbus users (Ctr, Dev), the fieldbus users being connected to one another via a fieldbus (F), wherein, At least one first fieldbus user (Dev) is designed to provide and / or receive process data (IO), and a second fieldbus user (Ctr) is designed to run an application (AP), where, - In a first step (S1), a topology (Topo) with configuration parameters (CP) of the fieldbus users (Ctr, Dev) is determined in a configuration file (CD) using a configuration tool (CT), and - In a second step (S2), the first fieldbus user (Dev) is parameterized to subsequently communicate via the fieldbus (F) with at least one configuration data set (Dconf), which includes at least a first part (CD1) of the configuration file (CD), - In a third step (S3), an object-oriented class (class) with elements (E) and functions (f) is generated from the configuration file (CD) and other code parts (C1,..., C5) originating from a program library (PB), which is used for communication between the second fieldbus user (Ctr) and the first fieldbus user (Dev), where, - In a fourth step (S4), the class (class) is instantiated in the application (AP) of the second fieldbus user (Ctr), and the function (f) is used for the communication when the application (AP) is executed, thereby enabling access (Z) to the process data (IO), characterized in that the fieldbus users (Ctr, Dev) are divided into two of the following types, IO controller type, for the second fieldbus user (Ctr) and IO device type, for the first fieldbus user (Dev), where, - The IO controller type is the type of device that undertakes control tasks and runs the application (AP) within itself, and - The IO device type is the type of device that receives data from an industrial process or outputs data to an industrial process as a field device, where the device is controlled by a device of the IO controller type, where, - A mesh network topology (Masch-Topo) with the configuration parameters (CP) of the fieldbus users (Ctr, Dev) is determined in a network configuration file (mCD) using the configuration tool (CT), and where, - The generation of the class (class) is divided into the generation of a server class (SC) and the generation of a client class (CC), and - In a device of the IO controller type, two classes (SC, CC) are instantiated in the application (AP), and - In a device of the IO device type, at least the server class (SC) is instantiated.

2. The method according to claim 1, wherein The other code parts (C1,..., C5) include the following source code parts: - A first source code part (C1), the first source code part including code and compilation options for operating different second fieldbus users (Ctr), wherein the second fieldbus users (Ctr) are designed as target platforms with different hardware specifications, - A second source code part (C2), the second source code part including code for the interface description of the first fieldbus user (Dev), - A third source code part (C3), the third source code part including code for the interface description of the IO mapping class of the first fieldbus user (Dev), - A fourth source code part (C4), the fourth source code part including code for the description of device type, IO module type or IO sub-module type in the configuration and parameterization of all fieldbus users (Ctr, Dev), - A fifth source code part (C5), the fifth source code part including code for the description of different protocol stacks for different types of fieldbus communication.

3. The method according to claim 1 or 2, wherein The configuration parameters (CP) are taken from the device master data file (GSD) for each of the fieldbus users (C, D).

4. The method according to claim 1 or 2, wherein The embedding and instantiation of the generated program code (G) are performed by means of a software development environment (IDE).

5. The method according to claim 1 or 2, wherein - An existing fieldbus (F) is used to construct a mesh network architecture of multiple said devices, and wherein, when the corresponding application programs (AP1,..., AP4) are executed in the corresponding fieldbus users (Ctr, Dev), bidirectional communication between the fieldbus users (Ctr, Dev) of the IO controller type is now also performed through an additional server class (SC) and an additional client class (CC).

6. The method according to claim 5, wherein, When determining the topology (topo), on the one hand - Consider the parallel and independent access (Z) of at least two different fieldbus users (Ctr) of the IO controller type to the process data (IO) of the same fieldbus user (Dev) of the IO device type, and on the other hand - Consider the free allocation of the process data (IO) of any fieldbus user (Dev) of the IO device type to the fieldbus user (Ctr) of the IO controller type, and generate the server class (SC) and the client class (CC) with corresponding access rights and access paths by means of the network configuration file.

7. The method according to claim 1 or 2, wherein For the generated class (class) and when generating subclasses, the following structural and performance characteristics are generated for the class: - Class: User interface, the user interface can be used by each fieldbus user (Dev) at least once, the user interface includes all access feasibility to the IO modules / sub-modules of the fieldbus user (Dev), the access feasibility includes functions allowing access via clear symbols across the whole station or access as a whole or also in bit granularity via module slot positions, wherein a link to the runner can also be executed. - Class: IO-mapped user interface, which can be used by each fieldbus user (Dev) at least once, and which includes the address data of the fieldbus user (Dev), and which controls the data exchange between the user interface class and the communication stack class, - Class: Communication stack, which executes calls to the functions or communication methods of the protocol stack, and thus undertakes the communication construction with the fieldbus user (Dev), - Class: Network stack, which is generated once for each fieldbus (F) and can be used equally by all the above classes.

8. The method according to claim 7, wherein The classes are shown in C++ notation.

9. The method according to claim 7, wherein, Other communication stack classes can be embedded in the network stack class.

10. An engineering station for configuring and parameterizing fieldbus users (Ctr, Dev), the fieldbus users being connected to one another via a fieldbus (F), wherein, At least one first fieldbus user (Dev) is designed to provide and / or receive process data (IO), and a second fieldbus user (Ctr) is designed to run an application (AP), where the engineering station has the following tools, Configuration tool (CT), which is designed to determine the topology (Topo) in an editor using the configuration parameters (CP) of the fieldbus users (Ctr, Dev) in the configuration file (CD), Parameterization tool (PT), which is designed to parameterize and load the first fieldbus user (Dev) so as to subsequently communicate with at least one configuration data set (Dconf) via the fieldbus (F), and the configuration data set includes at least a first part (CD1) of the configuration file (CD), Program code generator (PCG), which is designed to generate an object-oriented class (class) with elements (E) and functions (f) from the configuration file (CD) originating from the program library (PB) and other code parts (C1,..., C5), and the class is used for the communication between the second fieldbus user (Ctr) and the first fieldbus user (Dev), where, An installation tool (S4) is also provided, which is designed to instantiate the class (class) in the application (AP) of the second fieldbus user (C), so that the function (f) is used for the communication when the application (AP) is executed, and through this communication, access (Z) to the process data (IO) is achieved, and the fieldbus users (Ctr, Dev) are divided into two types among the following types, IO controller type, for the second fieldbus user (Ctr), IO device type, for the first fieldbus user (Dev), where, - The IO controller type is the type of device that undertakes control tasks and runs the application (AP) in itself, and - The IO device type is the type of device that receives data from the industrial process or outputs data to the industrial process as a field device, and the device is controlled by the device of the IO controller type, where, The configuration tool (CT) is configured to determine a mesh network topology (Masch-Topo) in the network configuration file (mCD) using the configuration parameters (CP) of the fieldbus users (Ctr, Dev), and it is provided that, the generation of the class is divided into the generation of the server class (SC) and the generation of the client class (CC), in a device of the IO controller type, two classes (SC, CC) are instantiated in the application (AP), and in a device of the IO device type, at least the server class (SC) is instantiated.

11. The engineering station according to claim 10, wherein, The library (PB) includes at least one of the following source code parts (C1, C2, C3, C4): - A first source code part (C1), which includes code and compilation options for operating different second fieldbus users (Ctr), where the second fieldbus users (Ctr) are designed as target platforms with different hardware specifications, - A second source code part (C2), which includes code for the interface description of the first fieldbus user (Dev), - A third source code part (C3), which includes code for the interface description of the IO mapping class of the first fieldbus user (Dev), - A fourth source code part (C4), which includes code for the description of the device type, IO module type, or IO sub-module type in connection with the configuration or parameterization of all fieldbus users (Ctr, Dev) and the above-mentioned code parts, - A fifth source code part (C5), which includes code for the description of different protocol stacks for different types of fieldbus communication.

12. The engineering station according to claim 10 or 11, wherein, The library (PB) includes device main data files (GSD) for each of the fieldbus users (C, D), which describe the specific communication characteristics of the fieldbus users.

13. The engineering station according to claim 10 or 11, which is designed for parameterizing and configuring the fieldbus users (Ctr, Dev) of the IO controller type or the IO device type.

Images