DE10112843A1 - Automation data distribution system uses coded datagram for communication between data processing station and automation component - Google Patents

Abstract

The automation data distribution system has a data processing station which is provided with a network address and an automation component (AK) with a network address, which is functionally coupled to the data processing station, with communication between them via a datagram which is fully coded in clear text. Also included are Independent claims for the following; (a) a datagram for use in a system for automation data distribution; (b) an automation data distribution method

Description

BACKGROUND OF THE INVENTION 1. Environment of the invention

The present invention is generally in the field of Factory automation. More precisely, it describes a method for data distribution between applications of factory automation and software applications from the IT area.

2. State of the art in the field of the invention

Have automation technology and business data processing has developed in parallel and relatively independently of one another over the years. since For some time, however, the importance of being transparent and timely Data flow between all aspects and subareas of a company recognized. Factory automation and commercial software applications are included regarded as an integral part of a higher-level data flow process. The Term "Manufacturing Execution System" ("MES") - in German also the Vertical integration term - used to refer to this integration.

MES enables commercial applications directly on Access production data. This is useful for monitoring the Process control: for example for visualization (HMI), alarming, remote maintenance and remote configuration, and for control systems ("SCADA"). It is also suitable MES for the collection and evaluation of process data for planning purposes, for Example in the context of production planning and control systems (PPS / ERP) Manufacturing Management Information Systems (MMI) and for capturing Production data. Finally, there is a growing number of Software applications that work directly with automation components communicate to data from sensors and other external data sources too to capture. Examples include building automation, environmental technology, and Laboratory applications in which no real-time properties are required.  

In summary: MES aims for a more direct, timely data flow between automation components and IT software applications. In many Manufacturing companies can do this Quality improvements are achieved and buffer times are reduced. In the present Competitive environment caused by globalization, buit-to-order Customer specification) and just-in-time production (minimization of storage times) important productivity gains can be achieved.

A trouble-free direct data exchange between the control level (e.g. automation technology applications) and the planning level (for example, business applications) has been practically almost so far impossible because both areas are isolated from each other and for different Purposes were developed. They usually used incompatible with each other Methods and paradigms for data transmission. For example Transmission protocols and media of the control level are not a counterpart on the Planning level. Furthermore, numerous were at the control level mutually incompatible transmission protocols and media uses what a consistent data flow inevitably stands in the way. The traditional one Industrial communication is best served by a variety of manufacturers and device-specific transmission and application protocols characterized (for Example 3946R, RK512, Modbus, IEC870, Mewtocol, AK, MPI, LSV2, Interbus, Devicenet, MSV2), most of which are virtually unknown in the office world are.

The use of industrial protocols for a continuous data flow to Planning level often fails because of a monitoring of the lower Protocol layers are required, however, by modern computer architectures is not supported. For example, the M-Bus protocol (a protocol from the field of telecontrol technology) after receiving a telegram 11-bit pause before a response telegram can be sent. This is with active (buffered) serial interface cards, as they are in today Computers are widely used not to make.

The operational procedures (or paradigms) of control level and Planning levels differ fundamentally. At the control level  sequential processes with query architectures (master / slave) used to create a to achieve deterministic time behavior and thus real-time capability. in the In contrast, software applications from the IT area often use event-driven architectures. The cyclical, sequential program structures, that are used at the control level cannot simply be Common multitasking computers are transferred because they are a large part of the Would require computing power. Accordingly, it is neither useful nor simple for a Windows PC, sensor data several hundred times per second to query what would be required to monitor a sensor. PCs and PC Software are much better suited for event-driven processing of Change data instead of for the continuous cyclical monitoring of Data sources (which is more the domain of programmable logic controllers is).

Most industrial protocols have been narrowly defined Designed for use, d. H. for communication with a specific Type of peripheral device, but not for standardized data exchange between systems of different architecture. Mix also Industry protocols sometimes have multiple layers of the ISO / OSI layer model. This represents a major obstacle to the use of such protocols in office Applications and modern network environments. A protocol that is Spread over several layers of the ISO / OSI model is inflexible and often only difficult to link with other applications and / or transmission media. For example, linking to Office applications would be much easier, if it is "only" about the implementation of different data formats on the higher protocol layers (ISO / OSI layers 6 and 7) and not at the same time also about difficult time behavior on the lower protocol layers (ISO / OSI Layers 4 and below). However, wherever industrial protocols span multiple Extending protocol layers often results in an "all or nothing" situation in which the office application data with the industrial peripheral only over one can exchange complex gateway.

One approach to solving this problem is to use defined software interfaces (APIs, = Application Program Interface,  Software interface between application program and system-related Software modules). This includes numerous software products for access Peripherals via non-standard APIs, DDE servers and OPC servers. The The problem of incompatible communication protocols is caused by abstraction from the concrete data transfer procedures to a higher level - one defined software interface to the application program - encountered. Therefore a software application only needs to call functions from the API to use different peripheral devices to exchange data without worrying about the details to take care of the data transfer. An API-based approach - in particular, if it is network-compatible - is connected to a specific component or Object technology like OLE or ActiveX bound. It is therefore also on certain operating systems tied to the component technology in question support. Another limitation of this approach is that implied Client / server architecture from OPC and DDE, which assumes that a central Software process (the server) with different peripheral devices via fieldbus or serial point-to-point connections.

A problem specific to OPC is its complexity, both in terms of on the familiarization as well as on the implementation. OPC and OLE are only with to implement considerable use of resources in the field device. The Implementation of an OPC server in an embedded system with marketable Microcontrollers are difficult, if not impossible.

Another approach is based on the basic idea, with Ethernet and TCP / IP to use a continuous transport medium for data transmission. Here there are different efforts to use Ethernet as a "fieldbus replacement" propagate and access TCP as the future universal transport protocol on automation components. A fundamental problem with this approach is that TCP is only a transport protocol (but not an application protocol) and not even particularly good for because of its high protocol overhead automation purposes (low data throughput and slow connection establishment / disconnection). In addition, TCP is not packet-oriented, but data stream oriented. For data stream-oriented (also: character-oriented) Protocols can separate a single data structure into multiple packets  Length, where the recipient of the data has the problem Recognize the beginning and end of the data structure. There is at least one more for this higher-level, package-oriented protocol required, but for which neither automation technology is still a standard in the office world has prevailed (approaches include, for example, RFC 1006 and Modbus / TCP). In In practice, such non-standardized protocols are only available above TCP Use OPC server or comparable API solutions. This is a fundamental difference to the Internet: Internet applications do not require that Use a specific API or a specific one Component technology for sending emails or accessing websites. The The difference is that Internet applications are well-defined, simple and use easy-to-implement application protocols that can be found in the Factory automation is currently missing. The changeover also requires one existing communication infrastructure with common field buses and point-to-point Point connections on Ethernet significant investments in hardware, software, Training, commissioning and maintenance.

Another method is to integrate a web server into the Field device (often based on an industrial PC integrated into the field device), which means the field device becomes "Internet-capable". However, this process is not only very expensive, but also has the disadvantage that the HTML used here Document format bad for automated post-processing Software process is suitable.

The oldest method of accessing software Automation components consist of device drivers that have a specific Implement industrial protocol. The device driver can be from Application program used via a proprietary software interface (API) become. The application itself needs little or nothing about what is used Knowing protocol. This was primarily used under DOS, can also be found on Windows and Unix systems. The implementation of the Device drivers usually take the form of a static or dynamic Software library (LIB or DLL) or in the form of software components (ActiveX, VCL). However, there is no API standard for accessing  Automation components. An application programmer who is different Industrial protocols used (to address different devices) must mostly use several different APIs. Device drivers can also be used From a practical point of view, usually only by software developers within themselves programmed applications. Use with existing ones Standard software applications (such as web browsers) or through Non-programmers are practically impossible. Beyond that, this approach is only limited network capability. An API or driver implies a one-to-one connection between an application and a driver or DLL. In conventional Software architectures only work such connections locally, but not via the network. That means that the driver or DLL is on the same machine must run like the application and the automation component as well must be connected directly to this computer. Although some newer APIs and Component technologies (mainly DCOM and CORBA) are able to to call "remote" or "distributed" functions and processes over the network, this happens at the price of increased complexity and proprietary technology (in Case of DCOM). The vast majority of available APIs or driver interfaces (implemented as a DLL or as a DDE server) in the field of factory automation not networkable; which is why the software applications run on the same machine to which the automation component is directly connected. This disadvantageous because applications (especially at the higher levels of Automation pyramid) tend to centralize, whereas Automation components and controls rather for decentralization to tend.

DDE (Dynamic Data Exchange) is a process for Interprocess communication, with which Windows programs interact with each other Can exchange messages. Windows system calls can be used for this to send messages to another application or to send messages from to receive another application. Many software houses offer DDE servers for industrial protocols. Such DDE servers often allow Windows Applications to exchange data with automation components without Knowing details about the transmission protocols and media used. The Problem of incompatible protocols and data formats is caused by a parent  API bypassed the details of data transfer before application hides. DDE servers use a uniform API (the Windows DDE API), which is also supported by numerous existing Windows applications (e.g. Microsoft Excel) is supported. Therefore DDE servers can also be used by non- Programmers. On the other hand, DDE requires the operating system Microsoft Windows and is not network-compatible. In addition, DDE has one low performance and high overhead.

OPC is a further development of the DDE server technology for that industrial environment based on OLE (Object Linking and Embedding). OLE enables Windows applications to exchange data ("objects") with each other exchange, even via network. The architecture of OPC is almost identical with DDE, with the difference that one OPC server is also on another, per TCP / IP network accessible computer can be installed. OPC client and However, servers always run on PCs with the Microsoft Windows operating system. OPC is a complex programming interface with a lot of training.

Efforts have recently been increasing to use Ethernet as a "better fieldbus" or "fieldbus replacement" in industrial automation. This is due to the The fact that Ethernet is the dominant transmission medium in the field of Office communication is, and components at affordable prices from a variety of Providers can be obtained. In addition, Ethernet supports higher Transmission speeds than conventional fieldbuses and enables one easy internet access.

The Ludwigsburg company Jetter AG then has a new one Control concept developed which Ethernet and TCP / IP for data exchange used throughout the company, right down to the field device in the production facility. However, this concept requires the exchange of existing machines and Automation components that do not have an Ethernet interface. The resulting network is powered by switches and high-speed Ethernet almost real-time capable, although strictly speaking not because of its Ethernet deterministic protocol architecture is not suitable for real-time applications. During industrial automation usually in the form of a hierarchical Architecture is represented ("automation pyramid") is the Jetter model  flat and without different hierarchical levels. There are no isolated ones Automation cells more, because the control is carried out centrally and not decentralized from PLCs. The software used for control does not run on one local PLC, but on a server in the network. Limitations of this The solution is: Existing control and communication hardware must be replaced by the hardware of a single manufacturer; a standard Application protocol (ISO / OSI layer 7) is not specified, so the Application layer is proprietary; thus there are only proprietary ones, not standardized transitions into commercial data processing.

SUMMARY OF THE INVENTION

The present invention avoids the disadvantages of current state of the art using a system and method for automated data exchange between control level and planning level. there The present invention retains the hierarchical model of factory automation ("Automation pyramid"), which has proven itself in many thousands of installations has at. Implementations of the present invention also fit existing standardized software interfaces. Implementations of the The present invention can be used on numerous operating systems and in field devices be made without the resources of a Windows PC required are. Furthermore, the present invention can be used different transmission media and protocols can be implemented.

In certain respects, the present invention can be a system for Distribution of automation data (Automation Data Distribution, abbreviated Embody ADD), consisting of a data processing station (DS) with a Network address, and an automation component (AK) with a Network address, functionally linked to the DS; where DS and AK are configured are that they are related to each other by using one or more transactions communicate, said transaction consisting of a datagram which is completely and coded in plain text. In this implementation, the Datagrams also contain a source attribute, which is the network address of the sender of the datagram specifies a target attribute which the Contains network address of the intended recipient of this datagram, and / or  a value attribute with a corresponding unit attribute, which the Specifies the unit of measurement of the value attribute. In addition, datagrams can be a or contain multiple security attributes (including but not limited to an attribute for a digital signature and / or an attribute for an expiry date or "expiry date"), a timestamp attribute, and / or one or more Failure assurance attributes (including but not limited to Checksum attribute, which contains redundancy information of the datagram content contains, and a sequence number attribute). The ADD system can also Profiles contain the structure of one or more datagrams specify. Such profiles can configure at least one specify said datagrams for use with a particular AK. The or the datagrams can be designed so that a state represents the AK becomes. The datagram (s) can be designed so that a command from a DS is represented to an AK. That or the datagrams can do it be used to acknowledge receipt of a previous datagram. The Transactions can be active, passive, or a combination of active and passive. Optionally, the ADD system can include a coordination office which is functionally coupled with the DS and AK and which the DS and AK Can assign network addresses. In some implementations, the Datagrams use the FactoryXML format. In other implementations the plain text descriptions can use the UTV format.

In other respects, the present invention can provide a distribution system of automation data representing a planning level with a Planning network to which one or more DS are connected; a Control level with a control network to which one or more AK are connected; and one or more gateways that are functional with the one or more AK and coupled to the planning network, the gateway or gateways serve to make it easier for the DS to communicate with the AK, by generating one or more datagrams and sending them to said AK; and in which the AK can work in such a way that it works with the DS communicate that they have one or more datagrams through the gateway or gateways generate and send to the DS.  

In other respects, the present invention may include a datagram which is within a system for the distribution of automation data is used, which in turn consists of at least one AK that is functional is coupled to at least one target component, wherein the datagram is composed of a source attribute that is the source (the sender) of the datagram identifies a target attribute which identifies the target (the recipient) of the Datagrams, where the target can be a DS or an AK, and that Datagram is fully encoded.

In yet another aspect, the present invention can be a method to distribute automation data in a system, which consists of a DS exists, which is functionally coupled to an AK, the method being a Contains source unit that generates a datagram, which consists of complete encoded descriptions in plain text, and a target unit, which the Datagram receives and responds appropriately. In this Implementation can be the source unit of a DS that is a query datagram the target unit (an AK) sends, and the target unit responds by sending a Send response datagram to the source unit, with the response datagram out a value attribute and an associated attribute with the one used Unit of measurement exists. Furthermore, the method in this implementation can be a Include source unit (an AK) that is active when predefined triggering occurs Events generates one or more datagrams and the datagram (s) on the destination sends.

In the present specification, the term "an" means an or several".

BRIEF DESCRIPTION OF THE DRAWINGS

The following drawings are part of the present Patent application and are attached to certain aspects of the present To illustrate invention. By referring to one or more of the Drawings in conjunction with the detailed description more specific  Implementations as presented here may be better for the invention to understand.

Fig. 1 is an abstract block diagram of an exemplary implementation of the present invention, illustrating a system for distribution of automation data.

Fig. 2 is an abstract block diagram of an exemplary implementation of the present invention and illustrates an alternative system for distribution of automation data, which includes a hardware gateway.

Fig. 3 is an abstract block diagram of an exemplary implementation of the present invention and illustrates an alternative system for distribution of automation data which includes a DDE software gateway.

Fig. 4 is an abstract block diagram of an exemplary implementation of the present invention and illustrates an alternative system for distribution of automation data, which contains a OPC software gateway.

DESCRIPTION OF EXEMPLARY IMPLEMENTATIONS

Fig. 1 shows a system for distribution of automation data ( "ADD") according to an exemplary implementation of the present invention. An advantage of the present invention is that it facilitates data flow between and within the control level ( 160 ) and the planning level ( 150 ) of a closed system such as a factory or an office. Commercial software applications on computers are usually within the planning level ( 150 ), while programmable logic controllers, peripheral devices, field devices, and automation software applications are usually within the control level. For the purposes of this document, the term "data processing station" (DS) is used for controlling, monitoring and evaluating devices and software applications both in the control level and in the planning level. The term "automation component" (AK), however, refers to peripheral devices, field devices and automation technology software applications. System components (both AK and DS) can be physical devices, peripheral devices and software applications.

The present invention enables real data distribution within of the overall system through the use of a uniform transaction format, which is used by all system components, no matter at which level they are are located. The basic transaction unit for data transmission in ADD is a fully coded device status or a fully coded command. Fully encoded means that no additional information (such as a predefined implementation table) is required to determine the device status or the Command to determine. In contrast, common AKs often only deliver one single value when queried. For example, a common scale their data via their computer interface simply with a line boundary Delivered with a label (e.g. 525.55 [CR]). Although 525.55 on a weight measurement can indicate, a DS would still have to know which unit of measurement the relevant Scales. In a typical installation, the DS would "know" (perhaps by using a conversion table) that the data is from a certain AK (for example "Libra 3") are calibrated in kilograms. Without Knowing the unit of measurement used, AK data is of limited value. Even when using conversion tables, this is the type of implementation badly suited for a distribution of the data within a network, because a any DS within the network would not be able to find the data source Determine the time and unit of measurement. Also would be Configuration changes network-wide updates of the implementation tables required. ADD addresses this problem entirely by using coded device states or commands, which in the previous example would include the unit of measurement of the transferred value.

A fully encoded data set should at least enable a DS to: to determine the data source without access to external information and, if data  the unit of this data is transmitted. When coding is complete Conversion tables at the recipient are not necessary. The information provided should can be processed by any recipient without further requirements.

In preferred implementations, the present invention uses Data records in plain text whenever possible and sensible. The encoding of data in plain text has several advantages over other types of coding. First, it is human readable. The simplest "terminal" (that is, a printer or a simple data display device) can be used to display ADD data for a display human users. Many veteran maintenance engineers in the Sales force has cost a lot of time and frustration, disturbed transmission channels by deciphering bit fields, checksums etc. The Troubleshooting options are excellent at ADD, which is important for the cases in which complex data testers are usually not available and Downtime is expensive. With ADD, a maintenance engineer can even use a device manipulate a simple terminal emulator since ADD records are without complex software can be compiled and transferred.

Furthermore, the plain text coding used by ADD is less error prone to version conflicts within a distributed environment. At Binary coding must be used to convert the transmitted tables Interpret data. If the conversion tables are saved locally (like this is usually the case), errors occur when these tables are not in the entire network will be updated. An advantage of ADD is that the The need for implementation tables to interpret data largely disappears.

Furthermore, the use of plain text coding makes few demands to the transmission channel. In some implementations of the present invention 7-bit encoding can be used, and ASCII control characters can be used for Protocol purposes are used if they do not appear in the user data. This Implementations simplify the construction of gateways. The simplified one Data formatting significantly simplifies the distribution of the data.  

As shown, an implementation of the present invention may include one or more DS (commercial software application [ 100 ] and programmable logic controller / PLC [ 110 ]) and one or more AK ( 120 and 130 ) that are functionally coupled to one another by a transmission medium ( 140 ) . Although the DS 100 and 110 and AK 120 and 130 are shown as directly connected to the transmission medium, a technically knowledgeable reader will understand that "functionally coupled" does not require a direct connection. For the purposes of this specification, a device can be said to be functionally coupled to another device if the devices can exchange information with one another regardless of the presence of any intermediary devices or transmission media.

In a preferred implementation, ADD can be implemented directly in any AK. This would allow AK 120 and 130 to communicate directly with DS 100 and 110 . This implementation would be suitable to replace traditional industrial protocols such as line-oriented ASCII, Modbus or the AK protocol (an application protocol from the automotive supply industry). TCP / IP over Ethernet is a preferred transmission medium 140 . However, one of skill in the art will understand that any suitable transmission medium 140 may be used, including (but not limited to) serial asynchronous connections, ISDN, wireless TCP / IP, USB, parallel interface connections, and GSM.

In some cases, control level ( 160 ) system components may not be able to use or connect to the necessary network protocols to communicate directly with planning level ( 160 ) system components. In these cases, a gateway can be used to enable communication. Many of the gateways in use today (both hardware and software gateways) can be used for this. A technically knowledgeable reader could indicate which special gateway can be used with the system components in a particular implementation.

As shown in Fig. 2, ADD hardware gateways ( 210 , 220 , 230 ) can be used where existing AKs are unable to use or join the required network protocols. An ADD hardware gateway translates from the network medium to the point-to-point medium (for example serial asynchronous interface) and takes care of the required protocol conversions on the higher layers (such as for example the presentation layer and the application layer). ADD generally does not require a large amount of computing and storage capacity. In preferred implementations, ADD hardware gateways can therefore be implemented as small protocol converters, which can be mounted on a top-hat rail or plugged onto an existing communication interface of the AK. An example of an ADD hardware gateway is (but is not limited to) an SMS gateway.

In other implementations (not shown) of the present invention, the transmission medium 140 may consist of two networks, a control level network and a planning level network, with one or more hardware gateways to facilitate communication between the two levels. The planning network and the control network can both be regarded as parts of the overall network 140 . In other implementations, AK 120 and 130 may not be directly connected to transmission medium 140 at all. In these implementations, the AK 120 and 130 may instead be connected to a PLC 110 , which in turn is coupled to the transmission medium 140 via a hardware or software gateway (see below).

Alternatively, the gateway functionality can also be implemented in software. As shown in FIG. 3, an ADD software gateway can be implemented as a DDE client 300 , which communicates with AK 340 via a DDE server 320 . As shown, the ADD Gateway can be installed on the computer on which the DDE server is running. DDE implementations currently only run on Windows PCs. Since most Windows PCs are network-compatible, this implementation has the additional advantage that ADD system components can use and communicate with the DDE server in the entire network. The DDE server 320 can communicate with an AK 340 via an industrial protocol 330 and translate this into DDE API calls 310 for communication with the DDE client 300 , and vice versa.

As shown in FIG. 4, an ADD software gateway can also be implemented as an OPC software gateway. In particular, an ADD gateway can be implemented as an OPC client application 400 . In the implementation shown, the ADD gateway logs on to an OPC server 430 as an OPC client and converts ADD to OPC 400 and vice versa in order to communicate with AK 450 . An advantage of this is that existing OPC client software 410 can continue to be used, since OPC servers can serve several clients at the same time.

A third group of gateway software (not shown) supports them Industrial protocols that use TCP / IP as a transmission channel, such as RFC 1006, or the network variant of Modbus, or peripheral devices such as digital I / O modules with proprietary network protocols. This type of ADD gateway can be installed on any computer on the network. A DS would be in in this case not directly with the system component "behind" the gateway communicate. Instead, the DS would send a datagram to the network address of the gateway. The gateway translates the datagram into the protocols and System component commands and vice versa.

In other implementations (not shown) a combination of Software and hardware gateways can be used within the same system. Furthermore, some implementations of the present invention can be gateways use for system components that require gateways and others System components that are ADD compatible and do not require gateways.

Transactions

In ADD systems, communication takes place between AK and DS (and with each other) through one or more transactions. Generally speaking Transactions an exchange of information between different System components of the ADD system in the form of fully coded datagrams. For the purposes of this specification, all datagrams are made up of complete encoded information. In some cases, the content of a datagram can contain data in a format that is not easily human-readable (for example binary or hexadecimal encoded data). However, datagrams are preferred human readable whenever possible.  

Fully encoded datagrams are the basic unit of an ADD Transaction. A datagram can be associated with a "record" of a database be compared. A datagram can have different functions. Typical functions are (but are not limited to): Representation of a Device status, representation of a command, or acknowledgment of a previous commands. In some cases, a datagram can have multiple Have functions at the same time.

With regard to AK, transactions can be "active" in the two categories and "passive" can be divided. An AK receives for passive transactions Command or request from another system component and can if necessary, respond accordingly. With active transactions can an AK data spontaneously transferred on their own initiative (usually at the Occurrence of a triggering event, or cyclically). In many systems Prefer active transactions as they are decentralizing amplify - they reduce data traffic in the network and simplify it Programming of data processing applications, the event-driven Paradigm of modern software development as it is for IT Applications is common. The specific structure and configuration of each Transaction can depend on several factors, including (but without to be limited to this) the type of implementation, the data format (see below) and the transmission channels used in an ADD system.

Any data format can be used that is fully encoded Datagrams leads. There are two data formats - FactoryXML and UTV (Unstructured Tag / Value) preferred because they are well-existing Software interfaces fit. FactoryXML is derived from the extensible format Markup Language (XML). UTV contains content similar to that used by FactoryXML however, a simpler, unstructured syntax.

FactoryXML

FactoryXML uses the syntax defined in the XML standard, but corresponds not necessarily the XML document model. Instead of that for XML Documents of typical static content can (and will) become the content of a  FactoryXML datagram, which represents a device state, dynamic to change. In addition, several FactoryXML datagrams can be on one and refer to the same subject. This is an important difference between XML and FactoryXML. In XML, the basic unit is a document (or a file). Different documents represent different things (books, articles etc.). In FactoryXML, the basic unit is a datagram. Different FactoryXML datagrams can refer to the same item (for example on a certain peripheral device), and represent different states at different times. Although the Can change the state of the peripheral device, the peripheral device remains on and the same thing. Because a fully encoded ADD datagram is a device state must represent clearly, it may be within a FactoryXML datagram do not give multiple identical sub-elements. A sensor can, for example, too deliver only a certain value at a certain point in time. Each Changes must be encoded in a separate datagram. A sensor Datagram with multiple "value" elements is therefore not permitted (against multiple "value" elements such as "value1", "value2" etc. for complex sensors can be used as long as no multiple instances of a single one Elements exist). In contrast, multiple sub-elements in XML Documents (e.g. "Chapter", "Paragraph") permitted and even common. Despite the Differences between XML and FactoryXML can be FactoryXML datagrams processed by ordinary XML parsers. Therefore, an XML-enabled Store FactoryXML datagrams immediately.

An example FactoryXML datagram can look like this:

Implementations of the present invention, which FactoryXML datagrams (like the example above) can use one or more elements consist of an element name ("Tag") and an optimal content (value).  

In some implementations, tags can only consist of letters in Lowercase exists, with the exception of predefined tags, where the first Is capitalized. Alternatively, upper and lower case be ignored.

A FactoryXML element can be sub-elements of any hierarchical depth contain. However, sub-elements of the FactoryXML root element must be unique his; Multiple identical sub-elements are not allowed, regardless of whether they are on the same or at different hierarchical levels. Tags for FactoryXML elements can be freely defined, with the exception predefined standard tags (see below).

FactoryXML includes a standardized attribute list. Which Standard attributes are used in a particular FactoryXML datagram, can be configured (for example by using profiles, see below). The standard attribute list can contain the following attributes (without this) to be limited): Attributes for data security (for example a digital one Signature, expiry date, etc.), a time stamp, and attributes for backup data integrity (e.g. a checksum, CRC, etc.).

Although FactoryXML attributes are generally optional, you can use them or non-use may be required in certain situations by the Configuration of the ADD system. For example, the Using a digital signature using one simultaneously Timestamp and a sequence number. A FactoryXML compatible Device must be able to process all standard attributes and must not be included Error conditions or undefined behavior on receiving any Standard attribute respond.

In many FactoryXML implementations, the encoding of Datagrams are made in the ASCII character set. Numerical data can be viewed as Floating point values can be encoded with a decimal point, with an optional Sign (prefix) and an optional exponent (suffix). An omitted Sign can indicate a positive value. An omitted exponent can display an exponent of one. Data can also be integer values  (Integer), either in decimal or in hexadecimal Spelling. Hexadecimal notation can be indicated by the prefix "0x" become. Negative decimal values can be preceded by a minus sign be identified. An omitted sign can be a positive value mark. Data can also be displayed as text values. Set text values are made up of strings as specified in XML document format are. The processing of text spaces (whitespace) can be identical to XML document format. Finally, FactoryXML can do one sentence Predefined tags to clearly identify certain states and Deploy units. Predefined tags can be used in FactoryXML datagrams as empty elements can be used. The first letter of a predefined day is always capitalized. Examples include (without claim to Completeness): <On / <, <Off / <, <Leftl <, <Right / <, <Up / <, <Down / <, <Open / <, <Closed / <, <Full / <, <Empty / <. The use of these tags can be done without specifying one unit. For other situations, there can be predefined tags for everyone Give base units and derived units of measurement, such as (without this) limited): <Meter / <, <Kilogram / <, <Second / <, <Ampere / <, <Kelvin / <, <Mol / <, <Candela / <, <Fahrenheit / <, <Celsius / <, <Inch / <, <Ampereh / <, <Percent / <.

In a preferred implementation, applications use predefined FactoryXML tags whenever possible to reduce the possibility of ambiguous value labels. Where values or units of measurement are coded as text fields at will, there is a need for interpretation. Example: The following FactoryXML datagram -

- does not use a standardized unit. The value "F" for the element <unit <suggests the unit Fahrenheit, but is not unique. The following FactoryXML datagram eliminates any ambiguity by using a predefined tag:

In some implementations, they can be specific or special Meaningful tags are used to add or replace device states of the <value <tag. For example, for a thermometer too a tag called <temperature <can be used. Similarly, in one Flow meter a day called <rate <can be used. Some units can transmit multiple values using different tags (for example <rate1 <, <rate2 <etc.).

An "src" attribute can be used to identify the data source (i.e. the Network address of the data source) of a FactoryXML datagram do. In view of the present invention, "network address" is unique address means the unique location of a unit within the Systems describes. A network address can be an IP address, IPX address, etc. or it can be a symbolic address (for example "Thermometer2"). Source addresses can be freely defined to a specific device or a identify specific application within a network. In a preferred implementation, the source address is an understandable symbolic Surname. ADD source addresses must be unique, but do not have to be identical to Network addresses of the transmission medium (i.e. host name or IP Addresses); they also don't have to be identical for a particular device because on one application can run several applications, which then have different applications Need addresses.

In addition, FactoryXML supports unique source addresses worldwide, that can be assigned by a coordination office. Such an address can for example, "burned" into a peripheral device by the manufacturer, so that addressed this device without further configuration steps during commissioning can be.

The "src" attribute enables a very simple and precise Log transactions as datagrams are immediately sent to a sender  can be assigned. It also allows the use of a Transport channel for multiple devices (multiplexing).

In preferred implementations, everyone uses FactoryXML-enabled Device has a globally unique source address that is assigned by the coordination office is issued. Where this is not possible, another preset can be used Source address (such as "ADD") can be used. In these cases the default source address can be used to initialize a device, so that applications have the ability to determine whether the device is ADD is compatible. In other implementations, the use of a default source address.

A datagram can contain additional information, as in the following example:

In this datagram, the attribute for the destination address ("dest") denotes the Data sink to which the datagram is sent. The destination address is identical to the source address of the device to which the datagram is sent. It can give predefined global addresses, such as "*" or "any", which are used can, if a datagram are sent to all devices or applications that can be achieved via a given transmission channel. In some Implementations can also use wildcards in the destination address attribute. be used.

A timestamp attribute ("t" in the example above) can be used for this to specify the point in time at which the datagram was created. In preferred implementations all datagrams have a time stamp. The Using timestamps is particularly useful in distributed environments which data is written directly to a database without any further intermediate steps  become. Various methods can be used for coding time stamps become. In a preferred implementation, the ISO 6801 standard can be used be a timestamp with hours, minutes and seconds without Generate colons and hyphens. In addition, year, month, day, Milliseconds and Zulu time (UTC) can be specified. For network-compatible devices the time can be synchronized with the protocol specified in RFC 1129. For devices that cannot calculate the time, a preset value can be set be used. In other implementations, timestamps are optional.

A sequence attribute ("seq") can be used to order of a particular datagram in relation to previous and subsequent ones Identify datagrams. In preferred implementations, the Sequence number as a positive integer value between 0 and 65535 become. In the event of an overflow, the sequence number can be reset to 0. The sequence attribute enables data loss and sequence errors to be recognized, for non-error-correcting transmission channels (such as UDP) may occur. This can result when using receipts (see below) data loss through retransmission can be prevented. When transferring Commands, the data processing station can answer the command clearly reference. If the data processing station has a sequence number used together with a command (set) or a query (poll), the Answer use the same sequence number.

In some implementations, a checksum attribute ("crc") are used, which contains redundancy information of the datagram content. The checksum enables error detection when using unsecured Transmission channels, such as serial asynchronous interfaces. In preferred implementations, the checksum attribute is in acknowledgment mode used. A checksum together with receipt datagrams can be one provide automatic error correction. For example, a recipient use the checksum to determine whether the datagram was transferred without errors. If not, he can retransmit by sending a negative Force receipt. This procedure is repeated until the datagram is error free has been transferred (i.e. until the content and checksum match). this is not  particularly useful for TCP / IP transmission channels, but it can be important for serial Point-to-point connections and modem routes should be automatic Error correction is not necessarily already carried out by the transmission channel becomes. The implementation methods for checksums are generally known. In In one implementation of the present invention, the checksum can be called CRC-16 for the datagram content without whitespace and without the checksum be calculated yourself.

An attribute for a digital signature ("sig") can be used, which contains encrypted redundancy information of the datagram content. In a preferred implementation can use the signature from the datagram content with the RSA algorithm can be calculated, which previously with the MDS hash function is encoded. A public key process can be used. The recipient can use the sender's public key to encrypt the Decrypt the hash value and use a second one, even from the datagram content compare the calculated hash value. If the two values match, the content of the datagram is considered valid. In a preferred one Implementations must also use a digital signature Source address, a time stamp and a sequence number can be used. For to further increase security, an expiry date ("exp") can be used become. A datagram with a digital signature must not be a response to one Datagram without signature or in response to a datagram with an invalid one Signature will be sent. When using network transmission channels the SSL protocol (Secure Socket Layer) can also be used to transfer the To further increase security.

An expiry attribute ("exp") can be used which represents the Defines the point in time at or after which a datagram becomes invalid. On End of validity can be particularly useful to ensure security when manipulating of actuators to increase. Without an expiry date, a "tapped" Transmission channel "listened to" datagram (even if it is with a digital signature is secured) sent again identically at a later date to repeat a specific action (e.g. a goal, a Security lock etc. to open). The specification of an end of validity (for  Example one second after the datagram has been sent) can one Provide protection against improperly retransmitted datagrams, since after the End of validity cannot be processed by the recipient.

Some implementations of the present invention can be saved Use profiles. Profiles can be used generally to cover the whole to describe the elements, including permissible value ranges, in datagrams can be used for a specific device or a specific application. FactoryXML profiles can be specified in different forms. To the Example can be a FactoryXML profile as XML Document Type Definition (DTD) be expressed. Alternatively, a FactoryXML profile can be used as an XML schema be expressed. A profile preferably models a specific one System component as complete as possible. In some implementations, generic profiles can be used as a starting point for individual profiles. In other implementations, FactoryXML profiles can be based standardized profiles are modeled by standardization bodies for Different applications, device types and industries have been defined.

An exemplary FactoryXML profile can look like this:

The profile shown is a generic FactoryXML profile for sensors (such as temperature sensors, pressure sensors, voltmeters, scales, etc.), consisting of an element <value <and an element <unit <. An example datagram for a temperature sensor looks like this:

As an implementation option, a generic FactoryXML profile for actuators (such as switches, valves, etc.) can be implemented with a <value <element as follows:

An exemplary datagram for manipulating a digital (binary) output (switch) with this profile can look like this:

Complex peripheral devices such as PLCs are usually difficult to model with generic profiles. Nevertheless, application-specific profiles for complex peripheral devices can be defined. An example FactoryXML profile for the Siemens image recognition system SIMATIC VS710 looks as follows:

In this implementation, the peripheral device consists of a camera an integrated processor for image recognition, for example in processes Monitor connection with conveyor belts. The VS710 has a PROFIBUS Interface and an asynchronous serial interface. The asynchronous serial Interface uses the 3964R protocol for error correction and a proprietary, device-specific protocol above 3964R for command and Data exchange.

As shown, FactoryXML profiles can be designed to do all of them Functions and idiosyncrasies of a device or application. To the For example, the FactoryXML element "program" can be used to create the Manipulate image recognition program within the VS710. It uses the Sub-elements "load", "reset", "start" and "stop". The FactoryXML element "monitor" starts or stops the output of image recognition results. The FactoryXML element "observation" contains results from the VS710 spontaneously generated when the monitoring function "monitor" has been switched on. The FactoryXML elements "readconfig" and "writeconfig" can be used to to read or write configuration data.

FactoryXML datagrams can optionally be included in a FactoryXML envelope. A FactoryXML envelope is not a FactoryXML element because it can contain multiple identical sub-elements. FactoryXML envelopes cannot contain standard FactoryXML attributes. A FactoryXML envelope can be useful in situations where an XML parser does not support multiple root elements. An example FactoryXML datagram in a FactoryXML envelope can look like this:

UTV

The present invention provides for the use of alternative data formats. One of these alternative data formats is called UTV, an acronym for "unstructured tag / value". A very simple UTV datagram can look like this:
src = thermometer2
t = 234412
value = 1.92
unit = Celsius

As you can see, UTV contains content similar to FactoryXML, but the data is less structured. With UTV coding, a tag can be followed by an optional value. For example, tags and values can be separated by an equal sign. Tags without values correspond to empty FactoryXML elements. Predefined tags (such as <Kg / <, <On / <, <Off / <) can be treated like values in UTV. Multiple tags can be separated by whitespace. The following can be used as spaces (without claim to completeness): [SP] (ASCII characters 32), "and" characters ("&"), plus signs ("+"), tabs, carriage returns ([CR], ASCII characters 13) and line feeds ([LF], ASCII characters 10). Elements and attributes are generally treated syntactically in the same way in UTV. The following example datagram contains the same content as the example above, but uses different separators:
src = Themometer2 = 234412 = 1.92 = Celsius

Some UTV implementations can include parent elements to convey more information and structure. Parent elements can be encoded as prefixes, using a period to separate the prefix. An exemplary datagram of this implementation can be structured as follows:
sensor.src = Thermometer2
sensor.t = 234412
sensor.value = 1.92
sensor.unit = Celsius

UTV can be used in situations where the target application is unable to process FactoryXML or in which FactoryXML simply would be impractical. UTV requires packet-oriented transmission channels, in which the Transmission protocol marking the end of the message (or Datagram end) supported. Include meaningful transmission channels for UTV (Without exclusivity): HTTP clients, the device states to an HTTP server transmit via URI coding (since URI coding FactoryXML not supported, but probably UTV); HTTP server, the passive transactions using URI Accept coding; SMS gateways (bidirectional) as active alarm Transactions UTV can use to send alarm messages to cell phone displays (encoded as a UTV datagram) to which a user with the Retransmission of a UTV-encoded SMS message that he can reply to on the Type in the keyboard of his cell phone and the one on the other side too Changes in configuration or the like; WAP / WML clients due to the limited display options with WAP; Alerting and Remote configuration via email; and simple HTML pages for browsers that don't use XML support.  

Transactions

Commands can be sent to an automation component with the standard element "set". In a preferred implementation, a command is acknowledged with the new or current device status. If the "seq" attribute (sequence number) is used, the automation component will preferably use the same "seq" value in its response datagram. The following sequence table shows the contents of a datagram exchange in which a DS sends a command to an AK (for example a binary output) to set the status "On":

In the transaction shown, the DS sends a command to an AK with the Network address "Switch5". The command is that the content of the element <value < should be set to the value "On". The DS uses sequence number 12 for Identify this transaction. The AK replies with a datagram, which contains the new value, indicating that the command was successful was carried out. The response datagram uses the same sequence number as the command datagram so that the answer is clearly the command can be assigned.

In the event of an error, the response datagram contains the actual value of the element concerned, together with an <error <element, which contains an error description. The following sequence table shows the exchange of datagrams, in which a DS sends commands to an AK (for example a digital output) in order to switch on an "unsupported" state "high".

As can be seen, this transaction failed because the DS tried the value Set "high", but the AK only supports the values "On" and "Off".

The acceptance of commands by a system component can be done via Configuration on commands from specific stations (identified by their Source address). Together with the network address (if available) and with the digital signature you can transfer the command restrict selected stations, creating opportunities for abuse be restricted.

The standard element <poll <can be used to query a device or application status. A query transaction is similar to a command transaction. If <poll <is used as an empty element, the response datagram contains a complete data structure of the queried device or application. However, <poll <can also be used to query specific sub-elements. The following example transaction illustrates the content of datagrams with which a DS ("erp") queries the status of an AK ("ramp"):

The following example transaction shows how a DS can query the content of a specific sub-element:

Active transactions

Active transactions are initiated spontaneously by an AK. The edition takes place cyclically, when the state changes or when certain ones arrive Conditions. In preferred implementations, active transactions (especially those that are triggered by changes in state) by the Protect receipts against data loss.

With an active cyclic data output an AK can use datagrams Send cyclically at predefined time intervals (e.g. every second). In In many situations, however, the active output when the status changes be preferred because it reduces network load and programming the DS simplified.

If there is an active data output when there are changes in status, an AK can be activated Send datagram in case of a change of state. In addition, the current Status of the AK when establishing a connection or when switching on the device (for connectionless transmission channels) are sent. Active data output at State changes allow a significant reduction in the complexity of Software applications that evaluate the data and also helps the Reduce network load. For connectionless or unsecured Acknowledgment channels can be used to prevent data loss avoid that could otherwise lead to serious malfunctions.  

With active data output when certain conditions occur (Alerting) an AK can send a datagram if one or more Conditions are met. The conditions can be simple or complex.

In preferred implementations, active transactions can be acknowledged by the DS to prevent datagrams from being lost, especially if non-error correcting transmission channels such as UDP are used. In acknowledgment mode, an AK waits for an acknowledgment for each datagram before the next datagram is transmitted. An acknowledgment can be an empty root element with the sequence number of the received datagram. Alternatively, the standard elements <ack <and <nak <can be used. The advantage of this is that negative acknowledgments are also possible, which speeds up a transaction in the event of a faulty transmission channel (the sender does not have to wait until his timeout expires). The following transaction illustrates the receipt operation:

When using error-detecting transmission channels such as UDP not necessarily a checksum attribute to be used. Checksums preferably on non-error-proof transmission channels such as serial Asynchronous interfaces used.

If the data generating station within a predefined time (Timeout) does not receive an acknowledgment, the last datagram can be retransmitted until an acknowledgment is received or a predefined maximum number of Repetitions is reached. No subsequent datagrams should be transmitted before a valid receipt has been received.  

Receipts are particularly useful in connection with the active one Data output when the state changes. The active data output when the status changes advantageous because it simplifies programming and reduces the network load. This However, the type of transmission can lead to fatal consequences if data is lost remain unnoticed. The receipt operation can be used to such Data loss with non-error-correcting transmission channels such as UDP prevent.

Registration and deregistration (subscribe / unsubscribe)

The destination address for active transactions can typically be two ways to be defined: (1) permanently configured within a device or a Application, (2) dynamic by signing in and out. A dynamic one Registration and deregistration is particularly useful for connectionless Transmission channels like UDP. You can use the standard elements "subscribe" and "unsubscribe" can be implemented. A station that deals with an ADD device "subscribe" will receive output from this device depending on the preconfigured operating mode (for example active cyclic data output) until it unsubscribes with "unsubscribe".

Registration and deregistration can be ADD commands. Registration and deregistration can be acknowledged by the AK. The following attributes can be used when logging in:
<! ATTLIST subscribe
trigger (cyclic | delta | alarm) #IMPLIED
ack (yes | no) #IMPLIED <

The "trigger" attribute determines whether the output is cyclic State changes (delta) or when certain conditions occur (alarm) he follows. The "ack" attribute specifies whether acknowledgments are sent or not.

Some implementations of the present invention can use logon and logoff transactions. An exemplary registration and deregistration transaction can look like this:

In this example, a DS registers with a scale ("ramp2"), which then cyclically (every second) sends datagrams to the DS until the DS joins unsubscribe again. Registration and deregistration will be acknowledged by the AK.

In some cases, the DS can choose a transaction mode that is different from the default mode. This is done by setting values for the "trigger" and "ack" attributes. The following sequence table shows an exemplary transaction that illustrates how a unit can register for active data output with changes of status with confirmations:

Here the DS reports for active data output when the status changes Confirmations. The AK begins the output with the sequence number 0. Das Datagram is acknowledged by the DS. At 9:23:13 a.m. there is no broadcast, since the device status (in this case the measured weight) has not changed. The next transmission takes place at 09:23:14, as the weight changes from 123.2 to Changed 123.9 kilograms. The datagram is acknowledged again, and the DS then logs off.

When registering, you can also enter a valid range of values for a specific one Element. This is useful for alerting, being different Applications can define different threshold values. in the An alert is triggered if values outside the  allowable range fall. The output continues when the state changes until the value of the element concerned is again within the valid range, or the output can be continued cyclically for a predefined time. For The standard elements "min", "max", "equal" and "unequal" are used.

The following examples explain (both in FactoryXML and in UTV) datagrams for registration that can be used in different situations. In the following example, a DS registers for an alarm if the value of the "temperature" element exceeds 110.9 or falls below 34.2:

The following example shows how an alarm application can register when the value of the "gate5" element changes to the "Open" value:

The next example shows how an application can register for alarms if the "color" element takes a value other than "green":

The definition of alarm conditions can include the elements "max", "min", Use "equal" and "unequal". Mixing these elements (except of "max" and "min") within a condition definition is not permitted and nonsensical. "max" and "min" can be used together or individually.

Transmission channels

None of the data formats described in the present specification are bound to a specific transport medium or protocol. Yet are preferred in practice implementations with TCP / IP or related Internet protocols can be found.

Implementations of the present invention can be multiple use different transmission channels, including simple ones Transport protocols (ISO / OSI layer 4) and application protocols (ISO / OSI- Layer 7). In practice, implementations are preferred Transport protocols can be found because they are more flexible and efficient Allow data exchange options.

In one form of implementation, the AK acts as a TCP server and waits on connection requests. A DS can establish a connection as a TCP client, to send commands to the AK and / or to receive data from the AK. This type of transmission channel can support all FactoryXML transactions. Acknowledgment operation does not make sense here, since TCP already is error correcting. You can also use this channel to log in and out (subscribe / unsubscribe), with the AK actively using a TCP client connection  to the DS, transmits a datagram, and the TCP connection again closes.

In another implementation, the AK can act as a TCP client and Establish connections to a preconfigured TCP server to send datagrams to transfer. As an alternative to permanently configured connections, too Connections to DS are established that were previously via a TCP server channel have registered with the AK (subscribe). This transmission channel is the first Line useful for active (spontaneous) transactions. The use of Confirmation datagrams do not make sense on this transmission channel since TCP is already error correcting.

Instead of TCP, UDP can also be used. UDP has opposite TCP has some advantages, including better performance through lower protocol Overhead, packet-oriented versus stream-oriented transmission and Broadcast support. On the other hand, UDP is error-detecting, but not error correcting, so packet loss as a result of Transmission errors can occur. In addition, UDP datagrams can Arrive in the wrong order. FactoryXML solves these problems through the use of sequence numbers. Sequence numbers can do this used to detect data loss and sequence errors.

Data loss may not be critical in polling operations, because the DS recognizes the lack of a response to its query and the query can then start again. Even with active (spontaneous) cyclical output of data, the loss of individual data packets is usually not critical, since a The data is automatically updated in the next cycle. Are at the spontaneous data output only transfer change data (or alarm data), however, it is recommended to use a transport protocol other than UDP or the use of the receipt mode. In this mode, the one with the Receipts associated with protocol overhead are usually acceptable since one Comparatively changing the data that leads to the sending of a datagram rarely occurs in the modes in which this method is normally used becomes.  

In connection with UDP, the login and logout are for spontaneous Datagrams (subscribe / unsubscribe) are particularly useful. A DS can be called UDP Register the client with an AK that acts as a UDP server (subscribe). After The roles are swapped over and the AK sends change data to DS, which then receives UDP datagrams.

As an alternative to TCP and UDP, other Internet protocols such as Example T / TCP (TCP for Transactions, see RFC 1379 and RFC 1644) used become. T / TCP offers a much faster connection and disconnection than TCP and is comparable in performance to UDP, but is error correcting like TCP. In view of the present invention is T / TCP a preferred faster alternative to TCP.

Both FactoryXML and UTV can be any data stream oriented Use transport channels, such as serial asynchronous interfaces, ISDN or USB. In practice, implementations are used to correct errors Protocols preferred. When using error-detecting, but not error-correcting protocols can be provided in FactoryXML Receipts are used to avoid data loss. For UTV are error-correcting, packet-oriented transmission channels required.

Implementations of the present invention can also be used as HTTP Use transmission channel. The advantage of HTTP is the large number of installed HTTP servers and clients (i.e. web browsers) worldwide. The following Section describes different ways of using HTTP together with of the present invention, however, does not provide a complete list of possible ones Implementations.

HTTP server, POST method

An HTTP-POST command from a DS (the HTTP client) can be used a FactoryXML datagram (for example with a <set <- or <poll <- Datagram) to an AK (the HTTP server). The AK can with one Answer FactoryXML datagram. A further data output of the AK is only possible if the underlying TCP connection is kept open.  

HTTP server, GET method

An HTTP GET request (for example with a "set" or "poll" - Standard element) can be triggered by a DS, being a UTV datagram is transported within the URI. Examples of this are the URIs "http: // lightswitch5? set.actuator.value = on" and "http: // themometer2? poll.sensor.unit". The AK, which acts as an HTTP server, can use a FactoryXML datagram reply. Further issues of the AK are possible, provided the underlying TCP Connection remains open.

HTTP client, POST method

This transmission channel is useful for applications in which an AK Submit data by filling out a "web form", or where simply the Widely used CGI technology is to be used for business Applications to provide automation data. The HTTP server can be, for example, a business application that configures is that it transmits the transmission data of an AK (for example a UTV datagram) with a Can process CGI script. The AK (the HTTP client) must be suitable for active data output must be configured, usually for output at Change of state or when predefined conditions occur.

HTTP client, GET method

An AK registers as an HTTP client with a DS (the HTTP server) and transmits a UTV datagram as part of the URI. An example of this would be the URI "http: // server? src = thermometer2 = 23,442 = Celsius". The HTTP server can respond with a FactoryXML datagram, which is generated by a CGI Script is generated. This transmission channel is useful for active data output in the event of a change of state or the occurrence of predefined criteria.

Email can be used as a transmission channel and is particularly useful for alarming and remote maintenance. Emailing can be used for active data output AK can be used. The AK can preconfigure a UTV datagram Send email address or to a remote user who "subscribe" has registered. Email reception can be used for remote configuration. On  remote administrator can use commands in UTV (or FactoryXML) encoding send that can be transmitted using the Internet email protocol. E-mail- Reception can also be used for registration ("subscribe") for active data output are used, the active data output then to the email address of the remote administrators can be sent via email. Commands can be written both in the subject field of the email and in the email content become.

Other implementations of the present invention use wireless Transmission channels like SMS and WAP. Cell phones have a special practical Significance for alarming, remote maintenance and remote configuration. Virtually everyone Maintenance engineer in the field has a cell phone. Also are cell phones able to receive and send ASCII text messages (SMS) and serve as a restricted access to the Internet via WAP. Both options make them suitable and attractive terminals for ADD.

SMS messages are short text messages (up to 160 characters) can be output on the mobile phone display or on the keyboard of the mobile phone can be entered. The active data output of an AK due to Change of state or due to the occurrence of predefined conditions UTV coded to be sent to one or more cell phones via SMS. Depending on SMS Service Center can have different access options to get to to get the radio network. The access options usually include Email, analog modem, ISDN, and GSM modem; all of these options can be found on easily supported by ADD devices. For all access options to the SMS Service Center besides email it may be desirable to send an SMS Install network gateway, which has multiple applications or devices can use within the network. AK can be used by mobile phone are manipulated by SMS messages.

Some cell phones can already "browse" the Internet by using the wireless Application Protocol (WAP) for data transmission support and wireless Markup Language (WML) to display the data. WML is a subset of HTML. WAP enables the querying of ADD devices by "browsing" Menus and hotlinks and can be used for remote diagnosis and remote maintenance.  

However, WAP is unsuitable for alarming and active data output in some Implementations because a peripheral device may not be active via WAP can send a cell phone.

The above examples have been outlined to determine certain Explain implementations of the invention. Technically knowledgeable readers should Please understand the techniques presented in the examples as those of the inventor recognized as working well for the practical implementation of the invention and the therefore viewed as preferred practices in their practical implementation can be. However, technically knowledgeable readers should also understand that numerous changes within certain implementations of the Invention can be made that are still the same or lead to similar results without deviating from the spirit and scope of the invention to deviate.

Claims (26)

1. A system for the distribution of automation data (ADD), consisting of:
a data processing station (DS) with a network address;
an automation component (AK) with a network address and functionally connected to the DS;
in which said DS and AK are configured to communicate with one another by means of one or more transactions, said transaction consisting of a datagram, the datagram being fully encoded and containing a description in plain text. 2. The ADD system of claim 1, further said in said datagram a source attribute to identify the network address of the source of the Contains datagrams. 3. The ADD system of claim 1, in said datagram further a target attribute containing the network address of the intended data sink for this datagram contains. 4. The ADD system of claim 1, wherein said datagram further includes:
a value attribute, as well
a unit attribute that specifies the unit used by said value attribute. 5. The ADD system of claim 1, in said datagram further contains one or more security attributes. 6. The ADD system of claim 5 in which at least one of said Security attributes consist of an attribute with a digital signature.   7. The ADD system of claim 5 in which at least one of said Security attributes consist of an end-of-validity attribute, which is a Indicates the time after which said datagram becomes invalid. 8. The ADD system of claim 1, further said in said datagram contains a timestamp attribute which indicates the time at which said Datagram was created. 9. The ADD system of claim 1, in said datagram further contains one or more attributes for error protection. 10. The ADD system of claim 9, further comprising said datagram a checksum attribute which includes redundancy information of the content of contains said datagram. 11. The ADD system of claim 9, further said in said datagram contains a sequence number attribute. 12. The ADD system of claim 1, which further includes a profile, which are the permissible elements, parameters and attributes in said datagram specified. 13. The ADD system of claim 12, in which said profile Datagram specified for use with a particular type of AK. 14. The ADD system of claim 1, wherein said datagram is a State of said AK represents. 15. The ADD system of claim 1, wherein said datagram is a Command from said DS to said AK represented. 16. The ADD system of claim 1, wherein said transaction further contains a receipt datagram with which the successful or unsuccessful Receipt of said datagram can be displayed.   17. The ADD system of claim 1, wherein said transaction (s) is one active transaction. 18. The ADD system of claim 1, wherein said transaction (s) is one is a passive transaction. 19. The ADD system of claim 1, further comprising a Coordination point contains which is functional with said / said DS and with said / said AK is coupled, said coordination point said DS and AK can assign network addresses. 20. The ADD system of claim 1, wherein said datagram is the FactoryXML format used. 21. The ADD system of claim 1, wherein said datagram is the UTV Format used. 22. A system for the distribution of automation data, consisting of:
a planning level consisting of
a planning network, and one or more DS that are functionally coupled to said planning network;
a control level consisting of
a control network and one or more AKs that are functionally coupled to said planning network; and
one or more gateway units that functionally with said / n AK
and are linked to said planning network,
wherein said gateway unit (s) serve to assist said DS in communicating with said AK by generating and sending one or more datagrams, said datagrams containing fully encoded descriptions in plain text; and
said AK can communicate with said DS by sending one or more datagrams through said gateway units to said DS. 23. A datagram for use in a system for distributing automation data, consisting of an AK, which is functionally coupled to a DS, the datagram containing:
a source attribute identifying the data source of said datagram, said data source being the AK or the DS;
a target attribute which identifies a data sink of said datagram, said data sink may be the AK or the DS;
said datagram being fully encoded. 24. A method for automated data distribution in a system consisting of a source unit which is functionally coupled to a target unit, the method comprising:
a source unit that generates a datagram consisting of fully encoded descriptions in plain text; and
a target unit that receives said datagram and replies meaningfully to the content of said datagram. 25. The method for automated data transmission according to claim 24, in said source unit is a DS which said a query datagram to Sends target unit (an AK), and said target unit with sending one Responds to said source unit, the datagram being a value Attribute and an associated unit attribute. 26. The method for automated data distribution according to claim 24, in which furthermore said source unit is an AK which is actively one or more Datagrams generated and said one or more datagrams to said Sends target device when a predefined triggering event occurs.