The present invention relates to system mapping architectures. BACKGROUND OF THE INVENTION In the operation of large complex systems, failure conditions can occur where alternative modes of operation need to come into effect. A failure of one part of a system can have a knock-on effect on the operation of quite remote parts of the system or on the system as a whole. The need to identify alternative modes of operation can be critical where the operation of the system is necessary in terms of safety, the need to maintain capability, or the need to maintain operations.

During failure conditions, organisations typically rely upon system experts to assess the current system state and provide an assessment of what can be achieved or not achieved with the remaining system and whether alternative means are available. However, where a system is a complex arrangement of interrelated microsystems and/or a hierarchical system structure, the system assessment may require individual assessments of each microsystem and/or each level of a hierarchical system. This can prove to be an inefficient and slow process requiring individual reports to be filed and collated for each microsystem or system level.

Expert systems are known for monitoring or simulating system operations. Expert systems are typically based upon a database of expert knowledge. When, for example, a failure condition occurs in a system, an expert system will provide solutions or alternatives for overcoming the failure. Essentially, an expert system can provide what should be done. However, known expert systems do not consider what can be done. This is a question which requires knowledge of the capabilities of a system.

It is an object of the present invention to provide a way of readily determining the operating capabilities of an actual or simulated system. It is a further preferred object of the present invention to readily assess how a failed capability can be corrected for.

It is a further preferred object of the present invention to readily determine alternative ways of maintaining a capability.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention there is provided a system mapping architecture for processing and mapping operating capabilities of a system based upon an interrelationship model, said model including: a plurality of objects, each object representing a component of said system or a capability of at least part of said system, wherein each object has a current state; and a plurality of sets, each set having at least one associated object and each set having a current state, wherein the current state of a set is determined by the current state(s) of the object(s) associated with the set; wherein each object, which represents a capability of at least a part of said system, has at least one associated set; the current state of an object, which represents a capability of at least part of said system, being determined by the current state(s) of the associated set(s); wherein each of said plurality of objects and each of said plurality of sets are recursively processed to determine the current state of each object and each set until the current state of each object and each set achieves a fixed state.

Preferably, the system mapping architecture will be implemented in a computer or provided in a software package. According to a second aspect of the present invention there is provided a method for providing a system mapping architecture for determining operating capabilities of a system, said method including the steps of: creating an interrelationship model, said model including: a plurality of objects, each object representing a component of said system or a capability of at least part of said system, wherein each object has a current state; and a plurality of sets, each set having at least one associated object and each set having a current state, wherein the current state of a set is determined by the current state(s) of the object(s) associated with the set; wherein each object, which represents a capability of at least part of said system, has at least one associated set; the current state of an object, which represents a capability of at least a part of said system, being determined by the current state(s) of the associated set(s);

processing each of said plurality of objects and each of said plurality of sets are to determine the current state of each object and each set; and repeating said processing step until the current state of each object and each set achieves a fixed state. The present invention provides the advantage of processing and providing the various operational capabilities of an actual or simulated system. The present invention is particularly advantageous where the system is complex involving higher and higher levels of capability, ie operational capabilities which are reliant upon other operational capabilities. It is envisioned that the present invention will have particular advantageous application in large complex organisational structures, for example, the organisation of health services, defence services or emergency services. It is also envisioned that the present invention will have advantageous applications in industrial systems, for example, operational plant systems, power generation systems, power distribution networks or telecommunication networks. BRIEF DESCRIPTION OF THE DRAWINGS

An illustrative embodiment of the present invention will be described with reference to the accompanying drawings wherein:

Fig. 1 is an Object Role Modelling (ORM) model applicable to a preferred embodiment of the present invention;

Fig. 2 is a flow chart of the processing of a preferred embodiment of the present invention;

Fig. 3 is an example of a capability model applicable to a preferred embodiment of the present invention; Fig. 4 is an example of a capability model applicable to a preferred embodiment of the present invention;

Fig. 5 is an example of a capability model applicable to a preferred embodiment of the present invention;

Fig. 6 is an example of a capability model applicable to a preferred embodiment of the present invention;

Fig. 7 is an example of a capability model applicable to a preferred embodiment of the present invention;

Fig. 8 is an example of a capability model, which combines the models of Figs. 3 to 7, applicable to a preferred embodiment of the present invention. DESCRIPTION OF EMBODIMENT

For convenience, the present invention will herein be referred to as a Capability Mapping Architecture (CMA). The CMA can be implemented on common computing platforms (eg PC, Apple, IBM, Sun, HP), utilising commonly known operating systems (eg Windows, HPUX, Solaris, Linux, BSD Unix, Mac OS) and in common programming languages (eg Visual Basic, C++, C, C#, Pascal, Java). The basic CMA structure is based upon an interrelationship model such as an Object Role Modelling (ORM) model. The model is preferably implemented in a relational database. Although it will be appreciated that other implementations could be employed, for example, in a rule-based structure such as an expert system. A representation of a preferred applicable ORM model is shown in Fig. 1.

The ORM model establishes the interrelationship between objects. An object is an abstract representation of a real-world concept or thing. In terms of the CMA, an object represents a component or a capability of a system. The ORM model also includes sets. A set represents one or more objects which are required to produce a capability.

The ORM model treats components and capabilities in the same way. A low level capability may be dependent upon a number of components. However, as a system becomes more complex, higher level capabilities may be dependent upon a combination of components and/or capabilities. Referring to Fig. 1 , each component (and capability) has a state. The state represents quantitative and/or qualitative information about the respective component (or capability). In terms of components, the type of information represented by a state may be dictated by the system or the component's role in such a system. Examples of component states may include activity state, production level, capacity, event probabilities etc. A capability state, in relatively simple applications, will be an indication of whether the capability can be achieved or not. However, in more advanced applications, the capability state

may not be a simple binary value but represent a fraction or percentage of an optimum capability.

Sets also have respective states. The state of a set is dependent upon the states of the components and/or capabilities represented by the set. In Fig. 1 , Component Set represents the relationship between components/capabilities and sets. This is a many to many relationship as a component/capability may be involved in more than one set, and a set may represent more than one component/capability.

Capability Set represents the relationship between sets and capabilities. This, again, is a many to many relationship as a set may produce more than one capability, and a capability may be derived from more than one set.

In order to implement the CMA, the ORM model is processed until all the states in the model have reached a steady state. The processing involved is illustrated in Fig. 2. Prior to processing, the ORM model is provided with initial states for each component, set and capability. The only states which can be truly derived from a system are the component states. The CMA assumes that the component states are fixed states. The set and capability states are set at a default state.

The processing involves recursively examining each set and capability until such time that there are no changes of state.

In terms of examining a set, the components/capabilities represented by the set are identified in the Component Set. The states of the components/capabilities are subjected to appropriate combinational computation to derive the set state. For example, in the simple case where the states have a binary value, if any of the components/capabilities in the Component Set has an inactive state then the set state is made inactive; if all of the components/capabilities in the Component Set have an active state then the set state is made active.

In terms of examining a capability, the sets which provide the capability are identified in the Capability Set. The states of the sets are subjected to appropriate combinational computation to derive the capability state. For example, in the simple case where the states have a binary value, if any of the sets in the Capability Set has an active state then the capability state is made

active; if none of the sets in the Capability Set has an active state, ie they are all inactive, then the capability state is made inactive.

It will be appreciated that the states of certain sets will not be immediately determined until the states of certain capabilities are determined and vice versa. It is for this reason that the processing is recursive or circular until all the states reach a steady state.

The processing requires that the components have fixed states. Obviously in a real system component states also change. Therefore the CMA acts upon a snapshot of the component states of the system at a single point in time. However, it is envisaged that the CMA could be adapted so that, upon a change in component state, an updated ORM model is created and the processing of the updated ORM model is instigated. In this way, a pseudo real-time CMA can be created.

Preferred embodiments of implementing the CMA will now be described. To assist with the description of these implementations a simple illustrative example of a system will be employed. In this system the states of the components, capabilities and sets have simple binary values, i.e. active or inactive. For this reason, Boolean algebra is readily able to be applied as the combinational computation in this system. It will be appreciated that in other systems the states may not be simple binary values. For example, depending upon the system, the states may need to represent a percentage of an optimum state or even a probability value to properly assess the capabilities of the system. In such cases, Boolean algebra could clearly not apply and some other appropriate form of combinational computation would need to be applied. It is expected that the selection and formulation of an appropriate combinational computation would be apparent to the person skilled in the art having regard to the particular system and capabilities to which the CMA is to be applied. For example, in a system where the states represent a probability (e.g. failure probability) the appropriate combinational computation may be statistical manipulation. In other systems where the states represent production, for example, the capability state may be dependent upon the maximum or minimum states of the set(s) which produce the capability, hence, a threshold comparison may be the appropriate form of combinational computation.

In Figs. 3-8, ovals represent components and capabilities, and square boxes represent sets.

In Fig. 3, there is modelled an example of one particular recipe for making Creme Fraϊche, the Larousse Creme Fraϊche recipe. In this recipe, there are two ingredients, cream and yoghurt, which equate to components. The Larousse recipe itself requires a particular combination of the ingredients; hence, this particular recipe equates to a set of the components. The Larousse recipe produces Creme Fraϊche; hence, Creme Fraϊche equates to the capability of the set. There are other recipes known for making Creme Fraϊche. These other recipes have either different ingredients or different measurements of the same ingredients. Fig. 4 models the capability of producing Creme Fraϊche in accordance with four alternative recipes (sets).

Creme Fraϊche itself is able to be used as an ingredient for other recipes, for example, Cream of Celery Soup. An example of this recipe is modelled in Fig. 5.

Creme Fraϊche, which was previously a capability, is now an ingredient. In terms of the ORM model, this makes no difference as capabilities and components are treated as the same. The Cream of Celery Soup recipe (set) produces two possible capabilities, ie the specific "Cream of Celery Soup" or the generic "Soup".

One of the other ingredients for Cream of Celery Soup is milk. Milk was also an ingredient for one of the Creme Fraϊche recipes. If, for example, milk was not available (inactive state) then Creme Fraϊche (capability) could still be made from one of the alternative recipes (sets). However, Cream of Celery Soup (capability) could not be made as the Cream of Celery Soup recipe (set) specifically requires milk as an ingredient (component).

Cream of Celery Soup can be one of many courses in a dinner plan. Fig. 6 models a particular dinner plan called a French Banquet. Fig. 7 models a more generic dinner plan.

Fig. 8 shows all of figs. 3-7 combined to form a complex system model. This model can be used to determine which recipes can or cannot be cooked. The model can also be used in reverse to identify the ingredients needed for a

recipe and whether or not those ingredients are available. For example, a user may realise that if he obtained some eggs then he would be able to make Cream of Celery Soup, since he has all the remaining ingredients.

Before the CMA can be processed, the states of all the components, sets and capabilities must be initially established. In the dinner example, the states of all the components would be known, ie they are available (active) or unavailable (inactive). A tabular example of the dinner components follows:

A tabular example of the applicable sets follows. Initially all the set states are inactive by default.

A tabular example of the applicable capabilities follows. Initially all the capability states are inactive by default.

The following is a pseudo code which performs the CMA processing. The code iterates through the component to set lists and the set to capability lists recursively until such time that no states change.

continue_flag = true do while continue_flag continue_flag = false for each element in Set set_result = true for each matching component in the Set get component state from component list set_result = (set_result AND component state) next component

if set_result <> Set.State continue_flag = true

Set.State = set_result End if next set element

for each capability in capability list capability_result = false get capability state from component list for each matching set in the capability list get Set.State from set list capability_result = (capability_result OR Set.State) next set if capability_result <> capability state continue_f lag = true capability state = capability_result end if next capability end

The first part of the code processes the sets. As an illustrative example there follows the code execution for the set "Larousse Creme FraTche" with all ingredients (components) active or true.

The first time through the loop component = Cream. Looking up Cream in the list we get the State = True.

The set_result is logically Anded with the component state, ie True and True = True. This result is placed in set_result.

The second time through the loop component = Yoghurt. Looking up Yoghurt in the list we get the state = True. The set_result is logically Anded with the component state, is True and

True = True. This result is placed in set_result.

There are no more matching components for this set so the loop ends.

The set_result, which is True, does not equal the existing set.state, which is False (or inactive). Therefore the continuejlag is set to True indicating a change of state has occurred during a processing run. The set.state is set to the set_result, ie True. Thus the set state for Larousse Creme Fraϊche is set as active.

As an illustrative comparison there follows the code execution for the set "Larousse Creme Fraϊche" with one of the ingredients (components) Cream inactive or False.

The first time through the loop component = Cream. Looking up Cream in the list we get the State = False.

The set_result is logically Anded with the component state, ie True and False = False. This result is placed in set_result.

The second time through the loop component = Yoghurt.

Looking up Yoghurt in the list we get the state = True. The set_result is logically Anded with the component state, is False and

True = False. This result is placed in set_result.

There are no more matching components for this set so the loop ends.

The set_result, which is False, does equal the existing set.state, which is

False (or inactive). Therefore the continue_flag remains as False indicating that no change of state has occurred during a processing run. The set.state is set to the set_result, ie False. Thus the set state for Larousse Creme Fraϊche is set remains inactive.

The second part of the code processes the capabilities. As an illustrative example there follows the code execution for the capability Creme Fraϊche with all sets (recipes) active or True.

The capability state is stored in the component list for this capability and is by default set to inactive or false.

The first matching set for Creme Fraϊche is the Larousse Creme Fraϊche.

The set state is True. The capability _result is logically ORed with the set state. The result of this will be a True due to the set state.

The code will then run through the next matching sets (Lach Creme Fraϊche, Lach Creme Fraϊche Low Fat and Lach Creme Fraϊche Sour Cream) in

turn. These all have True set states hence the capability_result in each case will remain True.

Once all four sets for this capability have been processed then the loop ends. If, at the end of the loop, the capability result had changed from that initially stored, then the continue-flag would be set as True to indicate that further processing is needed.

The above pseudo code essentially results in providing the states of capabilities in the system. However, the code may be adapted to provide some additional useful data. For example, in cases where a capability results in an active state, the sets which provide the active state could be identified to the CMA user. Furthermore, in cases where a capability results in an inactive state, the code may provide the means to back chain the CMA to identify the sets or components which caused the inactive capability. An alternative means of implementing the above processing is to use a forward chaining inference engine, eg CLIPS engine.

Each set and component attached to a set are transformed into a rule which requires each component to be active before the rule is activated. On activation, the rule creates a fact that the set is active. As the system, and hence the ORM model, increase in complexity, the implementation of the CMA by a forward chaining inference engine can be more susceptible to typographical, semantic and programmatic errors. In such cases, it has been found to be preferable to utilise an automated parser, using a database, which can generate rules by transforming the relationships described in the data. The data is easier to view and check when stored in a database as it can be sorted and queries can be created to check that the model is semantically correct.

Furthermore, editing is easier and the database can be used to provide configuration management of the data.

As an illustrative example, consider the set Larousse Forcemeat Stuffing Breast. An appropriate rule would be:

(default set_larousse_forcemeat_stuffing_breast (component butter active)

(component chicken active) (component eggs active) (component flour active) (component pepper active) (component salt active)

=>

(assert (set l_arousse_forcemeat_stuffing_breast active))

Each capability and each set that can provide that capability generate a rule, which triggers when the set is active and the capability is not active. On activation, the rule creates a fact that the capability is active.

As an illustrative example, consider the capability Forcemeat. An appropriate rule would be:

(default cap_larousse_forcemeat_stuff ing_breast

(set larousse_forcemeat_stuffing_breast active) (not (component forcemeat active)) =>

(assert (component forcemeat active))

(default cap_larousse_forcemeat_stuffing_veal

(set larousse_forcemeat_stuffing_veal active) (not (component forcemeat active)) => (assert (component forcemeat active))

The inference engine approach is beneficial in terms of providing faster processing of capabilities in a CMA. However, the forward chaining inference engine does not, by itself, support the facility of back chaining, which, as indicated before, could source the problems with failed capabilities. It is therefore preferable to incorporate a back chaining model into this implementation. The back chain model can be built by using the same data stored in the database used to create the ORM model.

One approach for implementing the back chain model is to make a node structure from the data. A node list of the components/capabilities is created. Each node is a structure containing textual, type and other information. In the case of capabilities, the structure contains a list of pointers to the sets attached to the capability. The sets themselves are stored in a node list. Each node in the set node list contains textual and again a list of pointers to component/capability elements making up the set. The node list is only needed in the backward direction from capability to components and, hence, is the reference to back chaining. An alternative approach for implementing the back chaining model is similar to the above approach, however, using XML. The components/capabilities are stored in XML nodes. Sets too are stored in XML nodes. Each capability XML node contains a list of the set XML nodes that make up the capability. Each set XML node contains a list of component/capability XML nodes that make up the set. The XML file is then interpreted into a Document Object Model (DOM), an internal representation of an XML structure, which allows the structure to be interacted with.

As discussed before, depending upon the system in question, the states may include representations of different types of information and as a result the combinational computation can be different. There follows two examples to illustrate this point.

Using Logistics as an example, each component of a system can be calculated as having failure probabilities. Examples of such probabilities may be figures representing Mean Time Between Failure (MTBF) or Mean Time To Repair (MTTR). Logistics engineers use these figures along with spares holdings to calculate availability figures for equipment over a mission period. For example, based upon known failure rates, one can hold 5 spares and maintain 95% operational time over 3 months. The CMA can be use to combine the individual component availability figure (or conversely the chance of failure) to provide a figure showing the availability of a capability. While the logistics engineer can do this calculation, the

CMA model can continually recalculate and reassess the calculation based upon actual data as it is happening.

As an example, consider a computer network, having 3 computers and a printer, which can be connected by a switch to form a system. The following table lists the probabilities of failure for each of the components over a year.

In the CMA, these equipment items could be included in a set which requires all elements to be available. The probability that the set will be available can be calculated by combining the probabilities of each component and subtracting the probability of both occurrences. This can be calculated as a single equation or by combining the components one by one. The following equations illustrate the latter.

X1 = P(Computer A) + P(Computer B) - P(Computer A).P(Computer B)

0.11 + 0.05 - (0.11).(0.05) 0.1545

X2 = P(Computer C) + X1 - P(Computer C).X1 0.45 + 0.1545 - (0.45). (0.1545)

0.534975

X3 = P(Printer) + X2 - P(Printer).X2

0.24 + 0.534975 - (0.24). (0.534975) 0.646681

P(Set) = P(Switch) + X3 - P(Switch).X3

0.13 + 0.646681 - (0.13). (0.646681 ) 0.6926254

Therefore, there is a 69.2554% chance of the set failing during the period. Consider that now the set can provide a capability as a backup call centre and that there exists another centre (set) with a similarly calculated failure probability of 0.546 chance of failure.

The failure probability of this capability could now be defined as the probability that either one centre (set) is available. This can be calculated by multiplication of the set probabilities, giving a 35.3% chance that a backup centre will not be available.

The CMA could be used to combine production levels to combined capability production levels, in certain systems. For example, consider an electrical generator complex having a number of generators. The generators can be used in different combinations depending upon demand, maintenance routines and cooling off times. In this context, a mode of operations may be achieved by using generators 1 , 2 and 3. Each generator may produce 100MW of power, providing a total power of 300MW.

Hotel services may require 250 MW of power. Consider that power for the hotel services may provided by the above three generators, a fourth generator which can produce 280MW, or a fifth generator which can produce 260MW. In this case, the capability can show that a minimum of 260MW can be achieved if all the different power sources are available.

While the present invention has been described with reference to specific preferred embodiments, it will be appreciated that various modifications and changes could be made to this embodiment without departing from the scope of the invention.