GB2377045A - Configuration manager - Google Patents

Configuration manager Download PDF

Info

Publication number
GB2377045A
GB2377045A GB0115891A GB0115891A GB2377045A GB 2377045 A GB2377045 A GB 2377045A GB 0115891 A GB0115891 A GB 0115891A GB 0115891 A GB0115891 A GB 0115891A GB 2377045 A GB2377045 A GB 2377045A
Authority
GB
Grant status
Application
Patent type
Prior art keywords
components
configuration
component
manager
image
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
GB0115891A
Other versions
GB0115891D0 (en )
Inventor
Tom Cool
Vroede Koen De
Jan Weytjens
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Europe (Belgium) NV
Original Assignee
Sony Europe (Belgium) NV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management

Abstract

A configuration manager for use in forming an image from a plurality of components including objects and collections of objects, the configuration manager including a selector for selecting components from a database for use in the image and an analyser for analysing the selected components to determine what other components are required by the selected components and means for ensuring that all components required by the selected components are themselves selected. Each component being stored in association with a plurality of attributes which at least indicate any other components required by the component. An editor may be provided for editing or modifying the selected components wherein the editor may amend the attributes stored in association with the components such that properties of a component can be changed without the need for recompilation. The configuration manager may further include a version controller for determining the version of components and converting the contents of older version components to the current version. The configuration manager may be implemented as a four layer structure comprising a persistence layer, a common code base layer, a layer of platform independent core classes and a platform specific GUI layer.

Description

<Desc/Clms Page number 1>

CONFIGURATION MANAGER The present application relates to a configuration manager, in particular, to a configuration manager for use in forming an image from a plurality of components.

Various object orientated programming systems are known in which binary images for running an application are constructed from a number of objects. Many different types of object may exist, together with collections of objects that provide operating system services to application objects and also collections of semantically related objects. These objects and groupings may be described as components of an image.

Object orientated programming is a very effective way of programming.

However, considerable burden is placed on the programmer to provide a group of components which are correctly inter related.

The present application recognises for the first time the need for simplifying the process of assembling components of an image and facilitating the sharing of components between different users.

According to the present invention, there is provided a configuration manager for use in forming an image from a plurality of components including objects and metaspaces, the configuration manager including: a selector for selecting components from a database for use in the image; an analyser for analysing selected components to determine what other components are required by said selected components; and means for ensuring that all components required by the selected components are themselves selected.

According to the present invention, there is also provided a method of forming an image from a plurality of components including objects and metaspaces, the method including: selecting components from a database for use in the image; analysing selected components to determine what other components are required by said selected components; and

<Desc/Clms Page number 2>

ensuring that all components required by the selected component are themselves selected.

In this way, application developers are able to focus on their application's components, without worrying about what is required by the operating system or other components in the image of their application under construction.

Preferably, the means for or step of ensuring also ensures that all the components are properly configured.

Preferably, each component is stored in association with a plurality of attributes, the attributes at least indicating any other components required respectively by said each component and the analyser referring to the attributes.

In this way, when the analyser refers to the attributes of a particular component, it is able to determine from those attributes any other components required by that particular component. Hence, the configuration manager is able easily to determine all of the inter dependencies of the selected components.

The configuration manager may prompt a user to select other components required by the selected components or automatically select the other components required by the selected components.

In this way, an application developer can concentrate on selecting the important or significant components of the image under construction without monitoring which components are required to accompany the selected components.

An editor may be provided for editing selected components and storing the edited components separately to the database.

In particular, a project file may be provided for recording the selected components. <RTI>Unmodified</RTI> components from the database may be recorded merely by way of pointers to the database, whereas edited components may themselves be stored.

The editor may amend the attributes stored in association with the components.

In this way, the properties of a component can be changed without the need for recompilation. If the editor is used to change the dependency of a component, the new modified component will be stored in the project file. The configuration

<Desc/Clms Page number 3>

manager can then determine what new components are therefore required for selection.

Preferably the configuration manager includes a display for displaying all of the components available from the database for selection and all of the components selected for the image, for instance those recorded for the project file.

Two views may be provided, one for a master database and one for the selected components required for the project image. Components of the master database selected for the project image may be illustrated in the view for the project image even though a pointer is merely provided to the master database. On the other hand, components which have been modified and stored in the view for the project image may be marked or highlighted so as to indicate that they have been modified.

Preferably, the configuration manager includes a version controller for determining the version of the components of the master database and for converting older version components to the current version and storing the converted components.

The configuration manager may be implemented as a four layer structure including a persistence layer, a common code base, a layer of platform independent core classes and a platform specific graphical user interface layer.

In order to provide robust persistence, the version information is implemented in the persistence layer.

The attributes are implemented in the common code base and any logic, such as the means for ensuring, is contained in the layer of platform independent core classes.

A system may be provided further comprising a compiler for compiling all of the selected components together to form the image. Hence, the method may further include compiling all of the selected components together to form the image.

According to the present invention, there is also provided a computer readable storage medium having recorded thereon code components that, when loaded on a computer and executed, will cause that computer to operate as defined above.

<Desc/Clms Page number 4>

The invention will be more clearly understood from the following description given by way of example only, with reference to the accompanying drawings, in which: Figure 1 illustrates a configuration manager display; Figure 2 illustrates an attributed entity diagram ; Figure 3 illustrates a local view accessing local and master repositories; Figure 4 illustrates a hierarchial viewing of repositories; Figure 5 illustrates an attributed entity view diagram; Figure 6 illustrates the four layer structure of a configuration manager; Figure 7 illustrates an example of a definition change; and- Figure 8 illustrates a version dependent read function.

Applications that run on object oriented systems consist of carefully assembled collections of active objects. In embedded systems, these objects co-exist with the objects required by the operating system and are in a binary file called an image.

Such images may be run on computers, but will often be required by electronic devices or embedded devices which run the application. In these cases, the image has to be created in its entirety before being loaded onto the device. Since, in most cases, the image cannot be altered, it is important that it is correctly configured before it is loaded.

To create an image, it is proposed to provide a configuration manager which allows developers to easily define, configure and manage objects in images.

Several types of object can exist. It is also proposed to provide two types of object groupings, namely collections of objects that provide operating system services to application objects to be called metaspaces and collections of semantically related objects to be called packages. These objects and groupings will be described as components of an image.

The configuration manager may be provided with a display 2 as illustrated in Figure 1. The display 2 may be the display screen of a computer system in which the configuration manger is embodied.

<Desc/Clms Page number 5>

The illustrated display is divided into three views 4,6 and 8 representing respectively a master database, a local database and a project image. It is not necessary to provide more than the master database view 4 and the project image view 8, but, on the other hand, a number of different local database views could be provided.

The master database view 4 provides a representation of all of the components available from a master database to which the configuration manager has access. This master database should include all of the basic components of the object orientated operating system for which an image is being constructed. However, it may also include many other components which have been written and-which have become available for general use. In order to construct an image, a user merely selects required components from the master database. In order to do this, in one embodiment, a user could merely drag the representation of a component in the master database view 4 across into the project image view 8. All of the selected components are then illustrated in the project image display 8.

Of course, since the configuration manager has selected one of the components already stored in the master database, it is not necessary for the data of that component to be duplicated in a portion of the memory allocated to the project image. Thus, the configuration manager can record that component by way of a reference to the appropriate component even though the project view 8 shows the component in question.

Of course, custom components can also be written for the application and these can be recorded as part of the project image or a local database.

The master database can be used as a read-only database and contain components that are shared by a development team. In a preferred embodiment, special administrator rights would be required to replace or add components to the master database.

On the other hand, the local database could be used to store an individual's own components or components whether they are original components from the master database that have been modified. Of course, this database could also be shared with other developers.

<Desc/Clms Page number 6>

Thus, where a custom component or a component of the master database that has been modified is selected for the project image or the local database, that component is stored in the memory for the project image or the local database.

Otherwise, where the component of the project image is merely a component from the local database or the master database, the configuration manager need only keep the reference to the appropriate component in the master database.

Preferably, each component in the image has properties that are configurable such as PIC/PID, stack and heap size, scheduling priorities and so on. The developer can create custom properties and change variables for each component. Preferably, the properties of the target platform can also be specified.

Thus, each component of the image preferably has configurable properties, for instance the metaspace on which an object runs or the memory areas where its code and data are to be loaded. The properties that characterize different types of components can change, as well as the default values of these properties. Indeed, due to changing requirements, the type of property may also be changed, for instance from an integer value to a string value.

The properties could be modelled using class data members. However, modification of the set of data members or the data members themselves (for example their default values) would then require recompilation depending on the implementation language. This is the case for C ++. It is here recognised that such changes should not require recompilation of the configuration manager and that this requirement should apply to the properties of all components in an image, including packages and metaspaces.

In view of the above, it is now proposed that each component has associated with it a plurality of attributes for modelling the properties of component.

It is proposed that properties should be modelled with typed attributes, that is, with pairs of classes; classes that implement named types and classes that implement variables corresponding to the type. Both the type and value classes derive respectively from <RTI>an tKeType</RTI> and Attribute Value base class. The attribute value class, as the name suggests represents the value of the property. The type class

<Desc/Clms Page number 7>

encapsulates type-information about the property (for example, the default value) and type specific constraints (for example, a maximum value for an integer).

Referring to Figure 2, image components are modelled by derivation from the <RTI>AttributedEntity</RTI> base class 10 because the properties (typed attributes) must be allowed to change. This base class is, in essence, a polymorphic container of <img class="EMIRef" id="024174175-00070001" />

instances of Attribute Value-derived classes 12. The attribute types for each component type are grouped together in an instance of the ME'Tpe//o class 14. This class, similar to the AttributedEntity class 10, maintains a list of polymorphic pointers to AttributeType-derived class instances 16, and can be considered as the meta data of the associated component type.

Some of the attributes allow the configuration manager to analyse the components and to determine what other components are required by them. In particular, the attributes of a component will indicate other components required by that component. Thus, for example, where an object requires a particular metaspace from the operating system, this will be indicated by way of the attributes.

Other attributes may be provided for other purposes such as influencing how the image is built, how the image will behave at runtime, etc.

The configuration manager can then ensure that all of those components have been selected, either by prompting the user to select them or by automatically selecting them. The additional components having been selected to this way are then of course themselves checked such that any components required by them are also selected.

It will be appreciated that, with an arrangement as discussed above, it is possible for a number of users to share the master database and each modify components in different ways according to their needs. To allow collaboration and sharing of components between developers, it is proposed that repositories should be available to permit concurrent access to predefined components. It is proposed that users can modify properties of these components as discussed above without effecting the work of others.

In order to do this, the master, local and project databases discussed above for the configuration manager can be generalised to a plurality of memories such as a

<Desc/Clms Page number 8>

master repository, a local repository and a project repository. The master repository is read-only and can be shared by multiple users. The two other repositories are writable. The local repository stores modified versions of items in the master repository as well as new items. It can be shared by different users and projects.

For the configuration manager, the project repository stores modified components that are only relevant to the current project as well as settings necessary to build the image (for example the interrupt handling policy).

In order to identify a particular component, each component is stored in a repository based on a unique key. Thus, modified versions of a component always have the same key as the original, but are stored in a different repository. For example, when a component in the master database/repository is modified, the modified version is stored in the local or project repository using the same key. This is illustrated in Figure 3. In particular, the original component A, having key X, is stored in the master repository with reference to key Z. However, this component has been modified to include a reference to key Y and has been stored in the local repository, but still with key X. The local view of the configuration manager requiring a component with key X takes that component from the local repository.

Since that component requires reference to key Y, the configuration manager therefore looks for a component having key Y. Since the local repository does not contain such a component, the local view refers to component B of the master repository. Thus, it will be seen that a component refers to another component by specifying the key of the referred component. This means that it is not possible for a component to refer to a certain version of another component explicitly. Version is determined by the context in which the reference is evaluated. Browsing the master repository using a master view displays the version that is stored in the master repository, but browsing the local view displays, in order of precedence, the version stored in the local repository or, if this does not exist, the version stored in the master repository.

Thus, as illustrated in Figure 4, this process of evaluating a reference in a context is encapsulated in views. A view is responsible for selecting a certain version of a component, based on a key or other form of ID. It specifically uses one

<Desc/Clms Page number 9>

or more repositories using some order of precedence or hierarchy between those repositories to arrive at the correct version.

Thus, the project view 20 of Figure 4 would first look for a component in the project repository 26, then the local repository 28 and finally the master repository <RTI>30.</RTI> On the other hand, the local view 22 would look for a component first in the local repository 28 and then the master repository 30 and the master view 24 would merely look in the master repository 30. Of course, the particular hierarchy assigned to the repositories can be different for each view. Thus, another project view might assign a hierarchy with the local repository as first choice, its own project repository as second choice, another project repository as third choice and the master repository as last choice.

This system is applicable to any arrangement in which different versions of the same type of data or file are stored in different repositories. As indicated previously, for the configuration manager discussed above, the graphical user interface (GUI) uses three repositories and three views. There is a view to browse the master database, a view to browse the local database and a view to browse the project repository. Of course, the project view is more complicated, since it also has to take into account the project's image composition which allows the user to explicitly select a certain version of a component to be included in the image.

Component versions are modelled by the configuration manager as instances <img class="EMIRef" id="024174175-00090001" />

of the AttributedEntity class. This is illustrated in Figure 5.

Repositories are instances of the AttributedEntitySpace class, which is a container for AttributedEntities. Finally, the view is an instance of an AttributedEntity View-derived class, implemented the specific mechanism to resolve references.

The configuration manager is preferably implemented as a four layer structure as shown in Figure 6. In particular, it has 1) a thin persistence layer, 2) a common code base of platform-independent core classes 3) a layer of platform-independent ACM-specific classes and 4) a platform-specific graphical user interface (GUI) layer.

The persistence layer can be used to particular advantage with the configuration manager.

<Desc/Clms Page number 10>

Persistence refers to an object's ability to transcend time or space. A persistent object saves its state in a permanent storage system to make it possible for the process that created the object to terminate, without losing the information represented by the object. Later, the object may be reconstructed by another process and will behave in exactly the same way as it did in the initial process. However, the mere ability to make objects persistent is not sufficient to implement robust persistence, namely persistence that is resilient to changes in the definitions of the persistent classes. Such changes may for instances be required to accommodate design improvements. Components may be designed which are intended for use with the components of a particular master database but will not operate with the components of an earlier equivalent master database.

Changes may give rise to sychronisation problems, for instance class definitions compiled into the program may differ from definitions used by the data files. The result of this is that files in which instances of previous versions of the persistent classes are stored can no longer be read.

In order to overcome this, the configuration manager determines the version of the components of the master database and operates accordingly. Where the version is older than that currently in use, it preferably takes the necessary steps to convert the components. It may also issue some warning to the user. On the other hand, when the components of the master database are from a more recent version than that currently in use, the configuration manager may merely have to issue a warning to the user and prevent use of those components.

Considering a more specific example of the operation, write and read functions write and read a persistent class's data members, both static and non-static to and from an input/output stream. This approach, however, may cause problems when class definitions are changed as illustrated in Figure 7, which shows two versions of a class A.

The pseudo-code shows two class definitions with corresponding read and write functions for the persistence. The instance of class A, written with the first implementation, cannot be read with the second implementation. In particular, the second implementation will try to read a float, but will encounter an integer.

<Desc/Clms Page number 11>

To overcome this, it is proposed that version information is written out together with the persistent classes. This version information relates to the version of the implementation that was used to write the class.

Each persistent class contains a different read function for each (past) version that must still be supported by the robust persistence mechanism. Each read function reads the values of the corresponding old implementation and coverts them to the values needed by the current implementation. Applied to the example of class A, this results in the pseudo-code illustrated in Figure 8.

When an instance is read, the read function that is used to read the instance is selected from the version information found in the stream. When an instance is read to a stream, it is always written with the current (and latest) implementation so that the write method is not version-based.

Thus, the configuration manager may provide a framework that enables classes to register read functions on a version basis and that is able to select the correct read function, based on the version information found in the stream. The implementation of this framework is centred around three classes. The Persistence Versionlnfo class encapsulates the version information, such as major and minor version number and status such as alpha, beta or release.

The association between the different versions and their corresponding read <img class="EMIRef" id="024174175-00110001" />

functions is then managed by the Persistence ClassIOManager. The core of the robust persistence is the PersistenceManager class, that maintains a PersistenceClassIOManager class for each persistent class.

Considering again the four layer structure illustrated in Figure 6, the persistence layer is thus provided in the first layer.

The second layer comprises the core classes. The common code base consists of a polymorphic hierarchy of attribute type and value classes, classes that model domain class metadata (i. e. type descriptions), a base class that maintains a set of attribute values, the main classes that derive from this class and enable the properties of components to be changed as discussed above, classes that help manage the object repositories, classes that provide an infrastructure for allowing different views of

<Desc/Clms Page number 12>

objects in the repositories so as to allow collaboration between different object repositories as discussed above and helper classes.

The first and second layers comprising the common code base and persistent <img class="EMIRef" id="024174175-00120001" />

layer together make up the backend of the configuration manager. t) p The third layer containing the configuration manager specific classes implement the configuration managers logic as discussed above. In particular, the configuration manager determines which components are required by selected components and takes appropriate action.

As discussed above, to function properly some components of an image may require the presence of other components. For example when a develeper adds an application object that runs on a particular metaspace, that metaspace and all the objects that comprise it are required.

Preferably, these relationships are modelled by means of a dependencies property defined for different sub classes of the attributed entity bases class to be described below. Dependencies are described as the list of objects, packages and metaspaces that a component requires. The logic layer provides the necessary functionalities to analyse these dependencies and to add any missing component to the image. The components that make up the basic operating system have their dependencies pre configured in the master repository. However, application developers may also specify dependencies through the graphical user interface (GUI).

Finally, the fourth layer comprises the graphical user interface (GUI) and concerns itself with presentation and input verification using APIs provided by the layers two and three.

Claims (19)

1. A configuration manager for use in forming an image from a plurality of components including objects and metaspaces, the configuration manager including: a selector for selecting components from a database for use in the image; an analyser for analysing selected components to determine what other components are required by said selected components; and means for ensuring that all components required by the selected components are themselves selected.
2. A configuration manager according to claim 1 wherein: each component is stored in association with a plurality of attributes, the attributes at least indicating any other components required respectively by said each component and the analyser referring to said attributes.
3. A configuration manager according to claim 1 or 2 wherein: the means for ensuring includes means for prompting a user to select other components required by the selected components.
4. A configuration manager according to claim 1,2 or 3 wherein: the means for ensuring includes an automatic selector for selecting other components required by the selected components.
5. A configuration manager according to any preceding claim further including: an editor for editing selected components and storing the edited components separately to the database.
6. A configuration manager according to claim 5 further including: a project file for recording the selection of components as pointers to selected components of the database and for storing edited components.
7. A configuration manager according to claim 5 or 6 when appendant on claim 2 wherein:
<Desc/Clms Page number 14>
the editor is for amending the attributes stored in association with the components such that the properties of a component can be changed without the need for recompilation.
8. A configuration manager according to any preceding claim further including: a display for displaying all of the components available from the database for selection and all of the components selected for the image.
9. A configuration manager according to any preceding claim further including: a version controller for determining the version of software used to create the components of the database and, where the version is older than a current version for which the configuration manager was intended, for converting the contents of the components to the current version and storing the converted components.
10. A configuration manager according to any preceding claim comprising a four layer structure including a persistence layer, a common code base, a layer of platform independent core classes and a platform specific graphical user interface layer.
11. A configuration manager according to claim 10 wherein version information is contained in the persistence layer.
12. A configuration manager according to claim 10 or <RTI>I I</RTI> when appendant on claim 2 wherein the attributes are contained in the common code base.
13. A configuration manager according to claim 10, 11 or 12 wherein the means for ensuring is contained in the layer of platform independent core classes.
14. A system for forming an image including a configuration manager according to any preceding claim and a compiler for compiling all of the selected components together to form the image.
15. A method of forming an image from a plurality of components including objects and metaspaces, the method including: selecting components from a database for use in the image; analysing selected components to determine what other components are required by said selected components; and
<Desc/Clms Page number 15>
ensuring that all components required by the selected component are themselves selected.
16. A method according to claim 15 further including: compiling all of the selected components together to form the image.
17. A configuration manger constructed and arranged substantially as hereinbefore described with reference to and as illustrated by Figures 1 to 8 of the accompanying drawings.
18. A method of forming an image substantially as hereinbefore described with reference to and as illustrated by Figures 1 to 8 of the accompanying drawings.
19. A computer readable storage medium having recorded-thereon code components that, when loaded on a computer and executed will cause that computer to operate according to any preceding claim.
GB0115891A 2001-06-28 2001-06-28 Configuration manager Withdrawn GB0115891D0 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB0115891A GB0115891D0 (en) 2001-06-28 2001-06-28 Configuration manager

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB0115891A GB0115891D0 (en) 2001-06-28 2001-06-28 Configuration manager

Publications (2)

Publication Number Publication Date
GB0115891D0 GB0115891D0 (en) 2001-08-22
GB2377045A true true GB2377045A (en) 2002-12-31

Family

ID=9917580

Family Applications (1)

Application Number Title Priority Date Filing Date
GB0115891A Withdrawn GB0115891D0 (en) 2001-06-28 2001-06-28 Configuration manager

Country Status (1)

Country Link
GB (1) GB0115891D0 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2398659A (en) * 2003-02-18 2004-08-25 Fisher Rosemount Systems Inc Module class objects representing process entities for creating module objects for configuring a process plant control system.
US7117052B2 (en) 2003-02-18 2006-10-03 Fisher-Rosemount Systems, Inc. Version control for objects in a process plant configuration system
GB2442369A (en) * 2004-11-02 2008-04-02 Dell Products Lp System for communicating an information handling system image through a network
US7526347B2 (en) 2003-02-18 2009-04-28 Fisher-Rosemount Systems, Inc. Security for objects in a process plant configuration system
US8000814B2 (en) 2004-05-04 2011-08-16 Fisher-Rosemount Systems, Inc. User configurable alarms and alarm trending for process control system
US8135481B2 (en) 2004-05-04 2012-03-13 Fisher-Rosemount Systems, Inc. Process plant monitoring based on multivariate statistical analysis and on-line process simulation
US8825183B2 (en) 2010-03-22 2014-09-02 Fisher-Rosemount Systems, Inc. Methods for a data driven interface based on relationships between process control tags
US8881039B2 (en) 2009-03-13 2014-11-04 Fisher-Rosemount Systems, Inc. Scaling composite shapes for a graphical human-machine interface

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5845119A (en) * 1995-11-08 1998-12-01 Hitachi, Ltd. Software development tool for combining software components/modules
US6223342B1 (en) * 1996-11-06 2001-04-24 A. Chacko George Object-oriented sequencing using hierarachical configuration streams

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5845119A (en) * 1995-11-08 1998-12-01 Hitachi, Ltd. Software development tool for combining software components/modules
US6223342B1 (en) * 1996-11-06 2001-04-24 A. Chacko George Object-oriented sequencing using hierarachical configuration streams

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
A CASE-oriented configuration management agent, Tuppa & Selberherr, IASTED International Conference, Honolulu, 19-21 Aug 1996, pages 368-371, ISBN 0-88986-211-7 *

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2398659A (en) * 2003-02-18 2004-08-25 Fisher Rosemount Systems Inc Module class objects representing process entities for creating module objects for configuring a process plant control system.
US7043311B2 (en) 2003-02-18 2006-05-09 Fisher-Rosemount Systems, Inc. Module class objects in a process plant configuration system
US7117052B2 (en) 2003-02-18 2006-10-03 Fisher-Rosemount Systems, Inc. Version control for objects in a process plant configuration system
GB2398659B (en) * 2003-02-18 2007-12-05 Fisher Rosemount Systems Inc Module class objects in a process plant configuration system
US8788071B2 (en) 2003-02-18 2014-07-22 Fisher-Rosemount Systems, Inc. Security for objects in a process plant configuration system
US7526347B2 (en) 2003-02-18 2009-04-28 Fisher-Rosemount Systems, Inc. Security for objects in a process plant configuration system
US8473087B2 (en) 2003-02-18 2013-06-25 Fisher-Rosemount Systems, Inc. Version control for objects in a process plant configuration system
US7729792B2 (en) 2003-02-18 2010-06-01 Fisher-Rosemount Systems, Inc. Version control for objects in a process plant configuration system
US7971052B2 (en) 2003-02-18 2011-06-28 Fisher-Rosemount Systems, Inc. Configuration system using security objects in a process plant
US8000814B2 (en) 2004-05-04 2011-08-16 Fisher-Rosemount Systems, Inc. User configurable alarms and alarm trending for process control system
US8060834B2 (en) 2004-05-04 2011-11-15 Fisher-Rosemount Systems, Inc. Graphics integration into a process configuration and control environment
US8127241B2 (en) 2004-05-04 2012-02-28 Fisher-Rosemount Systems, Inc. Process plant user interface system having customized process graphic display layers in an integrated environment
US8135481B2 (en) 2004-05-04 2012-03-13 Fisher-Rosemount Systems, Inc. Process plant monitoring based on multivariate statistical analysis and on-line process simulation
US8185219B2 (en) 2004-05-04 2012-05-22 Fisher-Rosemount Systems, Inc. Graphic element with multiple visualizations in a process environment
GB2442369B (en) * 2004-11-02 2009-06-24 Dell Products Lp System and method for information handling system image network communication
GB2442369A (en) * 2004-11-02 2008-04-02 Dell Products Lp System for communicating an information handling system image through a network
US8881039B2 (en) 2009-03-13 2014-11-04 Fisher-Rosemount Systems, Inc. Scaling composite shapes for a graphical human-machine interface
US8825183B2 (en) 2010-03-22 2014-09-02 Fisher-Rosemount Systems, Inc. Methods for a data driven interface based on relationships between process control tags

Also Published As

Publication number Publication date Type
GB0115891D0 (en) 2001-08-22 grant

Similar Documents

Publication Publication Date Title
Ungar et al. Organizing programs without classes
Wirth et al. Project Oberon
US5873097A (en) Update mechanism for computer storage container manager
US7865868B2 (en) .NET ribbon model for a ribbon user interface
US5933646A (en) Software manager for administration of a computer operating system
US5428729A (en) System and method for computer aided software engineering
US4809170A (en) Computer device for aiding in the development of software system
Anderson et al. Chimera: Hypertext for heterogeneous software environments
US5499365A (en) System and method for controlling versions of objects in an object oriented computing environment
US5832264A (en) Object-oriented communications framework system with support for multiple remote machine types
US6061689A (en) Object aggregation representation of relational database rows having nontraditional datatypes
Boudier et al. An overview of PCTE and PCTE+
US6993759B2 (en) Diagrammatic control of software in a version control system
US5530861A (en) Process enaction and tool integration via a task oriented paradigm
US6230318B1 (en) Application programs constructed entirely from autonomous component objects
US6745208B2 (en) Method and apparatus for synchronizing an XML document with its object model
US5761684A (en) Method and reusable object for scheduling script execution in a compound document
US6704743B1 (en) Selective inheritance of object parameters in object-oriented computer environment
US6108661A (en) System for instance customization
US20090083268A1 (en) Managing variants of artifacts in a software process
Robinson Professional c
US20040243381A1 (en) Automated test execution framework with central management
US20060041879A1 (en) System and method for changing defined user interface elements in a previously compiled program
US7694272B2 (en) Method, a language and a system for the definition and implementation of software solutions by using a visualizable computer executable modeling language
US20070079299A1 (en) Method, apparatus and program storage device for representing eclipse modeling framework (EMF) ecore models in textual form

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)