WO2004049156A2 - Verfahren und system zur transformation von programmen, die sich auf die softwarekonfiguration eines verteilten leitsystems beziehen - Google Patents

Verfahren und system zur transformation von programmen, die sich auf die softwarekonfiguration eines verteilten leitsystems beziehen Download PDF

Info

Publication number
WO2004049156A2
WO2004049156A2 PCT/EP2003/013009 EP0313009W WO2004049156A2 WO 2004049156 A2 WO2004049156 A2 WO 2004049156A2 EP 0313009 W EP0313009 W EP 0313009W WO 2004049156 A2 WO2004049156 A2 WO 2004049156A2
Authority
WO
WIPO (PCT)
Prior art keywords
control system
software configuration
state
text
information
Prior art date
Application number
PCT/EP2003/013009
Other languages
English (en)
French (fr)
Other versions
WO2004049156A3 (de
Inventor
Peter Bort
Rainer Drath
Alexander Fay
Luca Cavalli
Massimo Scarpellini
Original Assignee
Abb Research Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Abb Research Ltd. filed Critical Abb Research Ltd.
Priority to AU2003288131A priority Critical patent/AU2003288131A1/en
Publication of WO2004049156A2 publication Critical patent/WO2004049156A2/de
Publication of WO2004049156A3 publication Critical patent/WO2004049156A3/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/656—Updates while running

Definitions

  • the invention relates to a method and a system for transforming first information in a first format, which describes a first software configuration of a first distributed control system, into second information in a second format, which describes a second software configuration of a second distributed control system, in particular for the Case that the first information is in a text-based programming language.
  • control systems are often used to control and / or regulate industrial processes.
  • control systems are created for the purpose of detecting and mastering the distributed structure inherent in these industrial processes via a physical distribution of control system units or control / regulation units, the control system units communicating with one another and exchanging data and / or information can.
  • a control system can record the data and / or information received from the respective process and issue instruction signals to control units, which can influence the process and determine its physical sequence, so that compliance with certain required characteristics is guaranteed or guaranteed.
  • a control system is normally described by explicit information in relation to its particular hardware / software configuration, for example by data, parameters, program descriptions or the like.
  • This information normally contains: a. Information with respect to the number, type and configuration of the 'rtsystem in the Le contained control system units and / or b. Information on the number, type and configuration of the input / output (I / O) cards connected to the control system units, and / or c. Information on the number, type and configuration of the specific means used to establish a communication link between the control system units, and / or d. Information on the number, type and structure of the means used to control the control system units, and / or e.
  • Information about the behavior of the control system units which generally comprises the programs that run on the control system units of the control system and other peripheral parameters, such as the throughput times (cycle times) of the programs, and / or f.
  • Information labels that are used to identify the various elements of a control system.
  • This invention relates to the e. Information described in the above list, especially the programs.
  • the programs or program components running on the control system units of the control system are very often procedural programs which are available in a text-based language and consist of a list of commands which are issued by the. ,
  • Commands to obtain information e.g. from a specific source of information
  • a control system may become obsolete, or, more generally, the need to control a particular industrial process with another control system that is equipped with more powerful hardware and / or software. In this case, it is necessary to install and configure the new control system and to restart the technical process control process.
  • the configuration of the new control system requires experts to revise the information relating to the software configuration of the old control system.
  • mapping tables which allow logical connections to be established between the elements of the old control system and the elements of the new control system.
  • these mapping tables are a guideline whereby the creation of the elements of the configuration of the new control system is permitted based on the elements of the configuration of the old control system.
  • some prior art methods use computerized tools. These computerized tools aim to accelerate the manual transformation or conversion by means of an automatic transformation of the information relating to the input / output configuration of the old control system.
  • EP-A-00 201 534.5, EP-A-00 201 535.2, EP-A-00 201 536.0, EP-A-00 201 549.3, and EP-A-00 201 550.1 describe a method and describes a related tool that allows automated translation or transformation, which eliminates some disadvantages of the manual or semi-automatic procedures known at the time (filing date April 28, 2000) and which for the Translation of hardware / software information of the configuration of control systems can be considered as the closest prior art.
  • EP-A-201 534.5 is described explicitly in EP-A-201 534.5, but, as indicated above, also by the characteristic features of the operating systems of the control system, such as the use of privileged (preemptive) or non-privileged (not preemptive) multitasking, the querying of events, the processing of iterative loops or the processing of interruptions.
  • This information is not explicitly shown in the software configuration, but is an inherent feature of the control system and the operating systems used in it. For this reason, this information cannot be taken into account by the procedure described in the specified patent applications.
  • the converted software configuration program can be a text-based program.
  • US 5,842,204 and US 5,768,546 describe the prior art for the translation of text-based programs. These patents describe two methods of translating computer languages from a source system to that of a target system. The main reason that the methods specified in these two patents achieve unsatisfactory results or cannot be used is that the methods are designed for standard computer programs, i.e. no text-based programs for control systems are considered here that have special characteristics and functionalities that are described in normal or conventional computers do not exist. Another reason for inadequate results from the methods described in these patents is that real-time environments cannot be considered, which is very important for control systems. Another disadvantage is that the methods described in the two patents do not translate based on a knowledge-based approach. Such a knowledge-based approach is more flexible than a hard-coded translation, as described for example in the two patents, and allows or enables the knowledge required for the translation to be collected more easily and expanded more freely.
  • the invention is based on the object of an improved method and system for transforming a first piece of information in a first format, which describes a first software configuration of a first distributed control system, into a to provide second information in a second format, which describes a second software configuration of a second distributed control system, as a result of which, in particular, the effort for manual postprocessing of computerized information is reduced or avoided.
  • This object is achieved by a method and a system for transforming a first piece of information in a first format that describes a first software configuration of a first distributed control system into a second piece of information in a second format that describes a second software configuration of a second distributed control system
  • the invention builds on the generic prior art in that in one method the runtime behavior of the first software configuration is recorded on the first control system and is taken into account in the transformation into the second information in such a way that the second control system with the second information is linked to the first Control system with the first information has the same runtime behavior.
  • the runtime behavior also referred to as execution behavior or real-time behavior
  • the disadvantages described above are reduced to a negligible degree or a negligible degree.
  • the software configuration for a control system can advantageously be represented by means of a combination of one or more text-based or non-text-based programming languages.
  • the runtime behavior for the first control system can advantageously be represented by means of a combination of one or more text-based or non-text-based programming languages.
  • the software configuration for a control system, in particular for the first control system is also displayed at the same time, this results in a particularly simple possibility of display.
  • each text-based or non-text-based programming language is not object-oriented, but is functional, procedural and based on conditional or unconditional instructions.
  • the execution behavior of the first control system is recorded and / or displayed via intrinsic features, in particular via
  • these intrinsic features can be expanded with further intrinsic or inherent features, which can also relate directly to the first and / or second system used, e.g. a system and / or programming language-specific processing of conditional instructions or statements.
  • a preferred development of the method according to the invention provides that the execution behavior of the first control system is recorded via relationships given implicitly in its software configuration.
  • the execution or runtime behavior is obtained indirectly, but in a particularly simple manner, since no analysis of the first control system itself is necessary, but only an analysis of the software configuration controlling it with regard to the execution or runtime behavior of the first control system.
  • the execution or runtime behavior of the first control system can of course also be examined directly, ie, for example an observation of the actions of the control system taking into account the software configuration.
  • the execution behavior of the first control system is converted into the second information using at least one knowledge database, the at least one knowledge database being tailored at least to the first control system.
  • elements of the first software configuration are mapped into elements of the IEC61131 languages using a set of translation rules.
  • the IEC61131 languages in particular the text-based language IEC61131 Structured Text (ST) and IEC61131 Sequential Function Chart (SFC), are particularly suitable for a platform-independent, i.e. neutral representation of programming languages.
  • a software configuration converted into this neutral representation according to the invention can be checked particularly easily and / or used to emulate a control system, and can also be converted from the neutral representation into the second software configuration in a particularly simple manner.
  • the method according to the invention preferably further provides that the execution behavior of elements of the first software configuration are represented in elements of the second software configuration and / or their arrangement therein.
  • the known translation methods can be advantageously used, taking into account the execution behavior, e.g. to those mentioned in the introduction to the description.
  • dynamic program control parameters which guide the execution of the first software configuration in the first control system can advantageously be mapped into elements of the second software configuration and / or their arrangement.
  • Such a mapping results in a particularly simple conversion or transformation, especially if this is not directly, but via the previously described neutral layer, since then only individual elements and no program control parameters have to be taken into account during the transformation from the neutral layer.
  • the first software configuration can preferably be mapped into a neutral layer that has different states that emulate an execution behavior in such a way that the first software configuration and its execution behavior are simulated in the first control system.
  • a neutral layer that has different states that emulate an execution behavior in such a way that the first software configuration and its execution behavior are simulated in the first control system.
  • the neutral layer can advantageously be based on an expanded state model, which has a basic state, a halt state, an active state, and an off state, with transitions
  • an expanded status model can be used to implement each execution behavior in a sufficient manner from a first control system to a second control system, either entire programs of the software configuration of the first control system or only parts thereof can be represented by means of the expanded status model, ie the expanded status model is represented by nesting is scalable.
  • the invention builds on the generic state of the art in that a system detects the runtime behavior of the first software configuration on the first control system and takes it into account in the transformation into the second information in such a way that the second control system with the second information also contributes to the first control system the first information has the same runtime behavior.
  • the system can advantageously represent the software configuration for a control system by means of a combination of one or more text-based or non-text-based programming languages.
  • system can advantageously represent the runtime behavior for the first control system by means of a combination of one or more text-based or non-text-based programming languages.
  • each text-based or non-text-based programming language is not object-oriented, but is functional, procedural and based on conditional or unconditional instructions.
  • the system it is preferably further provided that it detects and / or displays the execution behavior of the first control system via intrinsic features, in particular via
  • a preferred development of the system according to the invention provides that it records the execution behavior of the first control system via relationships implicitly given in its software configuration.
  • the system according to the invention can advantageously map dynamic program control parameters which guide the execution of the first software configuration in the first control system into elements of the second software configuration and / or their arrangement.
  • system according to the invention can advantageously map the first software configuration into a neutral layer that has different states that emulate an execution behavior such that the first software configuration and its execution behavior are simulated in the first control system.
  • the neutral layer in the system according to the invention can advantageously be based on an expanded state model which has a basic state, has a halt state, an active state, and an off state, with transitions
  • stop state either by means of a "stop" command to the basic state or by means of a "next" command to the active state, and elements which have been converted into elements of the software configuration of the first control system are implemented in the active state.
  • a computer program which has the features of the method according to the invention and is executed by suitable hardware leads to a preferred embodiment of the system according to the invention.
  • a computer program, in particular a computer program stored on a data carrier and having the features of the method according to the invention, is therefore expressly included in the disclosure content of the present application.
  • the first software configuration of the first control system can be translated into the second software configuration for the second control system of different types or different types.
  • Both the first configuration for the first control system and the second configuration for the second control system are intended to control or regulate the same industrial process by managing continuous control / regulation, discrete control / regulation, batches and sequences.
  • the second software configuration is to produce the same or an improved behavior with the second control system in relation to the first software configuration with the first control system. Accordingly, regardless of the language used, the second software configuration with the second control system must also have the same functional behavior and execution behavior as the first software configuration with the first control system, which is guaranteed according to the invention or at least better supported.
  • the automatic, preferably computerized tool according to the invention can feature the features of EP-A-00 201 534.5, EP-A-00 201 535.2, EP-A-00 201 536.0, EP-A-00 201 549.3, and EP-A-00 201 550.1 have tools described which are hereby incorporated by reference into this application, as a result of which the features described there can be combined in any way with those described here.
  • the tool according to the invention can manage all relevant aspects of the configuration of a control system regardless of the complexity or the number of control system units and programming languages used.
  • the computerized tool can manage the links between the different points of view and it is easily expandable in order to be able to record new types of control systems both as a source or as a target.
  • syntactic elements e.g. Statements, keywords and graphic elements
  • the text-based and / or non-text-based language of the source in syntactic elements such as Statements, keywords and graphic elements that are assigned to the text-based and / or non-text-based language of the target.
  • the program control parameters relating to the runtime can also be mapped, which can manage the execution of the programs in the real-time environment of control system units of the control system.
  • Figure 1 is an exemplary diagram of the operation of the tool according to the
  • Figure 2 shows a state graph of programs in the text-based language
  • FIG. 3 shows a state graph of a program in a neutral layer
  • FIG. 4 shows an SFC program of the state graph in the neutral layer
  • FIG. 5 incorporates the converted source program in the format shown in FIG.
  • FIG. 6 shows a structure of the converted programs in the target system
  • FIG. 7 shows an SFC translation of a program sequence that is predetermined by a structured programming language.
  • Figure 1 gives a result-oriented overview of the functioning of a system according to the invention.
  • the text-based and non-text-based languages are explained by way of example using the text-based language IEC61131 Structured Text (namely ST) and the non-text-based language IEC61131 Sequential Function Chart (namely SFC).
  • ST text-based language
  • SFC Sequential Function Chart
  • the invention can be seen generally and is independent of language. It is shown that the programs of a first control system 1, namely an SFC program 1a and a text-based program 1b, are converted or converted by translation into programs of a second control system 2, namely into a text-based program 2a and an SFC program 2b be transformed.
  • the tool described therefore converts the configuration information of the first control system from the format which relates to the development tool of the first control system to a format and structure which relate to the second control system.
  • the transformation of such a configuration includes or includes the type and number of control system units in the control system, the type, number and settings of I / O interfaces used to communicate with the process to the various control system units of the control system are connected, the required communication routes between the control system units and a higher-level monitoring means of the control system, the programs which define the behavior of the control system and which are written in different languages (not text-based and / or text-based), and the data and time relationships between the various programs.
  • the information used for the transformation is also provided in the information used for the transformation, which is used by the translation tool.
  • the information about the first control system used by the translation tool is conceptually equivalent to its configuration information, but is presented in a format which the tool can easily access and which the tool can easily manage.
  • the main aspect of this configuration tool is that the translation from text-based and / or non-text-based programming languages into other text-based and / or non-text-based programming languages, e.g. IEC61131SFC and / or ST takes place, taking into account the runtime behavior.
  • These programming languages are typically used to manage sequences and batches, although they could also be used for continuous and discrete controls.
  • the translation of text-based and non-text-based languages is shown using only the translation of a text-based language into a non-text-based language such as IEC61131SFC.
  • the procedure according to the invention is general and independent of the languages used, as indicated in FIG. 1, which shows a simplified flow diagram of the tool in a result-oriented manner.
  • the text-based code like all other programs in the control system unit, is executed at a specific rate assigned to the corresponding task. There can also be an interaction with the rest of the programs of the control system unit. Every statement or keyword in the text-based language has a well-defined functional and execution behavior.
  • the target's text-based language in this case SFC and ST, has different syntactic and semantic elements to produce the same behavior. Accordingly, the translation unit must have a set of translation rules which map the elements of the text-based language of the source to the elements of the languages of the target, for example the IEC61131 languages, which can also be used for the neutral layer advantageously provided according to the invention.
  • the translation therefore comprises two important parts:
  • the dynamic program control parameters such as State, status, mode that guide the execution of the program must be mapped.
  • the program control parameters relating to the execution time such as state, status and mode, which influence the execution of the program, can be manipulated via the execution of statements.
  • mode 2 To control a step-by-step process (mode). 2 shows an example of the text-based language TCL (Taylor Control Language), in which programs have three states: inactive, active and paused.
  • TCL Text-based language
  • the invention is not limited to the representation of TCL, but enables a general and language-independent representation.
  • FIG. 2 shows that a program can be transferred from an inactive state 3 via an activation to an active state 4, from which it can be switched back to the inactive state 3 via a termination or an abort or alternatively via a pause command in a pause state 5 can be set. From the pause state 5, the program can be switched back to the inactive state 3 by means of an abort or via a resume command back to the active state 4.
  • 2nd event i.e. an EVENT / ENDEVENT structure defines an event in a TCL program; this is used to define specific conditions according to which one or more state, status and / or mode transitions occur.
  • Time i.e. State, status and mode transitions can be manipulated in TCL programs using timeout functions.
  • an expanded state model was developed on the basis of the TCL state model, which also applies to other text-based languages used in a source. can be used for the representation of different states of a general program in a neutral layer. With this neutral representation, an intermediate step is realized when translating from the source system into the target system.
  • FIG. 3 This extended state model according to an advantageous development of the invention is shown in FIG. 3 and has a basic state 6, a halt state 7, an active state 8, and a switched-off state 9.
  • a program can be transferred from the switched-off state 9 to the basic state 6 by means of an “on” command, from which it can be transferred back to the off state 9 by means of an “off” command.
  • a program can be converted from the basic state 6 to the active state 8 by means of a "start command” and can be returned from the active state 8 to the basic state 6 by means of a "stop” command "Hal 'command are set to the stop state 7, from which it can be set to the basic state 6 either by means of a" stop "command or to the active state 8 by means of a" continue "command.
  • Fig. 4 shows how this code can be implemented with SFC.
  • This code frame here an SFC frame, can emulate the different program states shown in FIG. 3.
  • the program can either after the fulfillment of the condition T_off 11 into an SFC down state 12, which corresponds to the off state 9, or if the condition T_start 13 has been met, into an SFC Branch active state 14, which corresponds to active state 8.
  • the program can be switched from the SFC down state 12 to the SFC BaseState state 10 again under the condition T_on 15.
  • the program can branch from the SFC active state 14 either under the condition TA__stop 16 to the SFC base state 10 or under the condition TJialt 17 into an SFC stop state 18 which corresponds to the stop state 7.
  • the program can branch either to the SFC BaseState state 10 under the condition Th_Stop 19 or to the SFC active state 14 under the condition T_CONTINUE 20.
  • a converted source program is placed in the SFC active state 14 of the SFC frame, as is shown by way of example for a source program 21 likewise converted or translated into SFC in FIG. 5.
  • the execution behavior of a syntactic element of a text-based and / or non-text-based language relates to how the control system unit executes this syntactic element.
  • the syntactic element can be a normal statement that is carried out in a task together with other statements completely in a cycle time of the task, for example in a CPU time slot assigned to the task.
  • Normal_statement The execution time of a normal statement depends only on the CPU time and is always the same.
  • Interruptible statement (break_statement): The execution time of an interruptible statement depends on its functional definition. Interruptible means that the execution is stopped in a certain cycle time and is continued in the next cycle time.
  • the execution behavior of the text-based source program can be mapped to the target program. This means that the following procedural steps are only necessary if there is a different runtime behavior between the considered elements of the source system and the target system.
  • the following describes the translation of a for loop, which contains an interruptible execution branch, namely an if-then branch, and is translated from the structured programming language described below into the IEC61131 SFC shown in FIG. 7.
  • the interruptible statement here break_statement1
  • break_statement1 can be a statement that is waiting for a digital input of the assigned field to come true. In this way, the program may have to wait longer than one processing time at this point. This means that the SU unit in which this program is running ends the execution of this program in this cycle time (a kind of privilege) and continues in the next cycle time. If the digital input of the field has not yet come true, the execution of this program is ended again and continued in the subsequent throughput time, and so on.
  • the first normal statement normal_statement1 is executed before the for loop.
  • the second normal statement normal_statement2 is first executed before the branch is made on the basis of an if_condition1 condition.
  • the for loop is executed in the same throughput time if a normal branch occurs, ie if the condition if_condition1 does not exist and the else branch is therefore executed with the fifth normal statement normal_statement5.
  • the for loop is triggered when the interruptible branch occurs, i.e. if the condition if_condition1 is given, stopped at the point where the interrupt instruction exists, i.e. after the execution of the third normal statement normal__statement3 at the interruptible statement break_statement1, and started again from this point.
  • the waiting time depends on the type of interrupt instruction and the assigned parameters, e.g. can be waited for a certain time, or waited for a certain condition to come true.
  • the next fourth normal instruction normal_statement4 provided in the interruptible branch is only executed after the time specified by the interrupt instruction.
  • the process is divided into four steps and the for loop is in translated a while loop.
  • the for loop becomes a while loop because the for loop provided in ST and SFC does not allow a Boolean condition, but only the declaration of the first and last indices, ie the start value and the end value of the loop. Therefore, the loop must alternatively be stopped if the interrupt instruction can occur, which is then executed in the next step.
  • a second step S2 takes place when a first program condition 26 TRUE is fulfilled, which is always present.
  • the disadvantage of this is that execution stops after the instruction has been processed.
  • the second step S2 completely contains the while loop in its normal branch and only sets a general interrupt condition in its interruptible branch, which leads to a transition to a next step which contains the interrupt instruction and the code which is to be executed after the interrupt instruction ( see step S3).
  • the code inside the while loop has been slightly modified in relation to the source code to guarantee the same behavior.
  • the second normal statement normal__statement2 is first executed before the condition if_condition1 is checked.
  • the third statement normal_statement3 is executed within condition if_condition1 and the general break condition break_path is given, ie true. If the condition if_condition1 is not given, the fifth normal statement normal_statement5 is executed within the condition if_condition1.
  • the sixth normal statement normal_statement6 and an increment of the loop variable are executed before the while loop is ended.
  • a third step S3 or a fourth step S4 takes place.
  • the third step S3 takes place with a given second program condition 29, when the loop condition is given and the general interrupt condition is given.
  • the fourth step S4 takes place with a given third program condition 27, if the loop condition is not given and the general interrupt condition is not given.
  • a check of the check__break_statement1 interruption condition is first carried out if the general interruption condition is not given, the negated check result being assigned to the general interruption condition break_path1. This is followed by the statements that follow within the loop, namely the fourth normal statement normal_statement4 and the sixth normal statement normal_statement6, and an incrementation of the loop variables. After the third step S3, given a fourth program condition 30 that the general interruption condition does not exist, there is a jump to the second step S2.
  • step S4 the seventh normal statement normal_statement7 specified after the loop is carried out, according to which, if a fifth program condition 28 true, which is always present, is fulfilled, the previously described part of the structured programming language is completely processed.
  • check_break_statement1 statement is an expression or function that checks the state of the interrupt statement.
  • a PC running a suitable multitasking system with a graphical user interface, which preferably has the option of opening one or more windows.
  • a Java-implemented virtual machine that is adapted to the operating system and is used to execute the core functionality of the described translation tool.
  • a suitable means of accessing first and second control system data Such access to control system data will mostly be read for the configuration of the first control system and mostly write for the configuration of the second control system.
  • a suitable computer which can also be the one mentioned under 1 or connected to it, which also has a suitable connection to the database graphic layouts, as well as is used to generate the representation information for the graphs that the user wants to see during or after translation.
  • first control system a SFC program in the first control system b text-based program in the first control system second control system a text-based program in the second control system b SFC program in the second control system
  • Inactive TCL status Active TCL status TCL pause status
  • Basic status in the expanded status model Stop status in the expanded status model Active State in the extended state model Off state in the extended state model 0
  • SFC BaseState state 1 condition T_off 2 SFC down state 3 condition T_start 4 SFC active state 5 condition T_on 6 condition Ta_Stopp 7 condition T ialt 8 SFC stop state 9 condition Th_Stopp 0 condition T_continue 1 source program translated into SFC 2 basic state 3 program 1 4 program 2 5 program 3 6 first program condition 7 third program condition 8 fifth program condition second program condition fourth program condition

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Transformation einer ersten Information (1a, 1b) in einem ersten Format, die eine erste Softwarekonfiguration eines ersten verteilten Leitsystms (1) beschreibt, in eine zweite Information (2a, 2b) in einem zweiten Format, die eine zweite Softwarekonfiguration eines zweiten verteilten Leitsystems (2) beschreibt, wobei das Laufzeitverhalten der ersten Softwarekonfiguration auf dem ersten Leitsystem (1) erfasst und bei der Transformation in die zweite Information derart berücksichtigt wird, dass das zweite Leitsystem (2) mit der zweiten Information ein zu dem ersten Leitsystem (1) mit der ersten Information gleiches Laufzeitverhalten aufweist. Weiterhin betrifft die Erfindung ein entsprechendes System.

Description

Verfahren und System zur Transformation von Programmen, die sich auf die Softwarekonfiguration eines verteilten Leitsvstems beziehen
Beschreibung
Die Erfindung betrifft ein Verfahren und ein System zur Transformation einer ersten Information in einem ersten Format, die eine erste Softwarekonfiguration eines ersten verteilten Leitsystems beschreibt, in eine zweite Information in einem zweiten Format, die eine zweite Softwarekonfiguration eines zweiten verteilten Leitsystems beschreibt, insbesondere für den Fall, dass die erste Information in einer textbasierten Programmiersprache vorliegt.
Verteilte Leitsysteme bzw. verteilte Steuerungs- und/oder Regelungssysteme werden nach dem Stand der Technik häufig eingesetzt, um Industrieprozesse zu steuern und/oder zu regeln. Insbesondere werden Leitsysteme für den Zweck geschaffen, die diesen Industrieprozessen innewohnende verteilte Struktur über eine physische Verteilung von Leitsystem-Einheiten bzw. Steuerungs-/Regelungs-Einheiten zu erfassen und zu beherrschen, wobei die Leitsystem-Einheiten miteinander kommunizieren und Daten und/oder Information austauschen können.
Ein Leitsystem kann die vom jeweiligen Prozess erhaltenen Daten und/oder Informationen erfassen und Anweisungssignale an Steuereinheiten abgeben, die den Prozess beeinflussen und seinen physikalischen Ablauf bestimmen können, damit die Einhaltung bestimmter benötigter Merkmale garantiert bzw. gewährleistet wird.
Ein Leitsystem wird normaler Weise durch explizite Information in Bezug auf seine besondere Hardware-/Softwarekonfiguration beschrieben, z.B. durch Daten, Parameter, Programmbeschreibungen oder Ähnliches. Diese Information enthält bzw. beinhaltet normaler Weise: a. Information in Bezug auf die Anzahl, die Art und die Konfiguration der in dem Le'rtsystem enthaltenen Leitsystem-Einheiten, und/oder b. Information über die Anzahl, die Art und die Konfiguration der an die Leitsystem- Einheiten angeschlossenen Eingabe-/Ausgabe- (E/A) Karten, und/oder c. Information über die Anzahl, die Art und die Konfiguration der spezifischen Mittel, die zum Aufbau einer Kommunikationsverbindung zwischen den Leitsystem-Einheiten verwendet werden, und/oder d. Information über die Anzahl, die Art und den Aufbau der Mittel, die zur Steuerung der Leitsystem-Einheiten verwendet werden, und/oder e. Information über das Verhalten der Leitsystem-Einheiten, welche im Allgemeinen die Programme, die auf den Leitsystem-Einheiten des Leitsystems ablaufen, und andere Randparameter umfasst, wie z.B. die Durchlaufzeiten (Zykluszeiten) der Programme, und/oder f. Informationsetiketten, die zur Identifikation der verschiedenen Elemente eines Leitsystems verwendet werden.
Diese Erfindung bezieht sich auf die unter e. der obigen Liste beschriebene Information, insbesondere die Programme.
Die auf den Leitsystem-Einheiten des Leitsystems ablaufenden Programme bzw. Programmkomponenten sind sehr oft prozedurale Programme, die in einer textbasierten Sprache vorliegen und aus einer Liste von Befehlen bestehen, welche von dem . .
Betriebssystem des Leitsystems ausgeführt werden. Beispiele solcher Befehle oder Aussagen sind:
- Befehle zum Erhalten von Information, z.B. aus einer spezifischen Informationsquelle,
- Befehle zum Speichern und/oder Schreiben von Information,
- Funktionen, wie z.B. arithmetische Funktionen,
- bedingte Schleifen ("while", "repeat until"...),
- unbedingte Schleifen ("for ... times do", ...),
- bedingte Verzweigungen ("if ... eise", "case", ...). Die zur Beschreibung der Softwarekonfiguration eines Leitsystems verwendete Information ist durch ein geeignetes Format gekennzeichnet, weiches mit einem geeigneten Aufbau und einer geeigneten Semantik versehen ist. Der Ausdruck "Aufbau" und der Ausdruck "Semantik" beschreiben jeweils einen Satz von Regeln zur Kodifizierung und einen Satz funktioneller Beziehungen und Regeln, die ein Informationsformat kennzeichnen.
Die in einem Leitsystem erreichbare bzw. ausführbare Funktionalität wird in erster Linie durch die in den Programmen des Leistsystems angegebenen bzw. niedergeschriebenen Befehle (= die Semantik) bestimmt, welche durch Experten bei der Programmierung an ein bestimmtes Leitsystem angepasst wird, d.h. an die charakteristischen Merkmale der Betriebssysteme eines Leitsystems. Dies umfasst die Möglichkeit von Unterbrechungen (Interrupts), die Ausführungsprioritäten etc., ist aber nicht darauf beschränkt. Diese Information ist im Allgemeinen nicht explizit in der Softwarekonfiguration beschrieben, sondern ein der Ausführungsphilosophie des jeweiligen Leitsystems und seinen Betriebssystemen inhärentes Merkmal.
Mit dem Fortschreiten der Technologie kann ein Leitsystem veralten oder, allgemeiner, es kann das Bedürfnis zur Steuerung eines bestimmten Industrieprozesses mit einem anderen Leitsystem entstehen, welches mit einer leistungsfähigeren Hardware und/oder Software versehen ist. In diesem Fall ist es nötig, das neue Leitsystem zu installieren und zu konfigurieren, und den technischen Ablauf der Prozesssteuerung wieder zu starten.
Um die Kosten der Aktualisierung des Leitsystems zu minimieren, wird die sich auf die Softwarekonfiguration des alten Leitsystems beziehende Information im Allgemeinen wieder verwendet. Dieses Vorgehen impliziert es, technische Lösungen wiederzuver- wenden, die oft schon während einer langen Zeit der Steuerung durch das alte Leitsystem getestet wurden und demzufolge einen hohen Grad von Zuverlässigkeit der Prozesssteuerung sichern.
Es ist offensichtlich, dass diese technischen Lösungen auf jeden Fall verbessert werden könnten. Der Aufwand der Aktualisierung des alten Leitsystems wird bei der Wieder- Verwendung der Softwarekonfiguration des alten Leitsystems im Vergleich mit dem Aufwand zur Neugenerierung der die Softwarekonfiguration des neuen Leitsystems betreffenden Information jedoch auf jeden Fall reduziert.
Allerdings besteht aufgrund der Tatsache, dass das Leitsystem physikalisch ausgetauscht wird, unglücklicherweise nur eine geringe Möglichkeit, die sich auf die Softwarekonfiguration des alten Leitsystems beziehende Information so wie sie ist, d.h. unverändert, wiederzuverwenden, obwohl das Prozessverhalten dem Grunde nach gleich bleibt.
Durch die Inkompatibilität zwischen der Softwarekonfiguration für das neue Leitsystem und der Softwarekonfiguration für das alte Leitsystem ist zur Konfiguration des neuen Leitsystems eine von Experten durchzuführende Überarbeitung der sich auf die Softwarekonfiguration des alten Leitsystems beziehenden Information erforderlich.
Eine herkömmliche Vorgehensweise zur Ausführung dieser Konfiguration ist es, Abbildungstabellen zu verwenden, die es erlauben, logische Verknüpfungen zwischen den Elementen des alten Leitsystems und den Elementen des neuen Leitsystems aufzubauen. In der Praxis stellen diese Abbildungstabellen eine Richtlinie dar, wodurch das Erzeugen der Elemente der Konfiguration des neuen Leitsystems auf Grundlage der Elemente der Konfiguration des alten Leitsystems erlaubt bzw. ermöglicht wird. Neben einer völlig manuellen Vorgehensweise verwenden einige Verfahren nach dem Stand der Technik computerisierte Werkzeuge. Diese computerisierten Werkzeuge zielen darauf ab, die manuelle Transformation bzw. Umwandlung mittels einer automatischen Transformation der sich auf die Eingangs-/Ausgangs-Konfiguration des alten Leitsystems beziehenden Information zu beschleunigen.
In der EP-A-00 201 534.5, der EP-A-00 201 535.2, der EP-A-00 201 536.0, der EP-A-00 201 549.3, und der EP-A-00 201 550.1 werden ein Verfahren und ein sich darauf beziehendes Werkzeug beschrieben, die eine automatisierte Übersetzung oder Transformation erlauben, welche einige Nachteile der manuellen oder halbautomatischen zu der Zeit bekannten (Anmeldetag 28.04.2000) Vorgehensweisen beseitigt und welche für die Übersetzung von Hardware/Software-Information der Konfiguration von Leitsystemen als nächstliegender Stand der Technik betrachtet werden können.
Jedoch liefern die in diesen Patentanmeldungen beschriebenen Verfahren zur Transformation einer ersten Information in einem ersten Format, die eine erste Softwarekonfiguration eines ersten verteilten Leitsystems beschreibt, in eine zweite Information in einem zweiten Format, die eine zweite Softwarekonfiguration eines zweiten verteilten Leitsystems beschreibt, z.B. das in der EP-A-00 201 550.1 beschriebene Verfahren, immer noch unbefriedigende Ergebnisse. Das in den angegebenen Patentanmeldungen beschriebene Verfahren basiert auf der Analyse und Transformation von Information, die die Hardware-/Softwarekonfiguration eines Leitsystems beschreibt. Diese Information wird außerhalb des computerisierten Werkzeugs dargestellt und in dieses importiert. Ein Hauptgrund für das unbefriedigende Ergebnis der in den angegebenen Patentanmeldungen beschriebenen Verfahren ist es, dass die Funktion eines Leitsystems nicht nur von der Information bestimmt wird, die die Hardware-/Softwarekonfι- guration, wie sie z.B. in der EP-A-201 534.5 beschrieben ist, explizit beschreibt, sondern, wie zuvor angegeben, auch durch die kennzeichnenden Merkmale der Betriebssysteme des Leitsystems, wie beispielsweise die Nutzung von bevorrechtigtem (präemptivem) oder nicht bevorrechtigtem (nicht präemptivem) Multitasking, das Abfragen von Ereignissen, die Abarbeitung iterativer Schleifen oder die Abarbeitung von Unterbrechungen, bestimmt wird. Diese Information ist in der Softwarekonfiguration nicht explizit dargestellt, sondern ist ein inhärentes Merkmai des Leitsystems und der darin verwendeten Betriebssysteme. Deswegen kann diese Information durch die in den angegebenen Patentanmeldungen beschriebene Vorgehensweise nicht berücksichtigt werden.
Wird die in den zuvor genannten Patentanmeldungen beschriebene Vorgehen sweise verwendet, so wird ein konvertiertes Programm erzeugt, das von Experten umfangreich manuell überarbeitet werden muss, damit bei der Prozesssteuerung auf dem neuen Leitsystem kein unterschiedliches oder sogar fehlerhaftes Verhalten hervorgerufen wird.
Das konvertierte Programm der Softwarekonfiguration kann ein textbasiertes Programm sein. Die US 5,842,204 und die US 5,768,546 beschreiben den Stand der Technik für die Übersetzung von textbasierten Programmen. Diese Patente beschreiben zwei Verfahren, um Computersprachen von einem Quellsystem in die eines Zielsystems zu übersetzen. Der Hauptgrund, dass die in diesen beiden Patenten angegebenen Verfahren unzufriedenstellende Ergebnisse erzielen bzw. nicht verwendet werden können, ist, dass die Verfahren für Standardcomputerprogramme konzipiert sind, hier also keine textbasierten Programme für Leitsysteme berücksichtigt werden, die spezielle Charakteristiken und Funktionalitäten aufweisen, welche in normalen bzw. herkömmlichen Computern nicht existieren. Ein weiterer Grund für unzureichende Ergebnisse der in diesen Patenten beschriebenen Verfahren ist, dass keine Echtzeitumgebungen berücksichtigt werden können, was für Leitsysteme sehr wichtig ist. Ein weiterer Nachteil ist, dass durch die in den beiden Patenten beschriebenen Verfahren keine Übersetzung auf Grundlage einer wissensbasierten Vorgehensweise durchgeführt wird. Eine solche wissensbasierte Vorgehensweise ist flexibler, als eine fest-codierte Übersetzung, wie sie beispielsweise in den beiden Patenten beschrieben ist, und erlaubt bzw. ermöglicht das für die Übersetzung benötigte Wissen leichter zu sammeln und freier zu erweitern.
Zusätzlich zu den zuvor angegebenen Patenten existiert ein weiterer bedeutender Gesichtspunkt der textbasierten Übersetzung, der durch die EP 0 539 120 B1 beschrieben wird. Dieses Patent kann als Stand der Technik für die textbasierte Übersetzung auf Grundlage eines unabhängigen Baummodells erachtet werden. Das beschriebene Verfahren übersetzt das textbasierte Programm unter Berücksichtigung eines Baummodells, welches durch Parsen erzeugt wurde. Das beschriebene Verfahren liefert gute Ergebnisse bei der Übersetzung von textbasierten Sprachen, es basiert aber ebenfalls nicht auf einer Wissensbasis. Weiter werden auch hier nicht die speziellen Charakteristiken und Funktionalitäten von textbasierten Programmen in einem spezifischen Leitsystem berücksichtigt und auch auf die Merkmale von Echtzeitumgebungen, die für die in Leitsystemen ausgeführten textbasierten Programme wichtig sind, wird nicht eingegangen.
Der Erfindung liegt die A u f g a b e zugrunde, ein verbessertes Verfahren und System zur Transformation einer ersten Information in einem ersten Format, die eine erste Softwarekonfiguration eines ersten verteilten Leitsystems beschreibt, in eine zweite Information in einem zweiten Format, die eine zweite Softwarekonfiguration eines zweiten verteilten Leitsystems beschreibt anzugeben, wodurch insbesondere der Aufwand zur manuellen Nachbearbeitung einer computerisiert gewandelten Information verringert oder vermieden wird.
Diese Aufgabe wird durch ein Verfahren sowie ein System zur Transformation einer ersten Information in einem ersten Format, die eine erste Softwarekonfiguration eines ersten verteilten Leitsystems beschreibt, in eine zweite Information in einem zweiten Format, die eine zweite Softwarekonfiguration eines zweiten verteilten Leitsystems beschreibt, mit den Merkmalen der unabhängigen Ansprüche gelöst.
Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung ergeben sich aus den abhängigen Ansprüchen.
Die Erfindung baut auf dem gattungsgemäßen Stand der Technik dadurch auf, dass bei einem Verfahren das Laufzeitverhalten der ersten Softwarekonfiguration auf dem ersten Leitsystem erfasst und bei der Transformation in die zweite Information derart berücksichtigt wird, dass das zweite Leitsystem mit der zweiten Information ein zu dem ersten Leitsystem mit der ersten Information gleiches Laufzeitverhalten aufweist. Nach der Erfindung wird Information verwendet, die bis heute nicht beachtet wurde: Das Laufzeitverhalten, gleichwertig auch als Ausführungsverhalten oder Echtzeitverhalten bezeichnet, des ersten Leitsystems, z.B. über die implizite Information von intrinsischen oder inhärenten Merkmalen, die nach dieser Erfindung explizit beschrieben werden können und z.B. über eine Leitsystem-spezifische Wissensbasis zur Verfügung gestellt werden können. Durch die Verwendung dieser Information werden die zuvor beschriebenen Nachteile auf ein vemachlässigbares Maß bzw. einen vernachlässigbaren Grad reduziert.
Dabei kann die Softwarekonfiguration für ein Leitsystem in vorteilhafter Weise mittels einer Kombination einer oder mehrerer textbasierter oder nicht textbasierter Programmiersprachen dargestellt werden. Weiter kann das Laufzeitverhalten für das erste Leitsystem in vorteilhafter Weise mittels einer Kombination einer oder mehrerer textbasierter oder nicht textbasierter Programmiersprachen dargestellt werden. Insbesondere bei der gleichzeitigen Darstellung auch der Softwarekonfiguration für ein Leitsystem, insbesondere für das erste Leitsystem, ergibt sich hier eine besonders einfache Möglichkeit der Darstellung.
Im vorstehend erläuterten Zusammenhang kann in vorteilhafter Weise weiterhin vorgesehen sein, dass jede textbasierte oder nicht textbasierte Programmiersprache nicht objektorientiert, sondern funktional, prozedural aufgebaut ist und auf bedingten oder unbedingten Anweisungen basiert.
Bei dem erfindungsgemäßen Verfahren ist vorzugsweise weiterhin vorgesehen, dass das Ausführungsverhalten des ersten Leitsystems über intrinsische Merkmale erfasst und/oder dargestellt wird, insbesondere über
- die Verwendung von bevorrechtigtem oder nicht bevorrechtigtem Multitasking,
- aufruf- oder ereignisgetriebener Signalisierung,
- der Verwaltung und Ausführung von iterativen Schleifen, sowie der Möglichkeit, Schleifen zu unterbrechen und Wiedereinstiegspunkte.
Diese intrinsischen Merkmale können erfindungsgemäß mit weiteren intrinsischen oder inhärenten Merkmalen erweitert werden, die sich auch direkt auf das/ verwendete erste und/oder zweite System beziehen können, z.B. einer System- und/oder Programmiersprachenspezifischer Abarbeitung von bedingten Anweisungen oder Aussagen.
Eine bevorzugte Weiterbildung des erfindungsgemäßen Verfahrens sieht vor, dass das Ausführungsverhalten des ersten Leitsystems über implizit in dessen Softwarekonfiguration gegebene Beziehungen erfasst wird. Hierdurch wird das Ausführungs- oder Laufzeitverhalten indirekt, aber in besonders einfacher Weise erlangt, da keine Analyse des ersten Leitsystems selbst, sondern nur eine Analyse der dieses steuernden Softwarekonfiguration hinsichtlich des Ausführungs- oder Laufzeitverhaltens des ersten Leitsystems notwendig ist. Alternativ kann natürlich auch eine Untersuchung des Ausführungs- oder Laufzeitverhaltens des ersten Leitsystems direkt erfolgen, d.h. z.B. über eine Beobachtung der Aktionen des Leitsystems unter Berücksichtigung der Softwarekonfiguration.
Im Zusammenhang mit dem erfindungsgemäßen Verfahren wird weiterhin bevorzugt, dass das Ausführungsverhalten des ersten Leitsystems unter Verwendung von wenigstens einer Wissensdatenbank in die zweite Information gewandelt wird, wobei die wenigstens eine Wissensdatenbank wenigstens auf das erste Leitsystem zugeschnitten ist. Hierdurch kann ein Expertenwissen vorteilhaft für viele Transformationsprozesse zur Verfügung gestellt werden.
Bei dem erfindungsgemäßen Verfahren ist vorzugsweise weiterhin vorgesehen, dass Elemente der ersten Softwarekonfiguration über einen Satz Übersetzungsregeln in Elemente der IEC61131-Sprachen abgebildet werden. Die IEC61131 Sprachen, insbesondere die textbasierte Sprache IEC61131 Structured Text (ST) und IEC61131 Sequential Function Chart (SFC), eignen sich besonders für eine plattformunabhängige, d.h. neutrale Darstellung von Programmiersprachen. Eine nach der Erfindung in diese neutrale Darstellung gewandelte Softwarekonfiguration kann besonders einfach überprüft und/oder zur Emulation eines Leitsystems verwendet werden, sowie auch aus dieser neutralen Darstellung besonders einfach in die zweite Softwarekonfiguration gewandelt werden.
Weiter ist bei dem erfindungsgemäßen Verfahren vorzugsweise weiterhin vorgesehen, dass das Ausführungsverhalten von Elementen der ersten Softwarekonfiguration in Elemente der zweiten Softwarekonfiguration und/oder deren Anordnung darin abgebildet werden. Erfindungsgemäß kann unter Berücksichtigung des Ausführungsverhaltens in vorteilhafter Weise auf die bekannten Übersetzungsverfahren zurückgegriffen werden, z.B. auf die in der Beschreibungseinleitung genannten.
Bei dem erfindungsgemäßen Verfahren können dynamische Programmsteuerparameter, die die Ausführung der ersten Softwarekonfiguration in dem ersten Leitsystem leiten, in vorteilhafter Weise in Elemente der zweiten Softwarekonfiguration und/oder deren Anordnung abgebildet werden. Durch eine solche Abbildung erfolgt eine besonders einfache Umwandlung bzw. Transformation, insbesondere wenn dies nicht direkt, sondern über die zuvor beschriebene neutrale Schicht erfolgt, da dann bei der Transformation aus der neutralen Schicht nur einzelne Elemente und keine Programmsteuerparameter berücksichtigt werden müssen.
Weiter kann die ersten Softwarekonfiguration vorzugsweise so in eine neutrale Schicht abgebildet werden, die unterschiedliche ein Ausführungsverhalten nachbildende Zustände aufweist, dass dort die erste Softwarekonfiguration sowie deren Ausführungsverhalten in dem ersten Leitsystem nachgebildet werden. Auf diese Weise ist eine Emulation des Ausführungsverhaltens in einfacher Weise möglich, so dass dieses durch einen Experten nur nachgeprüft und ggf. in dessen Abweichungen überarbeitet werden muss.
Dabei kann die neutrale Schicht in vorteilhafter Weise auf einem erweiterten Zustandsmodell basieren, welches einen Grundzustand, einen Haltzustand, einen aktiven Zustand, und einen ausgeschalteten Zustand aufweist, wobei Übergänge
- von dem ausgeschalteten Zustand mittels eines "An"-Befehls in den Grundzustand,
- von dem Grundzustand entweder mittels eines "Aus"-Befehls in den Auszustand oder mittels eines "Starf-Befehls in den aktiven Zustand,
- von dem aktiven Zustand entweder mittels eines "Stop"-BefehIs in den Grundzustand oder mittels eines "Halt"-Befehls in den Haltzustand, und
- von dem Haltzustand entweder mittels eines "Stop"-Befehls in den Grundzustand oder mittels eines "Weiter'-Befehls in den aktiven Zustand vorgesehen sind, und wenigstens zu Elementen der Softwarekonfiguration des ersten Leitsystems gewandelte Elemente in dem aktiven Zustand implementiert werden. Durch dieses erweiterte Zustandsmodell kann erfindungsgemäß jedes Ausführungsverhalten in ausreichender Weise von einem ersten Leitsystem auf ein zweites Leitsystem umgesetzt werden. Es können entweder ganze Programme der Softwarekonfiguration des ersten Leitsystems oder auch nur Teile davon mittels des erweiterten Zustands- modells dargestellt werde, d.h. das erweiterte Zustandsmodell ist durch eine Ineinan- derverschachtelung skalierbar. Die Erfindung baut auf dem gattungsgemäßen Stand der Technik weiterhin dadurch auf, dass ein System das Laufzeitverhalten der ersten Softwarekonfiguration auf dem ersten Leitsystemerfasst und bei der Transformation in die zweite Information derart berücksichtigt, dass das zweite Leitsystem mit der zweiten Information ein zu dem ersten Leitsystem mit der ersten Information gleiches Laufzeitverhalten aufweist. Dadurch ergeben sich die im Zusammenhang mit dem erfindungsgemäßen Verfahren erläuterten Vorteile in gleicher oder ähnlicher Weise, weshalb zur Vermeidung von Wiederholungen auf die entsprechenden Ausführungen verwiesen wird.
Gleiches gilt sinngemäß für die folgenden bevorzugten Ausführungsformen des erfindungsgemäßen Systems, wobei auch bezüglich der durch diese Ausführungsformen erzielbaren Vorteile auf die entsprechenden Ausführungen im Zusammenhang mit dem erfindungsgemäßen Verfahren verwiesen wird.
Dabei kann das System die Softwarekonfiguration für ein Leitsystem in vorteilhafter Weise mittels einer Kombination einer oder mehrerer textbasierter oder nicht textbasierter Programmiersprachen darstellen.
Weiter kann das System das Laufzeitverhalten für das erste Leitsystem in vorteilhafter Weise mittels einer Kombination einer oder mehrerer textbasierter oder nicht textbasierter Programmiersprachen darstellen.
Im vorstehend erläuterten Zusammenhang kann in vorteilhafter Weise weiterhin vorgesehen sein, dass darin jede textbasierte oder nicht textbasierte Programmiersprache nicht objektorientiert, sondern funktional, prozedural aufgebaut ist und auf bedingten oder unbedingten Anweisungen basiert.
Bei dem erfindungsgemäßen System ist vorzugsweise weiterhin vorgesehen, dass es das Ausführungsverhalten des ersten Leitsystems über intrinsische Merkmale erfasst und/oder dargestellt, insbesondere über
- die Verwendung von bevorrechtigtem (präemptivem) oder nicht bevorrechtigtem (nicht präemptivem) Multitasking, - aufruf- oder ereignisgetriebener Signalisierung,
- der Verwaltung und Ausführung von iterativen Schleifen, sowie
- der Möglichkeit, Schleifen zu unterbrechen und Wiedereinstiegspunkte.
Eine bevorzugte Weiterbildung des erfindungsgemäßen Systems sieht vor, dass es das Ausführungsverhalten des ersten Leitsystems über implizit in dessen Softwarekonfiguration gegebene Beziehungen erfasst.
Im Zusammenhang mit dem erfindungsgemäßen System wird weiterhin bevorzugt, dass es das Ausführungsverhalten des ersten Leitsystems unter Verwendung von wenigstens einer Wissensdatenbank in die zweite Information wandelt, wobei die wenigstens eine Wissensdatenbank wenigstens auf das erste Leitsystem zugeschnitten ist.
Bei dem erfindungsgemäßen System ist vorzugsweise weiterhin vorgesehen, dass es Elemente der ersten Softwarekonfiguration über einen Satz Übersetzungsregeln in Elemente der IEC61131-Sprachen abbildet.
Weiter ist bei dem erfindungsgemäßen System vorzugsweise weiterhin vorgesehen, dass es das Ausführungsverhalten von Elementen der ersten Softwarekonfiguration in Elemente der zweiten Softwarekonfiguration und/oder deren Anordnung darin abbildet.
Das erfindungsgemäße System kann dynamische Programmsteuerparameter, die die Ausführung der ersten Softwarekonfiguration in dem ersten Leitsystem leiten, in vorteilhafter Weise in Elemente der zweiten Softwarekonfiguration und/oder deren Anordnung abbilden.
Weiter kann das erfindungsgemäße System in vorteilhafter Weise die erste Softwarekonfiguration so in eine neutrale Schicht abbilden, die unterschiedliche ein Ausführungsverhalten nachbildende Zustände aufweist, dass dort die erste Softwarekonfiguration sowie deren Ausführungsverhalten in dem ersten Leitsystem nachgebildet werden.
Dabei kann die neutrale Schicht in dem erfindungsgemäßen System in vorteilhafter Weise auf einem erweiterten Zustandsmodell basieren, welches einen Grundzustand, einen Haltzustand, einen aktiven Zustand, und einen ausgeschalteten Zustand aufweist, wobei Übergänge
- von dem ausgeschalteten Zustand mittels eines "An"-Befehls in den Grundzustand,
- von dem Grundzustand entweder mittels eines "Aus"-Befehls in den Auszustand oder mittels eines "Starf-Befehls in den aktiven Zustand,
- von dem aktiven Zustand entweder mittels eines "Stop"-Befehls in den Grundzustand oder mittels eines "Half-Befehls in den Haltzustand, und
- von dem Haltzustand entweder mittels eines "Stop"-Befehls in den Grundzustand oder mittels eines "Weiter"-Befehls in den aktiven Zustand vorgesehen sind, und wenigstens zu Elementen der Softwarekonfiguration des ersten Leitsystems gewandelte Elemente in dem aktiven Zustand implementiert werden.
Ein Computerprogramm, das die Merkmale des erfindungsgemäßen Verfahrens aufweist und durch geeignete Hardware ausgeführt wird, führt zu einer bevorzugten Ausführungsform des erfindungsgemäßen Systems. Ein Computerprogramm, insbesondere ein auf einen Datenträger gespeichertes Computerprogramm, das die Merkmale des erfindungsgemäßen Verfahrens aufweist, wird daher ausdrücklich in den Offenbarungsgehalt der vorliegenden Anmeldung einbezogen.
Nach der Erfindung kann die erste Softwarekonfiguration des ersten Leitsystems in die zweite Softwarekonfiguration für das zweite Leitsystem unterschiedlicher Art oder unterschiedlichen Typs übersetzt werden.
Sowohl die erste Konfiguration für das erste Leitsystem als auch die zweite Konfiguration für das zweite Leitsystem sind vorgesehen, den selben Industrieprozess zu steuern oder regeln, indem kontinuierliche Steuerung/Regelung, diskrete Steuerung/Regelung, Batches und Sequenzen verwaltet werden. Die zweite Softwarekonfiguration soll mit dem zweiten Leitsystem in Bezug auf die erste Softwarekonfiguration mit dem ersten Leitsystem dasselbe oder ein verbessertes Verhalten erzeugen. Demzufolge muss die zweite Softwarekonfiguration unabhängig von der verwendeten Sprache mit dem zweiten Leitsystem auch dasselbe funktionale Verhalten und Ausführungsverhalten zeigen, wie die erste Softwarekonfiguration mit den ersten Leitsystem, was nach der Erfindung gewährleistet oder zumindest besser unterstützt ist.
Das automatische, vorzugsweise computerisierte Werkzeug nach der Erfindung kann die Merkmale der in den EP-A-00 201 534.5, der EP-A-00 201 535.2, der EP-A-00 201 536.0, der EP-A-00 201 549.3, und der EP-A-00 201 550.1 beschriebenen Werkzeuge aufweisen, welche hiermit durch Bezugnahme in diese Anmeldung aufgenommen sind, wodurch die dort beschriebenen Merkmale mit den hier beschriebenen in beliebiger Weise kombinierbar sind. Somit kann das erfindungsgemäße Werkzeug alle relevanten Gesichtspunkte der Konfiguration eines Leitsystems unabhängig von der Komplexität oder der Anzahl von Leitsystem-Einheiten und verwendeten Programmiersprachen verwalten. Weiter kann das computerisierte Werkzeug die Verknüpfungen zwischen den unterschiedlichen Gesichtspunkten verwalten und es ist leicht erweiterbar, um neue Arten von Leitsystemen sowohl als Quelle oder auch als Ziel erfassen zu können.
Nach dieser Erfindung kann zusätzlich das Ausführungsverhalten von syntaktischen Elementen, wie z.B. Aussagen, Schlüsselwörtern und graphischen Elementen, der textbasierten und/oder nicht textbasierten Sprache der Quelle in syntaktische Elemente, wie z.B. Aussagen, Schlüsselwörter und graphische Elemente, der textbasierten und/oder nicht textbasierten Sprache des Ziels zugeordnet werden.
Weiter können nach dieser Erfindung zusätzlich die sich auf die Laufzeit beziehenden Programmsteuerparameter abgebildet werden, die die Ausführung der Programme in der Echtzeitumgebung von Leitsystem-Einheiten des Leitsystems verwalten können.
Die Erfindung wird nun unter Bezugnahme auf die beigefügten Zeichnungen anhand einer bevorzugten Ausführungsform beispielhaft erläutert, bei der insbesondere ein in einer textbasierten Sprache vorliegendes Programm in eine nicht-textbasierte Darstellung in der neutralen Ebene gewandelt bzw. transformiert wird.
Es zeigen:
Figur 1 ein beispielhaftes Diagramm der Wirkweise des Werkzeugs nach der
Erfindung; Figur 2 einen Zustandsgraphen von Programmen in der textbasierten Sprache
TCL (Taylor Control Language);
Figur 3 einen Zustandsgraphen von Programm in einer neutralen Schicht;
Figur 4 ein SFC-Programm des Zustandsgraphen in der neutralen Schicht;
Figur 5 eine Einbindung des konvertierten Quellenprogramms in den in der in Fig.
4 gezeigten Zustandsgraphen;
Figur 6 einen Aufbau der konvertierten Programme in dem Zielsystem; und
Figur 7 eine SFC-Übersetzung eines Programmablaufs, der durch eine eine strukturierte Programmiersprache vorgegeben ist.
Figur 1 gibt einen ergebnisorientierten Überblick über die Funktionsweise eines erfindungsgemäßen Systems. In der Fig. 1 sind die textbasierten und nicht textbasierten Sprachen beispielhaft mittels der textbasierten Sprache IEC61131 Structured Text (nämlich ST) und der nicht textbasierten Sprache IEC61131 Sequential Function Chart (nämlich SFC) erläutert. Die Erfindung ist jedoch allgemein zu sehen und sprachenunabhängig. Es ist gezeigt, dass die Programme eines ersten Leitsystems 1 , nämlich ein SFC-Programm 1a und ein textbasiertes Programm 1b, durch eine Übersetzung in Programme eines zweiten Leitsystems 2, nämlich in ein textbasiertes Programm 2a und ein SFC-Programm 2b, gewandelt bzw. transformiert werden.
Das beschriebene Werkzeug führt also die Konvertierung der Konfigurationsinformation des ersten Leitsystems aus dem Format, das sich auf das Entwicklungswerkzeug des ersten Leitsystems bezieht, in ein Format und einen Aufbau durch, welcher sich auf das zweite Leitsystem beziehen. Die Transformation einer solchen Konfiguration umfasst es bzw. beinhaltet, die Art und Anzahl von Leitsystem-Einheiten in dem Leitsystem, die Art, Anzahl und Einstellungen von E/A-Schnittstellen, die zur Kommunikation mit dem Prozess an die verschiedenen Leitsystem-Einheiten des Leitsystems angeschlossen sind, die benötigten Kommunikationsstrecken zwischen Leitsystem-Einheiten und einem übergeordneten Überwachungsmittel des Leitsystems, die in unterschiedlichen Sprachen (nicht textbasiert und/oder textbasiert) geschriebenen das Verhalten des Leitsystems definierenden Programme, und die Daten und Zeitbeziehungen zwischen den verschiedenen Programmen zu erfassen.
Alle Beziehungen, die in beliebiger Art zwischen Elementen der Konfiguration bestehen, werden ebenfalls in der zur Transformation benutzten Information vorgesehen, die von dem Übersetzungswerkzeug verwendet wird. Die von dem Übersetzungswerkzeug verwendete Information über das erste Leitsystem ist konzeptionell äquivalent zu dessen Konfigurationsinformation, ist aber in einem Format dargestellt, auf welches das Werkzeug einfach zugreifen kann und welches das Werkzeug einfach verwalten kann.
Der Hauptaspekt dieses Konfigurationswerkzeugs ist es, dass die Übersetzung aus textbasierten und/oder nicht textbasierten Programmiersprachen in andere textbasierte und/oder nicht textbasierte Programmiersprachen, wie z.B. IEC61131SFC und/oder ST erfolgt, wobei das Laufzeitverhalten berücksichtigt wird. Diese Programmiersprachen werden normaler weise verwendet, Abfolgen und Batches zu verwalten, obwohl sie ebenfalls für kontinuierliche und diskrete Steuerungen oder Regelungen verwendet werden könnten. Im Folgenden wird die Übersetzung von textbasierten und nicht textbasierten Sprachen beispielhaft lediglich anhand der Übersetzung einer textbasierten Sprache in eine nicht textbasierte Sprache wie IEC61131SFC dargestellt. Die Vorgehensweise nach der Erfindung ist jedoch allgemein und von den verwendeten Sprachen unabhängig, wie es in der Fig. 1 angedeutet ist, die ein vereinfachtes Ablaufdiagramm des Werkzeugs ergebnisorientiert darstellt.
Der textbasierte Code, wie alle anderen Programme in der Leitsystem-Einheit, wird mit einer bestimmten, dem entsprechenden Task zugeordneten Rate ausgeführt. Weiter kann eine Interaktion mit dem Rest der Programme der Leitsystem-Einheit stattfinden. Jede Aussage oder jedes Schlüsselwort der textbasierten Sprache weist ein wohldefiniertes funktionales und Ausführungsverhalten auf. Die textbasierte Sprache des Ziels, in diesem Fall SFC und ST, weist unterschiedliche syntaktische und semantische Elemente auf, um dasselbe Verhalten zu erzeugen. Demzufolge muss die Übersetzungseinheit einen Satz von Übersetzungsregeln aufweisen, die die Elemente der textbasierten Sprache der Quelle auf die Elemente der Sprachen des Ziels abbilden, z.B. der IEC61131 -Sprachen, die auch für die nach der Erfindung vorteilhafter Weise vorgesehene neutrale Schicht verwendet werden können.
Die Übersetzung umfasst also zwei wichtige Teile:
1. Das Ausführungsverhalten der Schlüsselworte und Aussagen der textbasierten Sprache der Quelle muss auf die Aussagen, Schlüsselworte und graphischen Elemente der SFC- und ST-Sprachen abgebildet werden.
2. Die dynamischen Programmsteuerparameter, wie z.B. Zustand, Status, Modus, die die Ausführung des Programms leiten, müssen abgebildet werden.
A) Abbildung der sich auf die Ausführungszeit beziehenden Programmsteuerparameter, wie Zustand, Status, Modus
In den textbasierten Sprachen der Quelle können die sich auf die Ausführungszeit beziehenden Programmsteuerparameter, wie Zustand, Status und Modus, die die Ausführung des Programms beeinflussen, über die Ausführung von Aussagen manipuliert werden.
Eine Manipulation dieser Parameter bietet die Mittel, um
- ein Programm zu aktivieren, abzubrechen oder in einen Pausenzustand zu versetzen (Zustand),
- unnormale Bedingungen zu definieren, detektieren und zu verwalten (Status), und
- ein Verfahren der schrittweisen Ausführung zu steuern (Modus). In der Fig. 2 ist die textbasierte Sprache TCL (Taylor Control Language) beispielhaft dargestellt, in der Programme drei Zustände aufweisen: inaktiv, aktiv und pausierend. Die Erfindung ist jedoch nicht auf die Darstellung von TCL beschränkt, sondern ermöglicht eine allgemeine und sprachunabhängige Darstellung.
Die Fig. 2 zeigt, dass ein Programm von einem inaktiven Zustand 3 über eine Aktivierung in einen aktiven Zustand 4 überführt werden kann, von welchem es über eine Beendigung oder einen Abbruch wiederum in den inaktiven Zustand 3 versetzt werden kann oder alternativ über einen Pausenbefehl in einen Pausenzustand 5 versetzt werden kann. Aus dem Pausenzustand 5 kann das Programm über einen Abbruch in den inaktiven Zustand 3 oder über einen Wiederaufnahmebefehl wieder zurück in deήi aktiven Zustand 4 versetzt werden.
In TCL existieren drei Arten der Manipulation des Zustands, Status und Modus in Programmen:
1. Demand, d.h. ein (direkter, unbedingter) Befehl, der einen Übergang von Zustand, Status oder Modus hervorruft, z.B.: Activate ('POWERUP', 3);
2. Event, d.h. eine EVENT/ENDEVENT-Struktur definiert ein Ereignis in einem TCL- Programm; diese wird verwendet, um spezifische Bedingungen zu definieren, entsprechend der einer oder mehrere Zustands-, Status- und/oder Modusübergänge erfolgen.
3. Time, d.h. Zustands-, Status- und Modusübergänge können in TCL-Programmen über Zeitablauffunktionen manipuliert werden.
Um in einem IEC61131 -basierten Zielsystem das Laufzeitverhalten eines TCL-Pro- gramms (und all der anderen Programmiersprachen für ein Leitsystem) zu emulieren, ist es nötig, die unterschiedlichen in dem Quellsystem möglichen Zustände eines TCL- Programms nachzubilden. Demzufolge wurde nach einer bevorzugten Ausführungsform der Erfindung auf Grundlage des TCL-Zustandsmodells ein erweitertes Zustandsmodell entwickelt, welches auch für andere textbasierte Sprachen, die in einer Quelle verwen- det werden können, für die Darstellung von unterschiedlichen Zuständen eines allgemeinen Programms in einer neutralen Schicht verwendet werden kann. Durch diese neutrale Darstellung wird bei der Übersetzung von dem Quell- in das Zielsystem ein Zwischen seh ritt realisiert.
Dieses erweiterte Zustandsmodell nach einer vorteilhaften Weiterbildung der Erfindung ist in der Fig. 3 gezeigt und weist einen Grundzustand 6, einen Haltzustand 7, einen aktiven Zustand 8, und einen ausgeschalteten Zustand 9 auf. Von dem ausgeschalteten Zustand 9 kann ein Programm mittels eines "An-"Befehls in den Grundzustand 6 überführt werden, von dem es mittels eines "Aus"-Befehls wieder in den Auszustand 9 überführt werden kann. Ein Programm kann von dem Grundzustand 6 mittels eines "Starf-Befehls in den aktiven Zustand 8 überführt werden und von dem aktiven Zustand 8 mittels eines "Stop"-Befehls in den Grundzustand 6 zurückversetzt werden. Aus dem aktiven Zustand 8 kann ein Programm mittels eines "Hal '-Befehls in den Haltzustand 7 versetzt werden, von dem es entweder mittels eines "Stop"-Befehls in den Grundzustand 6 oder mittels eines "Weiter'-Befehls in den aktiven Zustand 8 versetzt werden kann.
Um dieses Zustandsmodell in einem IEC61131 -basierten Zielsystem zu implementieren, ist es nötig, einen Coderahmen um den zugrunde liegenden Quellcode zu erstellen. Die Fig. 4 zeigt, wie dieser Code mit SFC realisiert werden kann. Dieser Coderahmen, hier ein SFC-Rahmen, kann die in der Fig. 3 gezeigten unterschiedlichen Programmzustände emulieren.
Von einem SFC-BaseState-Zustand 10, der dem Grundzustand 6 entspricht, kann das Programm entweder nach Erfüllung der Bedingung T_off 11 in einen SFC-Down- Zustand 12, der dem Auszustand 9 entspricht, oder unter Erfüllung der Bedingung T_start 13 in einen SFC-Active-Zustand 14 verzweigen, der dem Aktivzustand 8 entspricht. Aus dem SFC-Down-Zustand 12 kann das Programm unter der Bedingung T_on 15 wieder in den SFC-BaseState-Zustand 10 versetzt werden. Aus dem SFC- Active-Zustand 14 kann das Programm entweder unter der Bedingung TA__stop 16 in den SFC-BaseState-Zustand 10 oder unter der Bedingung TJialt 17 in einen SFC-Halt- Zustand 18 verzweigen, der dem Haltzustand 7 entspricht. Aus dem SFC-Halt-Zustand 18 kann das Programm entweder unter der Bedingung Th_Stop 19 in den SFC- BaseState-Zustand 10 oder unter der Bedingung T_CONTINUE 20 in den SFC-Active- Zustand 14 verzweigen.
Nach einer weiteren bevorzugten Ausgestaltung der Erfindung wird ein gewandeltes Quellprogramm in dem SFC-Active-Zustand 14 des SFC-Rahmens platziert, wie es beispielhaft für ein ebenfalls in SFC gewandeltes oder übersetztes Quellprogramm 21 in der Fig. 5 gezeigt ist.
Für den Fall, dass kein Programm aktiv ist, wird das ganze Untersystem in eine Art Basiszustand oder grundlegenden Zustand gesetzt. Zusätzlich kann festgelegt sein, dass nur ein Programm gleichzeitig ausgeführt werden kann. Dieses Verhalten kann mittels eines einfachen SFC-Rahmens mit einem Grundlegenden Zustand und parallelen Phasen für jedes gewandelte Quellprogramm emuliert werden. Die Fig. 6 zeigt, wie die gewandelten Quellprogramme (SFC und/oder ST) nach einem solchen Schema implementiert werden könnten. Aus dem grundlegenden Zustand 22 kann in verschiedene Programme verzweigt werden, z.B. in ein erstes Programm 23, das dem in der Fig. 5 gezeigten gewandelten Quellprogramm 21 im SFC-Code entspricht, in ein zweites textbasiertes Programm 24, oder in ein drittes Programm 25, das wiederum dem in der Fig. 5 gezeigten gewandelten bzw. transformierten Quellprogramm 21 entspricht. Nach Abarbeitung eines dieser Programme wird wieder der grundlegende Zustand 22 erreicht.
B) Abbildung des Ausführungsverhaltens der syntaktischen Elemente einer textbasierten und/oder nicht textbasierten Sprache
Das Ausführungsverhalten eines syntaktischen Elements einer textbasierten und/oder nicht textbasierten Sprache bezieht sich darauf, wie die Leitsystem-Einheit dieses syntaktische Element ausführt. Z.B. kann das syntaktische Element eine normale Aussage sein, die in einem Task zusammen mit anderen Aussagen vollständig in einer Durchlaufzeit des Tasks, z.B. in einem dem Task zugeordneten CPU-Zeitschlitz, ausgeführt wird. Es gibt aber auch andere Aussagen, die für eine bestimmte Zeit oder auf eine bestimmte Eingabe aus dem Feld warten müssen, wodurch ihre Ausführung sich über mehr als eine Durchlaufzeit erstreckt, d.h. in mehreren aufeinanderfolgenden dem Task zugeordneten Zeitschlitzen der CPU.
Die Analyse der textbasierten Sprachen ergibt, dass die folgenden syntaktischen Elemente existieren:
- Normale Aussage (normal_statement): Die Ausführungszeit einer normalen Aussage hängt nur von der CPU-Zeit ab und ist immer gleich.
- Unterbrechbare Aussage (break_statement): Die Ausführungszeit einer unterbrechbaren Aussage hängt von ihrer funktionalen Definition ab. Unterbrechbar bedeutet, dass die Ausführung in einer bestimmten Durchlaufzeit angehalten wird und in der nächsten Durchlaufzeit weitergeführt wird.
Mit Hilfe dieser Ausführungsmerkmale kann das Ausführungsverhalten des textbasierten Quellprogramms auf das Zielprogramm abgebildet werden. Das bedeutet, dass die folgenden beispielhaft dargestellten Verfahrensschritte nur notwendig sind, wenn zwischen den betrachteten Elementen des Quellsystems und des Zielsystems ein unterschiedliches Laufzeitverhalten besteht.
Im Folgenden wird die Übersetzung einer for-Schleife beschrieben, die einen unterbrechbaren Ausführungszweig enthält, nämlich einen if-then-Zweig, und aus der nachfolgend beschrieben strukturierten Programmiersprache in die in der Fig. 7 gezeigte IEC61131-SFC übersetzt wird.
normal_statement1 for J = 0 TO 15
{ normal_statement2 if(if_condition1)
{ normal_statement3 break_statement1 normal_statement4
} eise
{ normal_statement5
} normal_statement6
} normal_statement7
Die unterbrechbare Aussage, hier break_statement1 , kann eine Aussage sein, die darauf wartet, dass eine digitale Eingabe des zugeordneten Feldes wahr wird. Auf diese Weise kann es sein, dass das Programm an dieser Stelle länger als eine Durchlaufzeit warten muss. Das bedeutet, dass die SU-Einheit, in der dieses Programm abläuft, die Ausführung dieses Programms in dieser Durchlaufzeit beendet (eine Art Bevorrechtigung) und in der nächsten Durchlaufzeit weitergeführt. Ist die digitale Eingabe des Feldes jetzt noch nicht wahr geworden, so wird die Ausführung dieses Programms wiederum beendet und in der darauffolgenden Durchlaufzeit weitergeführt, und so weiter.
Die Ausführung in dem Quellsystem geschieht folgendermaßen:
- Vor der for-Schleife wird die erste normale Aussage normal_statement1 ausgeführt. - In der for-Schleife wird zunächst die zweite normale Aussage normal_statement2 ausgeführt, bevor die Verzweigung auf Grundlage einer Bedingung if_condition1 erfolgt. Die for-Schleife wird in der gleichen Durchlaufzeit ausgeführt, wenn eine normale Verzweigung auftritt, d.h. wenn die Bedingung if_condition1 nicht gegeben ist und somit der else-Zweig mit der fünften normalen Aussage normal_statement5 ausgeführt wird.
- Die for-Schleife wird bei Auftreten des unterbrechbaren Zweiges, d.h. wenn die Bedingung if_condition1 gegeben ist, an der Stelle gestoppt, an der die Unterbrechungsanweisung besteht, d.h. nach der Ausführung der dritten normalen Aussage normal__statement3 bei der unterbrechbaren Aussage break_statement1 , und nächstes Mal von dieser Stelle wieder gestartet. Die Wartezeit hängt von der Art der Unterbrechungsanweisung und den zugeordneten Parametern ab, z.B. kann für eine bestimmte Zeit gewartet werden, öder es kann darauf gewartet werden, dass ein bestimmter Zustand wahr wird.
- Nach der Unterbrechungsanweisung wird die im unterbrechbaren Zweig vorgesehene nächste vierte normale Anweisung normal_statement4 erst nach der durch die Unterbrechungsanweisung spezifizierten Zeit ausgeführt.
- Nach der Verzweigung wird in der selben Durchlaufzeit die sechste normale Aussage normal_statement6 ausgeführt.
- Nach der for-Schleife wird ebenfalls in der selben Durchlaufzeit die siebte normale Aussage normal_statement7 ausgeführt.
Bei der Analyse des Codes der strukturierten Programmiersprache ist festzustellen, dass es einen Ausführungspfad gibt, der nur aus normalen Anweisungen besteht, und einen Ausführungspfad, der eine Unterbrechungsanweisung enthält. Da wenigstens ein normaler Pfad enthalten ist, muss die Schleife kontinuierlich so oft wie möglich in einer Durchlaufzeit abgearbeitet werden, z.B. wie oben angegeben vollständig einschließlich der vor- und nachstehenden ersten und siebten normalen Aussagen normal__statement1 und normal_statement7, wenn die Durchlaufzeit lang genug ist.
Die Fig. 7 zeigt eine mögliche Lösung in dem Zielsystem. Aufgrund des unterbrechbaren Ausführungspfades ist der Ablauf in vier Schritte geteilt und die for-Schleife ist in eine while-Schleife übersetzt. Die for-Schleife wird zu einer while-Schleife, da die in ST und SFC vorgesehene for-Schleife keine Boolesche Bedingung erlaubt, sondern nur die Deklaration der ersten und letzten Indizes, d.h. des Startwerts und des Endwerts der Schleife. Deshalb muss die Schleife alternativ gestoppt werden, wenn die Unterbrechungsanweisung auftreten kann, welche dann in dem nächsten Schritt ausgeführt wird.
Nach einem ersten Schritt S1 , der lediglich die erste normale Aussage normal_statement1 enthält, um den nächsten Schritt nicht zu komplizieren, erfolgt bei Erfüllung einer ersten Programmbedingung 26 TRUE, die immer gegeben ist, ein zweiter Schritt S2. Der Nachteil daran ist, dass die Ausführung stoppt, nachdem die Anweisung abgearbeitet wurde.
Der zweite Schritt S2 enthält die while-Schleife in ihrem normalen Zweig vollständig und setzt in ihrem unterbrechbaren Zweig lediglich eine allgemeine Unterbrechungsbedingung, die zu einem Übergang in einen nächsten Schritt führt der die Unterbrechungsanweisung sowie den Code enthält, der nach der Unterbrechungsanweisung ausgeführt werden soll (siehe Schritt S3). Der sich innerhalb der while-Schleife befindliche Code ist in Bezug auf den Quellcode etwas abgeändert, um dasselbe Verhalten zu garantieren.
Insbesondere wird im zweiten Schritt S2 zunächst die allgemeine Unterbrechungsbedingung break_path definiert auf nicht gegeben, d.h. false, gesetzt, wonach die while- Schleife unter den Bedingungen der Schleifenvariablen, hier J<= 5, und der nicht gegebenen allgemeinen Unterbrechungsbedingung ausgeführt wird. In der while- Schleife wird zunächst die zweite normale Aussage normal__statement2 ausgeführt, bevor die Bedingung if_condition1 geprüft wird. Bei gegebener Bedingung if_condition1 wird innerhalb der Bedingung if_condition1 die dritte Aussage normal_statement3 ausgeführt und die allgemeine Unterbrechungsbedingung break_path auf gegeben, d.h. true, gesetzt. Bei nicht gegebener Bedingung if_condition1 wird innerhalb der Bedingung if_condition1 die fünfte normale Aussage normal_statement5 ausgeführt. Nach der Bedingung if_condition1 wird bei nicht gegebener allgemeiner Unterbrechungsbedingung break_path die sechste normale Aussage normal_statement6, sowie eine Inkrementierung der Schleifenvariablen ausgeführt, bevor die while-Schleife beendet wird. Nach dem zweiten Schritt S2 erfolgt abhängig von der allgemeinen Unterbrechungsbedingung und der Schleifenbedingung entweder ein dritter Schritt S3 oder ein vierter Schritt S4. Der dritte Schritt S3 erfolgt bei einer gegebenen zweiten Programmbedingung 29, wenn die Schleifenbedingung gegeben ist und die allgemeine Unterbrechungsbedingung gegeben ist. Der vierte Schritt S4 erfolgt bei einer gegebenen dritten Programmbedingung 27, wenn die Schleifenbedingung nicht gegeben ist und die allgemeine Unterbrechungsbedingung nicht gegeben ist.
In dem dritten Schritt S3 erfolgt zunächst bei nicht gegebener allgemeiner Unterbrechungsbedingung eine Überprüfung der Unterbrechungsbedingung check__break_statement1 , wobei der allgemeinen Unterbrechungsbedingung break_path1 das negierte Überprüfungsergebnis zugewiesen wird. Danach erfolgen die innerhalb der Schleife nachfolgenden Aussagen, nämlich die vierte normale Aussage normal_statement4 und die sechste normale Aussage normal_statement6, sowie eine Inkrementierung der Schleifenvariablen. Nach dem dritten Schritt S3 erfolgt bei einer gegebenen vierten Programmbedingung 30, dass die allgemeine Unterbrechungsbedingung nicht gegeben ist, ein Sprung zum zweiten Schritt S2.
In dem vierten Schritt S4 wird die nach der Schleife angegebene siebte normale Aussage normal_statement7 ausgeführt, wonach bei Erfüllung einer fünften Programmbedingung 28 true, die immer gegeben ist, der zuvor beschriebene Teil der strukturierten Programmiersprache vollständig abgearbeitet ist.
Das Verhalten dieser Sequenz ist sehr nahe an der Quellsequenz, mit den folgenden
Ausnahmen:
- Zwischen der ersten normalen Anweisung normal_statement1 und dem zweiten Schritt S2, in dem die Übersetzung der for-Schleife implementiert ist, liegt die Beendigung einer Durchlaufzeit und die Zuteilung der nächsten Durchlaufzeit. Bei dem Quellcode werden die erste normale Anweisung und der erste Schleifendurchlauf der for-Schleife in derselben Durchlaufzeit durchgeführt. Um hier näher am Quellcode zu sein, können der erste und der zweite Schritt S1 und S2 auch zusammengefasst werden. - Nach der Unterbrechungsanweisung stoppt die Ausführung, d.h. der dritte Schritt S3 wird der aktive Schritt. Erst in der nächsten Durchlaufzeit wird die allgemeine Unterbrechungsbedingung (break_path1) in die nicht gespeicherte Aktion berechnet. Wenn dies in derselben Durchlaufzeit wahr wird, werden die Anweisungen in der Aktion beim Verlassen ausgeführt. In derselben Durchlaufzeit kehrt die Verarbeitungsfolge in den zweiten Schritt S2 zurück. Das Problem liegt darin, dass bei unmittelbarem Wahrwerden der Unterbrechungsbedingung in Bezug auf das Quellsystem eine Durchlaufzeit verloren geht.
Diese Lösung ist skalierbar, in anderen Worten ist es möglich, die Anzahl von Alternativverzweigungen durch die Implementierung eines ähnlichen Musters zu erhöhen, wenn mehr unterbrechbare Ausführungszweige vorgesehen werden müssen. Die check_break_statement1 -Anweisung ist ein Ausdruck oder eine Funktion, die den Zustand der Unterbrechungsanweisung überprüft.
Die bevorzugte Ausführungsform des beschriebenen Werkzeugs sieht wie folgt aus:
1. Ein PC, auf dem ein geeignetes multitaskingfähiges System mit einer graphischen Benutzeroberfläche läuft, die vorzugsweise die Möglichkeit zum öffnen eines oder mehrerer Fenster hat.
2. Eine in Java realisierte virtuelle Maschine, die an das Betriebssystem angepasst ist, und verwendet wird, die Kernfunktionalität des beschriebenen Übersetzungswerkzeugs auszuführen.
3. Ein geeignetes Mittel, auf erste und zweite Leitsystemdaten zuzugreifen. Ein solcher Zugriff auf Leitsystemdaten wird für die Konfiguration des ersten Leitsystems meistens lesend und für die Konfiguration des zweiten Leitsystems meistens schreibend erfolgen.
4. Ein geeigneter Computer, der auch der unter 1. genannte sein kann oder an diesen angeschlossen ist, der einen geeigneten Ansc luss an die Datenbank mit graphischen Layouts hat, sowie verwendet wird, die Repräsentationsinformation für die Graphen zu generieren, die der Benutzer während oder nach der Übersetzung sehen möchte.
Die in der vorstehenden Beschreibung, in den Zeichnungen sowie in den Ansprüchen offenbarten Merkmale der Erfindung können sowohl einzeln als auch in beliebiger Kombination für die Verwirklichung der Erfindung wesentlich sein.
Bezugszeichenliste
erstes Leitsystem a SFC-Programm im ersten Leitsystem b textbasiertes Programm im ersten Leitsystem zweites Leitsystem a textbasiertes Programm im zweiten Leitsystem b SFC-Programm im zweiten Leitsystem Inaktiver TCL-Zustand Aktiver TCL-Zustand TCL-Pausenzustand Grundzustand im erweiterten Zustandsmodell Haltzustand im erweiterten Zustandsmodell Aktiver Zustand im erweiterten Zustandsmodell Auszustand im erweiterten Zustandsmodell 0 SFC-BaseState-Zustand 1 Bedingung T_off 2 SFC-Down-Zustand 3 Bedingung T_start 4 SFC-Active-Zustand 5 Bedingung T_on 6 Bedingung Ta_Stopp 7 Bedingung T ialt 8 SFC-Halt-Zustand 9 Bedingung Th_Stopp 0 Bedingung T_continue 1 In SFC übersetztes Quellprogramm 2 Grundlegender Zustand 3 Programml 4 Programm2 5 Programm3 6 erste Programmbedingung 7 dritte Programmbedingung 8 fünfte Programmbedingung zweite Programmbedingung vierte Programmbedingung

Claims

Patentansprüche
1. Verfahren zur Transformation einer ersten Information (1a, 1b) in einem ersten Format, die eine erste Softwarekonfiguration eines ersten verteilten Leitsystems (1) beschreibt, in eine zweite Information (2a, 2b) in einem zweiten Format, die eine zweite Softwarekonfiguration eines zweiten verteilten Leitsystems (2) beschreibt, dadurch gekennzeichnet, dass das Laufzeitverhalten der ersten Softwarekonfiguration auf dem ersten Leitsystem (1) erfasst und bei der Transformation in die zweite Information derart berücksichtigt wird, dass das zweite Leitsystem (2) mit der zweiten Information ein zu dem ersten Leitsystem (1) mit der ersten Information gleiches Laufzeitverhalten aufweist.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass die Softwarekonfiguration für ein Leitsystem (1 , 2) mittels einer Kombination einer oder mehrerer textbasierter oder nicht textbasierter Programmiersprachen dargestellt wird.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Laufzeitverhalten für das erste Leitsystem (1) mittels einer Kombination einer oder mehrerer textbasierter oder nicht textbasierter Programmiersprachen dargestellt wird.
4. Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass jede textbasierte oder nicht textbasierte Programmiersprache nicht objektorientiert, sondern funktional, prozedural aufgebaut ist und auf bedingten oder unbedingten Anweisungen basiert.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Ausführungsverhalten des ersten Leitsystems (1) über intrinsische Merkmale erfasst und/oder dargestellt wird, insbesondere über die Verwendung von
- bevorrechtigtem oder nicht bevorrechtigtem Multitasking,
- auf ruf- oder ereignisgetriebener Signalisierung,
- der Verwaltung und Ausführung von iterativen Schleifen, sowie
- der Möglichkeit, Schleifen zu unterbrechen und Wiedereinstiegspunkte.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Ausführungsverhaiten des ersten Leitsystems (1) über implizit in dessen Softwarekonfiguration gegebene Beziehungen erfasst wird.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Ausführungsverhaiten des ersten Leitsystems (1) unter Verwendung von wenigstens einer Wissensdatenbank in die zweite Information gewandelt wird, wobei die wenigstens eine Wissensdatenbank wenigstens auf das erste Leitsystem(l) zugeschnitten ist.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Elemente der ersten Softwarekonfiguration über einen Satz Übersetzungsregeln in Elemente der IEC61131 -Sprachen abgebildet werden.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Ausführungsverhaiten von Elementen der ersten Softwarekonfiguration in Elemente der zweiten Softwarekonfiguration und/oder deren Anordnung darin abgebildet werden.
10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass dynamische Programmsteuerparameter, die die Ausführung der ersten Softwarekonfiguration in dem ersten Leitsystem (1) leiten, in Elemente der zweiten Softwarekonfiguration und/oder deren Anordnung abgebildet werden.
11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die erste Softwarekonfiguration so in eine neutrale Schicht abgebildet wird, die unterschiedliche ein Ausführungsverhaiten nachbildende Zustände aufweist, dass dort die erste Softwarekonfiguration sowie deren Ausführungsverhaiten in dem ersten Leitsystem(l) nachgebildet werden.
12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass die neutrale Schicht auf einem erweiterten Zustandsmodell basiert, welches einen Grundzustand (6), einen Haltzustand (7), einen aktiven Zustand (8), und einen ausgeschalteten Zustand (9) aufweist, wobei Übergänge - von dem ausgeschalteten Zustand (9) mittels eines "An"-Befehls in den Grundzustand (6),
- von dem Grundzustand (6) entweder mittels eines "Aus"-Befehls in den Auszustand (9) oder mittels eines "Starf-Befehls in den aktiven Zustand (8),
- von dem aktiven Zustand (8) entweder mittels eines "Stop"-Befehls in den Grundzustand (6) oder mittels eines "Hal -Befehls in den Haltzustand (7), und
- von dem Haltzustand (7) entweder mittels eines "Stop"-Befehls in den Grundzustand (6) oder mittels eines "Weiter'-Befehls in den aktiven Zustand (8) vorgesehen sind, und wenigstens zu Elementen der Softwarekonfiguration des ersten Leitsystems gewandelte Elemente in dem aktiven Zustand (8) implementiert werden.
13. System zur Transformation einer ersten Information (1a, 1b) in einem ersten Format, die eine erste Softwarekonfiguration eines ersten verteilten Leitsystems (1) beschreibt, in eine zweite Information (2a, 2b) in einem zweiten Format, die eine zweite Softwarekonfiguration eines zweiten verteilten Leitsystems (2) beschreibt, dadurch gekennzeichnet, dass es das Laufzeitverhalten der ersten Softwarekonfiguration auf dem ersten Leitsystem (1) erfasst und bei der Transformation in die zweite Information derart berücksichtigt, dass das zweite Leitsystem(2) mit der zweiten Information ein zu dem ersten Leitsystem (1) mit der ersten Information gleiches Laufzeitverhalten aufweist.
14. System nach Anspruch 13, dadurch gekennzeichnet, dass es die Softwarekonfiguration für ein Leitsystem (1, 2) mittels einer Kombination einer oder mehrerer textbasierter oder nicht textbasierter Programmiersprachen darstellt.
15. System nach Anspruch 13 oder 14, dadurch gekennzeichnet, dass es das Laufzeitverhalten für das erste Leitsystem (1) mittels einer Kombination einer oder mehrerer textbasierter oder nicht textbasierter Programmiersprachen darstellt.
16. System nach Anspruch 14 oder 15, dadurch gekennzeichnet, dass darin jede textbasierte oder nicht textbasierte Programmiersprache nicht objektorientiert, sondern funktional, prozedural aufgebaut ist und auf bedingten oder unbedingten Anweisungen basiert.
17. System nach einem der Ansprüche 13 bis 16, dadurch gekennzeichnet, dass es das Ausführungsverhaiten des ersten Leitsystems (1) über intrinsische Merkmale erfasst und/oder dargestellt, insbesondere über die Verwendung von
- bevorrechtigtem oder nicht bevorrechtigtem Multitasking,
- aufruf- oder ereignisgetriebener Signalisierung,
- der Verwaltung und Ausführung von iterativen Schleifen, sowie
- der Möglichkeit, Schleifen zu unterbrechen und Wiedereinstiegspunkte.
18. System nach einem der Ansprüche 13 bis 17, dadurch gekennzeichnet, dass es das Ausführungsverhaiten des ersten Leitsystems (1) über implizit in dessen Softwarekonfiguration gegebene Beziehungen erfasst.
19. System nach einem der Ansprüche 13 bis 18, dadurch gekennzeichnet, dass es das Ausführungsverhaiten des ersten Leitsystems (1) unter Verwendung von wenigstens einer Wissensdatenbank in die zweite Information wandelt, wobei die wenigstens eine Wissensdatenbank wenigstens auf das erste Leitsystem (1) zugeschnitten ist.
20. System nach einem der Ansprüche 13 bis 19, dadurch gekennzeichnet, dass es Elemente der ersten Softwarekσnfiguration über einen Satz Übersetzungsregeln in Elemente der IEC61131 -Sprachen abbildet.
21. System nach einem der Ansprüche 13 bis 20, dadurch gekennzeichnet, dass es das Ausführungsverhaiten von Elementen der ersten Softwarekonfiguration in Elemente der zweiten Softwarekonfiguration und/oder deren Anordnung darin abbildet.
22. System nach einem der Ansprüche 13 bis 21, dadurch gekennzeichnet, dass es dynamische Programmsteuerparameter, die die Ausführung der ersten Softwarekonfiguration in dem ersten Leitsystem (1) leiten, in Elemente der zweiten Softwarekonfiguration und/oder deren Anordnung abbildet.
23. System nach einem der Ansprüche 13 bis 22, dadurch gekennzeichnet, dass es die ersten Softwarekonfiguration so in eine neutrale Schicht abbildet, die unterschiedliche ein Ausführungsverhaiten nachbildende Zustände aufweist, dass dort die erste Softwarekonfiguration sowie deren Ausführungsverhaiten in dem ersten Leitsystem(l) nachgebildet werden.
24. System nach Anspruch 23, dadurch gekennzeichnet, dass die neutrale Schicht auf einem erweiterten Zustandsmodell basiert, welches einen Grundzustand (6), einen Haltzustand (7), einen aktiven Zustand (8), und einen ausgeschalteten Zustand (9) aufweist, wobei Übergänge
- von dem ausgeschalteten Zustand (9) mittels eines "An"-Befehls in den Grundzustand (6),
- von dem Grundzustand (6) entweder mittels eines "Aus"-Befehls in den Auszustand (9) oder mittels eines "Starf-Befehls in den aktiven Zustand (8),
- von dem aktiven Zustand (8) entweder mittels eines "Stop"-Befehls in den Grundzustand (6) oder mittels eines "Half -Befehls in den Haltzustand (7), und
- von dem Haltzustand (7) entweder mittels eines "Stop"-Befehls in den Grundzustand (6) oder mittels eines "Weiter"-Befehls in den aktiven Zustand (8) vorgesehen sind, und wenigstens zu Elementen der Softwarekonfiguration des ersten Leitsystems gewandelte bzw. transformierte Elemente in dem aktiven Zustand (8) implementiert werden.
PCT/EP2003/013009 2002-11-22 2003-11-20 Verfahren und system zur transformation von programmen, die sich auf die softwarekonfiguration eines verteilten leitsystems beziehen WO2004049156A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2003288131A AU2003288131A1 (en) 2002-11-22 2003-11-20 Method and system for transforming programs relating to the software configuration of a distributed control system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10254531A DE10254531A1 (de) 2002-11-22 2002-11-22 Verfahren und System zur Transformation von Programmen, die sich auf die Softwarekonfiguration eines verteilten Leitsystems beziehen
DE10254531.6 2002-11-22

Publications (2)

Publication Number Publication Date
WO2004049156A2 true WO2004049156A2 (de) 2004-06-10
WO2004049156A3 WO2004049156A3 (de) 2006-03-16

Family

ID=32308652

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2003/013009 WO2004049156A2 (de) 2002-11-22 2003-11-20 Verfahren und system zur transformation von programmen, die sich auf die softwarekonfiguration eines verteilten leitsystems beziehen

Country Status (3)

Country Link
AU (1) AU2003288131A1 (de)
DE (1) DE10254531A1 (de)
WO (1) WO2004049156A2 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996018146A1 (en) * 1994-12-09 1996-06-13 Telefonaktiebolaget Lm Ericsson (Publ) Method of synchronization allowing state transfer
EP0743595A2 (de) * 1995-05-18 1996-11-20 Philips Patentverwaltung GmbH Kommunikationssystem mit Mitteln zum Austausch von Software
EP0809181A1 (de) * 1996-05-22 1997-11-26 Siemens Aktiengesellschaft Verfahren zum Austausch von Software in laufenden Steuerungssystemen

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1150205A1 (de) * 2000-04-28 2001-10-31 ABB Research Ltd. Computerisiertes Werkzeug zur Konvertierung von Hardware/Software konfigurationsbetreffende Information in einem verteilten Steuersystem

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996018146A1 (en) * 1994-12-09 1996-06-13 Telefonaktiebolaget Lm Ericsson (Publ) Method of synchronization allowing state transfer
EP0743595A2 (de) * 1995-05-18 1996-11-20 Philips Patentverwaltung GmbH Kommunikationssystem mit Mitteln zum Austausch von Software
EP0809181A1 (de) * 1996-05-22 1997-11-26 Siemens Aktiengesellschaft Verfahren zum Austausch von Software in laufenden Steuerungssystemen

Also Published As

Publication number Publication date
WO2004049156A3 (de) 2006-03-16
AU2003288131A8 (en) 2004-06-18
AU2003288131A1 (en) 2004-06-18
DE10254531A1 (de) 2004-06-09

Similar Documents

Publication Publication Date Title
DE10351351B4 (de) Verfahren und System zur dynamischen Generierung von User Interfaces
EP0502857B1 (de) Verfahren zur dynamischen bindung von definierbaren programmelementen eines interaktiven datenverarbeitungssystems
DE19781804B4 (de) Vorrichtung zur Simulation einer Echtzeit-Prozesssteuerung
EP1184758B1 (de) Verfahren zum Debuggen von Programmen für industrielle Steuerungen, insbesondere Bewegungssteuerungen, im Kontext der Flow Chart Programmierung
DE4011745C2 (de)
DE10335989B4 (de) Online-Änderungen von CIL-Code-Programmen für die Industrieautomatisierung
DE19960050A1 (de) Grafische Benutzerschnittstelle zur Entwicklung von Anwendungsbeispielen unter Verwendung einer Testobjektbibliothek
DE19728726A1 (de) Robotercontroller und dessen Steuerverfahren
DE10116809A1 (de) Programmierbare Steuereinrichtung und Vorrichtung zur Unterstützung einer Steuerprogrammentwicklung
LU93299B1 (de) Ablaufsteuerung von Programmmodulen
WO1994014117A1 (de) Verfahren zum testen mindestens einer klasse eines objektorientierten programmes auf einem rechner
DE19535519C2 (de) Verfahren zur Reduzierung des Umfanges von Computerprogrammen
EP0838054B1 (de) Verfahren und steuereinrichtung für eine graphische steuerung von abläufen in einem netzwerkmanagementsystem
EP1862901A1 (de) Eingabe von Programm-Anweisungen bei imperativen Programmiersprachen
WO2004049156A2 (de) Verfahren und system zur transformation von programmen, die sich auf die softwarekonfiguration eines verteilten leitsystems beziehen
EP1215571A2 (de) Verfahren zur automatischen Softwaregenerierung
DE102008048862A1 (de) Testmodul und Verfahren zum Testen einer O/R-Abbildungs-Middleware
EP0991995B1 (de) Unterbrechungsverfahren in einem computersystem mit unterbrechungssteuerung
DE19617842A1 (de) Verfahren zur Codetransformation
EP0662226B1 (de) Verfahren zur bearbeitung eines anwenderprogramms auf einem parallelrechnersystem
EP0671678A1 (de) Projektierbare Bedienoberfläche
DE19828611C2 (de) Datenverarbeitungsvorrichtung und zugehöriges Verfahren
DE10254530A1 (de) Verfahren und System zur wissensbasierten Transformation von textuellen Programmen, die sich auf die Softwarekonfiguration eines verteilten Leitsystems beziehen
EP1044409B1 (de) Programmablaufverfahren und verfahren zur erweiterung eines programmkomponentensystems
EP2085879A1 (de) Verfahren zum Betrieb eines Programmiergerätes, Computerprogramm zur Implementierung des Verfahrens und nach dem Verfahren arbeitendes Programmiergerät oder Programmiergeräte mit einem solchen Computerprogramm

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AU AZ BA BB BG BR BY BZ CA CN CO CR CU CZ DM DZ EC GD GE GH GM HR ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LV MA MD MG MK MN MW MX MZ NI NO NZ OM PG PH PL RU SC SD SG SL SY TJ TM TN TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP