WO2000008575A1

WO2000008575A1 - System and method for controlling revisions in an application

Info

Publication number: WO2000008575A1
Application number: PCT/AU1999/000615
Authority: WO
Inventors: Dermot Terrence Kennedy; Steven David Jones; Joshua Roland Urs Petrig
Original assignee: I & E Systems Pty. Ltd.
Priority date: 1998-07-31
Filing date: 1999-07-30
Publication date: 2000-02-17
Also published as: WO2000008576A1; WO2000008574A1

Abstract

A revision control system for use in an application having at least one set of components; said revision control system comprising a common project and at least one revisions project; said revision control system adapted to reserve components from said set against either said at least one revisions project or said common project wherein said system prevents said application from amending components reserved against said common project and said system allows said application to amend components reserved against said at least one revisions project and wherein said system is adapted to control the project against which said components are reserved whereby said system controls amendment of said components by said application.

Description

TITLE

"System and method for controlling revisions in an application"

FIELD OF THE INVENTION

The present invention relates to a computer engineering design system and aspects thereof, which have particular, but not exclusive, utility in the design, maintenance and upgrading of large scale reticular systems of components, such as large scale electrical circuits incorporating instrumentation for industrial plants.

BACKGROUND ART

Throughout the specification, unless the context requires otherwise, the word "comprise" or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

In large scale industrial plants such as offshore platforms in the oil and gas industry, the design of any reticular system such as electrical and instrumentation works, is of a complex and extensive nature. Accordingly, it is a standard and essential practice to thoroughly document the design of these systems in specification manuals and drawings.

The number of drawings of such a design in an offshore platform can be in the order of many thousands and consequently it is a major task to manage these drawings, particularly when changes are being undertaken to the same on virtually a daily basis by a number of different parties.

For instance, during the design of a new plant, there may be many different projects being undertaken by different project teams, simultaneously, who may be based in different geographical locations, depending upon who has been awarded the project. Each of these projects will involve the creation of new drawings which need to be added to a common store of such drawings, and may overlap with drawings of previously completed projects or projects being undertaken simultaneously by other project teams.

A similar situation arises with an existing plant which may have been operational for many years, and which has been the subject of an ongoing maintenance and upgrading program of existing electrical and instrumentation systems.

In either case, project teams may require access to stored master drawings or copies of same in order to undertake their particular project, and effect changes to these drawings as a consequence of their project design, or make design choices based on what is shown in these drawings, which may affect their project but not actually effect a change to these drawings.

Whilst a great deal of effort is made to minimise the occurrence of conflicts arising between different project teams by strictly managing the release of master drawings and copies of the same, problems invariably occur through inadequate communication between project teams or inadequate management. This generally manifests itself in the form of cost overruns, arguments between overlapping project team contractees and the owner/manager contractor of the plant, and unexpected delays in project completion.

One of the main reasons for these sorts of problems arising is that the drawings and specifications of same are generally reduced down ultimately to a paper form, even though they may have been drawn with the aid of a computer aided design tool, and thus are ultimately managed in a manual way between different project teams. Further, because different project teams can be totally autonomous to each other, the drawings and specifications created by them in relation to a particular project are not truly integrated with drawings and specifications of other projects, other than that they may be stored together by the contractor/owner at a common site once completed.

The term "as-built" is used in the engineering industry to refer to a component as it exists on a site. The term is used to distinguish such components from proposed changes to a component that are currently being planned by a project but which have not yet been effected and to distinguish such components from new components that are being proposed as part of a project but which have not been installed. Throughout this specification "as-built" will be used in this context.

DISCLOSURE OF THE INVENTION

It is an object of the present invention to alleviate or mitigate at least some of the problems associated with previous management of drawings and specifications developed in the design, maintenance and upgrading of large scale reticular systems of components, and to provide some improvements in relation to the same.

According to a first aspect of the invention, there is provided a revision control system for use in an application having at least one set of components; said revision control system comprising a common project and at least one revisions project; said revision control system adapted to reserve components from said set against either said at least one revisions project or said common project wherein said system prevents said application from amending components reserved against said common project and said system allows said application to amend components reserved against said at least one revisions project and wherein said system is adapted to control the project against which said components are reserved whereby said system controls amendment of said components by said application.

Preferably said revision control system is adapted such that said components have a default reservation against said common project and such that components reserved against said common project are available for reservation against a revisions project in response to commands issued by said application.

Preferably said revisions control system is adapted to allow said application to amend components reserved against a first revisions project in response to said application operating in the context of said first revisions project and said system is adapted to prevent said application from amending components reserved against said first revisions project in response to said application operating in the context of a second revisions project.

Preferably said revisions control system is adapted to transfer components from a first revisions project to a second revisions project in response to commands issued by said application when operating in the context of said first revisions project and to prevent transfer of components from said first revisions project to said second revisions project in response to commands issued by said application when operating in the context of said second revisions project.

Preferably said revisions control system is further adapted such that a user controlling said application nominates a revisions project in respect of which said user will control said application; said nominated revisions project forming said context of operation of said application.

Preferably said revisions control system further comprises a set of area data defining a plurality of areas; said application further adapted to assign at least one area from said area data to each said component and to said projects; said system, in response to commands issued by said application, is adapted to alter the project against which a component is reserved from said common project to a target revisions project; said alteration of said project against which said component is reserved is dependent on a positive result from a comparison of said at least one area assigned to said component with said at least one area assigned to said target project.

Preferably said revisions control system is further adapted such that said revisions projects comprise pre-defined authorisation data and said system is further adapted to transfer a component from a revisions project to said common project in response to receiving authorisation commands from said application corresponding with said pre-defined authorisation data.

Preferably said revisions control system is further adapted such that said authorisation commands are issued by said application subsequent to said application amending said component. Preferably said revisions control system is further adapted such that said projects further comprise a plurality of revisions levels; each said revisions levels having predefined authorisation data; said system adapted to assign a first revision level to a component upon reservation of said component against said revisions project and to re-assign said component to a further revisions levels in response to said system receiving authorisation commands from said application; and wherein said component is transferred to said common project in response to receiving authorisation commands at a final revisions level.

Preferably said revisions control system is further adapted to create a copy of a component in said set of components in response to receiving authorisation commands from said application; said authorisation commands corresponding to predefined authorisation data.

Preferably said revision control system is adapted to create a copy of a component in said set of components upon assigning a component from a first project to a second project.

According to a further aspect of the present invention there is provided a method of controlling revisions to components in an application having at least one set of components, a common project and at least one revisions project; said method comprising the step of 1 ) reserving components from said set against either said at least one revisions project or said common project; 2) preventing said application from amending components reserved against said common project and allowing said application to amend components reserved against said at least one revisions project; and 3) controlling the project against which said components are reserved whereby controlling said revisions to said components by said application.

Preferably said method of controlling revisions to a component further comprises the step 4) of reserving components in said set against said common project as a default; and 5) making components reserved against said common project available for reservation against a revisions project in response to commands issued by said application. Preferably said method of controlling revisions to a component further comprises the step 6) of allowing said application to amend components reserved against a first revisions project in response to said application operating in the context of said first revisions project and preventing said application from amending components reserved against said first revisions project in response to said application operating in the context of a second revisions project.

Preferably said A method of controlling revisions to a component further comprises the step 7) of transferring components from a first revisions project to a second revisions project in response to commands issued by said application when operating in the context of said first revisions project and preventing transfer of components from said first revisions project to said second revisions project in response to commands issued by said application when operating in the context of said second revisions project.

Preferably the method of controlling revisions to a component further comprises the step 8) of a user controlling said application nominating a revisions project in respect of which said user will control said application whereby said nominated application forms said context of operation of said application.

Preferably the method of controlling revisions to a component is further adapted such that said application further comprises a set of area data defining a plurality areas in which said components reside and said method further comprising the step 9) of assigning at least one area from said area data to each said component and to said projects; and the step 10) of, in response to commands from said application, altering the project against which a component is reserved from said common project to a target revisions project said alteration of said project against which said component is reserved being dependent on a positive result from a comparison of said at least one area assigned to said component with said at least one area assigned to said target project.

Preferably the method of controlling revisions to a component further comprises the step 11) of defining authorisation data for each project and 12) transferring a component from a revisions project to said common project in response to receiving authorisation commands from said application corresponding with said authorisation data.

Preferably the method of controlling revisions to a component further comprises the step 13) of said application issuing said authorisation command subsequent to said application amending said component.

Preferably the method of controlling revisions to a component further comprises the step 14) of defining a plurality of revisions levels for said revisions projects; 15) defining authorisation data for each said revision project; 16) assigning a first revision level to a component upon reservation of said component against said revisions project and to re-assign said component to a further revisions level in response to said system receiving authorisation commands from said application; and 17) transferring a component to said common project in response to authorisation commands from said application at a final revisions level.

Preferably the method of controlling revisions to a component further comprises the step 18) of creating a copy of a component in said set of components in response to receiving authorisation commands from said application; said authorisation information corresponding to a predefined authorisation level.

Preferably the method of controlling revisions to a component further comprises the step 19) of creating a copy of a component in said set of components upon assigning a component from a first project to a second project, including said common project.

According to a further of the present invention there is provided revisions control system as detailed above, wherein said system is adapted to assign to said components to said revisions levels in a one-way manner so that in the context of a revisions project a component is only assigned to a revisions level once.

Preferably the revision control system as detailed above further comprises a multiuser environment and said common project is accessible to users of said application. Preferably the revision control system comprises a sub-set of users that have access to pre-defined ones of said revisions projects.

Preferably the revision control system comprises a user having access to more than one revisions project is restricted to controlling said application in the context of one of said projects at any one time to the exclusion of the other projects the user has access to.

Preferably the revision control system is adapted such that each said user of a project is assigned an authorisation level in the context of said project and wherein said users operate said application to issue authorisation commands to said system; said authorisation commands commensurate with said users authorisation level.

BRIEF DESCRIPTION OF THE DRAWINGS

This invention will be better understood with reference to the following description of an embodiment of the invention and the enclosed drawings, in which:

Figure 1 shows in diagrammatical form a computer aided engineering (CAE) system;

Figure 2 shows in diagrammatical form a data structure used in the CAE system of Figure 1 ;

Figure 3a is schematic representation of a Revision Control Process;

Figure 3b is a flow chart of the revision control process of Figure 3a in operation;

Figure 4 is a flow chart of the operation of a conflict management process used by the CAE system of Figure 1 ;

Figure 5 shows a project set up - revisions portion of a Graphical User Interface (GUI) of the computer aided engineering system of Figure 1 ; Figure 6 shows a project set up - areas/facilities portion of the GUI in Figure 1 ;

Figure 7 shows a project set up screen - Users portion of the GUI in Figure 1 ;

Figure 8 shows a login prompt for a user of the GUI in Figure 1 ;

Figure 9 shows a component definition - general details screen as represented by the GUI of Figure 1 ;

Figure 10 shows a component definition - specific details screen as represented by the GUI of Figure 1 ;

Figure 11 shows a revisions prompt accessed through the update button in Figures 9 and 10;;

Figure 12 shows a delete/demolish prompt access through the delete/demolish button of Figures 9 and 10;

Figure 13 shows a revisions control screen accessed through the revisions button of Figures 9 and 10;

Figure 14 shows a component transfer screen accessed through the transfer button of Figure 13.

BEST MODEtSl FOR CARRYING OUT THE INVENTION

The present embodiments are directed towards a computer aided engineering system 100 for instrumentation and electrical components, although it should be appreciated that the Computer Aided Engineering System is also applicable to areas, such as communications systems and piping systems.

In particular the embodiments are directed towards a system for controlling changes to data within a database of the Computer Aided Engineering system. The embodiments are particularly advantageous in respect of the revisions control that they provide in a multi-user environment and multi-project environment. The system for controlling changes to data contained in a database may also be applicable in other data management tools, document management tools or applications development tools, such as Computer Aided Engineering Software (CASE) tools.

The computer aided engineering system of the embodiment utilises a data instantiation technique to minimise duplication of data entry in relation to components. This data instantiation is achieved by defining component specifications from which component instances are instantiated.

A component specification specifies the data attributes related to that component, and whether each data attribute is a specification level attribute or an instance level attribute. Specification level attributes are attributes which are common to all instances of a component. Instance level attributes are attributes that are dependent upon the particular instance of a component in question. For example, a component specification for a control card may include the number of input ports; the name of the card; the number of output indicators. Each of these attributes are common to all control cards of that type and are therefore specification level attributes. Instance level attributes include what is connected to each of the input ports, the tag name of the particular control card; where the particular control card is installed.

Data instantiation reduces data entry since the specification attributes need only be entered once and are automatically present in each instance of that component. A component specification defines the attributes of a specific type of component in an abstract manner. An instance of a component relates to a particular component.

Referring now to Figure 1 , a preferred embodiment of a computer aided engineering (CAE) system 100 is depicted.

The CAE system 100 comprises a data store 105 which stores data generated by the CAE system 100. The CAE system 100 also includes a database management system (DBMS) 140 for generating and managing the data stored in the data store 105. The DBMS achieves this by use of several tools, including a revision control and conflict management tool 145, a component specification and instance definition tool 150, a component connections tool 155, a project definition tool 160, and a drawing tool 165, a classification elements store 112 and a set of graphical symbols in component shape data store 114.

The CAE system 100 of the present embodiment is a networked version that provides the DBMS 140 with access to the data store 105 by means of an applications server tool 135 which communicates with a data server tool 115. The data server tool accesses the data store 105 by means of a transaction management tool 110.

The CAE system also includes a client 185 which is in communication with a CAE graphical user interface (GUI) 190. The client tool 185 communicates with the network 175 by means of a Public Switched Telecommunications network using preferably an ISDN line that feeds into a wide area network that connects to the network 175.

The CAE system however is not limited to having single user access. The CAE system 100 may be arranged according to standard networking procedures so that it can be accessed by a number of users each by means of a separate CAE client 185 and CAE GUI 190. The CAE system 100 may also be implemented in a freestanding version that is not networked.

The skilled addressee will appreciate that the CAE system 100 may be adapted to run on a number of different hardware platforms, including Unix ™ platforms and Windows NT ™ platforms. The CAE client 185 and CAE GUI 190 may also be installed on a number of different hardware platforms, including personal computers (PC) running windows™, Unix™ or Apple ™ operating systems.

Referring now to Figure 2, which is a diagrammatic representation of some of the various data types stored in the data store 105. Some of these data types stored in the data store 105 include Area hierarchy data 200, component specification data 270, component instance data 230, project data 215, user data 210; revision level data 260, and component connections data 250.

Area hierarchy data 200 stored in the data store 105 shall now be described.

The Area hierarchy data 200 is a hierarchal definition of various physical locations with different engineering facilities, sites and/or systems which are modelled by the CAE system 100. By way of example, the engineering facilities may be an offshore facility called Off_Shore_Facility_A 202 and a refinery facility called Refinery_Facility_A 203. Both Off_Shore_Facility_A 202 and Refinery_Facility_A 203 are one level down from a root level, called a root facilities level 201.

The root facilities level 201 contains data common to every engineering facility, site and/or system modelled by the CAE system 100.

One level down in the hierarchy from the Off_Shore_Facility_A data 202 is a number of sub areas (or zones) into which the Off_Shore_Facility_A data 220 is logically divided. Typically these sub areas will be modelled on the area tag names actually used on the facility that the CAE system 100 is modelling. In this example the name attributable for Off_Shore_Faciiity_A 202 has been designated as OSFA. Similarly a Power Generation building 235 on OSFA 220 has been designated name attribute PGB 204. Hence the unique tag for the power generation building 204 of OSFA 203 would be OSFA_PGB 204. Similarly a control room 205 in the PGB 204 may be assigned name attribute CR205. Hence its unique identifier in the Area hierarchy data 200 is OSFA_PGB_CR 205.

Each level in the hierarchy may be viewed as a container. Hence the OSFA 202 level contains the power generation building level 204 and all of its sub levels including the control room 205 and the generation room 206. The control room 205 and generation room 206 are each in turn contained within the power generation building 204. User data 210 stored in the data store 105 shall now be described. It details a list of user identification (id) attributes 211. There is provided one id attribute 211 for each user. These id attributes. 211 serve to identify each user to the CAE system 100. The user data 210 also includes an Authority level attribute 212 which defines the maximum authorisation level that a user can be assigned within a Project 215. Other data such as e-mail addresses 213 may also be contained in user data 210.

Project data 215 stored in the project data store 105 shall now be described. Each project in the project data 210 serves to model a particular project being performed on one of the facilities that is modelled by the CAE system 100. For example a project may be a maintenance project 217 to the control room 205 of the Power Generation building 204 on OSFA 202. Alternatively it may be installation project 218 for the installation of an additional generation plant in generator room 206 in the generation building 204 of OSFA 220.

Each of the projects in the project data 215 contains a project name 219 which uniquely identifies the project within the context of the project data 219.

A sub set of users from the user data 210 are assigned to each Project. Each user in this sub set is assigned a user project id attribute 221. This attribute uniquely identifies the user within the context of the project. It is a security measure allowing users to have different authority levels on different projects.

Each user assigned to a project is assigned a user approval level attribute 223. This provides each user with a certain level of authority within the context of the project for approving changes to design data.

Each project instance also has an authorised area attribute 224 which designates areas in the hierarchy data 200 which a project has access to.

For example, the maintenance project 217 for the control room 205, may only be designated as having access to the actual control room 205 (as opposed to other rooms in the Power Generation Building 204). Whereas, the installation project 218 may be designated as having access to all rooms in the power generation building 204.

In which case, the authorised area data 224 for the control room maintenance project 217 will reference area data for OSFA_PGB_CR 205 in the area hierarchy data 200. The authorisation area data 224 for the installation project 218 will need, only reference the Power_Generation_Building tag 204 (namely OSFA_PGB 204) in order to authorise access of the installation project 218 to every room in the power generation building 204.

Project data 215 may be viewed as a set of containers for the various components and connections (detailed further below) within the CAE system 100. In this regard each component and connection is reserved against a project.

Those components and connections that are not reserved against a project are reserved against a null project called an "As Built Common" project. It is preferable that there be one as built common project for the CAE system 100.

Components and connections that are reserved against the "As Built Common" project are free to be reserved by any project, such as the maintenance project 217 or the installation project 218. Components and connections reserved against a project other than the "As Built Common" project can not be reserved against any other project. This means that only one project can access and amend a particular instance of a component or connection at any one time.

Revisions data 251 which details naming conventions for revisions procedures that are adopted by the various projects 215 shall now be described.

Each revision (amendment/change) of a component 231 and a connection 251 is provided with a name using a revisions Name Attribute 267. An attribute called next revision 269 indicates the next revision level 269 in the sequence of revision levels 260 assigned to a project. An "As Built" 268 flag in the revisions level data 260 when set to 'TRUE" indicates that the component or connection will move to the "As Built Common" project when it issues at the "As Built", revision level.

Preferably, the pre-defined set of revision levels 260 conforms to standard engineering methodology such as "As Built" revision, "Revision A", "Revision B" etc. Each revision level is assigned a minimum approval level. Only users 211 nominated on a project with an appropriate approval level 223 (or higher) can authorise that a particular revision to a component or connection in the CAE system 100 can be marked off as approved.

Revisions data 250 also contains a set of approval levels 220, such as client level, chief engineer level, engineer level, maintenance level, commissioning engineer level etc. A sub set of these approval levels may be selected for the different revision levels 260 of a project. This enables the revisions process for different projects, eg. a maintenance project, to have different sets of authorisation levels than eg. an installation or retro-fit project.

Each approval level 220 in a revision 260 corresponds with one of the approval levels 223 assigned to the users of the project.

Component instance data 230 stored in the data store 105 will now be described.

Each component instance 231 in the component instance data 230 identifies a unique component such as a field device or cable within one of the engineering facilities modelled by the CAE system 100.

For example a component instance 231 may be one of many indicator lights each of which is installed on one of several switch boards. Each of the switch boards being located in the control room 205 of the power generation building 204 on the OSFA 202.

Each component instance 231 in the component instance data 230 has a component instance id attribute 237 which serves to uniquely identify each component of each facility modelled by the CAE system 100. Each component may exist several times within the set of component instances 215 so as to represent the component at different revision levels. This is because some of the components data may change as it progresses from revision level to revision level. The component history id attribute 238 operates as an alternate key for the component instances. It allows the various instances of a component at different revision levels to be distinguished from each other as well as from different components.

Each component instance 231 has an Area attribute 235 which references an area attribute in the Area hierarchy data 200. This area attribute 235 such as OSFA_PGB_CR 205 identifies the location of the component on the modelled facility. Each component may also have a component container id attribute 239 which identifies whether or not a component is contained by another component.

In the example of the indicator lights, component container Id 239 for the indicator lights will reference the panel on the switchboard on which the light is located and the component container Id 239 for each panel will reference the switch board cabinet in which they are located. The component container Id 239 for the switch board cabinet will typically be "null", unless it is itself contained within another component.

Each component instances 231 has a project attribute 236. The project attribute 236 references a project in the project data 215 which has reserved the component instance 231 thereby preventing access to the component by all other projects. Only one project instance may reserve a particular component instance 231 at any one time. If the component instance 231 is not reserved by a project instance then the project attribute 236 references an "As Built Common" project 215. This component instance reservation feature has application in revision control and conflict management procedures of which greater detail is provided below.

A revisions attribute 234 identifies the revision level which a component instance has been approved to within a project. For example a component instance may represent an "As Built" component in which case the component is referenced as belonging to the "As Built Common" project 216 for the facility on which the component is located. Alternatively it may be authorised at "revision level A" or at "revision level B" within the project against which the component instance 231 is reserved.

Each time a component is issued at a new revision level it is preferable that a new instance of the component be created that is, at least in part, identified by its revision level attribute. This enables a component, as it was issued, at various revision levels throughout a project's history to be reviewed. The component and its connections to other components may be issued by different projects.

Finally, each component instance 231 may have one or more connection point attributes 240. A connection point is a point where a component physically inter connects with another. A connection point may refer to an electrical connection or it may refer to a mechanical or hydraulic connection.

Connection point attributes 240 include a multi-point attribute 245. This attribute specifies whether or not the connection points 241 of the component instance 231 are grouped together or whether they are regarded as individual connection points. An example of a multi-point connection point is a three pin power plug for domestic power. The three pin plug has three terminals, positive, neutral and ground. Each of these terminals is a connection point within the CAE system 100. However the three terminals operate as a single unit as mechanically it is not possible to connect any one of the terminals to a power outlet without also connecting the other two at the same time. In this sense a three pin plug is a component that has a multi-point connection attribute.

Within the CAE system 100 a multi-point connection attribute 245 of connection data 240 may be used to check that design data for inter connecting components specifies two components that are mechanically capable of forming an inter connection. The connection point data 240 of the component specification also has a label attribute 242 which is a unique name assigned to each connection point of a component. It also has a ferrule attribute 243 which corresponds to the ferrule name of a component.

The CAE system 100 has a further data set, namely a connections data set 250. This data set details which connection points 241 inter connect to form an instance of a connection 251. As each of the connection points 241 of a connection 251 belong to a component instance 231 the connection data set 250 can be seen to reference connections 251 between components 231.

The connection data set 250 details for each connection 251 which connection point 241 of which component 231 is on the left of the connection 251 with respect to the loop of component which the connection 251 is in. It also specifies which connection point 241 is on the right hand side of the connection 251. This is achieved using two attributes, namely a "connection point on the left" attribute 254 and a "connection point on the right" attribute 255.

Each connection 251 is also flagged against the project data 215 and revisions data 260 in a similar manner to component instances 231.

A revision control process and a conflict management process used by the revisions control and conflict management tool 145 computer aided engineering system 100 will be now be described.

Referring now to Figure 3a which is a schematic representation of a revision control process utilised by the revisions control and conflict management tool 145. It details interactions between three projects, namely the installation project 218, the maintenance project 217 and the null project called the "As Built Common" project 216.

The installation project 218 is represented from the point of view of one component that the installation project 218 creates at 300. The solid outline of the project 218 indicates that the component 305 is contained within the installation project 218. This indicates that no other project within the CAE system 100 can access and modify the component.

The component progresses through various revision levels, namely levels A, B and C as dictated by the revisions data set 260 assigned to the installation project 218.

As the component moves from one revision level to the next, a copy of the component is created within the set of component instances 230. This provides a unique copy of each component at each revision level and allows the progress of a component to be tracked from initial design to being issued at the "As Built' revision level.

In the present example the component is installed and commissioned on the facility at revision level C. Once commissioned the component 305 is said to have been issued at the "As Built" revision level 310. A copy of the component instance with revision attribute 234 set to "As Built 1" is created.

Once the component has been issued at the "As Built 1" revision level it is reassigned to the "As Built Common" project 216. This enables other projects on the facility, whose authorised area attribute 224 encompasses the area where the component 305 is located, to access and modify the component.

If a problem is found with the component once it has been commissioned and issued at the "As Built" revision level 310, the component may be reassigned to the installation project 218.

When the component is reassigned to the installation project 218 it is preferably issued at a revision level that is different to any revision level that it has previously held within the installation project 218. In this case it is reassigned to the installation project 218 at level "OA" 315 and it moves through levels "OB" 315 and "OC" 315 before it issues at the "As Built 2" revision level 320 and is reassigned to the "As Built Common" project 216. When it issues at the "As Built Common" project 216 for the second time, the component is preferably designated as "As Built Revision 2". This indicates that it is the second "As Built" version of the component.

It can be seen therefore that the Revision control process is a one way process for components from revision level to revision level.

Hence within any one project a component is preferably never issued at the same revision level twice.

The revisions process of Figure 3a also indicates how connections data 250 may be assigned to the maintenance project 217 at the same time that the component 305 is assigned to the installation project.

This may arise for example where a controller is being replaced but the circuits that it controls are left unchanged.

In this case, the maintenance project for the unchanged circuit reserves the appropriate connections on the controller, so that the circuit can be re connected once the controller is installed on the facility.

The maintenance project also details that the connections of the component 305 may under go a series of revisions before they issue at the "As Built" level. This may be explained by referring again to the above example of a controller that is installed by the installation project 218. The connections of the controller are still reserved against the maintenance project 217, however it has been decided to modify the circuit that the controller is connected to.

A component that has issued at the ""As Built"" level will preferably exist between two projects, such as the installation project and the maintenance project. This enables different components from the two projects to be connected to the connection points of the same component, such as a controller. These changes to the connections of the controller preferably pass in a one way manner through some (or all) of the revision levels of the maintenance project 217. It should be noted that the maintenance project 217 has adopted a different set of revision conventions to the installation project.

As with the installation project, once the connections of the revised circuit have been commissioned, they issue at the ""As Built"" level. Once they have been issued at the "As Built" level the CAE system re assigns the connections to the "As Built Common" project 216.

Referring now to Figure 3b which shows a flowchart of a revision control process. A set of component instances at an "As Built" revision level 350 and reserved against the "As Built Common" project 216 is depicted. When a new project is needed, the system administrator at the step 355 creates a project say the installation project 218 and assigns to the Authorised Area Attribute 224 of the Project 218, an area or areas from the Area hierarchy data 200 over which the project 218 is authorised to operate. Hence, the project can only modify components and connections whose area attribute 235 corresponds with the area attribute 224 of the project 218. At step 360 the administrator assigns users to the user Project id attribute 221 of the project 218 and also assigns an approval level to each user on the project from the user approval level attributes 223 of the Project 218. At step 365 the administrator predefines the revision level attributes 267 for the project. Once these actions are completed at step 370, the project is ready to modify data and so can be instantiated.

At this point, users at step 375 may log into the project and create or modify components, component specifications and/or connections between components. When a component is created or modified, the user is prompted at step 380 to indicate the revision level 234 of component from the predefined list of revision levels 267.

At step 385, the newly created or modified component is instantiated (stored) in the data store 105 with the revision attribute 234 set as per the revision level selected by the user. At step 390, component instances are selected by authorised users having sufficient approval level attributes 223 and are approved at their current revision level. At step 397, if further changes are made to the component or its connections, the process returns to step 375. If no more changes are recorded to the component or its connections, the component can be installed and commissioned. Once commissioned the component may be set to revision level "As Built". Once the component has been approved at revision level "As Built", the project assignment flag 236 for the component instance is set to the "As Built Common" project and the component is then available for other projects to modify.

Accordingly, the revision control process of the embodiment provides a structured way to manage multiple projects and the large numbers of components and modifications that may be made to these components at any particular time. To maintain quality standards, a revision approval level for each component and its connections to other components is enforced through use of authorisation levels.

Figure 4 shows a flowchart describing a conflict management process.

The process has a set of "As Built" components 465 that are reserved against the "As Built Common" project 215. At step 400 an administrator of the CAE system 100 assigns areas from the Area Hierarchy data 200 to the Authorised area attribute 224 of a project called "Project A". At step 405, a user assigned to Project A modifies a component 231 , as a result of which the project assignment flag 236 for that component now indicates Project A. Effectively, Project A now owns the assigned component until the assigned component is issued at the "As Built" level or until it is transferred to another project. At step 410 further changes may or may not be applied to the component. If further changes are applied, the procedure returns to step 405. As part of this loop, various revision levels 266 within the project may be approved.

If at step 410 further changes to the component are not required, the revision level of the project is set to "as-built" at step 415. The component instance is then issued at the "As Built" revision level and the project assignment flag 236 for the component is reset to the "As Built Common" project 216. To illustrate the conflict management process, at step 420 a second project, "Project B", is assigned one or more areas of one or more facilities within which it may modify components 230. . For the purpose of illustration, it is assumed that the areas assigned to Project A and Project B overlap. At step 425, a user logged into Project B attempts to modify a component. If the Project assignment flag 236 of the component is set to the "As Built Common" project or to "Project B", the user of Project B at step 430 can proceed to modify the component as described above at step 405.

However, if the component which is sought to be modified by the user of Project B has a project assignment flag 236 which corresponds with another project, say

Project A, the user of the Project B is alerted at step 435 that their changes will not be applied because the selected component is currently assigned to Project A.

The user is provided with the name of the Project A and at step 440, resolution of the conflict between Project A and Project B over the component is resolved by negotiation between the users of the projects. If the negotiations conclude that the component should be retained by Project A, then the project assignment flag 236 is retained as Project A and the user of the Project B may not make any changes to that component. The user of the Project B may however, at step 445 continue to make changes to other components that are not currently assigned to any project or that are currently assigned to Project B.

If at step 440, the negotiations conclude that the component should be transferred to Project B then a user of Project A with sufficient authorisation level selects the component and initiates a transfer process. The transfer process enables an authorised user of Project A to select Project B, whereupon the project flag 236 of the component in question is set to Project B. This means that Project B can now modify the component and that Project A can no longer modify the component.

In an alternative embodiment custody of connections 250 between components may be transferred independently of custody of the component 230 that takes part in a connection. In this alternative embodiment, each item of connections data 250 has a project assignment flag associated therewith. In this embodiment each item of connections data also has a revisions attribute 252 which ensures that amendments to connections data proceeds through a revision control process as discussed above in relation to_. components.

With such an embodiment it is preferable that an "As Built Common" component separates Project A and Project B. Assume the component is component C. Certain connections to component C maybe reserved against Project A. Whilst other connections to component C may be reserved against project B. However component C is preferably neither reserved against Project A or Project B. This is to prevent modifications to component C that do not conform with the connections data of any other components that connects to component C. This rule is not essential as other checking procedures may be implemented to deal with conflict between projects arising from connections between components that are reserved against different projects.

Referring now to Figure 5 which shows a project setup screen 500 of GUI 190 in revisions mode. A project name 510 is provided at the top of the screen 500, with a drop-down list 515 provided for selecting other projects. A set of approval level attributes 220 that can be ascribed to a user is shown as a list in the Team Members window 520.

A set of revision levels 266 are shown in an expandable list in an approval authorities frame 525. Each revision level 266 has a name attribute 267 such as "As Built", A, B etc associated therewith. Selecting an expand/collapse button 540 will expand or collapse a list of approval level attributes 220 that are required for each revision level to issue. Approval from a user, with sufficient authority within the Project, is obtained before a revision level 266 is issued. Approval levels attributes 220 can be inserted or removed from a revision level 266 by simply dragging and dropping the required approval levels 220 from the Team Members screen 520 to a selected revision level 266 and vice versa. Alternatively, the "Rev Id" window 54t», the insert button 550 or the delete button 555 may be used.

Three revision levels 266 are shown, named "as-built", "a" and "b". Each of these revision levels 530 has a list of approval level attributes 220. This list indicates that each revision level requires approval from: a user having an authorisation level of at least "editor"; a user having an authorisation level of at least "checker"; and a user having an authorisation level of at least "lead engineer" before the component can issue at each one of revision levels A, B and "as-built". It should be appreciated that different Projects may have different sets of revision levels. These revision levels 266 may have different lists 535 of approval level attributes 220.

A new revisions level 530 can be added to a Project by either selecting a predefined revision level from a drop-down list 545 or a new level defined by typing a revision level name into the list 545 and selecting an "insert new" button 550. Similarly, a revision level can be deleted by selecting the revision level button 530 and then selecting "delete" button 555.

Revision control and conflict management are a Quality Assurance procedures that ensure that modifications to component instances 230 and connections data 250 are performed on a project by project basis.

This is achieved through the data structure of the CAE system 100. Specifically the data structure reserves every component instance 231 against a project by means of the component's project attribute 236. The set of projects includes a null project against which those components that are free for modification by any project are reserved. The null project is called the "As Built Common" project.

The name "As Built" is derived from common engineering terminology that means a component that has been installed and commissioned on a facility. An alternative definition of the "As Built" term is any component installed on a facility that is capable of being modified and that is not reserved against another project.

Should it be determined that certain components on a facility can not be modified without approval by certain persons or departments then the components that make up these systems can be reserved against projects specifically created for this task. This ensures that these components are transferred to a modifying project by a person authorised to approve their release for modification. Some embodiments may permit projects to modify the connections data 250 of these components 230 without allowing the components to be modified. This is achieved by a data structure that has revision control for connections data 250 that is separate to its revision control for component instance data 230.

Referring now to Figure 6 which shows the project set up screen 500 of GUI 190 in "areas and facilities" mode 605. Again, the project name 510 is shown at the top of the screen 500.

A list of facilities 610 from the Area Hierarchy data 200 is provided on the facilities screen 610.

A sub set of areas 615 within these facilities 610 that have been selected for entry against the authorised area attribute 224 of the Project is shown in the selected areas screen 615.

The hierarchical nature of the Area hierarchy data 200 is shown by the facility "Australia" containing three facilities named "Facility A", "Facility B" and "Onshore Plant". Each of these facilities can be expanded to reveal other facilities or areas contained within them. Areas may be added and removed to the selected areas list 615 from the facilities screen 610 by a drag-and-drop procedure.

Referring now to Figure 7, which shows the project set up screen 500 in "users" mode 700. Once again, the project name 510 is shown at the top of the screen 500.

A list of users 705 from user data 210 is provided in an All Personnel screen 705 whilst a list of user approval authorisation level attributes 223 is shown on the team member screen 710.

Assigning users to the project 510 is achieved by means of a drag-and-drop process. A user is selected from the list of users 705 and dragged onto a user approval level attribute 223 in the team members screen 710. This user approval level 223 is then assigned to that user for the project 510. The user may have a different approval level in a different project. Each user is also entered against the user Project Id attribute 221.

A new project can be created by clicking an "add project button" 715. An existing project can be renamed via a "rename project" button 720 or deleted via a "delete project" button 725. A project cannot be deleted if there exists any components whose project identification tags 236 reference the project being deleted. The "Project Setup" screens shown in Figures 5, 6 and 7 are preferably restricted to system administrators.

Referring now to Figure 8 which illustrates a login screen. To gain access to the computer aided engineering system 100, a user logs in by means of a login prompt 800. The user selects the project 282 on which they will be working via a drop down list 805 before entering their user name and password at 810 for that Particular project. The user name and password are checked that they are correct, and the user is then permitted access to the system 100 only in the context of the Project under which they have logged on. To modify a component reserved by a different project, the user logs on under that different project. This allows users to have different authorisation levels in different projects.

Once a user is logged in, the user can access components whose project assignment flag 236 corresponds with the project under which the user has logged on. The user may also access components that are reserved against the "As Built Common" project 216 and that have an area flag 235 that corresponds to the authorised area flag 224 of the project. The privileges granted to the user for the Project will depend upon the user approval level attribute 223 associated with the user when the project 805 is established by an administrator.

Referring now to Figures 9 and 10 which show a component instancing means having a general details screen 900 and a specific details screen 1000. The title bar of the screens 900 and 1000 both include a name 905 and 1005 respectively of a component instance, the current revision level 910 and 1010 respectively of the component and the project reserving the component 215 which is referenced by the project assignment flag 236 of the component instance 231. The tag name of the component is shown on both screens in the "Tag No./ltem" text box 915 and 1015 respectively, where the name can be edited. The area on the facility within which the component 215 is contained is shown in the "Area text box" 920 and 1020 respectively. A description of the component specification, which the component is an instance thereof, is shown in the "component specification text box" 925 and 1020 respectively. "Area Select Button" 930 and 1030 respectively provide a facility to change the area associated with a components area attribute 235. Similarly the "component specification select button" 935 & 1035 respectively provide a facility to change a components specification.

If the user makes changes to a component and seeks to apply those changes to the component by clicking the "Update" button 960 and 1060 in Figures 9 and 10 respectively, a "revisions" prompt 1100 shown in Figure 11 is displayed to the user. The user selects the required revision level for the changes from the drop- down list 1105. Clicking the "OK" button 1110 applies the changes to the component as follows:

A copy of the component instance in the data store 105 is made and the changes are applied to the copy of the component instance. The copy of the component with the changes applied thereto is marked as the "current" version of the component by means of incrementing the component History Id attribute. In this way, a full history of changes applied to the component is maintained within the CAE system 100.

When a revision level has been approved, as will be described below, the copies of the component data in the data store 105 which relate to changes made between the previously accepted revision and the recently accepted revision may be archived to reduce the storage size of the data store 105. In this manner, a revision history of the component as it stood at each accepted revision level is maintained in the data store 105 along with a list of incremental changes made as part of the current revision level.

SUBSTΓTUTE SHEET (Rule 26) (RO/AU) If the "delete/demolish" button 970 and 1070 shown in Figures 9 and 10 respectively is pressed, a verification prompt 1200 shown in Figure 12 is displayed. If the user selects the "demolish" button 1205 from the verification prompt 1200, the component instance data is tagged as being proposed for demolition. As soon as the component is issued at the "as-built" revision level, it will be regarded as demolished on the facility and the component will be reserved against a project called "demolished". The history of the component will remain, within the data store 105 until archived.

If the user selects the "delete" button 1210 in the form shown in Figure 12, a "deleted" attribute of the component will be set to true. The history of the component and any children components are retained, within the data store 105 until archived.

If the "reload" button 975 and 1075 shown in Figures 9 and 10 respectively is pressed, any changes a user has made to a component that have not been updated by use of the update button 960 or 1060 are discarded and the component is reloaded from data store 105 at its highest component Historical Id attribute level

Whenever changes are to be applied to a component, the instance of the component that is at the highest component Historical Id attribute level is displayed to the user.

Users with sufficient authorisation levels can approve changes to components via the screen shown in Figure 13 which is accessed by pressing the "Revision" buttons 980 and 1080 shown in Figures 9 and 10 respectively. The component window 1305 of the screen 1300 shows a list of components 1310 for which approval at a revision level nominated by a sign off window 1360 is sought.

The components 1310 preserve the concept of containership within other components, so that a hierarchical structure showing which components are contained within other components is achieved. Further, if a component has connections made thereto, from other component instances, the component can be expanded to show these connections 1390. In some embodiments, each component 1310 and their connections 1315 may separately require approval. Consequently, a connection can be approved at a different revisions level to its component.

Within the component window 1305 of screen 1300, each of the components 1310 is represented by an icon 1320, a tag name 1325, the revision level 1330 to which the component has been approved, and indication data 1335 indicating the approval levels required before the revision level can issue.

Similarly, each connection point of each component may be represented by an icon 1340. Further data may be included with reference to each connection point such as, the current revision level 1350 of the connection to which the connection point is associated and a list of authorisation levels 1355 for which the connection associated with the connection point requires approval. There may also be an indication 1356 of any other components associated with the connection.

When a user is presented with the revision screen of Figure 13, a "sign-off' 1360 revision level for the component is shown. The sign-off revision level corresponds with the revision level a component, selected in component window 1305, will issue at when approved A list of approval levels 1365 required for approving the revision before it can be issued is displayed in the approval levels window 1366. If a user does not have a sufficient authorisation level to be able to approve one or more of the approval levels in the approval list 1335, those approval levels can not be signed off by that user. This will require a user with a sufficient user approval level attribute 223 to log on and approve the revision level. It is preferable that a user can approve components and connections at a lower approval level than allocated by their user approval level attribute 223.

To approve a revision of a component at a revisions level that corresponds to the users "user approval level" attribute 223, the user selects the required component in the component display portion 1305 of screen 1300, then selects the required approval level from the approval level list 1335 and clicks the "approve revision" button 1370. In this regard, multiple-selecting is provided by means of a toggle button 1375. Pressing the button 1375 switches multiple-select on or off, and whilst multiple-select is on, the user can select multiple components and/or connections within the component display portion 1305 of screen 1300. This is useful when a large number of components require approval. It is preferable that the multiple select button 1375 operates according to the containership rules between the components in the component window 1305. Hence approving a component at a first level in the containership hierarchy approves all of its child components but does not approve its parent component.

When all of the approval levels required to approve the current revision of a component or connection have been obtained, that revision level can be issued by highlighting the component and clicking the "set revision" button 1380.

When the set revision button 1380 is selected, a copy of the component at the next revision level in the revision level data 260 is created in the data store 105. It is tagged as being unapproved.

The copy of the component that issued at the previous revision level is tagged as being issued at this previous revision level. All non-current copies of the component instance within the data store 105 that correspond with incremental changes made since the previously-accepted revision level may be deleted. If the revision level that was issued by pressing the set revision the button 1380 corresponds with the as-built common revision level, the project assignment flag 236 for that component is reset to the as-built common project.

The screen 1300 also includes a transfer button 1385, which presents to the user the dialogue shown in Figure 14 and which will be described below.

Conflict between projects that want to modify the same component or connection simultaneously is managed by the project attribute 236 of each component or connection.

When a user of a first project selects a component that it wants to modify and that is reserved against a second project, the user of the first project receives an error

STJBSTTTUTE SHEET (Rule 26) (RO/AU) message. The error message indicates that the component or connection is reserved against the second project.

To resolve the conflict the users of the project decide who should have priority for modifying the component or connection concerned.

Where it is decided that the component or connection should move to the first project then a user with sufficient authorisation on the first project selects the revisions control screen 1300. They then select the component or connection concerned and then select the transfer button 1385.

Upon selecting the transfer button 1385, a component connection transfer screen as shown in Figure 14 is displayed to the user. The transfer screen 1400 contains a list of projects 1410. The user selects from this list a target project to which the component or connection is to be transferred.

Upon selecting the target project, the user clicks on a select button 1405 which transfers the component to the target project by resetting the components project attribute 236 to correspond with the target project.

The revision control and conflict management procedures of the present embodiments may be equally applicable to other data structures, data management systems and database management systems not associated with computer aided engineering systems or computer aided drawing systems.

For example, the procedures may be applied to computer aided software engineering (CASE) tools and application development tools, particularly object oriented application development tools.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS

1. A revision control system for use in an application having at least one set of components; said revision control system comprising a common project and at least one revisions project; said revision control system adapted to reserve components from said set against either said at least one revisions project or said common project wherein said system prevents said application from amending components reserved against said common project and said system allows said application to amend components reserved against said at least one revisions project and wherein said system is adapted to control the project against which said components are reserved whereby said system controls amendment of said components by said application.

2. A revision control system as claimed in claim 1 wherein said system is adapted such that said components have a default reservation against said common project and such that components reserved against said common project are available for reservation against a revisions project in response to commands issued by said application.

3. A revisions control system as claimed in any one of claim 1 or claim 2 wherein the system is adapted to allow said application to amend components reserved against a first revisions project in response to said application operating in the context of said first revisions project and said system is adapted to prevent said application from amending components reserved against said first revisions project in response to said application operating in the context of a second revisions project.

4. A revisions control system as claimed in any one of claiml or claim 2 or claim 3 wherein said system is adapted to transfer components from a first revisions project to a second revisions project in response to commands issued by said application when operating in the context of said first revisions project and to prevent transfer of components from said first revisions project to said second revisions project in response to commands issued by said application when operating in the context of said second revisions project.

5. A revisions control system as claimed in any one of claim 3 or claim 4 wherein a user controlling said application nominates a revisions project in respect of which said user will control said application; said nominated revisions project forming said context of operation of said application.

6. A revisions control system as claimed in any one of the preceding claims wherein said application further comprises a set of area data defining a plurality of areas; said application further adapted to assign at least one area from said area data to each said component and to said projects; said system, in response to commands issued by said application, is adapted to alter the project against which a component is reserved from said common project to a target revisions project; said alteration of said project against which said component is reserved is dependent on a positive result from a comparison of said at least one area assigned to said component with said at least one area assigned to said target project.

7. A revisions control system as claimed in any one of the preceding claims wherein said revisions projects comprise pre-defined authorisation data and said system is further adapted to transfer a component from a revisions project to said common project in response to receiving authorisation commands from said application corresponding with said pre-defined authorisation data.

8. A revisions control system as claimed in claim 7 wherein said authorisation commands are issued by said application subsequent to said application amending said component.

9. A revisions control system as claimed in any one of claim 6 or claim 7 wherein said projects further comprise a plurality of revisions levels; each said revisions levels having predefined authorisation data; said system adapted to assign a first revision level to a component upon reservation of said component against said revisions project and to re-assign said component to a further revisions levels in response to said system receiving authorisation commands from said application; and wherein said component is transferred to said common project in response to receiving authorisation commands at a final revisions level.

10. A revisions control system as claimed in any one of claims 7, claim 8 or claim 9 wherein said system is adapted to create a copy of a component in said set of components in response to receiving authorisation commands from said application; said authorisation commands corresponding to predefined authorisation data.

11. A revision control system as claimed in any preceding claim wherein said system is adapted to create a copy of a component in said set of components upon assigning a component from a first project to a second project.

12. A method of controlling revisions to components in an application having at least one set of components, a common project and at least one revisions project; said method comprising the step of 1) reserving components from said set against either said at least one revisions project or said common project; 2) preventing said application from amending components reserved against said common project and allowing said application to amend components reserved against said at least one revisions project; and 3) controlling the project against which said components are reserved whereby controlling said revisions to said components by said application.

13. A method of controlling revisions to a component as claimed in claim 12 further comprising the step 4) of reserving components in said set against said common project as a default; and 5) making components reserved against said common project available for reservation against a revisions project in response to commands issued by said application.

14. A method of controlling revisions to a component as claimed in any one of claims 12 or 13 further comprising the step 6) of allowing said application to amend components reserved against a first revisions project in response to said application operating in the context of said first revisions project and preventing said application from amending components reserved against said first revisions project in response to said application operating in the context of a second revisions project.

15. A method of controlling revisions to a component as claimed in any one of claims12 to 14 further comprising the step 7) of transferring components from a first revisions project to a second revisions project in response to commands issued by said application when operating in the context of said first revisions project and preventing transfer of components from said first revisions project to said second revisions project in response to commands issued by said application when operating in the context of said second revisions project.

16. A method of controlling revisions to a component as claimed in any one of claim 14 or claim 15 further comprising the step 8) of a user controlling said application nominating a revisions project in respect of which said user will control said application whereby said nominated application forms said context of operation of said application.

17. A method of controlling revisions to a component as claimed in any one of claims 12 to 16 wherein said application further comprises a set of area data defining a plurality areas in which said components reside and said method further comprising the step 9) of assigning at least one area from said area data to each said component and to said projects; and the step 10) of, in response to commands from said application, altering the project against which a component is reserved from said common project to a target revisions project said alteration of said project against which said component is reserved being dependent on a positive result from a comparison of said at least one area assigned to said component with said at least one area assigned to said target project.

18. A method of controlling revisions to a component as claimed in any one of claims 12 to 17 further comprising the step 11) of defining authorisation data for each project and 12) transferring a component from a revisions project to said common project in response to receiving authorisation commands from said application corresponding with said authorisation data.

19. A method of controlling revisions to a component as claimed in claim 18 further comprising the step 13) of said application issuing said authorisation command subsequent to said application amending said component.

20. A method of controlling revisions to a component as claimed in any one of claim 18 or claim 19 further comprising the step 14) of defining a plurality of revisions levels for said revisions projects; 15) defining authorisation data for each said revision project; 16) assigning a first revision level to a component upon reservation of said component against said revisions project and to reassign said component to a further revisions level in response to said system receiving authorisation commands from said application; and 17) transferring a component to said common project in response to authorisation commands from said application at a final revisions level.

21. A method of controlling revisions to a component as claimed in any one of claims 18, claim 19 or claim 20 further comprising the step 18) of creating a copy of a component in said set of components in response to receiving authorisation commands from said application; said authorisation information corresponding to a predefined authorisation level.

22.A method of controlling revisions to a component as claimed in any one of claims 12 to 21 further comprising the step 19) of creating a copy of a component in said set of components upon assigning a component from a first project to a second project, including said common project.

23.A revisions control system as claimed in any one of claims 9 to 11 , wherein said system is adapted to assign to said components to said revisions levels in a one-way manner so that in the context of a revisions project a component is only assigned to a revisions level once.

24.A revision control system for an application as claimed in any one of claims 1 to 11 and claim 23 wherein said application comprises a multi-user environment and said common project is accessible to users of said application.

25. A revision control system as claimed in claim 24 wherein a sub-set of users have access to pre-defined ones of said revisions projects.

26.A revision control system as claimed in claim 25 wherein a user having access to more than one revisions project is restricted to controlling said application in the context of one of said projects at any one time to the exclusion of the other projects the user has access to.

27. A revision control system as claimed in any one of claims 25 or 26 wherein each said user of a project is assigned an authorisation level in the context of said project and wherein said users operate said application to issue authorisation commands to said system; said authorisation commands commensurate with said users authorisation level.