Background of the invention Industrial systems can be described and modelled in several ways, and the models obtained are used for many different tasks, such as supervision, control, measurement validation, alarm analysis, fault diagnosis and sensor fault detection.

One way of modelling industrial system is to use so-called causal models. A causal model is a model, which models parts of the system and the causal relation- ship between different parts of the system, i. e. , how the parts affect each other.

One example of a causal model is the so-called functional model. Functional models are used to model industrial systems by identifying the overall goal the system must achieve, the functions the system must perform to fulfil the goal, and the behaviour of the physical structure in order to realise the functions. The modelled system can for example be an electronic device, the process control system in a factory, customer-service activities in a bank, a robot, or the entire Internet.

The strength of functional modelling is in its ability to cope with the complexity in large industrial systems. This is due to the fact that the overall goal and functions in complex industrial systems are many and often very hard to recognise using classical modelling methods. Thus, functional modelling has been used to describe functions of human-machine systems, to perform diagnosis and planning in industrial plants, and to identify failures and their consequences in such plants.

One example of a functional model is the multilevel flow model (MFM). The basic idea of MFM is to model a man-made system designed and used with certain purposes in mind. The main strength of a multilevel flow model is that it is easy to build a model of a target system using MFM. Thus, MFM is preferably used in the modelling of large target systems.

In order to build large models or complex models it is often necessary to

provide means for hiding parts of the model inside larger structures of the model, <BR> <BR> e. g. , subparts, and connecting such structures into larger blocks of the model, e. g., submodels, which are connected to constitute the model.

However, none of the models described above and known to the inventor, provides this type of hierarchical abstraction, the so-called part-whole abstraction described above, wherein the model can be divided into smaller parts, submodels, which in turn may be divided into smaller sub-parts.

In some models according to the prior art, hierarchical abstraction is provided in one dimension, wherein the objects of the model are related to each other by means of relations.

The multilevel flow model according to the prior art provides hierarchical abstraction in mainly one dimension, the so-called means-end dimension, wherein goals of the system are related via achieve relations and condition relations to functions. The achieve relation connects a set of functions to a goal implying that these functions are used to fulfil the goal and the condition relation connects a goal to a function implying that the goal has to be fulfilled in order for the function to be available. Further, the function is connected via a realise relation to a component implying that the component is used to realise or implement the function.

In some literature (cf. Knowledge-Based Methods for Control Systems, Nov 1992, ISRN LUTFD2/TFRT-1040-SE) concerning MFM a hierarchical abstraction in a second dimension is briefly mentioned, namely the part-whole dimension described above, in which dimension a system may be viewed as a whole or divided into subsystems. The subsystems may further be divided into smaller parts until the leaf-components are reached. The hierarchical abstraction in the part- whole dimension has so far and known to the inventors only been considered in theoretical discussions as a desirable feature. However, the part-whole dimension has never been implemented since the problems of how to handle the complex causal dependencies between the different parts of the system, when dividing the model into submodels, have not been solved.

Figure la (prior art) shows a model of a small system using a known causal model. As shown in figure la the model has a relatively complex set of casual dependencies, so-called casual relations, which are illustrated by the lines from objects A, Bl, B2, B3, C to other objects MA, Mai, MB2, MB3, MC As illustrated in figure la the model contains several dependency loops. For example, the object A depends on the object B1 since the object MA depends on the object B1 to fulfil the object A. The object B1 depends on the object C since the object MB1 depends on the object C to fulfil the object B1. Furthermore, the object C depends on the object A since the object Me depends on the object A to fulfil the object C.

Figure lb (prior art) shows a model of the small system using a known multilevel flow model. In figure lb the objects A, B1, B2, B3 and C represent so- called goals and the objects MA, MB1, MB2, MB3 and Me so-called networks. In this case, the goal A depends on the goal B 1 since the network MA depends on the goal B to fulfil the goal A. The goal B 1 depends on the goal C since the network MB1 depends on the goal C to fulfil the goal B 1. Furthermore, the goal C depends on the goal A since the network Me depends on the goal A to fulfil the goal C.

Consider now that we want to manipulate the model according to figure la (prior art) to comprise a submodel, for example to treat the objects MB1, MB2 and MB3 as a submodel of the shown model. In this case, we have to substitute the objects MB1, MB2 and MB3, with a new entity, the submodel, and the objects Bl, B2 and B3 with one or several new objects. Further, the relations between these new objects and the submodel have to be defined. To perform this task, we have to decide the specific syntax defining how to handle the casual dependencies from one or several of the new objects of the submodel to the objects MA and Me and the casual dependencies from the objects A and C to the submodel.

To manipulate the multilevel flow model according to figure lb (prior art), the networks MB1, MB2 and MB3 have to be substituted with the new entity, the submodel, and the goals B 1, B2 and B3 with one or several new goals. Further, the relations between these new goals and the submodel have to be defined. To perform this task, we have to decide the specific syntax defining how to handle the casual dependencies from one or several goal (s) of the submodel to the networks MA and Me and the casual dependencies from the goals A and C to the submodel.

However, this is not a straightforward procedure neither using a causal model in general (cf. fig. la) nor using the known multilevel flow model (cf. fig. lb), since it is possible to make several different choices concerning which objects and relations that should belong to the submodel and thus be hidden inside the structure.

It is also possible to make several different choices concerning which objects that should be connected to the submodel on the outside. This also has consequences for which relations that should be allowed to pass in to and out from a submodel. These choices will affect the language, algorithms based on it, and especially, the expressive power and ease-of-use of the language.

The US Patent No 5,127, 005 discloses a fault diagnosis expert system for locating and eliminating sources of a machine trouble. The system comprises a storage part for storing an expert knowledge constructed in a hierarchical search tree structure in which cause-to-effect links connecting high-level effect events to low- level cause events are pre-defined and all possible low-level cause events are pre- enumerated for each high-level effect event, a user interface part for providing a user with questions and responses regarding the state of the machine trouble, an

inference part for inferring a cause of the machine trouble with the expert know- ledge and the user information, and an outputting part to be displayed for the user.

The UK Patent No 2 303 231 discloses a fault diagnostic device in which the basic structure of the fault model is produced automatically by the diagnostic sequence preparation stage from a structure model relating to the hierarchical structure of the technical system composed of individual subsystem and a function model relating to the functional relationships between the individual subsystems.

The fault model represents the relationships between fault causes and their effects.

In the methods and systems disclosed by the US Patent No 5,127, 005 and UK Patent No 2 303 231, the model of the target system takes a so-called tree structure in which causes and effects are linked together. However, a drawback when using a tree structure as the hierarchical abstraction of the target system is that a tree structure does not provide a part-whole decomposition of the model modelling the target system, since it is not possible for a node in a tree structure to comprise an internal tree structure.

In the US Patent No 5, 111, 413 a method and apparatus for simulating electronic hardware is disclosed. The apparatus allows a user to make incremental changes to an electronic circuit design without exiting from the simulation environment. However, according to the disclosed method and apparatus only the logical relationship between input and output signals for an object and signals between objects is modelled and not how the objects affect each other. Thus it is not possible to model what impact a first object has on other objects connected to the first object, i. e. it is not possible to model what consequence a failure or an improper operation of the first object has on other objects.

WO 91/15828 discloses a method and a system in which a programmed digital computer serving as a graphical"engine"is employed to construct an executable model for a complex system using a hierarchy of so-called"Colored" Petri Net's (CPN's or CP-nets). The operation of the complex system is specified in terms of a graphical net structure and formal net inscription which ensure develop- ment of a program, or executable model, and associated data structures, properly defining the system. After construction of the executable model of the system, the executable model can be compiled and executed to simulate the system. Thus, the executable model describes in which order different steps are to be taken to simulate the system.

Further, adding submodel structure blocks for electrical circuit diagrams can be accomplished, since these diagrams only contain one type of connection between objects, namely an electrical conductor line. By defining a submodel object with input and output ports, and connecting the internal lines to the ports'insides, and the outer lines to the ports'outsides, a simple solution with submodel objects that are

connected in exactly the same way as any other object/component is achieved. A submodel can be created from a selection of components and removed without affecting the model connection structure.

The same is true for Petri nets, colored Petri nets, Graphcet, etc. Here the single connection type is that of a possible state transition, and a submodel object can be connected in the same way as any other object (in this case states or places).

However in case of a general causal model, there are several different types of objects, such as goals, functions, etc. , and several types of casual and conditional connections. In the special case of multilevel flow models, there are goals, flow functions, managers, networks, achieve relations, achieve-by-management relations, and condition relations. In this case the solution used for electrical circuits and Petri nets no longer works, since the model will comprise different kinds of objects and especially since the model will comprise a plurality of different kinds of relations connecting the objects. It is no longer easy to decide which objects that should be internal to a submodel and which relations that should be connected to the outer world and, thus, enter and exit the submodel, in other words where the cuts to the surrounding model should be made.

In order to compose a legal and meaningful submodel, several different objects of different types may be needed inside the submodel, and a cut from the surrounding model parts cannot be made at any arbitrary connection. For example, in multilevel flow models, goals must be connected to flow networks through achieve relations, so the cut cannot be made between network and goal. At the same time, a sub-system described by a submodel also has a set of goals, and it would be natural that these goals are connected to the submodel with achieve relations. It is far from trivial to decide whether the submodel itself or only the networks inside should be connected to goals, or whether both should be. For example, if a submodel is connected to goals, the removal of the submodel will also lead to changes concerning the goals. If for example a submodel is not connected to goals, the question how to describe the submodel's goal connections has to be answered.

Further, the connections entering and exiting the submodel must provide a good model structuring method and be easy and natural to use. The designer of a model needs to have freedom to let different types of connections enter and exit a submodel. In contrast, if any type of connection is allowed, the submodels will not behave as working building blocks, and their role as a structuring tool will fail.

Thus, the easy solution used in electrical circuits, Petri nets, and other model types with only one type of connection does not work for model types with a more complex set of relations between the model elements.

Object of the invention Thus, an object of the invention is to provide an apparatus, a method and a computer program product for managing hierarchical structures of a model of a system that inter alia overcome the above mentioned problems and disadvantages.

Especially, the present invention refers to managing the hierarchical structures in a part-whole dimension. An aspect of the object is to provide a simple and computationally efficient apparatus and method for managing the hierarchical structures.

A second object of the invention is to provide an apparatus, a method and a computer program product for managing hierarchical structures of a model of a system using a model describing the physical flows of e. g. mass, energy or information and directly relating to physical parts of the system. An aspect of this second object is to use a model of the system that is simple to build.

Summary of the invention The present invention refers to an apparatus, a method and a computer program product for providing and managing hierarchical structures of a model of a flow system. The invention refers especially to an apparatus and a method for managing hierarchical structures in a part-whole dimension of the model, wherein said model models parts of the flow system and relationships between said parts.

The apparatus according to one embodiment of the invention comprises a data storage storing data structures types, which comprise information about model elements modelling the system. The apparatus comprises further a program storage storing predetermined operations for managing the hierarchical structure of the model and an interface receiving a command from an external structure and responding to said command. A processor is further coupled to said data storage, program storage and to said interface, and configured to receive a user command and to associate information in said command with data in said data structure types.

The processor is also configured to managing said data structure type according to a selected operation, and to provide a model of the system by means of the informa- tion comprised in the data structure types.

The data structure type may be an object data structure type, comprising a goal data structure type including information about a goal model element modelling the purpose of the system or of a part of the system. Further the object data structure type may comprise a function data structure type including informa- tion about a function model element modelling the capability of a part of the system, which is used to fulfil the goal. The object data structure type may also comprise a network data structure type including information about a network model element modelling the property of parts of the system to fulfil the conditions necessary to

allow other parts of the system to perform their function. Further, the object data structure type may comprise a submodel data structure type including information about a submodel model element modelling the hierarchical abstraction of parts of the system or the entire system. Furthermore, said data structure type may be a relation data structure type, comprising information about a relation model element modelling a relationship between a goal and a function.

In one embodiment of said apparatus the system is modelled by means of a causal model, a functional model or a multilevel flow model.

The present invention refers also to a computer program product for use in a computerised apparatus for managing hierarchical structures of a causal model of a flow system, said model modelling parts of the flow system and causal relationships between said parts. In one embodiment of the invention, the computer program product comprises means for receiving a user command and presenting information to a user concerning the managing of the model and for transferring and receiving data to and from an external structure. Further the computer program product comprises means for controlling the steps of the managing of the model and means for storing a plurality of data structures types arranged to comprise information and parameter values of model elements modelling the flow system. The computer program product comprises further means for storing a plurality of predetermined operations for managing the hierarchical structure of the model, wherein said operations are arranged to managing an instance of said data structure type in response to said user command and controlled by said means for controlling the steps of the managing of the model.

Brief description of the drawings The present invention will be described with reference to the following drawings, in which: Fig. 1 a shows an exemplifying model of a small system using a causal model according to prior art; Fig. lb shows an exemplifying model of the small system using a multilevel flow model according to prior art; Fig. 2a shows a schematic block diagram of an embodiment of the apparatus according to the present invention; Fig. 2b shows a schematic functional block diagram of the functional parts of an embodiment of the apparatus according to the present invention; Fig. 3 a shows a schematic block diagram of an embodiment of the data storage according to the present invention; Fig. 3b shows an exemplifying embodiment of the object data structure type according to the present invention;

Fig. 4a-4e show exemplifying embodiments of the internal data structure of the goal, function, component, submodel and relation data structure types 112a-112d and 114, respectively.

Fig. 5 shows a schematic block diagram of an embodiment of the program storage according to the present invention ; Fig. 6 shows a schematic flow chart of the method steps for building a model according to an embodiment of the present invention; Fig. 7 shows a schematic flow chart of the general method steps for managing hierarchical structures according to an embodiment of the invention; Fig. 8 shows an exemplifying embodiment of a graphical description of an MFM submodel in the closed state; and Fig. 9 shows an exemplifying embodiment of a graphical description of an MFM model in the open state.

Definitions The following definitions will be used to describe the present invention: Flow system refers to a system of components and the flow of entities between them, and the capabilities of the components concerning the flow, such as the capabilities to store, transport, provide, consume, and control the flow of something. These entities could be anything as long as it obeys conservation laws, e. g. , mass, energy, cash, or information flows. In a mass flow system the components may be pumps, tanks, conveyor belts, chemical reactions, biological processes, or other components that are used to maintain flows of mass. In an energy flow, the components may be radiators, batteries, electrical outlets, cords for transmission of electrical energy, and radioactive decay. In an information flow the components may be PID-regulators, sensors, and actuators, but also more abstract components such as information storage on an Internet server, network switches, document delivery systems, and means for verbal communication. A cash flow system may comprise components such as bank accounts, financial transactions, and investments.

Goal refers to the purpose of a system or a part of a system and is the outcome towards which certain activities of the system or the part of the system are directed. A goal could for example be to keep the level of water in a tank high enough and a sub-goal could be to provide electrical power to a pump, which is pumping water to the tank, wherein the sub-goal has to be fulfilled for the main goal to be fulfilled. A toplevel goal is a goal connected to a submodel by means of an achieve relation and a leaf goal is a goal connected to the submodel by means of a condition relation.

Function refers to the capabilities of the components of a system, which are used to fulfil the goals, i. e. , what the components is doing in order to fulfil the purpose of the system. A source function may for example be used to model the <BR> <BR> capability of a tank, i. e. , to provide an infinite amount of mass, or the capability of a power plant to provide an infinite amount of energy. Further, a transport function <BR> <BR> may, for example be used to model the capability of a pump, i. e. , to move an amount<BR> of mass, or the transfer of cash from one account to another, i. e. , move an amount of cash. A function may also be used to describe the capability to control the fulfilment of a goal. The manager function may be used to model the capability of the operators of a power plant to control the production of energy, and thereby fulfilling the goal of the power plant. A network function represents the property of parts of the system to provide the conditions necessary to allow other parts of the system to perform their function. The network function is used as a way of grouping several connected flow functions into a flow structure.

The inultilevelflow model (MFM describes the functional structure of a system as a set of interrelated flow structures on different abstraction level. The levels are connected via achieve and condition relations, and the flow structures consist of a set of connected functions.

Network is a collection of MFM functions that describe a flow in the target system/flow system. For example, the flow of electrical energy in a power supply system.

Achieve relation refers to an MFM relation that connects a network to a goal.

The interpretation of this relation is that if all functions in the network are available, i. e. , working, then the goal is achieved, otherwise the goal is not achieved.

Condition relation refers to an MFM relation that connects a goal to a function. If the goal is achieved the function is available, and if the goal is not achieved the function is not available.

Manager refers to a special MFM function that describes the capability of managing resources in the target system and controls the achievement of an MFM goal.

Part-whole refers to the capability to managing the system as a whole or decomposed into subsystem. A model providing a part-whole abstraction, is a model that can be divided into smaller parts, submodels, which in turn may be divided into smaller sub-parts dependent on the choice of e. g. an operator. The operator may for example zoom into a model element to find out want is comprised in the model element, i. e. to find out sub-elements comprised in the model element. Using the part-whole abstraction of the model it is also possible for an operator to hide sub- elements of a model element by zooming out, thus only the model element is shown and not the sub-elements comprised in the model element.

It should be emphasised that the term"comprising/comprises"when used in this description is taken to specify the presence of stated features, steps or components but does not preclude the presence of one or more other features, integers, steps, components or groups thereof.

Detailed description of the invention The present invention refers thus to an apparatus, a method and a computer program product for managing hierarchical structures of a model of a flow system.

The invention refers especially to an apparatus and a method for managing hierarchical structures in a part-whole dimension of the model, wherein said model models parts of the flow system and relationships between said parts.

The apparatus according to one embodiment of the invention comprises a data storage storing data structures types, which comprise information about model elements modelling the system. The apparatus comprises further a program storage storing predetermined operations for managing the hierarchical structure of the model and an interface receiving a command from an external structure and responding to said command. A processor is further coupled to said data storage, program storage and to said interface. The processor is configured to receive a user command and to associate information in said command with data in said data structure types. The processor is also configured to managing said data structure type according to a selected operation, and to provide a model of the system by means of the information comprised in the data structure types.

General setting Figure 2a shows a block diagram of a computerised device 100, such as a computer, for managing hierarchical model structures according to one embodiment of the invention. The computer 100 comprises a processor 102, such as a central processing unit (CPU), coupled to a system interface 104, a data storage 110, comprising a plurality of data structures, and a program storage 120, comprising a plurality of operations or procedures for managing the hierarchical structure. The data storage 110 and the program storage 120 can reside on any per se known memory structure such as a disk memory, read only memory (ROM), random access memory (RAM) or other types of memory.

The system interface 104 comprises or is communicatively coupled to a not shown user interface for communication between the device 100 and a user by means of an interaction means, a display unit, an input device such as a keyboard or a mouse. Further, the system interface 104 may comprise or be communicatively coupled to a not shown data communication equipment for communication between <BR> <BR> the device 100 and an external device, such as another computerised device, e. g. , a

computer. The communication is in one embodiment of the invention provided by a two-way communication link. Further, the communication link is preferably a wired communication link comprised in for example a local area network (LAN) such as Ethernet. However, another mode of communication, e. g. , a point-to-point communication using a modem, or a wireless communication link that fulfils the requirements for reliable transmission of information may also be used. The computerised device 100 according to the invention is thus communicatively connectable to an external apparatus, such as a check and control system (not shown) of e. g. a plant or a diagnostic station (not shown) comprised in a diagnostic system used to analyse the performance of e. g. , the plant. The device 100 may be used to configure the external diagnostic system, by transmitting the model, as stored in the data storage 110, by means of the system interface 104. The model may be transferred as a pure text representation, or in a compressed binary representation or any other form suitable for the chosen communication link. The computerised device 100 may also comprise operations or procedures stored in the program storage 120, that allows for verification and validation of the model, also operations to perform diagnostic reasoning, such as, alarm analysis or fault diagnosis, based on the model comprised in the data storage 110.

Functional parts Figure 2b shows schematically functional parts comprised in an embodiment of the computerised device 100 according to the invention. Typically, the functional parts are comprised in a computer program product for use in the computerised device 100 for managing hierarchical structures, but any or all of the functional parts may be realised as hardware parts of a computerised device. The functional parts comprise a system interface 200 comprising or communicatively connected to a user interface 202 for the presentation of information to the user as well as receiving inputted commands or information concerning the managing of the model, usually in the form of parameter updates. Further, the system interface 200 may comprise or be communicatively coupled to a data communication equipment 204, which is capable of transferring and receiving data to and from an external structure, such as another computerised device, a diagnostic station or a check and control system of e. g. a plant. The system interface 200 is further communicatively coupled to a managing control unit 206 for controlling the steps of the managing of the model. The managing control unit 206 comprises or is communicatively coupled a data storage 208 for storing information and parameter values of model elements modelling the system. The data storage 208 comprises thus a set of data structure types 210 for the model elements modelling the system.

The managing control unit 206 is further provided with or has access to

predetermined rules or a predetermined managing schemes, which rules and schemes preferably are comprised in a program storage 212 communicatively coupled to the managing control unit 206. The program storage 212 comprises a plurality of operations or procedures 214 for managing hierarchical structures.

The data storage 208 and the program storage 212 will be described in more detail below.

In the drawings, the lines drawn between different functional parts indicate that the parts are communicatively coupled, physically or by exchanging parameter values. This applies also to the units, structures and parts described anywhere in this description.

Data storage Figure 3 a shows an embodiment of the data storage 110 (in fig. 2b indicated by the reference numeral 208) comprising one or several data structure s (in fig. 2b indicated by 210), which serve to define the model. Thus, the data storage 110 comprises data structures for model elements that model the system. The model elements comprise objects and relations, wherein an object is for example a goal, a function, a network or a submodel, and a relation is for example an achieve relation or a condition relation connecting objects. In the shown embodiment of the invention the data storage 110 comprises one or several data structures such as an object data structure type 112 and a relation data structure type 114.

Figure 3b shows one embodiment of the object data structure type 112 according to the invention, comprising for example a goal data structure type 112a, a function data structure type 112b, a network data structure type 112c and a submodel data structure type 112d.

In one embodiment of the invention, the object data structure type 112 has an internal data structure comprising different attributes. These attributes may comprise information or parameter values such as an object identity, an object measurement, i. e. whether the object is connected to an external measurement, an object measurement value, i. e., the value of the measurement and other object attributes used by different diagnostic methods operating on the object. Further, the internal data structure may comprise other useful attributes describing the object such as the name and the location on the screen. Furthermore, the internal data structure may <BR> <BR> comprise object relationships, i. e. , information about how the object is connected to<BR> other objects, e. g. , the names of the connected objects and/or the relation connecting the objects.

In an embodiment of the invention the goal data structure type 112a has an internal data structure (cf. fig. 4a) comprising one or several attributes, such as an identity attribute identifying the goal, e. g. , the Name; a Type attribute defining

whether the goal is a single goal or a redundancy goal, i. e. , a goal that is achieved by more than one network; a Parent attribute, i. e. the identity of the submodel comprising the goal; a Description attribute describing the goal, e. g. to maintain level in tank T1 ; a Relation attribute identifying the relation that connects the goal to a network; an Screen Position attribute defining the position of the goal on e. g. a display; a Measurement attribute providing information about a measurement associated to the goal; an Alarm State attribute defining the state of the goal ; and a Primary Secondary (Prim Sec) attribute defining whether an alarm is a primary or a secondary alarm.

In an embodiment of the invention the function data structure type 112b has an internal data structure (cf. fig. 4b) comprising one or several attributes, such as an identity attribute identifying the function, e. g. , the Name of the function; a Type<BR> attribute defining the function type, e. g. , a transport function; a Parent attribute, i. e. the identity of the submodel comprising the function; a Network attribute defining the network comprising the function; a Description attribute describing the present function; a Left Connection attribute defining a function on the left hand side of the present function; a Right Connection attribute defining a function on the right hand side of the present function; a Screen Position attribute defining the position of the function on e. g. a display; a Measurement attribute providing information about a measurement associated to the function; an Alarm State attribute defining the state of the function; and a Primary Secondary (Prim Sec) attribute defining whether an alarm is a primary or a secondary alarm.

Further, in an embodiment of the invention the network data structure type 112c has an internal data structure (cf. fig. 4c) comprising one or several attributes, such as an identity attribute identifying the network, e. g. , the name of the network; an Object attribute indicating the object (-s) comprised in the network; a Parent attribute, i. e. , the identity of the submodel comprising the network, and a Screen Position attribute defining the position of the network on e. g. a display.

According to an embodiment of the invention, the submodel data structure type 112d has an internal data structure (cf. fig. 4d) comprising at least one attribute such as an identity attribute identifying the submodel, e. g. , the Name of the<BR> submodel; an Object/Relation attribute indicating the object (-s) /relation (-s) comprised in the submodel; a State attribute indicating if the submodel is open or closed, i. e. if the object (-s) /relation (-s) comprised in the current submodel are visible or not for a user; a Parent attribute, i. e. the identity of another submodel comprising the current submodel; a Top Level Goal attribute, i. e. the identity of a toplevel goal connected to the submodel; a Leaf Goal attribute, i. e. the identity of a leaf goal connected to the submodel; a Description attribute describing the submodel; and a Screen Position attribute defining the position of the submodel on

e. g. a display.

In an embodiment of the invention, the relation data structure type 114 comprises an internal data structure (cf. fig. 4e) comprising one or several of attributes, such as an Identity attribute identifying the condition relation, e. g. , the<BR> Name of the condition relation; a Parent attribute, i. e. , the identity of the submodel comprising the condition relation; a Goal attribute defining the goal the condition relation is connected to; a Function attribute defining the function the condition relation is connected to; an Influence attribute defining how the failure of the connected goal will affect the connected function; and a Model attribute defining the submodel to which the relation is connected.

Program storage Figure 5 shows an embodiment of the program storage 120 (in fig. 2b indicated by the reference numeral 212) comprising a plurality of predetermined procedures 122 (in fig. 2b indicated by 214) for managing a model of a part of the system or of the entire system, e. g. for storing, manipulating, modelling or retrieving the model or parts of the model. In an embodiment of the invention, these procedures comprise a create function procedure, a create goal procedure, a create relation procedure, a create network procedure and the corresponding delete, remove and edit procedures. Further, for the implementation of the inventive concept of submodels, the plurality of procedures may also comprise at least one of the following procedures: an open submodel procedure, a close submodel procedure, a create empty submodel procedure, a create submodel from selection procedure, a remove submodel procedure, a delete submodel procedure, a connect toplevel goal procedure, a create toplevel goal internally procedure, a connect leaf goal procedure, a create leaf goal internally procedure, a procedure for other internal operations, and a procedure for other external operations. Some of the procedures will be described in more detail below.

The method of building a model of a flow system according to one embodiment of the present invention will now be described (cf. fig. 6). In step 600 a first user command is inputted by means of an inputting means and in step 602 a first model element is selected in response to said first user command, wherein said first model element is an object, e. g. , a function, a goal, a network or a submodel.

The first model element is created in step 604 in response to said selection. Further an instance of an object data structure type 112 for the selected first model element is created and parameter values for the object are assigned to the attributes of the internal data structure of the instance of the object data structure type 112. That is, an instance of the object data structure type 112 according to one of the

exemplifying instances of the object data structure types 112a-112d, shown in fig.

4a-4d, is created. Furthermore, this created instance of the object data structure type 112 is stored in the data storage 110. In step 606 said first model element is displayed on a display by means of a display procedure and in step 608 a second user command is inputted by means of an inputting means. A second model element is selected in step 610 in response to said second user command and dependent on said first model element, wherein said second model element is an object or a relation, which relation for example is an achieve relation or a condition relation. In step 612 the second model element is created in response to said second command and dependent on said first model element. Further, an instance of the object data structure type 112 or an instance of the relation data structure type 114 is created for the selected second model element and parameter values for the object/relation are assigned to the attributes of the internal data structure of the instance the object data structure type 112 or the instance of the relation data structure type 114. That is, an instance of a data structure type 112,114 according to one of the exemplifying instances of object data structure types 112a-112d or the instance of the relation data structure type 114, shown in fig. 4a-4e, is created. Furthermore, the created instance of the object data structure type 112 or instance of the relation data structure type 114 is stored in the data storage 110. In step 614 the second model element is displayed on said display by means of the display procedure. Finally, in step 616 the steps are repeated from the step 600 until the model of the system is built.

The general method for managing hierarchical structures of a system model may comprise a number of steps, cf. fig. 7.

In step 700 a plurality of data structures types, which serve to define the model of the system, are stored in a data storage 110, wherein the data structures types comprises an object data structure type 112 and a relation data structure type 114. A plurality of predetermined procedures or operations for managing hierarchical structures are in the step 702 stored in the program storage 120. In step 704 a user command is inputted by means of an inputting means and in step 706 is an operation or procedure for managing hierarchical structures selected in response to said user command, which procedures for managing hierarchical structures will be described below. Possibly, an input parameter is selected in step 708 by means of the inputting means and in step 710 is the selected operation called, the possibly selected input parameter inputted and the operation is executed. In step 712, one or several of the instance of the object data structure type 112 or instance the relation data structure type 114 are managed dependent on the executed operation and in the step 714, the steps from the step 704 may be repeated.

It should be understood that in the step of selecting an input parameter, step 708 above, a null input parameter could be selected, i. e. the input parameter is void.

Examples of procedures for managing hierarchical structures of a system model according to embodiments of the present invention will now be described in more detail.

Open submodel operation Generally, the open submodel operation is performed on a closed submodel, whereby the closed submodel representation is replaced with an open submodel representation in response to a user command. In other words, this operation can be compared with a"zoom in"operation.

In a graphical representation, the open submodel operation works as follows.

One of the visible closed submodels is selected for the operation, for example, by means of an inputting means, e. g. , a mouse operation or a menu operation. In response to the user command, the screen content is then replaced with a new content, showing the internal structure of the submodel, i. e. , the internal model elements of the submodel. In other words, an open submodel operation on the submodel in figure 8 would mean that the model on the screen would be changed to look like the model in figure 9 instead. In figure 8, the closed submodel SM is selected and replaced with the internal model elements of the submodel SM. Thus, the internal objects, i. e. the network MA, the goal GB and the network MB are shown together with the internal relations, i. e. the achieve relation RB between the network MB and the goal G$ and the condition relation RBA between the Goal GB and the network MA. However, the external objects, i. e. the toplevel goal GA and the leaf goal Gc and the external relations, i. e. the achieve relation RA and the condition relation RCB will remain the same.

Thus, the open submodel procedure takes the object, i. e. , the submodel SM, as an input parameter. The submodel SM is then identified, by means of a tag or the <BR> <BR> like, and the internal model elements, i. e. , the internal objects O ; and relations Ri, of the submodel SM are retrieved from a data storage 110. The retrieval of the internal model elements is performed by searching the data storage 110 for instances of object data structure type 112 and instances of relation data structure types 114 having the name of the current submodel as a Parent attribute. If for example, the present submodel SM is identified with the Name attribute Model 0, every object having the Model 0 as the Parent attribute, cf. fig. 4a-4e, will be retrieved. In this specific example the goal G10, the function F13 and the condition relation C10 will be retrieved as the internal objects Oi and relations Ri of the present submodel SM.

The submodel SM is then substituted by the internal objects Oi and relations Ri, which are outputted from the open submodel procedure as output parameters to e. g. a display procedure displaying these internal objects Oi and relations Ri together with the entire model.

The open submodel procedure comprises in one embodiment of the invention the steps of : - receiving a submodel SM as an input parameter; - identifying the submodel SM, by means of a tag or the like; - retrieving internal objects Oi and relations Ri of the submodel SM from a data storage 110; - substituting the submodel SM with said retrieved internal objects Oi and relations Ri ; - outputting said internal objects Oi and relations Ri to e. g. a display unit; and - displaying the internal objects Oi and relations Ri on the display unit, e. g. , a screen, either instead of the previously presented model or in addition to it.

Close submodel operation Generally, the close submodel operation is the reverse of the open submodel operation, whereby the open submodel representation, in response to a user command, is replaced with a representation of the model containing a single submodel object and the surrounding model elements in the model, that is"zoom out".

In a graphical representation, the close submodel operation is selected by means of a user command using an inputting means, whereby the internal model elements of the submodel are replaced with a single submodel graphical object and the surrounding model elements in response to said user command. In figure 9, the internal objects and relations of the open submodel is replaced with the closed submodel SM. Thus, the network MA, the goal GB, the network MB, the achieve relation RB and the condition relation RBA are selected and replaced with the closed submodel SM, as shown in figure 8.

Thus, the close submodel procedure takes the internal elements, i. e. , the internal objects Oi and relations Ri, of the submodel SM as input parameters. In one embodiment of the invention, the close submodel procedure identifies the internal objects Oi and relations Ri, and retrieves information about the corresponding submodel SM, from a data storage 110. The retrieval of the submodel SM is performed by searching the data storage 110 for instances of the object data structure type 112 and instances of the relation data structure type 114 having a Name attribute corresponding to the identity of the inputted objects and relations, respectively, and retrieving the instance of the submodel type 112d having a Name attribute corresponding to the Parent attribute of the found instances of object data structure types 112 and instances of the relations data structure types 114. If for example, the goal G10, the function F13 and the condition relation C 10 are inputted as internal elements, cf. fig. 4a-4e, the submodel SM having the Name attribute

Model 0 will be retrieved since this Name attribute corresponds to the Parent attribute Model 0 of the internal elements. The internal objects Oi and relations Ri are then substituted by the submodel object SM, which then is outputted from the close submodel procedure as an output parameter to for example a display procedure displaying the submodel SM together with the entire model.

The close submodel procedure comprises in one embodiment of the invention the steps of : - receiving an internal objects Oi and relations Ri as input parameters; - identifying the internal objects Oi and relations Ri, by means of e. g. a tag; - retrieving the corresponding submodel SM from a data storage 110 ; - substituting the internal objects Oi and relations Ri with the retrieved submodel SM; - outputting said submodel SM to e. g. a display unit; and - displaying said submodel SM on the display unit, e. g. , a screen, either instead of the previously presented model or in addition to it.

Create empty submodel operation Generally, the create empty submodel operation creates a submodel object in a closed state in response to a user command. The created submodel contains no internal model elements and is not connected to a toplevel goal or a leaf goal.

Graphically, the create empty submodel operation is selected by means of an inputting means, whereby a new, empty submodel object is placed on the screen in response to the user command. Further, the created new submodel is shown in a closed state, cf. the submodel SM in figure 8. However, the created submodel does not contain any internal objects and is not connected to a toplevel goal or leaf goal.

Thus, the create empty submodel procedure is called by a user command and creates an empty submodel SM in response to the user command. Further, an instance of a submodel data structure type 112d is created and stored in a data storage 110 and information about the created submodel SM, such as the identity, i. e. the name of the submodel, and the state (closed) of submodel is stored in the created instance of a submodel data structure type 112d. Further, the created submodel SM is outputted from the create empty submodel procedure as an output parameter to for example a display procedure displaying the submodel SM possible together with the rest of the model.

The create empty submodel procedure comprises in one embodiment of the invention the steps of : - creating an instance of a submodel data structure type 112d for a submodel SM in response to a user command ; - storing information about the created submodel in the created instance of the

submodel data structure type 112d stored in a data storage 110; - outputting said submodel SM to e. g. a display unit; and - displaying said submodel SM on the display unit, e. g. , a screen, either instead of the previously presented model or in addition to it.

Create submodel from selection operation Generally, the create submodel from selection operation creates a submodel object, which is in the closed state, from a selection of existing model elements.

Unselected goals connected by achieve relations to selected objects become toplevel goals, and unselected goals connected by condition relations to other selected objects become leaf goals. All other selected model elements become internal objects and relations of the created submodel.

Graphically, the user command for the create submodel from selection operation is inputted by selecting a set of existing model elements, i. e. , objects and relations, by means of an inputting means and selecting the create submodel procedure. As mentioned above, unselected goals connected by achieve relations to selected objects become toplevel goals, and unselected goals connected by condition relations to other selected objects become leaf goals. All other selected model elements become internal objects and relations of the created submodel. Thus, the screen content is changed so that the selected model elements, which will become internal objects to the submodel, are replaced with a single submodel object shown in the closed representation. If for example the model elements shown in the area marked 20 in figure 9, i. e. the network MA, the goal GB, the network MB, the condition relation RBA and the achieve relation RB are selected, they will be replaced with the closed submodel SM, as shown in figure 8. Further, the goal GA and the goal Gc in figure 9 will become a toplevel goal and a leaf goal, respectively.

Thus, the create submodel procedure takes the selected objects O and relations R as input parameters and identifies them. A data storage 110 is then searched for retrieving instances of the object data structure types 112 and instances of the relation data structure types 114, respectively, having a Name attribute corresponding to the identity of identified objects and relations. The Name attribute comprised in the instance of the object data structure types 112 identifies the object, cf. fig. 4a, wherein G10 indicates the goal G10, and the Relation attribute comprised in the instance of the goal data structure type 112a identifies the relation, cf. fig. 4a, wherein A35 indicates the achieve relation A35. If one of the objects O is connected to an unselected goal by means of an achieve relation, the goal will become a toplevel goal, i. e. , an external object Oe, and the achieve relation will become an external relation Re. If one of the objects O is connected to an unselected goal by means of a condition relation, the goal will become a leaf goal, i. e. , an external

object Oe, and the condition relation will become an external relation Re. All other selected objects O and relations R will become internal objects Oi and relations Ri of the submodel SM. Further, the instances of the object data structures 112 and the instances of the relation data structures 114 will be updated. Thus the instances of the object data structure types 112 and the instances of the relation data structure type 114 of the internal objects and relations will have the name of the created submodel in the Parent attribute of their instances of the data structure types 112 and 114, respectively. The Model attribute of the instance of the relation data structure type 114 for the external relations Re will be assigned the identity of the created submodel. An instance of a submodel data structure type 112a will be created for the created submodel and assigned information about inter alia the internal objects and relations. The Top Level Goal attribute and the Leaf Goal attribute of the created instance of the submodel data structure type 112d for the created submodel will be assigned the identity of the external goals as described above. Information about the created submodel SM, the external objects Oe and relations Ré will then be outputted from the create submodel procedure as output parameters to e. g. a display procedure displaying the submodel SM, the external objects Oe and relations Re together with the entire model.

The create submodel procedure comprises in one embodiment of the invention the steps of : - receiving a selected objects O and relations R as input parameters; - identifying the selected objects O and relations R; - retrieving information about the selected objects O and relations R from a data storage 110; - if an object O is connected to a goal, which is not selected, by means of a condition relation or an achieve relation, defining the goal O as an external object Oe and the connected relation as an external relation Re ; - else, defining the object O as an internal object Oi and the corresponding relation as an internal relation Ri ; - creating a submodel SM and an instance of the submodel data structure type 112d ; - storing information about the submodel SM, the internal objects Oi and relations Ri of the submodel SM in the instance of the data structure types 112,114, respectively, comprised in the data storage 110; - substituting the internal objects Oi and relations Ri with the submodel SM; - outputting the created submodel SM, the external objects Oe and relations Re to e. g. a display unit; and - displaying the created submodel SM and the external objects Oe and relations Re on the display unit, e. g. , a screen, either instead of the previously presented

model or in addition to it.

Remove submodel operation The remove submodel operation removes a submodel but not its internal model elements, which are inserted in the surrounding model. Thus, this operation is the reverse of the operation create submodel from selection.

Graphically, a submodel object and the remove submodel operation are inputted and selected by means of a user command. The submodel is then replaced with the internal objects and relations and the screen content is then updated having the internal objects and relations inserted in the surrounding model.

Thus, the remove submodel procedure takes the selected submodel SM as an input parameter and identifies the submodel SM. The internal objects Oi and relations Ri of the submodel SM are then retrieved from a data storage 110. The retrieval is performed by retrieving the instances of the object data structure types 112 and instances of relation data structure types 114 having the submodel Name attribute, e. g. Model 0, as a Parent attribute. Further, the information about the submodel SM is possibly removed from the data storage 110, i. e. the instance of the submodel data structure type 112a for the current submodel is removed from the data storage 110. Further the submodel Name attribute, e. g. Model 0, is removed from the Parent attribute comprised in the instances of the object data structure type 112 and the instances of the relation data structure type 114, respectively. Then the internal objects Oi and relations Ri will be outputted from the remove submodel procedure as output parameters to e. g. a display procedure displaying the internal objects Oi and relations Ri together with the entire model.

The remove submodel procedure comprises in one embodiment of the invention the steps of : - receiving a selected submodel SM as an input parameter; - identifying the submodel SM; - retrieving the internal objects Oi and relations Ri of the submodel SM from a data storage 110 ; - removing the submodel SM, i. e. the instance of the submodel data structure type 112a, from the data storage 110 and accordingly updating the instances of the object data structure type 112 and the instances of the relation data structure type 114, respectively; - outputting the internal objects Oi and relations Ri to e. g. a display unit; and - displaying the internal objects Oi and relations Ri on the display unit, e. g. , a screen, either instead of the previously presented model or in addition to it.

Delete submodel operation The delete submodel operation deletes a submodel object together with all the internal objects and the corresponding relations, such as the achieve and condition relations. The toplevel goals and leaf goals are not deleted.

Graphically, a submodel object is selected by means of an inputting means and the operation is performed in response to a user command. The screen contents are replaced by the remaining parts of the surrounding model.

Thus, the delete submodel procedure takes the selected submodel SM as an input parameter and identifies the submodel SM. The internal objects Oi and relations Ri of the submodel SM are then retrieved from a data storage 110. The retrieval is performed by retrieving instances of object data structure types 112 and instances of the relation data structure types 114 having the submodel Name attribute, e. g. Model 0, as a Parent attribute. Further, the information about the submodel SM is together with the information about the internal objects Oi and relations Ri deleted from the data storage 110, i. e. the instances of the object data structure types 112 and the instances of the relation data structure types 114 for these objects and relations are deleted from the data storage 110.

The delete submodel procedure comprises in one embodiment of the invention the steps of : - receiving a selected submodel SM as an input parameter; - identifying the submodel SM; - retrieving the internal objects Oi and relations Ri of the submodel SM from the data storage 110 ; - deleting the information about the submodel SM together with the information about the internal objects Oi and relations Ri, i. e. deleting the corresponding instances of the object data structure types 112 and instances of the relation data structure types 114, from the data storage 110; Connect toplevel goal operation The connect toplevel goal operation creates an achieve relation between an existing external goal and a submodel in the closed state. The goal then becomes a toplevel goal of the submodel.

Graphically, the goal and submodel objects are connected by means of an inputting means, such as mouse clicks, and the achieve relation is then established and the objects and the relation are shown on the screen.

Thus, the connect toplevel goal procedure takes an existing external goal Oe and a submodel SM in closed state as input parameters and creates an external relation Re, such as an achieve relation, between the goal Oe and the submodel SM.

The inputted external goal Oe and the submodel is identified and the instance of the

submodel data structure type 112d for the submodel are retrieved from a data storage 110. The instance of the submodel data structure type 112d is analysed to <BR> <BR> see if the submodel is in a closed state, i. e. , if the State attribute of the instance of the submodel data structure type 112d is closed. If the submodel is in a closed state, an external relation is thus created together with an instance of the relation data structure type 114 for the external relation. The identity of the external goal Oe, which is connected to the created relation Re, is added to the Top Level Goal attribute of the instance of the submodel data structure type 112d of the submodel SM. Further information about the submodel SM is stored in the Model attribute of the instance of the relation data structure type 114 of the created relation Re.

Furthermore, the identity of the created external relation Re is added to the Relation attribute of the instance of the goal data structure type 112a for the external goal Oe and the identity of the external goal is assigned to the Goal attribute of the instance of the relation data structure type 114 for the relation Re. Then the external relation Re, external goal Oe and the submodel SM will be outputted from the connect toplevel goal procedure as output parameters to e. g. a display procedure displaying the external relation Re, external goal Oe and the submodel SM together with the entire model.

The connect toplevel goal procedure comprises in one embodiment of the invention the steps of : - receiving an existing external goal Oe a submodel SM as input parameters; - identifying the submodel SM and the external goal Oe ; - retrieving information about the submodel SM from a data storage 110, i. e. retrieving the instance of the submodel data structure type 112d of the submodel SM; - if the submodel is in the closed state, i. e. having a State attribute equal to closed, creating an external relation Re between the external goal Oe and the submodel SM, thus creating an instance of a relation data structure type 114; - storing said external relation Re, i. e. storing an instance of a relation data structure type 114, in a data storage 110 and updating the instance of the submodel data structure type 112d and the instance of the goal data structure type 112a; - outputting the external relation Re, external goal Oe and the submodel SM to a e. g. display unit; and - displaying the external relation Re, external goal Oe and the submodel SM on the display unit, e. g. , a screen, either instead of the previously presented model or in addition to it.

Create toplevel goal internally operation The create toplevel goal internally operation creates a goal in a submodel, which is in the open state. The goal is designated as a toplevel goal, and becomes a toplevel goal of the submodel. The goal also becomes available in the surrounding model.

Graphically, a goal is created and placed above the upper line in an open submodel object, that is, in the area marked 10 in the figure 9. If the submodel later is closed, the goal is also available on the outside in the surrounding model.

Thus, the create toplevel goal internally procedure takes an open submodel SM as input parameter, identifies the submodel SM and creates an external goal Oe connected by means of an external relation Re, such as an achieve relation, to the submodel SM. The instance of the submodel data structure type 112d for the submodel is retrieved from a data storage 110 and analysed to see if the submodel is in an open state, i. e. , if the State attribute of the instance of the submodel data structure type 112d is open. If so, an instance of a goal data structure type 112a is created for the external goal together with an instance of a relation data structure type 114. Further, the Relation attribute of the instance of the goal data structure type 112a is assigned the identity of the created relation and the Goal attribute of the instance of the relation data structure type 114 is assigned the identity of the external goal. The location of the goal on a display is defined by the Screen Position attribute of the instance of the goal data structure type 112d. The identity of the created goal Oe is added to the Top Level Goal attribute of the instance of the submodel data structure type 112d of the submodel SM. Then the external relation Re, external goal Oe and the submodel SM will be outputted from the create toplevel goal internally procedure as output parameters to e. g. a display procedure displaying the external relation Ran external goal Oe and the submodel SM together with the entire model.

The create toplevel goal internally procedure comprises in one embodiment of the invention the steps of : - receiving a submodel SM as an input parameter; - identifying the submodel SM; - retrieving the instance of the submodel data structure type 112d from a data storage 110 ; - if the submodel SM is in the open state, creating an external goal Oe and an external relation Re between the external goal Oe and the submodel SM, and creating the corresponding instances of the goal data structure type 112d and the relation data structure type 114; - storing the external goal Oe and an external relation Ré, i. e. the created instance of the goal data structure type 112d and the created instance of the relation data

structure type 114, in a data storage 110, and updating the instance of the submodel structure type 112d to comprise the identity of the created goal Oe ; - outputting the external relation Re, external goal Oe and the submodel SM to a e. g. display unit; and - displaying the external relation Re, external goal Oe and the submodel SM on the display unit, e. g. , a screen, either instead of the previously presented model or in addition to it.

Connect leaf goal operation The connect leaf goal operation creates a condition relation between an existing external goal and a submodel in closed state. The goal then becomes a leaf goal of the submodel.

Graphically, the goal and the submodel objects are connected by means of an inputting means, such as mouse clicks, and the condition relation is established and shown on the screen.

Thus, the connect leaf goal procedure takes an existing external goal Oe and a submodel SM as input parameters and creates an external relation Re, such as an condition relation, between the goal Oe and the submodel SM. The connect leaf goal operation identifies the inputted existing external goal Oe and the inputted submodel SM. Further the instance of the submodel data structure type 112d of the inputted submodel is retrieved from the data storage 110 and analysed to see if the State attribute of the instance of the submodel data structure type 112d is equal to closed.

If this is the case, an instance of a relation data structure type 114 is created for the created external relation. The Goal attribute of the instance of the relation data structure type 114 is assigned the name of the existing external goal and the identity of the created external relation Re is assigned to the Relation attribute of the instance of the goal data structure type 112a for the external goal Oe. Further, the identity of the external goal Oe, which is connected to the created relation Re, is added to the Leaf Goal attribute of the instance of the submodel structure type 112d of the submodel SM. Furthermore, information about the submodel SM is stored in the Model attribute of the instance of the relation structure type 114 of the create relation Re. Then the external relation Re, external goal Oe and the submodel SM will be outputted from the connect leaf goal procedure as output parameters to e. g. a display procedure displaying the external relation Re, external goal Oe and the submodel SM together with the entire model.

The connect leaf goal procedure comprises in one embodiment of the invention the steps of : - receiving an existing external goal Oe a submodel SM as input parameters; - identifying the external goal Oe and the submodel SM;

- retrieving the instance of the submodel data structure type 112d from a data storage 110; - if the submodel is in the closed state, creating an external relation Re between the external goal Oe and the submodel SM and creating an instance of a relation data structure type 114 for the created external relation ; - storing the external relation Re, i. e. the instance of the relation data structure type 114 in the data storage 110 and updating the instance of the submodel data structure type 112d and the instance of the goal data structure type 112a comprised in the data storage 110; - outputting the external relation Ref external goal Oe and the submodel SM to e. g. a display unit; and - displaying the external relation Re, external goal Oe and the submodel SM on the display unit, e. g. , a screen, either instead of the previously presented model or in addition to it.

Create leaf goal internally operation The create leaf goal internally operation creates a goal in a submodel, which is in the open state. The goal is designated as a leaf goal, and becomes a leaf goal of the submodel. The goal also becomes available in the surrounding model.

Graphically, a goal is created and placed below the lower line in an open submodel object, that is, in the area marked 30 in figure 9. If the submodel later is closed, the goal is also available on the outside in the surrounding model.

Thus, the create leaf goal internally procedure takes an open submodel SM as input parameter, identifies the submodel SM and creates an external goal Oe of a goal existing in the submodel SM. The goal is connected by means of an external relation Re, such as a condition relation, to the submodel SM. Thus, the instance of the submodel data structure type 112d for the submodel is retrieved from the data <BR> <BR> storage 110 and analysed to see if the submodel is in an open state, i. e. , if the State attribute of the instance of the submodel data structure type 112d is open. If so an instance of a goal data structure type 112a and an instance of a relation data structure type 114 are created for the created external goal Oe and the created external relation Re, respectively. Further, the Goal attribute of the instance of a relation data structure type 114 is assigned the identity of the goal and the identity of the created goal Oe is added to the Leaf Goal Attribute of the instance of the submodel data structure type 112d of the submodel SM. Then the external relation Re, external goal Oe and the submodel SM will be outputted from the create leaf goal internally procedure as output parameters to e. g. a display procedure displaying the external relation Re, external goal Oe and the submodel SM together with the entire model.

The create leaf goal internally procedure comprises in one embodiment of the invention the steps of : - receiving a submodel SM as an input parameter ; - identifying the submodel SM; - retrieving the instance of the submodel data structure type 112d from a data storage 110 ; - if the submodel SM is in the open state, creating an external goal Oe and an external relation Re between the external goal Oe and the submodel SM, creating an instance of a goal data structure type 112a and an instance of a relation data structure type 114; - storing the instance of the goal data structure type 112a and the instance of a relation data structure type 114 in the data storage 110 and updating the instance of the submodel data structure type 112d ; - outputting the external relation Re, external goal Oe and the submodel SM to e. g. a display unit ; and - displaying the external relation Re, the external goal Oe and the submodel SM on the display unit, e. g. , a screen, either instead of the previously presented model or in addition to it.

Other internal operations All model-building operations available for creating and editing MFM models are also available in a submodel, when it is in the open state. All the created model elements (except toplevel and leaf goals) become internal model elements of the submodel. Examples of such operations are create, connect and move.

Graphically, the internal model elements are comprised in the area marked 20 in figure 9.

Other external operations Further, closed submodels can be moved, copied, undone, etc. , in the same way as other MFM objects.

The present invention has been described with reference to exemplary embodiments, however those skilled in the art will appreciate that various changes and modifications can be made to the exemplary embodiments while remaining within the scope of the of the invention.