DE19818041A9 - Computer design generating method for operating and monitoring guiding system - Google Patents

Abstract

In order to enable an extremely simple, user-friendly and inexpensive handling of control systems (2), in particular for process and production systems, the present invention provides a method for generating a surface for operating and monitoring control systems (2), in particular for process and production systems Production plants, proposed, whereby information from a server computer (4) adaptable to at least one control system (2) via a client-server computer network on a client computer (5) in input and display elements (17) are visualized.

Description

description

The present invention relates to a method for generating a surface for operating and monitoring Control systems, in particular for process and production systems. Surfaces are used in the field of control system technology required for the monitoring and / or control of industrial systems. They serve the visual representation of process operations, measurement and control variables and / or operating units.

Different platform-specific visualization and operating concepts are known which, due to the different Hardware and software platforms do not have room for cross-system information exchange allow. Furthermore, the information arising in the field of control system technology, for example process sequences, is descriptive Input, status and output variables and their relationships to one another, setpoints, setpoints and the like, as they occur in various process and production systems, for example in power plants, Refineries, freight systems and the like, only available locally, that is in the broadest sense directly on site.

There is a need for uniform visualization and operating concepts in order, on the one hand, to give the operating personnel a to enable simple handling of these, so that, for example, a quick familiarization period in different Systems based on a uniform basic structure familiar to the user is given, and on the other hand in order to be as possible to enable a modular structure for many levels of the control system, for example with standardized components. In order to be able to use the widest possible range of possible applications, it is necessary to separate it from each to be able to act in given hardware and software environments, i.e. to provide platform-independent systems, which at the same time enable a cross-system exchange of information. It is also in the case of control systems there is a need for high availability.

The present invention is based on the object of a method for generating a user interface and observation of control systems, especially for process and production systems, to indicate which one is the most simple, user-friendly and inexpensive handling of control systems, especially for process and production systems, enables.

For the technical solution, a method for generating a surface for operating and monitoring control systems is required, in particular for process and production plants, provided in the area of control systems Information from a server computer that can be adapted to at least one control system via a client-server computer network be viusalized in input and display elements on a client computer.

According to the method, the information that arises in the area of control systems is sent to the respective control system via a adaptable server computer accessible to a client computer in the client-server computer network, whereby the information from the server computer is visualized on the client computer in input and display elements will. The information is only processed and evaluated by the client computer and stored in visualized with the corresponding input and display elements. The information can be sent from the server computer for example, given as pure ASCII data in the client-server computer network and on the part of the client computer be interpreted accordingly on this.

In that the information is viusalized in input and display elements on the client side in accordance with the procedure, an extremely simple, user-friendly and inexpensive handling of control systems is given.

The input and display elements can advantageously be freely parameterized and configured. This will make that The range of use in the area of different control systems has increased considerably, while for the user at the same time there is a high degree of customization with regard to the design of its surface.

According to a further particularly advantageous proposal of the invention, the client-server computer network is a Intranet and / or Internet. On the one hand, this achieves a high level of availability, which is due to the rapidly advancing networking the office world to so-called intranets as well as the worldwide networking in so-called Internet and a use of the networks for operating and monitoring control systems, especially for process and production systems enables. Such is global operation and monitoring of process and production systems, for example for the display of control information such as logs, messages, data stocks from databases, and the like given.

According to a further advantageous proposal of the invention, the visualization takes place by means of a web browser. This makes it easy to operate and monitor control systems with common web browsers, which are available for almost all hardware and software platforms. Dealing with the control system is thus further simplified and more user-friendly for the user.

The use of Internet technologies makes the operation and monitoring of control systems extremely cost-effective, because simple computers or terminals can be used and not special and expensive hardware must be used. The information that arises in the area of control systems can also be found on many display different hardware and software platforms at the same time, advantageously according to access authorizations staggered. With the associated low administration and maintenance effort, save further costs. Furthermore, users can be in their familiar environment, for example from to Operate and monitor control systems from home. Thanks to a modular software structure, Gradually convert or equip existing control systems.

According to a further particularly advantageous proposal of the invention, the input and display elements generated by the client computer. This relieves the client-server computer network as much as possible and reduces processing time for generating the input and display elements is essentially only dependent on the performance of the client computer. For this purpose, for example, a data record is transferred from the server to the client, there interpreted and executed and after processing by the user, for example by input, for Finishing sent back to the server. The actual program thus runs on the client computer. According to Another advantageous proposal of the invention is the input and display elements using Java applets and / or Java beans generated. Java is an interpreter language developed by Sun Microsystems that has a similar structure is like the object-oriented programming language C ++. Java applets are small programs created with Java that are stored in

HTML pages built in and can be used there for interactive applications. HTML (HyperTextMarkup-Languages) was specially developed for Internet technology and is the basis of the World Wide Web (WWW). The HTML format describes the graphic formatting of texts and the integration of images and events. With HyperText is understood to mean the possibility of using cross-references contained in a text to another point in a To jump text, specifically to load another web page on the Internet, on the World Wide Web. Java beans are Java components, which are even more powerful than Java applets, i.e. offer different or further options.

Java itself opens up extensive advantages. For example, Java is platform-neutral, simple, secure, fast and dynamic. The speed of Java is based on the fact that two technologies are combined in an applet developed in Java are. On the one hand, the source code of a program is first translated into the so-called Java byte code. Subsequently the applet created in this way is executed by an interpreter available in common web browsers. The libraries used in the applet to generate text, graphic and graphic components are only used when the of the program, i.e. executed at runtime, i.e. on the respective client computer.

The performance features given with Java and on the Internet can thus be easily and inexpensively implemented Use way to operate and monitor control systems.

Advantageously, with a further proposal of the invention, the input and display elements include messages, Curves and / or system graphics such as system images and the like.

Further advantages and features of the invention emerge from the following description on the basis of examples. Show:

Fig. 1 is a schematic representation of a communication structure between individual parts of the system;

Fig. 2 is a schematic diagram illustrating a structure of an applet, here for visualizing a graphics system; Fig. 3 is an illustration of an exemplary embodiment of messages;

Fig. 4 is an illustration of an embodiment of waveforms and

Fig. 5 is an illustration of an embodiment of a system graphics.

Fig. 1 shows in a schematic representation of the communication structure between the different parts of the system, via TCP / IP connections (Transmission Control Protocol / Internet Protocol) is performed. The telegrams used here contain pure ASCII data, which are interpreted accordingly in the individual subsystems.

The communication architecture 1 comprises three separate layers, a server 4 for connection to a control system 2, here for example on SICALIS PMC WinCC or SiiX from Siemens, and others, using appropriate adaptation modules 3, a broker 4, which is provided by the server 4 and hereinafter also referred to as the server as well as a client 5 for generating and visualizing input and display elements by calling of so-called methods, here in the form of curve blocks 6, message blocks 7 and system graphics blocks 8, which are specifically available here in the form of beans, so that the client 5 is used for the applet connection.

The flow of communication between the individual layers is carried out as follows:

A so-called method 9 in the client 5 called, via which a corresponding telegram 10 is generated and sent. For this task poses the client 5 different methods for sending and receiving telegrams ready, for example registration and deregistering various modules for generating input and display elements.

These interfaces are described in more detail below:

40 Send telegram

The sendTelegram method sends a telegram that was generated by a data source. Telegrams the sent via this interface always expect a refuse or accept response.

45 Send telegram without reply

The sendLastTelegram method sends a telegram to which no response is expected from the data source will, e.g. B. the telegram for logging off variables.

50 Generate client ID

The maketJniquelD method is used to receive a new client ID, which is then included with the individual orders can be passed. The method does not require any input parameters. A client ID is used as a return parameter as String returned.

To illustrate the communication flow, the following is an example of the variable registration for visualization a system graphic, for example a process picture, is explained:

The client 5 and the system graphics module 8 run in a Java applet. This means that there is no TCP / EP connection here needed. After calling the corresponding method 9, the client 5 assembles the associated telegram 10. The telegram 10 is automatically expanded by the client 5 to include a so-called client ID, which is a string represents. This clearly identifies the registration request via this TCP / IP connection. the Client ID is used for subsequent actions relating to this login request.

The telegram 10 generated in this way is sent from the client 5 to the server 4 via a TCP / IP connection. the When the telegram 10 arrives, server 4 checks whether there is already a registration for this module 8. Is this if this is not the case, a new ID number in the server 4, the so-called broker ID, is assigned for this order which then the registration of this module 8 is managed. In the received telegram 10, the client ID replaced by the broker ID and the order 14 is forwarded to the corresponding adaptation module 3. If for this one Block already has a registration from another client, no telegram is sent to the adaptation module 3

forwarded, instead a telegram 12, a so-called positive acknowledgment, is sent directly to the client 5 with the Client ID returned.

The adaptation module 3 processes the registration 14 for the pad 8 and sends a positive or negative acknowledgment telegram 13 back to server 4. This telegram 13 again contains the broker ID that was received in Telegram 14 was included.

The server 4 can use this broker ID to send the order to a specific client or to a specific one

Assign client ID. In the received response telegram 13, the broker ID is now replaced by the client ID and the response telegram 12 is forwarded to the client 5. Depending on the positive or negative acknowledgment, the client 5 receives the corresponding method called up in the respective module 8, represented here by the one marked with 15 Arrow, where the actual processing then takes place. These methods are outlined above.

Furthermore, error handling is handled within the client 5 using different methods. One of them on the one hand that the TCP / EP connection to the server 4 was properly closed, on the other hand the error occur when using the TCP / IP connection.

For this purpose, the following two methods are used, which are automatically called by the client 5:
15th

TCP / IP connection closed (TCP closed)

The method TCP closed is called when the TCP / IP connection is properly closed in the client. The method requires the following parameters:
TCPConnection: The TCP / IP connection that was closed.

Faulty TCP / IP connection (TCP error)

The method TCP error is called in the case of an error in the TCP / IP connection in the client. In the method, the faulty TCP / IP connection is closed. The method requires the following parameters:
TCPConnection: the TCP / IP connection that caused an error
TCPException: the generated exception that contains an indication of the error.

Furthermore, the client 5 can be adapted to special requirements via various parameters Take into account the properties of the client 5.

The following parameters can be used:

DebugMode: is used to control the debug mode in the client. If the debug mode is switched on, messages output on the console in the web browser.

TCPBuffer: the size of the TCP / TP buffer that the client is using. The size is, for example, between 4 Kbytes and 64 Kbytes.

While the client 5 enables access to various methods through the modules 6, 7 and 8, the Server 4 does not offer any public methods for access, since access is only possible via the client 5 and the adaptation module 3 to be held. The curve block 6, the message block 7 and the system graphic block 8 cannot therefore directly access the methods of server 4.

Like the client 5, the server 4 can be adapted using various parameters and special requirements. When the server 4 is started, the parameters are entered via the command line, for example.

The following parameters can be used:
Port: is used to select the server socket.

Error handling is carried out independently by the server 4. Different error cases, especially with regard to the connections, can be intercepted.
The following errors can be used:

- Connection breakdown to a client

In the event of a break in the TCP / IP connection to a client, the server will use that of this client logged-on variables are logged off from the associated adaptation module.

- Connection breakdown to an adaptation module

If the TCP / IP connection to an adaptation module breaks down, all clients that receive variables from this adapt are informed of the breakdown of the connection. To do this, the server sends a shutdown telegram to these clients. The client is then responsible for further processing this error message.
- Incorrect connection establishment to an adaptation module

If an error occurs when establishing a connection to an adaptation module, the requesting module is first sent Client sent a refuse telegram from the server. Upon receipt of the refuse telegram, the client can send suitable Take action.

The adaptation modules 3 are responsible for the connection to a special control system 2. For this purpose, the adaptation module 3 must convert the telegrams 14 arriving from the server 4 via a TCP / IP connection into corresponding commands to the control system 2. The telegrams 14 to be processed by the adaptation module 3 include, for example, error handling with regard to the connection to the server 4 or to the control system 2.
The adaptation module 3 has to take into account the following cases, for example:

- Proper shutdown of the adaptation module

If the adaptation module is shut down, a shutdown telegram is sent to all connected servers. The servers can forward this telegram to the corresponding clients.

- TCP / EP connection to a server aborted

The adaptation modules are responsible for all registrations that have been carried out by the disturbed server are to be ended by logging out to the control system. Telegrams sent by the control system to the disturbed server can be discarded by the adaptation modules.

- Error during job execution in control system 5 The adaptation modules can send telegrams that arrive from a server with a negative acknowledgment (refuse telegram) send back.

- Proper shutdown of the control system

If the control system is shut down, a shutdown telegram is sent to all connected servers. The servers can forward this telegram to the corresponding clients. 10

The adaptation module 3 itself does not offer any public methods of access, since access is only possible via the server 4 takes place. The components or modules 6, 7 and 8 for visualizing input and display elements take effect thus not directly to the methods of the server 4.

The adaptation module 3 can be set using various parameters, which can be used, for example, as command line 15 parameters can be entered when starting the adaptation module 3. The parameters are specific to the control system.

The adaptation module 3 confirms the method call to the server 4 via an acknowledgment telegram 13 and delivers the corresponding Data back.

The telegrams used by the system are composed of individual parameters, for example are all separated by a separator. The parameters are basically transmitted as ASCH strings carry. The telegram must end with an end character, for example with a "Vn". The telegrams are between a client 5, a server 4 and an adaptation module 3 exchanged.

A telegram can be structured as follows:

version / RQID / TTD / data 25

version:

Telegram version "V1.0"

Request identifier 30

The job identifier specifies the job that the recipient of the telegram has to carry out.

startVarUpdate: variable update

start: 35

stop VarUpdate: variable update

to stop:

startMsgUpdate: Start message update

stopMsgUpdate: Stop the update of the message

getVarArchiv: Reading a variable archive 40

getMsgArchiv: Reading a message archive

setVar: write a variable

get Van One-time reading of a variable

setMsg: message operation

accept: positive acknowledgment 45

refuse: Negative receipt

shutdown: The system was shut down

new Van new variable value

newMsg: new message record

stop: end of a telegram sequence 50

login: login of a client to the server

acceptlogin: Login refused

refuselogin: Rejection of a registration

data: The structure of the data depends on the job ID. The exact structure is the respective order volume To be taken from the spelling.

The date and time are shown in the telegrams as a character string. Represent the date and time the so-called GMT time. The display takes place, for example, with the following format:

Day.Month.Year-Hour: Minute: Second: Milliseconds 60

The individual orders or order telegrams can be structured as follows.

Start variable update "startVarUpdate"

65 Description

The job is used to register a variable for updating. The registered variable is taken from the current

rush process image of the addressed control system read.

Telegram structure

version / RQID / IID / host / variable / cycleTime

parameter

version: Telegram version RQID: Request ID of the triggering job HD: Job identifier = startVarUpdate host: Name of the computer on which the addressed control system is located. The name must be on the computer of the Known to the server variable: Name of the variable to be updated. The syntax of the variable name is system-dependent. cycletime:

0 spontaneous update> 0 cycle time in ms

End variable update "stopVarUpdate"

description

The job is used to deregister a registered variable from the update. Telegram structure

version / RQID / HD

Parameter 30

version: Telegram version RQID: Request ID of the triggering job HD: job identifier = stop VarUpdate

Start message update "startMsgUpdate"

description

The job is used to register to receive current reports. 40

Telegram structure

version / RQID / HD / host / info / cycleTime parameter

version: Telegram version RQID: Request ID of the triggering job HD: Job ID = startMsgUpd host: Name of the computer on which the addressed control system is located. The name must be on the computer of the Server.

info: The character string contains system-specific additional information that is evaluated by the addressed control system will. In the control system, this parameter consists of the format name with which the message text is prepared shall be.

cycleTime: This parameter should normally be set to 0 (spontaneous update). Only with reporting systems that are based on a database, it may be necessary to query the data cyclically. 0 spontaneous update> 0 cycle time in ms

End message update "stopMsgUpdate"

description

The purpose of the job is to end the registration system. 65

Telegram structure
version / RQID / HD

Parameter 5

version: Telegram version

RQID: Request ID of the triggering order

IID: job identifier = stopMsgUpdate

Read tag from archive "getVarArchiv"

description
The job is used to read tags from the archive. 15th

Telegram structure
version / RQrD / HD / host / variable / archive / filter

parameter

version: Telegram version
RQID: Request ID of the triggering order

ITD: Job ID = getVarArchiv 25

host: Name of the computer on which the addressed control system is located. The name must be on the computer of the Server.

variable: Name of the variable to be read. The syntax of the variable name is system-dependent, archive: The archive name is only relevant for database-oriented control systems. The syntax of the archive name depends on the system. If the parameter is not used, "unused" must be entered there. 30 filter: SQL statement for filtering data records from the archive. If no filter is used, enter "unused".
Syntax:

where DATE {<, =,>,> =, <=} 'day.month.year.hour: minute: second.millisecond' [AND DATE]

35 Read messages from the archive "getMsgArchiv"

description

The job is used to read messages from the archive. 40

Telegram structure

version / RQrD / HD / host / variable / archive / filter

45 parameters

version: Telegram version
RQID: Request ID of the triggering order

HD: job identifier = getMsgArchiv 50

host: Name of the computer on which the addressed control system is located. The name must be on the computer of the Server.

info: The character string contains system-specific additional information that is evaluated by the control system addressed will. With the cle control system, this parameter consists of the format name with which the message text is prepared shall be. 55

archive: The archive name is only relevant for database-oriented control systems. The syntax of the archive name is system-dependent. If the parameter is not used, "unused" must be entered there. Filter: SQL statement for filtering data records from the archive

Write variable value "setVar" 60

description

This job changes a variable value in the process image.

65 Telegram structure

version / RQrD / HD / host / variable / value / user

parameter

version: Telegram version
RQID: Request ID of the triggering order
IID: job identifier = setVar

host: Name of the computer on which the addressed control system is located. The name must be on the server computer be known.

variable: Name of the variable to be changed. The syntax of the variable name is system-dependent, value: The archive name is only relevant for database-oriented control systems. The syntax of the archive name depends on the system. If the parameter is not used, "unused" must be entered there, user: The name of the user who performed the operation.

Read variable value "getVar" Description

This job is used to read the value of a variable once.

Telegram structure

version / RQID / HD / host / variable

parameter

version: Telegram version

RQID: Request ID of the triggering order

IID: job identifier = getVar

host: Name of the computer on which the addressed control system is located. The name must be known on the server computer.
variable: Name of the variable to be read. The syntax of the variable name is system-dependent.

Operate message "setMsg"

description
35

The job is used to operate a message, i.e. messages can be acknowledged, deleted and commented on will.

Telegram structure
40

version / RQrD / HD / host / message / function / value / user

parameter

version: Telegram version

RQID: Request ID of the triggering order

IID: job identifier = setMsg

host: Name of the computer on which the addressed control system is located. The name must be known on the server computer.
message: Unique number of the message. Is treated differently by the control systems.

time: Date / time the message was generated

class: message class

state: message status function:

Operation function:
acknowledge (acknowledge message)

delete (delete message)

comment

value: Additional parameters for the function. The parameter is currently only relevant for the "Comment message" function.

The comment is also transmitted here.
user: The name of the user who performed the operation.

Positive, negative and error messages and the like can be used as acknowledgment telegrams. The following acknowledgment telegrams can be structured as follows:

Positive acknowledgment "accept" 65

description

The job is used to positively acknowledge a request.

Telegram structure
version / RQID / HD

Parameter 5

version: Telegram version

RQID: Mirroring the request ID of the triggering job

HD: order identifier = accept

Negative receipt "refuse"

description
The job is used to acknowledge a request negatively. 15th

Telegram structure
version / RQID / nD / refuserD / description

parameter

version: Telegram version

RQID: Mirroring the request ID of the triggering job

HD: job identifier = refuse 25

refuselD: Number that describes the reason for the rejection

description: Additional text that describes the reason for the rejection

New variable value "newVar"

30 Description

The telegram is used to transfer variable data records. Depending on the registration, these are current Values from the process image or archive values.

35 Telegram structure

version / RQrD / HD / value / time / state

Parameter 40

version: Telegram version

RQID: Mirroring the request ID of the triggering job

HD: job identifier = refuse

value: New value of the variable. Numerical values are always transferred as converted double values. 45

time: time stamp of the associated Y value. The fair value is shown in the presentation. day.month.year-hour: minute: se-

customer.millisecond

state: Status of the variables

New message "newMsg" 50

description

The telegram is used to transmit message data records. Depending on the registration, these are current Messages or archive messages. 55

Telegram structure

version / RQrD / HD / message / time / class / state / string / comment / bgcolor / fgcolor / bold / italic / underline

60 parameters

version: Telegram version

RQID: Mirroring the request ID of the triggering job

HD: job identifier = newMsg 65

message: Unique number of the message. Is treated differently by the control systems.

time: Date / time the message was generated

class: message class

state: message status
string: plain text of the message
comment: message comment

bgcolor: Background color of the message as an RGB value (for example 255.255.255) fgcolor: Foreground color of the message as an RGB value (e.g. 0.0.0) bold: Display text in bold. 0 = no; 1 = yes. italic: display text at an angle. 0 = no; 1 = yes. underline: make text underlined. 0 = no; 1 = yes.

Shutdown "shutdown"

description

The job is to inform the client that a component has ended. 15th

Telegram structure

version / RQID / nD / shutdownlD / description parameter

version: Telegram version

RQID: Mirroring the request ID of the triggering job IID: job identifier = shutdown

shutdownID: Number describing the reason for the shutdown description: Additional text that describes the reason for the shutdown

Stop "stop" description

The "stop" telegram marks the end of a telegram sequence.

Telegram structure 35

version / RQID / HD

parameter

version: Telegram version

RQID Mirroring the request ID of the triggering job IID: job identifier = stop

Login "login" 45

description

A client tries to log into the server via the "login" telegram. Telegram structure

version / RQID / HD

Parameter 55

version: Telegram version

RQID: Login ID = FFFFFFFF HD; Job ID = login

Accept login "acceptlogin" 60

description

The server confirms the login of a client via the "acceptlogin" telegram and assigns it an ID. Telegram structure

version / RQID / HD / clientid

10

parameter

version: Telegram version

RQID: unused

IID: order identifier = acceptlogin 5

clientid; ID that the server assigns to its clients

Reject login "refuselogin"

Description 10

The server reports via the "refuselogin" telegram that a registration was not accepted.

Telegram structure

version / RQrD / HD / description

parameter

version: Telegram version 20

RQID: unused

HD: order identifier = acceptlogin

clientid: ID that the server assigns to its clients

description: Description of the rejection

Access to individual modules 6, 7 and 8 for generating input and display elements consists of three 25 individual phases:

1. Registration for the process variable via the job, for example start VarUpdate

2. Information of the client about new values of the block, for example with the job newVar

3. Deregistration for the block, for example via the stop VarUpdate 30 job The individual phases can be represented as follows:

start VarUpdate

startVarUpdate

-> Register variable

refuse

40

< Variable could not be registered

will

accept - '' 45

< Variable registered successfully

newVar ⁵⁰

<; - new variable value

shutdown .

Θ < System was terminated

■ s topVar Update '' ₆₀ ^: >'Log off variable

In order to visualize curves with curve module 6, this receives data from current or archived process data. Depending on the type of process data, i.e. current or archived, different jobs are used. the
Orders to request current curve data consist of three individual phases: 65

1. Registration for the process variable, for example via the startTagLog job.

2. Information from the client about new values of the process variable, for example with the job newVar.

3. Deregistration for the process variable, for example via the stopTagLog order. The individual phases with the associated applications look like this:

₅ startTagupd

•> Register variable

refuse

¹⁰ Θ < Variable could not be registered

will be accept

< Variable registered successfully

_20th newTag

< new variable value

shut down

Θ i System was terminated

^30th stopTagLog

-> Log off variable

Access to process tags for the visualization of curve progressions with archived data also consists of 35 three phases:

1. Registration for the process variable, for example via the getTagArch job.

2. Information from the client about new values of the process variable, for example with the job newTag.

3. Automatic logoff for the process variable, for example after stop. 40 The individual phases with the associated applications are as follows:

12th

getTagArch
•> Read archive

refuse ⁵

Θ < Archive could not be read

accept

< Archive can be read

newTag

< new variable value

shut down

Θ < System was terminated

stop

> Finished reading archive

Different jobs are used to visualize current or archived messages.
Access to current messages from a process variable consists of three individual phases:

1. Registration for messages from the process variable, for example via the startMsgLog job.

2. Information of the client about new messages of the process variable, for example with the job newMsg. 35

3. Deregistration for messages from the process variables, for example via the stopMsgLog job.

The individual phases with the associated orders are as follows:

startMsgLog ₄₀

•: > Register reporting service

refuse

© < Service could not be registered ⁴⁵

will

accept

< Service successfully registered

newMsg ₅₅

<new message

shut down
Θ <System was terminated

stopMsgLog

> Unsubscribe from the reporting service

Access to archived messages of a process tag consists of three individual phases:

1. Registration for the process variable, for example via the order getMsgArch.

2. Information of the client about the individual archived messages of the process tag, for example with the 5 Order newMsg.

3. Deregistration for the process variable, for example via the order stop.

The individual phases with the associated orders look like this:

₁₀ getMsgArch

-> read archive

is refuse

© < Archive could not be read

accept

< Archive can be read

newMsg

<new message record

shut down

>< System was terminated

© stop

< Reading archive finished

The system offers two different types of so-called message windows for the visualization of messages on, a so-called current message window and a so-called selected message window.

The current message window shows the current incoming messages in the correct chronological order. The current one Message window can be adapted to the respective application with parameterizable filters. Messages yours 45 Change status are updated or deleted in the respective display element.

In the so-called selected message window, messages from a message archive are displayed in the correct chronological order. Message operations can be carried out from the selected message window, for example individual and group acknowledgments, commenting on messages, displaying and changing info texts, selecting images, deleting messages, setting selections. A message structure can look as follows (cf. also the message structure shown in the individual lines from left to right in Fig. 3):

Date / time start of message, identify systems, message class, message status, message text, message number, message duration and process value.

Different message states and message classes can be color-coded.

With the curve block, archived process values and process values from system graphics are graphically converted into a Kur-55 venform shown. The curve block offers the following functionality, for example:

- Representation of any number of curves

- Curve display with different colors, line types and fill patterns

- Representation of the curves as a polygon, step curve and single points

₆₀ _ Y-axes separately for each curve or for several curves simultaneously with automatic or manual scaling and labeling

- An X-axis with scaling and labeling, optionally as a time or value axis

- Scrolling of static curves, if their scope exceeds the display area, separately for all axes.

65 - Dynamic assignment of color values for individual curves, e.g. B. to change the color of the curve in the event of limit violations

to be able to switch.

- Display of the curve values using a ruler.

- Enlargement (zooming) of sections

- Overlaying the curve area with a grid

- Show a legend with additional information

- Creation of cumulative curves

- Online changing of parameters.

The system graphics module 8 is used on the one hand to display current control system data, for example process data Process images and, on the other hand, for entering new control system values. For example, the visualization of a plant diagram is carried out via a single Java applet. The Java applet contains visual and non-visual Java components that are parameterized using certain properties. An additional parameterization of the Java applet is not necessary.

The visual components of the Java applet are used to represent basic graphic elements such as lines, Circles, rectangles and the like, graphics and control elements such as buttons and the like are used. the Non-visual components serve to connect to certain process variables given in the respective control system.

Communication between the individual components is controlled via so-called Java events.

The network connection to the server 4 is implemented via the client 5. There is a corresponding client component embedded in the respective applet.

Fig. 2 is the architecture of a Java applet for visualization of a graphic system, for example, illustrated a plant picture. An exemplary embodiment of such a system diagram is shown in FIG. 5. The TCP / IP connection to the server 4 is shown in FIG. 2 by the arrow labeled 11.

The non-visual components are used to connect the system image to the process variables of a control system. A distinction must be made between elements and components for outputting variable values from the control system and elements or components for entering variable values into the control system.

The individual elements or components have uniform interfaces that are used for the chaining of individual non-visual components are designed. Thus, several non-visual output components can be combined into one Processing chain are linked. Each component has an internal state, for example is managed as a double value. The individual methods can be used to read and write to this internal state can be accessed. For each non-visual component the name of the respective process variable and the respective Computer name on which the associated control system is located must be specified. The non-visual components are initialized by the client 5 when the applet is started. For this purpose, a so-called event is sent by the client, whereby the corresponding method is carried out in the non-visual components. In this method will the registration of the element or the component for the entered process variable is carried out.

The output elements or components include components for connection to a data source, converter, which convert the process value into another value, for example a numerical value into a Convert strings and links that merge several process values.

The following interface methods must be implemented by the respective components:

Input methods (newVar)

To set the internal state of the output component, several newVar methods with different Transfer parameters offered. The method newVar with the following parameters is used by the client component called when a new process value is present:

String: The associated client ID that was returned when logging on for this process variable.
String: The new value of the process variable as a string.

In addition to these transfer parameters, there is the newVar method with other types for the value transfer of the process variable. The process value can also be transferred as a double, float, int or long.

45 output methods (getXxxValue)

Various get methods are available to read the internal status of the output component. The following methods can be used:

getDoubleValue: The method returns the internal status as a double.

getFloatValue: The method returns the internal status as float.
getlntValue: The method returns the internal status as an int.
getLongValue: The method returns the internal status as long.
getStringValue: The method returns the internal status as a string.

55 Special Output Methods

There are special methods for the converter and link components to access the converted and linked To be able to access values. A detailed description of these methods can be found in the corresponding description of the method.

In order to forward values entered by the user via the client 5 to the control system 2, an input element is used or an input component is required. The input element converts the entered value to a string and sends it with the required information to the client, which then sends a telegram 10 to the server 4. The internal state of the input element or the input component is determined by various transfer parameters affected methods.

For example

SetDoubleValue: The method receives a double value as a transfer parameter.
setFloatValue: The method receives a float value as a transfer parameter.
setlntValue: The method receives an int value as a transfer parameter.
setLongValue: The method receives a long value as a transfer parameter.
setStringValue: The method receives a string value as a transfer parameter.

In addition, a corresponding telegram for setting variable values is sent from each method via the client 5 discontinued.

The connected process values are graphically displayed via the visual components or elements. The representation ranges from the purely textual to a symbolic representation of values. The individual elements include primitive, graphic components, for example for circles, lines and the like, complex graphic Components, for example for images and the like, as well as so-called GUI elements, for example checkboxes, Buttons and the like.

Each visual component offers specific access methods over which the graphical appearance of the component can be influenced.

The communication between the visual and the non-visual elements or components is, as already explained, controlled via so-called events. To do this, components log on to other components. The interconnection is carried out purely graphically, for example with the appropriate editors.

If the value of a non-visual component changes, an event is generated after the value change. When triggered This event is then checked to see which components are registered for this event of the generating component to have. The registered components are informed about the triggering of the event and then corresponding Methods activated in the respective target components. This mechanism can be so extensive Processing chains are implemented.

Furthermore, data can be transferred to the respective system graphic using special functions, for example for simulation which can be used for simulation and thus also for training users.

In Figs. 3, 4 and 5, an embodiment for different input and display elements 17 is shown in each case, which are operated and monitored by means of a web browser, the header is indicated here at 16.

The exemplary embodiments shown above serve for explanation and are not restrictive.
30th

Claims (8)

Claims 1. A method for generating a surface for operating and monitoring control systems (2), in particular for process and production systems, with information from one in the area of control systems (2) to at least one control system (2) adaptable server computer (1) via a client-server computer network a client computer (5) in input and display elements (19) are viusalized. 2. The method according to claim 1, characterized in that the input and display elements (19) can be freely parameterized and are configurable. 3. The method according to claim 1 or claim 2, characterized in that the client-server computer network is an intranet and / or internet. 4. The method according to one or more of claims 1 to 3, characterized in that the visualization takes place by means of a web browser (18). 5. The method according to one or more of claims 1 to 4, characterized in that the input and display elements (19) can be generated by the client computer (5). 6. The method according to one or more of claims 1 to 5, characterized in that the input and display elements (19) can be generated using Java applets. 7. The method according to one or more of claims 1 to 6, characterized in that the input and display elements (19) can be generated using Java beans. 8. The method according to one or more of claims 1 to 7, characterized in that the input and display elements (19) Include messages, curves and / or system graphics. For this 5 page (s) drawings