US20060101375A1 - Device configuration and management development system - Google Patents
Device configuration and management development system Download PDFInfo
- Publication number
- US20060101375A1 US20060101375A1 US10/484,871 US48487104A US2006101375A1 US 20060101375 A1 US20060101375 A1 US 20060101375A1 US 48487104 A US48487104 A US 48487104A US 2006101375 A1 US2006101375 A1 US 2006101375A1
- Authority
- US
- United States
- Prior art keywords
- data
- management
- devices
- configuration
- documentation
- 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.)
- Granted
Links
- 238000011161 development Methods 0.000 title claims abstract description 92
- 238000007726 management method Methods 0.000 claims description 322
- 238000000034 method Methods 0.000 claims description 62
- 238000004891 communication Methods 0.000 claims description 28
- 230000006870 function Effects 0.000 claims description 17
- 238000012545 processing Methods 0.000 claims description 10
- 238000013500 data storage Methods 0.000 claims description 8
- 238000013499 data model Methods 0.000 claims description 7
- 238000012546 transfer Methods 0.000 claims description 7
- 238000012986 modification Methods 0.000 claims description 6
- 230000004048 modification Effects 0.000 claims description 6
- 238000004883 computer application Methods 0.000 claims 2
- 238000010586 diagram Methods 0.000 description 25
- ATCJTYORYKLVIA-SRXJVYAUSA-N vamp regimen Chemical compound O=C1C=C[C@]2(C)[C@H]3[C@@H](O)C[C@](C)([C@@](CC4)(O)C(=O)CO)[C@@H]4[C@@H]3CCC2=C1.C=1N=C2N=C(N)N=C(N)C2=NC=1CN(C)C1=CC=C(C(=O)N[C@@H](CCC(O)=O)C(O)=O)C=C1.O([C@H]1C[C@@](O)(CC=2C(O)=C3C(=O)C=4C=CC=C(C=4C(=O)C3=C(O)C=21)OC)C(=O)CO)[C@H]1C[C@H](N)[C@H](O)[C@H](C)O1.C([C@H](C[C@]1(C(=O)OC)C=2C(=CC3=C(C45[C@H]([C@@]([C@H](OC(C)=O)[C@]6(CC)C=CCN([C@H]56)CC4)(O)C(=O)OC)N3C=O)C=2)OC)C[C@@](C2)(O)CC)N2CCC2=C1NC1=CC=CC=C21 ATCJTYORYKLVIA-SRXJVYAUSA-N 0.000 description 24
- 238000013507 mapping Methods 0.000 description 10
- 230000004044 response Effects 0.000 description 7
- 239000003292 glue Substances 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 230000001052 transient effect Effects 0.000 description 3
- 101150012579 ADSL gene Proteins 0.000 description 2
- 102100020775 Adenylosuccinate lyase Human genes 0.000 description 2
- 108700040193 Adenylosuccinate lyases Proteins 0.000 description 2
- 230000009471 action Effects 0.000 description 2
- 230000004931 aggregating effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- 230000014616 translation Effects 0.000 description 2
- 230000009118 appropriate response Effects 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/10—Requirements analysis; Specification techniques
Definitions
- the present invention relates to the development and/or management of configuration and management parameters for devices.
- Networked devices With the prevalent use of networked devices, the provision for both local and remote management has become essential for the proper functioning of a network.
- Networked devices can be used for a wide range of functions and it highly desirable to provide both local and central management.
- the present inventors have developed and end to end management solution which utilises a common management data structure during the development, deployment, and use of managed devices.
- a common management model is used which can provide a common management interface.
- One aspect of the present invention provides a device configuration system and method for developing and managing configuration and management information for devices.
- the system enables developers to develop configuration data and/or management data.
- Configuration and/or management data is stored as device data that is stored in accordance with a common management model. This enables the parameters and the management information to be managed.
- Parameters and management data entered in the common model can be output in a software product as a device management product which includes a parameters and management data for a set of devices.
- the device management product can thus be used to configure and manage a set of devices using the common management model.
- Each device has configuration and management data stored therein in accordance with the common management model. This provides for both central management and for local management using the common management model. In this way end to end management is provided.
- Another aspect of the present invention provides a device configuration development system for developing and/or managing configuration and/or management information for devices.
- Device data structured in accordance with the common model of parameters relating to the configuration and/or management of the devices is stored.
- a developer interface allows a software developer to develop software for configuring and/or managing devices and to store device data in accordance with a common model.
- a device configuration and/or management software product for configuring and managing a set of devices is built by reading stored data for a set of devices structured in accordance with the common model.
- Device management and control software is configured for controlling a processing apparatus in a device manager to configure and/or manage the devices using the data for the devices included in the product and to provide the data for a device to the device to allow a local configuration and/or management at the device.
- the device management and control software can be included in the product or it can be already installed in the device manager processing apparatus.
- the software product is built by reading and including in the software product the software developed by the software developer for loading onto devices for configuring and managing the devices.
- the devices comprise network devices and the common model is a model of parameters relating to the configuration and management of the network devices which can be for example network configuration parameters e.g. network protocol capabilities.
- the common management model comprises a model of hardware characteristics, software characteristics and relationships therebetween. This therefore provides a full picture of the characteristics of the device for management purposes.
- the device data comprises configuration data and meta data.
- the configuration data defines configuration parameters that can be set for the device.
- a configuration data can have configuration values that can be set by the developer or be settable by a manager centrally or by an operator of the device
- the meta data comprises management information for the configuration data and for the device.
- the device data can include management data which includes interface information defining the configuration of a user interface to the device data i.e. defining a management interface.
- the meta data can define a common interface for central and local management.
- the common user interface preferably comprises a web interface provided by a web server.
- the device data can be copied to allow a developer to enter device data if the need arise by simply copying device data for another device which most closely resembles the new device to be developed and modifying the device data as necessary.
- the developer interface means includes means for generating code stubs for management functionality from the device data for combination with the software provided by the software developer to control the device.
- this capability provides encouragement for a developer to use the development system to enter the management data and the task of writing the code for the management functionality is removed from the developer. It is only necessary for the developer to interface the code stubs into their code by writing suitable interface code or ‘glue’.
- documentation for each device is stored. This can be stored as segments associated with respective parameters in the common model. Documentation for a device can be generated automatically by inserting management information from the management model into the documentation. Thus as management parameters are updated, the documentation is automatically updated.
- the documentation can be stored as document segments with each segment being associated with a respective parameter and having management parameters associated therewith. Thus documentation can be built up by incorporating management parameters into the documentation segments and aggregating the document segments to provide complete documentation for the device.
- configuration parameters identify a configured device comprising configuration data which is complete for a device or a configuration profile that includes some configuration data that can be input to complete or modify the configuration data for a device. For example, a number of configuration parameters could be set to a default value that can be altered by a user in order to modify the configuration data to provide a device profile.
- configuration parameters for a device can comprise configuration parameters from a configuration profile and user input configuration parameters.
- the configuration parameters from a configuration profile can be common to a large number of devices.
- the present invention provides a management system or method for managing devices using the common management model.
- Data storage means stores management and configuration data for each device for managing and configuring the device.
- the management and configuration data is structured in accordance with the common management model i.e. in accordance with a common model of parameters related to the functioning and management of the devices.
- Means of communicating with the devices is provided in each device.
- the devices are provided with a copy of the management and configuration data for respective devices to provide for local management and configuration.
- each device has a subset of the data in the common management model relevant for the management of the device.
- a device management means controls communications to and from the devices to provide central configuration of the devices and receipt of management data from the devices.
- a device management system can be provided by the device development environment and the common management model can be used in both.
- the device management system can, in one embodiment, provide the copy of the management and configuration data to each of the devices. In this way the management system can provide the initial configuration for the devices.
- This initial configuration can include the storage of code modules for controlling the devices for sending to and storing at the devices.
- the code module can be the same for the same type of device thus providing for not only common hardware but also common software for devices. The only difference between devices thus lies in the configuration and management data. This enables simple reconfiguration of devices by reconfiguration of their configuration and management data. No change of code is needed.
- the configuration data defines configuration instances for devices. Also the configuration data can define a configuration profile for which some user definable configuration data can be entered or modified. This enables a configuration profile to apply to a set of devices and it enables a manager of the devices to assign configuration parameters individually only to the subset of the whole set of configuration data in order to provide a unique set of configuration data for a device.
- Another aspect of the present invention provides a centrally managed device in which data for the device is stored and structured in accordance with a common model of parameters related to the functioning and management of devices managed by a central management system.
- the means for communicating with the central management system is provided under the control of the control means to control the sending of management data to the central management system.
- the data comprises a set of configuration parameters and a set of management parameters.
- the management parameters are associated with respective configuration parameters and provide management information on the configuration parameters.
- the management parameters comprise meta data for the configuration data.
- control means comprises a code module implemented by a processor in the device.
- the code module is downloadable from the central management system.
- a further aspect of the present invention provides a device documentation generation system method in which meta data for each of the parameters defining characteristics of a plurality of devices is stored.
- the meta data is stored in accordance with a common data module for the devices.
- Documentation can be input for association with meta data for respective parameters and documentation for a device can be generated by incorporating the meta data into the documentation. In this way, as the meta data is changed i.e. the management information changes, the documentation is automatically updated.
- the documentation can be input as segments associated with respective parameters defining the characteristics of the device.
- the document generation then includes aggregating the appropriate document segments for appropriate parameters relevant to the device.
- the meta data includes an indication of the language of the documentation to be generated for a device.
- the input documentation is stored and can comprise documentation in more than one language for a parameter.
- the documentation is then generated using the documentation in the language indicated by the indication in the meta data for the device.
- a further aspect of the present invention provides a device configuration development system for developing control code for devices.
- a code store stores a library of code stubs for providing device management functions.
- a data store stores metadata on device configuration parameters, wherein the meta data comprises management information for the device configuration parameters. Meta data can be input into the data store and code stubs can be determined for a device to provide the management functionality defined in the input meta data using the library of code stubs in the code store.
- this aspect of the present invention enables a developer to merely input management information into the common database and receive in return code stubs for providing the management functionality to be incorporated within the developer's code for controlling the device.
- a further aspect of the present invention provides a device management system and method for providing information defining a management interface for devices to provide for local and central management.
- Device data structured in accordance with the common module for the management of devices is stored.
- Information defining a management interface for devices is input for storage in the device data.
- the device data is output as a set of device data to provide a management interface for the central management of the set of devices and as device data for each data to provide the same management interface for the local management of each device.
- a further aspect of the present invention provides a device configuration development system and method for developing and managing configuration and management information for devices.
- the required functionality of the devices is defined and desired attributes for management of the devices are entered.
- the entered attributes are stored as a central database for management of the devices and as a set of data in the devices for local management of the devices.
- a carrier medium carrying the code is thus within the scope of the present invention.
- the carrier medium can either be a transient carrier medium or a storage carrier medium.
- a transient carrier medium can comprise a signal such as an electrical, optical, microwave, radio frequency or acoustic signal carrying computer code.
- An example of a transient carrier medium is a signal carrying computer code over the Internet (an Internet Protocol (IP) Network).
- IP Internet Protocol
- the storage medium can comprise any conventional storage medium such as a floppy disk, hard disk, CD ROM, tape device, or solid state memory device.
- FIG. 1 is a schematic diagram of a hardware model used in accordance with an embodiment of the present invention
- FIG. 2 is a schematic diagram of a software model used in an embodiment of the present invention
- FIGS. 3 a to 3 k are tables illustrating the data structure of the hardware model in a relational database in accordance with an embodiment of the present invention
- FIGS. 4 a to 4 e are tables illustrating the data structure of the software model in a relational database in accordance with an embodiment of the present invention
- FIGS. 5 a to 5 d are tables illustrating the interfacing between the hardware model and the software module in a relational database in accordance with an embodiment of the present invention
- FIG. 6 is a table providing information on configuration data
- FIG. 7 is a table providing the documentation information for the parameters in the tables
- FIG. 8 is a table giving information on the external form of attributes in the embodiment of the present invention.
- FIGS. 9 a and 9 c are selected tables used for identifying user interface selection options in accordance with an embodiment of the present invention.
- FIG. 10 is a table of the configuration data
- FIG. 11 is a schematic diagram of a development system in accordance with an embodiment of the present invention.
- FIG. 12 is a flow diagram of the development process in accordance with an embodiment of the present invention.
- FIG. 13 is a flow diagram showing the development and management of the management information used for documentation in accordance with an embodiment of the present invention
- FIG. 14 is a schematic diagram of a device management system in accordance with an embodiment of the present invention.
- FIG. 15 is a schematic diagram of the components of a device in which the components provide for central and local configuration and management of the device,
- FIG. 16 is a diagram showing the retrieval of management information
- FIG. 17 is a diagram illustrating retrieval of parameters
- FIG. 18 is a diagram illustrating the download of configuration data to configure the device
- FIG. 19 is a diagram illustrating the configuration of a device
- FIG. 20 is a diagram illustrating the implementation of a feature in a device
- FIG. 21 is a diagram illustrating the retrieval of management information using a command line interface
- FIG. 22 is a diagram illustrating the setting of a feature using the command line interface
- FIG. 23 is a diagram illustrating the interfacing to the meta data using a command line interface
- FIG. 24 is a schematic diagram of the use of the configuration and management components as a ubiquitous interface to any device.
- the present invention is built the premise of a common management model.
- the management model is common to:
- the network manager responsible for managing a network of devices
- the devices that contain a set of the configuration and management data appropriate for the device.
- the common management model used is based on a meta data model.
- the meta data model comprises a hardware model, a software model and relationships therebetween.
- the model used and the data structure in accordance with the model will now be described.
- FIG. 1 schematically illustrates the hardware model.
- a hardware model defines a hardware model for a product that can comprise a number of chassis. Each chassis can have a number of slots into which can be placed a number of cards. Each card can have a number of ports.
- the port can comprise an ISDN port, a ATM port, or an ADSL port as an port instance.
- the card can identify the capabilities of a card e.g, a ISDN card, a ATM card, or a ADSL card as a card instance.
- the slot identifies the type of slot provided in the chassis e.g. a ISA slot or a PCI slot as a slot instance.
- the chassis identifies a chassis instance having a particular chassis serial number.
- the hardware model will also be given a name identifying that hardware model as a hardware instance.
- FIG. 2 is a schematic diagram of a software model.
- a software release or a software version all have a number of features, e.g. an IP (Internet Protocol) capability.
- IP Internet Protocol
- Each feature will have components e.g. IPsys.
- Each component will have an attribute e.g. timeout.
- the hardware and software model define the characteristics of the system.
- Values for attributes can be set as configuration data in order to define a configuration instance for the device. This comprises the configuration data table ( FIG. 10 ) that will be described in more detail hereinafter.
- FIGS. 3 a to 3 k illustrate the data structure that is a series of relational database tables for the hardware model in an embodiment of the present invention.
- FIG. 3 a illustrates the port table.
- the port represents a physical port will have a connection to another real world entity. Information will be transferred across the port into the device.
- a port is part of a card and a card can contain zero or many ports and thus a port type can have more than one instance. It is possible to run multiple logical interfaces over a single port. The set of logical interfaces available is determined by a combination of the port type and the software version running on the device.
- the parameter PortOID defines a unique identifier for each port.
- BaseInterfaceNumber identifies a base number at which logical interfaces on this port will be based. Interfaces will be described in more detail hereinafter with reference to FIGS. 5 a to 5 d.
- Document_RES comprises a pointer to the documentation text for this port. The documentation table will be described in more detail with reference to FIG. 7 .
- FIG. 3 b is a table for mapping ports to a card. Each card is uniquely identified together with each port. It is also possible for a port to have more than one instance on a card.
- FIG. 3 c is a diagram of the card table providing data for a card.
- Each card is uniquely identified by a parameter CardOID.
- Marketing product code for the card is also identified as well as a hardware board revision.
- the parameter BaseInterfaceNumber indicates the base number the logical interfaces on the card will be based at. There is also a pointer to the documentation text for the card.
- a card represents a physical card thst is inserted into a device and provides a certain capability in the device. Most cards will contain additional physical ports for the device which will be used to interface the device for other devices.
- FIG. 3 d illustrates the card to slot mapping table which provides the link between the card table and slot table. This table simply provides pointers between the slots and the cards.
- FIG. 3 e illustrates the slot table providing data for each slot.
- a slot represents a physical slot that is present on a chassis.
- a slot is of a particular type and this determines the set of cards that are compatible with the slot.
- Each slot is identified by a unique identifier and a description is provided of the slot.
- a pointer to the documentation text for each slot is also provided in the table.
- FIG. 3 f illustrates the slot to chassis mapping table to link the slots to the chassis.
- the table provides unique pointers between the slots and the chassis.
- Each slot can have more than one instance i.e. there can be more than one slot of the same type on the chassis.
- FIG. 3 g illustrates the chassis table.
- the chassis represents the physical chassis that can be inserted into a hardware model.
- the chassis is simply a carrier for slots into which cards can be inserted.
- a chassis is compatible with a particular model or set of hardware models.
- An example of a chassis will be a compact PCI chassis or a case for an ISDN router.
- Each chassis is uniquely identified by information on the marketing product code and hardware board revision is provided in the table. Also the unique pointer to the documentation text for the chassis is provided in the table.
- FIG. 3 h illustrates the chassis to hardware model mapping table. This maps the chassis to a hardware model.
- the table uniquely identifies the hardware and each chassis linking to the hardware model.
- a chassis can have more than one instance in the hardware model.
- FIG. 3 i illustrates the hardware model table.
- a hardware model represents an actual physical hardware model that is deployed by a named user.
- a model is simply a container for the chassis that will actually contain the hardware for the device.
- An actual hardware model could be an ISDN router or a cabinet rack that contains a specified set of chassis.
- the hardware model table contains a unique identifier of each hardware model together with the marketing product code for each hardware model. Also a pointer to the documentation text for the hardware model is included in the table.
- FIG. 3 j illustrates the hardware model to family mapping table that maps the links between a hardware model and a hardware product family.
- FIG. 3 k illustrates the family table.
- a hardware model family is intended to represent a collection of hardware models that are part of the same marketing product group. Each family is given a unique identifier together with a description of the product family.
- the table also contains a pointer to a documentation text for each product family.
- FIGS. 3 a to 3 k provide a data structure to identify the hardware characteristics of a device with links to documentation for particular characteristics.
- FIGS. 4 a to 4 e illustrate the tables forming the data structure of the software model.
- FIG. 4 a illustrates the attribute table that defines the attribute characteristics.
- a software configuration attribute represents a single configurable parameter that could potentially map to a particular structure or memory location in the device. From a configuration management point of view it is the values of the configuration attributes that must be stored to have a complete view of the parameters that are configured in the device. Configuration parameters are versioned so that changes in their default values, ranges and labels can be performed over the time. The history of an attribute can be kept so that the evolution of a parameter can be followed in an audit.
- the software version is made up of a collection of configuration attributes that describe the complete set of parameters configurable in the software version. As can be seen in FIG. 4 a, an attribute is given a unique identifier together with a version number.
- Each attribute includes a pointer to the component that holds the attributes.
- the type of attribute is also identified.
- the type identifies the user interface type for the attribute.
- the attribute could be a SELECT type which means that it will be linked to a selector so that when the attribute is displayed, a drop down menu is displayed to allow the attribute value to be changed by selection from the menu.
- a user interface label for the attribute as well as minimum and maximum values and a default value for the attribute are also contained in the table.
- a display size on the user interface for the attribute and text that should be appended after the user interface representation for the attribute are also included in the table together with help text.
- the parameter SelectorName identifies a selector name that can be used in the user interface. This will be described in more detail hereinafter.
- the order of the attribute in the display is also identified by a parameter in the attribute table.
- the table further contains a pointer to the documentation text for the attribute.
- the attribute table contains meta data for an attribute.
- An attribute can have a value which will be held by a configuration data table as will be described in more detail with reference to FIG. 10 .
- FIG. 4 a stores meta data which can be used for management and for providing a management interface. The information regarding the user interface can be used by user interface code to generate a management user interface which is standard and common whether the data is being viewed centrally or at the device.
- FIG. 4 b illustrates the component table.
- a software configuration component acts as a view of configuration attributes. When generating an interface such as a web interface for a particular component, a single form can be created which displays all the attributes associated with the component. It is possible for a configuration attribute associated with more than one configuration component. This allows for multiple views of collections of attributes to be built up. Each component is given a unique identifier. Within the table each component has the name of the parent feature to link to the parent feature. The type of configuration component is indicated.
- the configuration component can either be a system configuration component or an interface configuration component.
- the concept of system and interface objects is based on the approach by SNMP modellers defined in RFC 1213 MIB-II. Interface objects relate to interfaces and can be both physical e.g.
- the maximum number of elements that can be stored by the configuration component is also part of the configuration table and a user interface titled to the configuration component is stored. Further, there is a unique pointer to the documentation text for the configuration component.
- the component table provides all the necessary information to provide a user interface comprising a single view of all of the attributes associated with the component and the user interface title will appear on such a user interface.
- FIG. 4 c illustrates the feature table.
- a software feature is a set of related component definitions.
- the feature table contains a unique identifier of the feature together with a short description of the feature and a pointer to documentation text for the feature.
- FIG. 4 d illustrates the software version table.
- the software version represents all of the information that is relevant to the meta data of that particular software release for a device type.
- An entry in this table represents an actual source code release from a device development team.
- Each software version is given a unique identifier in the table and its file name is identified.
- An identity tag which comprises a string which identifies the software version as it would appear in the embedded device is also contained within the software version table.
- a version number and user friendly description of the software version is further included in the table.
- the parameter ActivationMechanism defines the mechanism that will be used in the device to activate the software.
- the parameter InterfaceStack determines the interfaces that are available for the software version to link the hardware and software as will be described in detail hereinafter.
- the user interface provided in this embodiment of the present invention is a web interface and this requires a web server.
- the parameter WebVersionOID identifies the web version which will accompany the software and be loaded on the device.
- the software version table also includes a pointer to the documentation text for the software version.
- FIG. 4 e illustrates the attribute software mapping table which links the software versions and each attribute provided by the software version.
- FIGS. 5 a to 5 d illustrate the data tables for the interface model linking the software and hardware models.
- FIG. 5 a illustrates the interface table.
- the logical interface represents the end of a logical connection over the device over a specific protocol.
- a logical interface can allow other logical interfaces to run over it to form a containment tree.
- Each logical interface is given a unique identifier and description.
- the logical interface is also given a number at which logical interfaces of that type are based on. Further, a unique pointer to documentation for the interface is also contained in the interface table.
- FIG. 5 b illustrates the interface stack table.
- This table illustrates the nesting of logical interfaces in a management model.
- the interface stack include a unique identifier of the management model that the relationship is part of.
- the lower and higher level interfaces are identified and how many instances of the higher layer interface can run on top of the lower layer interface.
- the table also includes a description of the relationship.
- FIG. 5 c illustrates the component to interface mapping table. These mappings indicate a set of constraints on the relationships rather than an actual assigment.
- an ISDN configuration object can be related to an ISDN type interface but not to an Ethernet type interface.
- the mapping data indicates the maximal set of allowed mappings.
- FIG. 5 d illustrates the port to the interface mapping table in which a port is mapped to an interface.
- FIGS. 5 a to 5 d illustrate how ports and components can be mapped to interfaces that can be stacked.
- an interface can be an ISDN logical interface.
- An ISDN logical interface can support the Internet Protocol (IP) and the point to point protocol (PPP).
- IP Internet Protocol
- PPP point to point protocol
- the software feature IP includes components such as IPsys and IP interface.
- the interface stack can define the relationships between the port and the components in a stacked manner.
- FIG. 6 illustrates the configuration information table.
- This table is not part of the metadata or development data.
- This data is the actual data or values for a configuration instance for a device.
- a configuration is assigned a unique value that can identify the complete configuration of a device or a profile configuration that can be used for configuring a family of devices.
- Devices can be stand-alone devices that have been configured completely or profile devices that can be configured from a profile by the insertion of specific configuration parameters to distinguish a specific device configuration.
- the configuration is given a name and the type of configuration is identified i.e. whether it is a profile, a profiled device or a stand alone device.
- Each configuration is given a serial number and for profiled devices, the identification of the profile on which the profiled device configuration is built is also stored in the table.
- the table further stores information on the current state of the device or profile.
- the current state indicates whether the configuration is in a pending state i.e. changes have been made, an accepted state where the configuration is available for use in a device, or active where the configuration has been used in a device.
- the parameter SwVersionOID identifies the version of the software to be assigned to the device.
- the software version has an attribute that identifies the software binary image that will be loaded on the device.
- WebVersionOID identifies the version of the embedded web pages that will run in the device.
- HwModelOID identifies the hardware model for the device.
- FIG. 7 illustrates the documentation table containing the documentation text for devices.
- Each characteristic in the hardware and software model which includes a unique documentation identifier links to documentation in the documentation table.
- FIG. 8 illustrates the external form table.
- This table defines the external form for attributes.
- the table identifies the attribute and the attribute version and gives an identifier for the external form to go with the actual form name.
- the external form defines the data syntax transformation. For example it can define a command line interface (CLI) string for the attribute for use by a CLI module in an embedded system in a device.
- CLI command line interface
- FIGS. 9 a , 9 b and 9 c illustrate selector tables to provide drop down menus to allow a user to select parameters. Selector names are links from other tables to define the appearance and utility of a user interface.
- FIG. 9 a illustrates a selector table that gives the name of a selector and an identifier for the selector element.
- the user interface display order and label is contained within the selector table together with a value that is represented. There is also a unique pointer to the documentation for the element.
- a selector element represents an individual entry in an enumeration in a selector. Each selector represents one entry from a possible list of entries.
- FIG. 9 b illustrates a configuration selector table.
- a configuration selector represents an enumeration of values that can be set for a configuration command.
- FIG. 9 c illustrates the software version selector table. This table holds a unique identifier for each software version and identifies a selector parent and selector elements.
- FIG. 10 illustrates a configuration data table.
- This data is not part of the metadata and it stores configuration data that comprises instances of attributes that belong to a device configuration or a profile configuration.
- Each configuration is given a unique ID and each configuration value is given a version number (VersionIx).
- the parameter InterfaceIx identifies which interface this attribute is associated with.
- the parameter ListIx enables more than one value for attributes.
- the attribute is identified using the parameter ConfigAttributeOID.
- the value is assigned as FieldValue.
- the parameter IsPartOfQuickPage indicates whether this configuration instance is an attribute that can be modified by a user to generate a profiled device configuration.
- the attribute meta data is used to form part of a display termed “a QuickPage”.
- a QuickPage enables value (configuration parameters) to be input by modifying default values to complete a profiled device configuration.
- the QuickPage comprises a user interface to allow a user to enter the values for attributes. If the configuration ID indicates from the configuration information table ( FIG. 6 ) that the configuration is a profile, then this flag indicates that the attribute is part of a “profiles QuickPage” definition and the FieldValue is the default value to be used when creating a device based on the profile. The value can however be changed by a user using the QuickPage. If the configuration ID identifies a profile device then this field indicates that the FieldValue contains the final value to be used for the attribute for that device.
- FIG. 11 is a schematic diagram of a development system for the development and management of configuration data and management data for devices.
- a development server 1 stores the data tables described hereinabove in a database 2 under the control of a database manager 3 .
- the table that are stored in the development system are the metadata tables since no specific configuration instance data is generated. The generation of specific configuration instances is performed in the device manager and thus in the development system the configuration information table of FIG. 6 and the configuration data table of FIG. 10 are not stored in the database 2 .
- a user's module 4 provides a gateway to the database for users and controls the type and level of access to the data
- a web server 5 is provided to use server side scripting such as active server page (ASP) code 6 or Java server page (JSP) code to provide a web interface to certain users.
- ASP active server page
- JSP Java server page
- the web server 5 uses the ASP to generate web pages using data from the database 2 .
- the data comprises the configuration data giving the values for attributes and the meta data defining the way the configuration data should be displayed.
- the development server 1 also includes a product release builder 7 for building a software product for release. Developers code 8 and code stubs 9 are also provided for building of binary code included in the product by the product release builder 7 .
- the product release builder 7 outputs a device management product 10 .
- a documentation application 11 is provided for the generation of documentation for a device using the documentation included in the meta data stored in the database 2 .
- a developer's computer 20 in this embodiment is shown separately to the development server 1 .
- the functionality can however be incorporated within the development server 1 .
- the developer's computer 20 includes a development application 21 which can comprise a Java application running on a Java Virtual Machine.
- the development application includes a code generator 22 to allow a developer to generate code to provide functionality required of a device.
- a code stub generator 23 is also provided for the automatic generation of code stubs 9 for management purposes.
- the user interface 24 is also provided to allow the developer to interface to the application.
- the development application 21 thus enables the developer to generate developer's code 8 and code stubs 9 .
- the development application 21 interfaces via the user's module 4 to the database manager 3 to gain access to the database 2 to thereby operate on the data structure as described hereinabove.
- the administrator's computer 30 is illustrated in this embodiment as being separate to the development server 1 . It can however be incorporated within the development server 1 .
- a development application 31 is operated by the administrator to enable the administrator to access the database via the user's module 4 and database manager 3 . Also the development application 31 controls the product release builder 7 to control the release of the device management product 10 .
- development system illustrated in FIG. 4 can be used by software developers using the developer's computer 20 to develop code for implementation on devices.
- an administrator can control the information being entered into the database 2 to provide a management function to manage the configuration and management data contained within the database 2 and to control the release of a device management product 10 .
- Other persons can gain access to the database 2 to contribute to the development of the data in the database.
- a documentor can use the computer 40 in order to access the database 2 in order to add information into the documentation table as illustrated in FIG. 7 .
- the access provided to the documentor can be controlled by the user's module 4 .
- a translator can gain access to the documentation in the documentation table as illustrated in FIG. 7 in order to input translations of documentation where necessary. Once again the functionality made available to the translator can be controlled by the user's module 4 .
- step S 1 Initially market research is carried out in order to determine product requirements (step S 1 ). This results in a product definition (step S 2 ) and a functional specification is drawn up (step S 3 ). Following this hardware and software is designed to provide the functions (step S 4 and S 5 ). These steps can be carried out iteratively to arrive at the necessary hardware and software to perform the functions.
- step S 2 a product definition
- step S 3 a functional specification
- step S 4 and S 5 Initially market research is carried out in order to determine product requirements.
- step S 4 and S 5 a functional specification is drawn up
- step S 4 and S 5 a functional specification
- These steps can be carried out iteratively to arrive at the necessary hardware and software to perform the functions.
- a developer can use a developer's application to access the database 2 .
- the developer enters data describing hardware and software (step S 7 ).
- step S 7 a This can be achieved by selecting a previous hardware model in the database 2 (step S 7 a ) and selecting a previous software model (step S 7 b ) meta data for the previous model is copied and a new entry made in the database 2 .
- the data can then be modified by the developer to modify the entries in the database to specify new hardware or software characteristics (step S 7 c ).
- step S 8 data is entered into the database.
- Code stubs to provide the management functions can then be automatically generated (step S 9 ) and under the control of the administrator using the administrator's computer 30 , the developer's code 8 and the code stubs 9 can be taken in by the product release builder 7 to build a management device product 10 (step S 10 ).
- the product includes:
- binary code for the devices to be managed (performed by combining the developer's code 8 and the code stubs 9 ), which includes metadata for the management and configuration of the device.
- the software product is thus the code required for a new software release for a device and it includes meta data for the configuration and management of the device by a network (device) manager.
- the network management code is a standard code that utilises the metadata for managing and configuring devices and determined by the software release.
- the network management code can thus be provided separately or combined with the software release product for a device to allow the management and configuration of the device over a network.
- FIG. 13 is a flow diagram illustrating the process of managing and developing the configuration and management data in the database 2 .
- a user uses the computer 40 to access the web server 5 and logs in.
- the user's module 4 determines the role to be performed by the user (step S 21 ). If a user is a documentor, the user can access undocumented features that are presented as a web page (step S 22 ). The user is thus able to enter documentation for a particular features or characteristic so the software or hardware. If changes are made in the database (step S 23 ), the database is updated in step S 24 and the user can then log out in step S 25 .
- step S 26 If it is determined by the user's module 4 that the user is a reviewer, they are presented with a web page of unreviewed features (step S 26 ) the reviewer can thus review the features and make any changes they feel its necessary. If the user's module 4 determines the user is a translator, untranslated features are presented to the user as a web page (step S 27 ). The translator can thus enter translations as necessary.
- FIG. 14 is a schematic diagram of a network device management system in accordance with an embodiment of the present invention.
- the device manager 50 illustrated in FIG. 14 is generated.
- the device manager 50 is connected over a network 60 to networked devices 70 , 71 , 72 and 73 .
- the network preferably comprises an Internet Protocol (IP) network.
- IP Internet Protocol
- Within the device manager there is a database 51 storing a copy of the data stored in the database 2 within the development system 1 .
- the metadata tables are copied and also configuration instance tables ( FIGS. 6 and 10 ) are set up to store configuration instances for devices.
- a database manager 52 controls access to the database 51 .
- a device code store 53 stores binary code for each of the devices 70 , 71 , 72 and 73 .
- a device configurator 54 (also termed a VAMP client/server) provides the connection over the network 60 to the devices 70 , 71 , 72 and 73 .
- the device configurator 54 can download the code stored in the device code store 53 to the devices 70 , 71 , 72 and 73 in order to provide the code for controlling the devices to provide the management function.
- the device configurator 54 can also access the database 51 via the database manager 52 in order to download a copy of configuration and management data to the network devices 70 , 71 , 72 and 73 .
- the devices 70 , 71 , 72 and 73 need only store the configuration and management data relevant to the respective device. It is however configuration and management data that has been derived from the common data structure in databases 2 and 51 in the development system I and the device manager 50 respectively.
- the device configurator 54 acts as both the web server and web client since the protocol used for communication over the network 60 to the devices 70 , 71 , 72 and 73 is preferable the hypertext transfer protocol (HTTP).
- HTTP hypertext transfer protocol
- the device manager 50 also includes a configuration generator 55 for generating a complete set of configuration data i.e. the device configuration from a profile configuration. This enables the operator of the device manager 50 to configure multiple devices using a single profile.
- a profile configuration is available, the user of the device manager 50 can use the configuration generator to select the profile and use it to generate a profiled device by entering parameters. This can be done by using a user interface termed a “Quick Page” to allow a user to enter the necessary parameters to distinguish the individual device.
- the Quick Page allows the default values of certain attributes in a profile configuration to be modified by the manager to provide the configuration comprising the profile device.
- the profile device configuration can then be downloaded to configure a device 70 , 71 , 72 or 73 by the device configurator 54 .
- the manager can define new profile configurations by defining attributes which are part of the QuickPage.
- FIG. 15 schematically illustrates modules in the device to provide for local and central management of the device.
- a platform application 100 to be configured and managed is interfaced via glue 101 , 102 and 103 comprising code to an interprocess communication module 104 for communication with a portable communication module 105 .
- a portable communication module 105 interfaces to BSD (Berkeley Distribution System) sockets.
- the communication protocol stack comprises Internet Protocol (IP) 106 , Transmission Control Protocol (TCP) 107 , and Unigram Data Protocol (UDP) 108 and a serial port 109 is provided to interface to the BSD sockets 110 .
- the portable module 105 is the code that is common to all devices.
- a web server 111 Within the module 105 a web server 111 , a TELNET server 112 and a serial interface 113 are provided.
- the device can communicate via HTTP using a VAMP engine 114 .
- a management request broker 116 that contains configuration data and logic and meta data for the configuration and management of the device.
- a configuration instrumentation broker 119 is provided in conjunction with the configuration glue 111 for communication to the platform application software 100 .
- a Simple Network Management Protocol (SNMP) instrumentation broker 120 is provided in conjunction with the glue 102 for communication of instructions to or from the platform application software 100 .
- the SNMP instrumentation broker 120 is provided to allow integration with SNMP agents running in the device.
- An event instrumentation broker 121 is provided in conjunction with event glue 103 to communicate events from the application software 100 into the embedded framework event management system.
- An event system 122 monitors events and a performance monitor 123 monitors performance statistics. This enable the provision of event and statistic management information via the VAMP engine 114 in a management interface as a web page.
- a simple mail transfer protocol (SMTP) client 124 is provided to enable e-mail communication with the device.
- SMTP simple mail transfer protocol
- Embedded web data 125 stores web information for the construction of web page interfaces as an interface to the device.
- a scripting engine 126 provides for scripting and a scheduler 127 schedules certain actions under the control of timer services 128 .
- FIG. 16 illustrates the operation of the device acting as a web server to display management information in the form of a web page for a feature x.
- the HTTP server 111 receives an HTTP get request for the web page for management information on feature x via the TCP/IP stack 106 and 107 from a web browser loaded on a computer 170 .
- Computer 170 comprises can comprise any web enabled computer.
- the request is passed on to a VAMP engine 114 to provide the management functionality.
- Embedded web information 125 is used by the VAMP engine 114 to construct the hypertext transfer mark up language (HTML) i.e. the web page to be returned.
- the VAMP engine 114 also requests information from the management request broker 116 .
- the management request broker returns meta data which is used by the VAMP engine 114 to construct the web page.
- the meta data stored by the management request broker 116 controls the user interface by configuring the form of the web page.
- the meta data can control the order in which items appear, the text to appear after items, and the language used.
- the management request broker 116 also returns configuration data which comprises the actual values for parameters.
- the web page constructed by the VAMP engine 114 is then returned to the computer 170 for display as a web page.
- management request broker 116 is able to respond to the request for management information from the VAMP engine 114 using configuration data stored within the management request broker 116 .
- FIG. 17 illustrates an example where the management information required in the HTTP request from the computer 170 is not all contained within the configuration data within the management request broker 116 .
- the information required could include status data.
- the HTTP server 111 receives the request and passes to VAMP engine 114 .
- the VAMP engine uses the meta data from the management request broker 116 to determine whether the information requested is present within the configuration data. If, using the meta data, it does identify that the attributes requested are present in the configuration data but must be obtained from the hardware platform on which the code module 1 15 is being implemented, a callback is invoked by the management request broker 116 through the configuration instrumentation broker 117 , the interprocess communication 104 and the configuration glue 111 to the platform application software 100 .
- the requested attribute information is returned to the management request programme 116 and passed on to the VAMP engine 114 for inclusion within the web page as described with reference to FIG. 16 .
- a web page interface is provided for management information thus allowing local or remote access to management information on the network device.
- the scripting engine 136 stores code for the dynamic generation of web pages. However, it is possible also for static embedded web pages to be used.
- FIG. 18 is a diagram of the operation of the device when performing an auto provisioning function.
- the device executes a script within the scripting engine 136 which causes the VAMP engine 114 to control HTTP server 111 to generate and an HTTP get request to the VAMP server 54 in the device manager 50 for configuration and management information.
- the requested information is returned by the VAMP server 54 in the device manager 50 and is received at the VAMP engine 114 via the HTTP server 111 .
- the VAMP engine 114 then stores the retrieved configuration and management data within the management request broker 116 . It can also store downloaded web page data in the embedded web store 125 . Thus in this way the device can be initially configured automatically.
- FIG. 19 is a diagram illustrating the modification of parameters under the control of the device configurator acting as a VAMP client 54 within the device manager 50 .
- the VAMP client sends an HTTP request with attributes that are received in the VAMP engine 114 via HTTP server 111 .
- the management request broker 116 invokes call backs into the application software 100 in order to attempt to modify an attribute in the platform application software 100 .
- a response is then returned to the VAMP client 74 within the device manager 50 via the VAMP engine 114 .
- the state of the object is then stored by the management request broker 116 .
- the management data is only updated if the request was successful e.g. if the request was to disable a circuit but the circuit was busy, the device will not action the request and the management data must reflect this.
- the VAMP client 54 within the device manager 50 can also retrieve configuration data from the management request broker without performing the modification of the attributes in a similar manner to that described with reference to FIG. 19 except that no callback is invoked into the platform application software 100 . Instead the configuration data is used to return the requested attributes as a HTTP response to the VAMP client 54 within the device manager 50 .
- FIG. 20 illustrates the process of implementing or registering a feature in the device.
- the management request broker 116 includes meta data and configuration data for the feature.
- the configuration instrumentation broker 119 initiates the callbacks for the registration process in order to pass the necessary attributes.
- the implementation of feature X can be configured in the device.
- FIG. 21 illustrates the provision of a command line interface capability within the device to allow the fetching of attributes.
- a command line interface 115 is provided to enable a TELNET session to be used for communication with the device.
- a computer 170 establishes a TELNET session over the TCP/IP stack 106 and 107 with the TELNET server 112 .
- the TELNET server 112 passes on the command line input to the command line interface 115 .
- the command line interface 115 interacts with the management request broker 116 in order to determine if necessary responses can be provided from the configuration data using the meta data.
- the command line interface 115 then generates a text response that is passed by the TELNET server 112 as a response in the TELNET session to the computer 170 .
- FIG. 22 illustrates the use of the command line interface 115 to modify attributes in the platform application software 100 .
- a TELNET session is established by a computer 170 with the TELNET server 112 over the TCP/IP stack 106 and 107 .
- the input attribute setting request is received by the command line interface 116 which uses the meta data to determine whether the response can be fulfilled by the configuration data. In this case it could not and a callback is invoked by the management request broker 116 through the configuration instrumentation broker 119 to the platform application software 100 in order to pass on the attribute modification.
- the response is received to confirm the modification and the command line interface 115 responds with an appropriate response that is passed by the TELNET server 112 to the computer 170 .
- FIG. 23 illustrates the use of the command line interface for retrieving management information i.e. on-line help for users of the command line interface.
- a user types in a component name e.g. set feature X, but cannot remember the attribute.
- a request for information on feature X is sent as a command line instruction over a TELNET session on the computer 170 via the TELNET server 112 to the command line interface 115 .
- the command line interface 115 retrieves the necessary information from meta data within the management request broker 116 in order to return the information. In this case the attributes for a component are the returned information.
- a user can select one to complete the command.
- FIG. 24 is a schematic diagram illustrating the flexibility of the code module 115 .
- This can be installed in any network device 150 to provide the management and configuration function.
- the management and configuration function can be provided by connecting a computer 170 using the web browser over the network connection 160 to interface to the code module 105 .
- the code module 105 can either be loaded into the device 150 or can be provided on a separate physical device e.g. an internal card, or an external module.
- the present invention is application to any device that can be managed centrally such as a networked device.
- the management data can comprise any function or parameters that require monitoring or control.
- the management parameters can include statistics, notifications from the devices, device performance parameters, and/or device status parameters.
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Stored Programmes (AREA)
- Control Or Security For Electrophotography (AREA)
- Computer And Data Communications (AREA)
Abstract
Description
- The present invention relates to the development and/or management of configuration and management parameters for devices.
- There is a need when developing devices for a management capability for the devices to be generated. Thus a device developer must devote some time to the task of providing management capabilities in a device. This is something that many developers dislike and can overlook. The responsibility usually falls to an administrator or manager to ensure that a management function is provided in the device by requesting certain management functions to be encoded in the device.
- With the prevalent use of networked devices, the provision for both local and remote management has become essential for the proper functioning of a network. Networked devices can be used for a wide range of functions and it highly desirable to provide both local and central management.
- In the prior art, the provision of both local and central management of devices is approached separately. A device developer is frequently required to provide certain management functions and does so by providing software for the device which provides an interface to the device e.g. over the network. An administrator or manager then provides a central management capability separately. This means that there is a fragmented approach to the management of the devices. There are two separate development groups, one providing local management and the other providing central management. This requires an increase in effort making it time consuming and expensive to create and maintain all the necessary documentation. Further coordination between the groups can be difficult and thus the maintenance of consistency and compatibility between the two ends of the management can be difficult. Further, developers who are normally responsible for influencing device features often do not understand the management requirements.
- Thus in accordance with one aspect of the present invention, the present inventors have developed and end to end management solution which utilises a common management data structure during the development, deployment, and use of managed devices. A common management model is used which can provide a common management interface.
- One aspect of the present invention provides a device configuration system and method for developing and managing configuration and management information for devices. The system enables developers to develop configuration data and/or management data. Configuration and/or management data is stored as device data that is stored in accordance with a common management model. This enables the parameters and the management information to be managed. Parameters and management data entered in the common model can be output in a software product as a device management product which includes a parameters and management data for a set of devices. The device management product can thus be used to configure and manage a set of devices using the common management model. Each device has configuration and management data stored therein in accordance with the common management model. This provides for both central management and for local management using the common management model. In this way end to end management is provided.
- Another aspect of the present invention provides a device configuration development system for developing and/or managing configuration and/or management information for devices. Device data structured in accordance with the common model of parameters relating to the configuration and/or management of the devices is stored. A developer interface allows a software developer to develop software for configuring and/or managing devices and to store device data in accordance with a common model. A device configuration and/or management software product for configuring and managing a set of devices is built by reading stored data for a set of devices structured in accordance with the common model. Device management and control software is configured for controlling a processing apparatus in a device manager to configure and/or manage the devices using the data for the devices included in the product and to provide the data for a device to the device to allow a local configuration and/or management at the device. The device management and control software can be included in the product or it can be already installed in the device manager processing apparatus.
- In one embodiment of the present invention, the software product is built by reading and including in the software product the software developed by the software developer for loading onto devices for configuring and managing the devices.
- In a preferred embodiment, the devices comprise network devices and the common model is a model of parameters relating to the configuration and management of the network devices which can be for example network configuration parameters e.g. network protocol capabilities.
- In one embodiment of the present invention, the common management model comprises a model of hardware characteristics, software characteristics and relationships therebetween. This therefore provides a full picture of the characteristics of the device for management purposes.
- In one embodiment of the present the device data comprises configuration data and meta data. The configuration data defines configuration parameters that can be set for the device. A configuration data can have configuration values that can be set by the developer or be settable by a manager centrally or by an operator of the device The meta data comprises management information for the configuration data and for the device.
- In one embodiment the device data can include management data which includes interface information defining the configuration of a user interface to the device data i.e. defining a management interface. In this way, the meta data can define a common interface for central and local management. In one embodiment, for networked devices, the common user interface preferably comprises a web interface provided by a web server.
- In one embodiment of the present invention, the device data can be copied to allow a developer to enter device data if the need arise by simply copying device data for another device which most closely resembles the new device to be developed and modifying the device data as necessary.
- In one embodiment of the present invention, the developer interface means includes means for generating code stubs for management functionality from the device data for combination with the software provided by the software developer to control the device. Thus this capability provides encouragement for a developer to use the development system to enter the management data and the task of writing the code for the management functionality is removed from the developer. It is only necessary for the developer to interface the code stubs into their code by writing suitable interface code or ‘glue’.
- In one embodiment of the present invention, documentation for each device is stored. This can be stored as segments associated with respective parameters in the common model. Documentation for a device can be generated automatically by inserting management information from the management model into the documentation. Thus as management parameters are updated, the documentation is automatically updated. The documentation can be stored as document segments with each segment being associated with a respective parameter and having management parameters associated therewith. Thus documentation can be built up by incorporating management parameters into the documentation segments and aggregating the document segments to provide complete documentation for the device.
- Within the common model, it is possible for the configuration parameters to identify a configured device comprising configuration data which is complete for a device or a configuration profile that includes some configuration data that can be input to complete or modify the configuration data for a device. For example, a number of configuration parameters could be set to a default value that can be altered by a user in order to modify the configuration data to provide a device profile. Thus in this way configuration parameters for a device can comprise configuration parameters from a configuration profile and user input configuration parameters. The configuration parameters from a configuration profile can be common to a large number of devices.
- In accordance with another aspect, the present invention provides a management system or method for managing devices using the common management model. Data storage means stores management and configuration data for each device for managing and configuring the device. The management and configuration data is structured in accordance with the common management model i.e. in accordance with a common model of parameters related to the functioning and management of the devices. Means of communicating with the devices is provided in each device. Also the devices are provided with a copy of the management and configuration data for respective devices to provide for local management and configuration. Thus each device has a subset of the data in the common management model relevant for the management of the device. A device management means controls communications to and from the devices to provide central configuration of the devices and receipt of management data from the devices.
- Thus in accordance with this aspect of the present invention, a device management system can be provided by the device development environment and the common management model can be used in both.
- The device management system can, in one embodiment, provide the copy of the management and configuration data to each of the devices. In this way the management system can provide the initial configuration for the devices. This initial configuration can include the storage of code modules for controlling the devices for sending to and storing at the devices. The code module can be the same for the same type of device thus providing for not only common hardware but also common software for devices. The only difference between devices thus lies in the configuration and management data. This enables simple reconfiguration of devices by reconfiguration of their configuration and management data. No change of code is needed.
- The configuration data defines configuration instances for devices. Also the configuration data can define a configuration profile for which some user definable configuration data can be entered or modified. This enables a configuration profile to apply to a set of devices and it enables a manager of the devices to assign configuration parameters individually only to the subset of the whole set of configuration data in order to provide a unique set of configuration data for a device.
- Another aspect of the present invention provides a centrally managed device in which data for the device is stored and structured in accordance with a common model of parameters related to the functioning and management of devices managed by a central management system. The means for communicating with the central management system is provided under the control of the control means to control the sending of management data to the central management system.
- In an embodiment of the present invention, the data comprises a set of configuration parameters and a set of management parameters. The management parameters are associated with respective configuration parameters and provide management information on the configuration parameters. Thus the management parameters comprise meta data for the configuration data.
- In one embodiment the control means comprises a code module implemented by a processor in the device. The code module is downloadable from the central management system.
- A further aspect of the present invention provides a device documentation generation system method in which meta data for each of the parameters defining characteristics of a plurality of devices is stored. The meta data is stored in accordance with a common data module for the devices. Documentation can be input for association with meta data for respective parameters and documentation for a device can be generated by incorporating the meta data into the documentation. In this way, as the meta data is changed i.e. the management information changes, the documentation is automatically updated.
- In one embodiment, the documentation can be input as segments associated with respective parameters defining the characteristics of the device. The document generation then includes aggregating the appropriate document segments for appropriate parameters relevant to the device.
- In one embodiment the meta data includes an indication of the language of the documentation to be generated for a device. The input documentation is stored and can comprise documentation in more than one language for a parameter. The documentation is then generated using the documentation in the language indicated by the indication in the meta data for the device.
- A further aspect of the present invention provides a device configuration development system for developing control code for devices. A code store stores a library of code stubs for providing device management functions. A data store stores metadata on device configuration parameters, wherein the meta data comprises management information for the device configuration parameters. Meta data can be input into the data store and code stubs can be determined for a device to provide the management functionality defined in the input meta data using the library of code stubs in the code store.
- Thus this aspect of the present invention enables a developer to merely input management information into the common database and receive in return code stubs for providing the management functionality to be incorporated within the developer's code for controlling the device.
- A further aspect of the present invention provides a device management system and method for providing information defining a management interface for devices to provide for local and central management. Device data structured in accordance with the common module for the management of devices is stored. Information defining a management interface for devices is input for storage in the device data. The device data is output as a set of device data to provide a management interface for the central management of the set of devices and as device data for each data to provide the same management interface for the local management of each device.
- A further aspect of the present invention provides a device configuration development system and method for developing and managing configuration and management information for devices. The required functionality of the devices is defined and desired attributes for management of the devices are entered. The entered attributes are stored as a central database for management of the devices and as a set of data in the devices for local management of the devices.
- Any one of the aspects of the present invention described hereinabove can be used in combination with any ones of the aspects of the inventions hereinabove.
- Any aspect of the present invention described hereinabove can be implemented in dedicated hardware, in a mixture of dedicated hardware and programmable hardware or in solely programmable hardware. The present invention can thus be embodied as programmable code for controlling a processor to carry out the processing steps. A carrier medium carrying the code is thus within the scope of the present invention. The carrier medium can either be a transient carrier medium or a storage carrier medium. A transient carrier medium can comprise a signal such as an electrical, optical, microwave, radio frequency or acoustic signal carrying computer code. An example of a transient carrier medium is a signal carrying computer code over the Internet (an Internet Protocol (IP) Network). The storage medium can comprise any conventional storage medium such as a floppy disk, hard disk, CD ROM, tape device, or solid state memory device.
- Embodiments of the present invention will now be described with reference to the accompanying drawings, in which:
-
FIG. 1 is a schematic diagram of a hardware model used in accordance with an embodiment of the present invention, -
FIG. 2 is a schematic diagram of a software model used in an embodiment of the present invention, -
FIGS. 3 a to 3 k are tables illustrating the data structure of the hardware model in a relational database in accordance with an embodiment of the present invention, -
FIGS. 4 a to 4 e are tables illustrating the data structure of the software model in a relational database in accordance with an embodiment of the present invention, -
FIGS. 5 a to 5 d are tables illustrating the interfacing between the hardware model and the software module in a relational database in accordance with an embodiment of the present invention, -
FIG. 6 is a table providing information on configuration data, -
FIG. 7 is a table providing the documentation information for the parameters in the tables, -
FIG. 8 is a table giving information on the external form of attributes in the embodiment of the present invention, -
FIGS. 9 a and 9 c are selected tables used for identifying user interface selection options in accordance with an embodiment of the present invention, -
FIG. 10 is a table of the configuration data, -
FIG. 11 is a schematic diagram of a development system in accordance with an embodiment of the present invention, -
FIG. 12 is a flow diagram of the development process in accordance with an embodiment of the present invention, -
FIG. 13 is a flow diagram showing the development and management of the management information used for documentation in accordance with an embodiment of the present invention, -
FIG. 14 is a schematic diagram of a device management system in accordance with an embodiment of the present invention, -
FIG. 15 is a schematic diagram of the components of a device in which the components provide for central and local configuration and management of the device, -
FIG. 16 is a diagram showing the retrieval of management information, -
FIG. 17 is a diagram illustrating retrieval of parameters, -
FIG. 18 is a diagram illustrating the download of configuration data to configure the device, -
FIG. 19 is a diagram illustrating the configuration of a device, -
FIG. 20 is a diagram illustrating the implementation of a feature in a device, -
FIG. 21 is a diagram illustrating the retrieval of management information using a command line interface, -
FIG. 22 is a diagram illustrating the setting of a feature using the command line interface, -
FIG. 23 is a diagram illustrating the interfacing to the meta data using a command line interface, and -
FIG. 24 is a schematic diagram of the use of the configuration and management components as a ubiquitous interface to any device. - The present invention is built the premise of a common management model. The management model is common to:
- 1. The developer when developing the code for the device and the development managers,
- 2. The network manager (device manager) responsible for managing a network of devices, and
- 3. The devices that contain a set of the configuration and management data appropriate for the device.
- Thus during the development phase, the developer and the development manager work on these same data which will end up on the devices and on the networked device managing system.
- The common management model used is based on a meta data model. The meta data model comprises a hardware model, a software model and relationships therebetween. The model used and the data structure in accordance with the model will now be described.
-
FIG. 1 schematically illustrates the hardware model. A hardware model, defines a hardware model for a product that can comprise a number of chassis. Each chassis can have a number of slots into which can be placed a number of cards. Each card can have a number of ports. - Thus this is a hardware model of a network device having communication ports. Thus for example, the port can comprise an ISDN port, a ATM port, or an ADSL port as an port instance. The card can identify the capabilities of a card e.g, a ISDN card, a ATM card, or a ADSL card as a card instance. The slot identifies the type of slot provided in the chassis e.g. a ISA slot or a PCI slot as a slot instance. The chassis identifies a chassis instance having a particular chassis serial number. The hardware model will also be given a name identifying that hardware model as a hardware instance.
-
FIG. 2 is a schematic diagram of a software model. A software release or a software version all have a number of features, e.g. an IP (Internet Protocol) capability. Each feature will have components e.g. IPsys. Each component will have an attribute e.g. timeout. - Thus the hardware and software model define the characteristics of the system. Values for attributes can be set as configuration data in order to define a configuration instance for the device. This comprises the configuration data table (
FIG. 10 ) that will be described in more detail hereinafter. -
FIGS. 3 a to 3 k illustrate the data structure that is a series of relational database tables for the hardware model in an embodiment of the present invention. -
FIG. 3 a illustrates the port table. The port represents a physical port will have a connection to another real world entity. Information will be transferred across the port into the device. There are many different types of port and the type of port determines the type of connection associated with the port. A port is part of a card and a card can contain zero or many ports and thus a port type can have more than one instance. It is possible to run multiple logical interfaces over a single port. The set of logical interfaces available is determined by a combination of the port type and the software version running on the device. - The parameter PortOID defines a unique identifier for each port. BaseInterfaceNumber identifies a base number at which logical interfaces on this port will be based. Interfaces will be described in more detail hereinafter with reference to
FIGS. 5 a to 5 d. Document_RES comprises a pointer to the documentation text for this port. The documentation table will be described in more detail with reference toFIG. 7 . -
FIG. 3 b is a table for mapping ports to a card. Each card is uniquely identified together with each port. It is also possible for a port to have more than one instance on a card. -
FIG. 3 c is a diagram of the card table providing data for a card. Each card is uniquely identified by a parameter CardOID. Marketing product code for the card is also identified as well as a hardware board revision. The parameter BaseInterfaceNumber indicates the base number the logical interfaces on the card will be based at. There is also a pointer to the documentation text for the card. A card represents a physical card thst is inserted into a device and provides a certain capability in the device. Most cards will contain additional physical ports for the device which will be used to interface the device for other devices. -
FIG. 3 d illustrates the card to slot mapping table which provides the link between the card table and slot table. This table simply provides pointers between the slots and the cards. -
FIG. 3 e illustrates the slot table providing data for each slot. A slot represents a physical slot that is present on a chassis. A slot is of a particular type and this determines the set of cards that are compatible with the slot. There are can be zero or more slots available on a chassis. Each slot is identified by a unique identifier and a description is provided of the slot. A pointer to the documentation text for each slot is also provided in the table. -
FIG. 3 f illustrates the slot to chassis mapping table to link the slots to the chassis. The table provides unique pointers between the slots and the chassis. Each slot can have more than one instance i.e. there can be more than one slot of the same type on the chassis. -
FIG. 3 g illustrates the chassis table. The chassis represents the physical chassis that can be inserted into a hardware model. The chassis is simply a carrier for slots into which cards can be inserted. A chassis is compatible with a particular model or set of hardware models. An example of a chassis will be a compact PCI chassis or a case for an ISDN router. Each chassis is uniquely identified by information on the marketing product code and hardware board revision is provided in the table. Also the unique pointer to the documentation text for the chassis is provided in the table. -
FIG. 3 h illustrates the chassis to hardware model mapping table. This maps the chassis to a hardware model. The table uniquely identifies the hardware and each chassis linking to the hardware model. A chassis can have more than one instance in the hardware model. -
FIG. 3 i illustrates the hardware model table. A hardware model represents an actual physical hardware model that is deployed by a named user. A model is simply a container for the chassis that will actually contain the hardware for the device. An actual hardware model could be an ISDN router or a cabinet rack that contains a specified set of chassis. The hardware model table contains a unique identifier of each hardware model together with the marketing product code for each hardware model. Also a pointer to the documentation text for the hardware model is included in the table. -
FIG. 3 j illustrates the hardware model to family mapping table that maps the links between a hardware model and a hardware product family. -
FIG. 3 k illustrates the family table. A hardware model family is intended to represent a collection of hardware models that are part of the same marketing product group. Each family is given a unique identifier together with a description of the product family. The table also contains a pointer to a documentation text for each product family. - It can thus be seen that
FIGS. 3 a to 3 k provide a data structure to identify the hardware characteristics of a device with links to documentation for particular characteristics. -
FIGS. 4 a to 4 e illustrate the tables forming the data structure of the software model. -
FIG. 4 a illustrates the attribute table that defines the attribute characteristics. A software configuration attribute represents a single configurable parameter that could potentially map to a particular structure or memory location in the device. From a configuration management point of view it is the values of the configuration attributes that must be stored to have a complete view of the parameters that are configured in the device. Configuration parameters are versioned so that changes in their default values, ranges and labels can be performed over the time. The history of an attribute can be kept so that the evolution of a parameter can be followed in an audit. The software version is made up of a collection of configuration attributes that describe the complete set of parameters configurable in the software version. As can be seen inFIG. 4 a, an attribute is given a unique identifier together with a version number. Each attribute includes a pointer to the component that holds the attributes. The type of attribute is also identified. The type identifies the user interface type for the attribute. For example the attribute could be a SELECT type which means that it will be linked to a selector so that when the attribute is displayed, a drop down menu is displayed to allow the attribute value to be changed by selection from the menu. A user interface label for the attribute as well as minimum and maximum values and a default value for the attribute are also contained in the table. A display size on the user interface for the attribute and text that should be appended after the user interface representation for the attribute are also included in the table together with help text. The parameter SelectorName identifies a selector name that can be used in the user interface. This will be described in more detail hereinafter. The order of the attribute in the display is also identified by a parameter in the attribute table. The table further contains a pointer to the documentation text for the attribute. - Thus the attribute table contains meta data for an attribute. An attribute can have a value which will be held by a configuration data table as will be described in more detail with reference to
FIG. 10 .FIG. 4 a stores meta data which can be used for management and for providing a management interface. The information regarding the user interface can be used by user interface code to generate a management user interface which is standard and common whether the data is being viewed centrally or at the device. -
FIG. 4 b illustrates the component table. A software configuration component acts as a view of configuration attributes. When generating an interface such as a web interface for a particular component, a single form can be created which displays all the attributes associated with the component. It is possible for a configuration attribute associated with more than one configuration component. This allows for multiple views of collections of attributes to be built up. Each component is given a unique identifier. Within the table each component has the name of the parent feature to link to the parent feature. The type of configuration component is indicated. The configuration component can either be a system configuration component or an interface configuration component. The concept of system and interface objects is based on the approach by SNMP modellers defined in RFC 1213 MIB-II. Interface objects relate to interfaces and can be both physical e.g. ports and logical e.g. protocols such as PPP and X25. System objects are system wide e.g. protocols such as IP, SNMP or TCP or software applications. The maximum number of elements that can be stored by the configuration component is also part of the configuration table and a user interface titled to the configuration component is stored. Further, there is a unique pointer to the documentation text for the configuration component. - It can thus be seen that the component table provides all the necessary information to provide a user interface comprising a single view of all of the attributes associated with the component and the user interface title will appear on such a user interface.
-
FIG. 4 c illustrates the feature table. A software feature is a set of related component definitions. The feature table contains a unique identifier of the feature together with a short description of the feature and a pointer to documentation text for the feature. -
FIG. 4 d illustrates the software version table. The software version represents all of the information that is relevant to the meta data of that particular software release for a device type. An entry in this table represents an actual source code release from a device development team. Each software version is given a unique identifier in the table and its file name is identified. An identity tag which comprises a string which identifies the software version as it would appear in the embedded device is also contained within the software version table. A version number and user friendly description of the software version is further included in the table. The parameter ActivationMechanism defines the mechanism that will be used in the device to activate the software. The parameter InterfaceStack determines the interfaces that are available for the software version to link the hardware and software as will be described in detail hereinafter. The user interface provided in this embodiment of the present invention is a web interface and this requires a web server. Thus the parameter WebVersionOID identifies the web version which will accompany the software and be loaded on the device. The software version table also includes a pointer to the documentation text for the software version. -
FIG. 4 e illustrates the attribute software mapping table which links the software versions and each attribute provided by the software version. -
FIGS. 5 a to 5 d illustrate the data tables for the interface model linking the software and hardware models. -
FIG. 5 a illustrates the interface table. The logical interface represents the end of a logical connection over the device over a specific protocol. A logical interface can allow other logical interfaces to run over it to form a containment tree. Each logical interface is given a unique identifier and description. The logical interface is also given a number at which logical interfaces of that type are based on. Further, a unique pointer to documentation for the interface is also contained in the interface table. -
FIG. 5 b illustrates the interface stack table. This table illustrates the nesting of logical interfaces in a management model. The interface stack include a unique identifier of the management model that the relationship is part of. The lower and higher level interfaces are identified and how many instances of the higher layer interface can run on top of the lower layer interface. The table also includes a description of the relationship. -
FIG. 5 c illustrates the component to interface mapping table. These mappings indicate a set of constraints on the relationships rather than an actual assigment. For example an ISDN configuration object can be related to an ISDN type interface but not to an Ethernet type interface. In other words the mapping data indicates the maximal set of allowed mappings. -
FIG. 5 d illustrates the port to the interface mapping table in which a port is mapped to an interface. - Thus
FIGS. 5 a to 5 d illustrate how ports and components can be mapped to interfaces that can be stacked. For example an interface can be an ISDN logical interface. An ISDN logical interface can support the Internet Protocol (IP) and the point to point protocol (PPP). Thus the software feature IP includes components such as IPsys and IP interface. Thus the interface stack can define the relationships between the port and the components in a stacked manner. -
FIG. 6 illustrates the configuration information table. This table is not part of the metadata or development data. This data is the actual data or values for a configuration instance for a device. A configuration is assigned a unique value that can identify the complete configuration of a device or a profile configuration that can be used for configuring a family of devices. Devices can be stand-alone devices that have been configured completely or profile devices that can be configured from a profile by the insertion of specific configuration parameters to distinguish a specific device configuration. The configuration is given a name and the type of configuration is identified i.e. whether it is a profile, a profiled device or a stand alone device. Each configuration is given a serial number and for profiled devices, the identification of the profile on which the profiled device configuration is built is also stored in the table. The table further stores information on the current state of the device or profile. The current state indicates whether the configuration is in a pending state i.e. changes have been made, an accepted state where the configuration is available for use in a device, or active where the configuration has been used in a device. The parameter SwVersionOID identifies the version of the software to be assigned to the device. The software version has an attribute that identifies the software binary image that will be loaded on the device. WebVersionOID identifies the version of the embedded web pages that will run in the device. HwModelOID identifies the hardware model for the device. -
FIG. 7 illustrates the documentation table containing the documentation text for devices. Each characteristic in the hardware and software model which includes a unique documentation identifier links to documentation in the documentation table. There is also a language field to enable the language of the documentation to be set. -
FIG. 8 illustrates the external form table. This table defines the external form for attributes. The table identifies the attribute and the attribute version and gives an identifier for the external form to go with the actual form name. The external form defines the data syntax transformation. For example it can define a command line interface (CLI) string for the attribute for use by a CLI module in an embedded system in a device. -
FIGS. 9 a, 9 b and 9 c illustrate selector tables to provide drop down menus to allow a user to select parameters. Selector names are links from other tables to define the appearance and utility of a user interface. -
FIG. 9 a illustrates a selector table that gives the name of a selector and an identifier for the selector element. The user interface display order and label is contained within the selector table together with a value that is represented. There is also a unique pointer to the documentation for the element. A selector element represents an individual entry in an enumeration in a selector. Each selector represents one entry from a possible list of entries. -
FIG. 9 b illustrates a configuration selector table. A configuration selector represents an enumeration of values that can be set for a configuration command. -
FIG. 9 c illustrates the software version selector table. This table holds a unique identifier for each software version and identifies a selector parent and selector elements. -
FIG. 10 illustrates a configuration data table. This data is not part of the metadata and it stores configuration data that comprises instances of attributes that belong to a device configuration or a profile configuration. Each configuration is given a unique ID and each configuration value is given a version number (VersionIx). The parameter InterfaceIx identifies which interface this attribute is associated with. The parameter ListIx enables more than one value for attributes. The attribute is identified using the parameter ConfigAttributeOID. The value is assigned as FieldValue. The parameter IsPartOfQuickPage indicates whether this configuration instance is an attribute that can be modified by a user to generate a profiled device configuration. The attribute meta data is used to form part of a display termed “a QuickPage”. A QuickPage enables value (configuration parameters) to be input by modifying default values to complete a profiled device configuration. The QuickPage comprises a user interface to allow a user to enter the values for attributes. If the configuration ID indicates from the configuration information table (FIG. 6 ) that the configuration is a profile, then this flag indicates that the attribute is part of a “profiles QuickPage” definition and the FieldValue is the default value to be used when creating a device based on the profile. The value can however be changed by a user using the QuickPage. If the configuration ID identifies a profile device then this field indicates that the FieldValue contains the final value to be used for the attribute for that device. - The use of these data tables as a common set of configuration and management data will now be described.
-
FIG. 11 is a schematic diagram of a development system for the development and management of configuration data and management data for devices. Adevelopment server 1 stores the data tables described hereinabove in adatabase 2 under the control of adatabase manager 3. The table that are stored in the development system are the metadata tables since no specific configuration instance data is generated. The generation of specific configuration instances is performed in the device manager and thus in the development system the configuration information table ofFIG. 6 and the configuration data table ofFIG. 10 are not stored in thedatabase 2. A user'smodule 4 provides a gateway to the database for users and controls the type and level of access to the dataA web server 5 is provided to use server side scripting such as active server page (ASP)code 6 or Java server page (JSP) code to provide a web interface to certain users. Theweb server 5 uses the ASP to generate web pages using data from thedatabase 2. The data comprises the configuration data giving the values for attributes and the meta data defining the way the configuration data should be displayed. Thedevelopment server 1 also includes aproduct release builder 7 for building a software product for release.Developers code 8 and code stubs 9 are also provided for building of binary code included in the product by theproduct release builder 7. Thus theproduct release builder 7 outputs adevice management product 10. Adocumentation application 11 is provided for the generation of documentation for a device using the documentation included in the meta data stored in thedatabase 2. - A developer's
computer 20 in this embodiment is shown separately to thedevelopment server 1. The functionality can however be incorporated within thedevelopment server 1. The developer'scomputer 20 includes adevelopment application 21 which can comprise a Java application running on a Java Virtual Machine. The development application includes acode generator 22 to allow a developer to generate code to provide functionality required of a device. Acode stub generator 23 is also provided for the automatic generation of code stubs 9 for management purposes. Theuser interface 24 is also provided to allow the developer to interface to the application. Thedevelopment application 21 thus enables the developer to generate developer'scode 8 and code stubs 9. Thedevelopment application 21 interfaces via the user'smodule 4 to thedatabase manager 3 to gain access to thedatabase 2 to thereby operate on the data structure as described hereinabove. - The administrator's
computer 30 is illustrated in this embodiment as being separate to thedevelopment server 1. It can however be incorporated within thedevelopment server 1. Within the administrator's computer 30 adevelopment application 31 is operated by the administrator to enable the administrator to access the database via the user'smodule 4 anddatabase manager 3. Also thedevelopment application 31 controls theproduct release builder 7 to control the release of thedevice management product 10. - Other users of the system can gain access to the
database 2 using thecomputer 40 hosting aweb browser 41 to gain access via theweb server 5, the user'smodule 4 and thedatabase manager 3. - Thus the development system illustrated in
FIG. 4 can be used by software developers using the developer'scomputer 20 to develop code for implementation on devices. - Also an administrator can control the information being entered into the
database 2 to provide a management function to manage the configuration and management data contained within thedatabase 2 and to control the release of adevice management product 10. Other persons can gain access to thedatabase 2 to contribute to the development of the data in the database. For example, a documentor can use thecomputer 40 in order to access thedatabase 2 in order to add information into the documentation table as illustrated inFIG. 7 . The access provided to the documentor can be controlled by the user'smodule 4. - A translator can gain access to the documentation in the documentation table as illustrated in
FIG. 7 in order to input translations of documentation where necessary. Once again the functionality made available to the translator can be controlled by the user'smodule 4. - The steps performed during the development of a device will now described with reference to the flow diagram of
FIG. 12 . - Initially market research is carried out in order to determine product requirements (step S1). This results in a product definition (step S2) and a functional specification is drawn up (step S3). Following this hardware and software is designed to provide the functions (step S4 and S5). These steps can be carried out iteratively to arrive at the necessary hardware and software to perform the functions. During the design of the software, a developer can use a developer's application to access the
database 2. The developer enters data describing hardware and software (step S7). - This can be achieved by selecting a previous hardware model in the database 2 (step S7 a) and selecting a previous software model (step S7 b) meta data for the previous model is copied and a new entry made in the
database 2. The data can then be modified by the developer to modify the entries in the database to specify new hardware or software characteristics (step S7 c). Thus in step S8 data is entered into the database. Code stubs to provide the management functions can then be automatically generated (step S9) and under the control of the administrator using the administrator'scomputer 30, the developer'scode 8 and the code stubs 9 can be taken in by theproduct release builder 7 to build a management device product 10 (step S10). The product includes: - a. an installation application for installing the code onto a network management system,
- b. configuration data and meta data for a set of products to be managed by the network management system, and
- c. binary code for the devices to be managed (performed by combining the developer's
code 8 and the code stubs 9), which includes metadata for the management and configuration of the device. - The software product is thus the code required for a new software release for a device and it includes meta data for the configuration and management of the device by a network (device) manager.
- The network management code is a standard code that utilises the metadata for managing and configuring devices and determined by the software release. The network management code can thus be provided separately or combined with the software release product for a device to allow the management and configuration of the device over a network.
-
FIG. 13 is a flow diagram illustrating the process of managing and developing the configuration and management data in thedatabase 2. In step S20 a user uses thecomputer 40 to access theweb server 5 and logs in. The user'smodule 4 determines the role to be performed by the user (step S21). If a user is a documentor, the user can access undocumented features that are presented as a web page (step S22). The user is thus able to enter documentation for a particular features or characteristic so the software or hardware. If changes are made in the database (step S23), the database is updated in step S24 and the user can then log out in step S25. - If it is determined by the user's
module 4 that the user is a reviewer, they are presented with a web page of unreviewed features (step S26) the reviewer can thus review the features and make any changes they feel its necessary. If the user'smodule 4 determines the user is a translator, untranslated features are presented to the user as a web page (step S27). The translator can thus enter translations as necessary. - It is thus apparent to the skilled person in the art that to arrive at the development process a common database is used by the developers and managers in order to provide configuration and management data for the devices. When the development process is complete, an administrator can cause the
product release builder 7 to generate a management device product for the management of a set of devices. Adevice management product 10 can then be installed in a device management system to manage networked devices. -
FIG. 14 is a schematic diagram of a network device management system in accordance with an embodiment of the present invention. When thedevice management product 10 is stored in a computer system, thedevice manager 50 illustrated inFIG. 14 is generated. Thedevice manager 50 is connected over anetwork 60 tonetworked devices database 51 storing a copy of the data stored in thedatabase 2 within thedevelopment system 1. The metadata tables are copied and also configuration instance tables (FIGS. 6 and 10 ) are set up to store configuration instances for devices. Adatabase manager 52 controls access to thedatabase 51. Adevice code store 53 stores binary code for each of thedevices network 60 to thedevices device configurator 54 can download the code stored in thedevice code store 53 to thedevices device configurator 54 can also access thedatabase 51 via thedatabase manager 52 in order to download a copy of configuration and management data to thenetwork devices devices databases device manager 50 respectively. - In this embodiment the
device configurator 54 acts as both the web server and web client since the protocol used for communication over thenetwork 60 to thedevices - The
device manager 50 also includes aconfiguration generator 55 for generating a complete set of configuration data i.e. the device configuration from a profile configuration. This enables the operator of thedevice manager 50 to configure multiple devices using a single profile. When a profile configuration is available, the user of thedevice manager 50 can use the configuration generator to select the profile and use it to generate a profiled device by entering parameters. This can be done by using a user interface termed a “Quick Page” to allow a user to enter the necessary parameters to distinguish the individual device. The Quick Page allows the default values of certain attributes in a profile configuration to be modified by the manager to provide the configuration comprising the profile device. The profile device configuration can then be downloaded to configure adevice device configurator 54. The manager can define new profile configurations by defining attributes which are part of the QuickPage. -
FIG. 15 schematically illustrates modules in the device to provide for local and central management of the device. - A
platform application 100 to be configured and managed is interfaced viaglue interprocess communication module 104 for communication with aportable communication module 105. Aportable communication module 105 interfaces to BSD (Berkeley Distribution System) sockets. Within the device the communication protocol stack comprises Internet Protocol (IP) 106, Transmission Control Protocol (TCP) 107, and Unigram Data Protocol (UDP) 108 and aserial port 109 is provided to interface to theBSD sockets 110. Theportable module 105 is the code that is common to all devices. Within the module 105 aweb server 111, aTELNET server 112 and aserial interface 113 are provided. The device can communicate via HTTP using aVAMP engine 114. It can also communicate using the traditionalcommand line interface 115 via theTELNET server 112 orserial interface 113. At the heart of themodule 115 is amanagement request broker 116 that contains configuration data and logic and meta data for the configuration and management of the device. Aconfiguration instrumentation broker 119 is provided in conjunction with theconfiguration glue 111 for communication to theplatform application software 100. A Simple Network Management Protocol (SNMP)instrumentation broker 120 is provided in conjunction with theglue 102 for communication of instructions to or from theplatform application software 100. TheSNMP instrumentation broker 120 is provided to allow integration with SNMP agents running in the device. Anevent instrumentation broker 121 is provided in conjunction withevent glue 103 to communicate events from theapplication software 100 into the embedded framework event management system. - An
event system 122 monitors events and aperformance monitor 123 monitors performance statistics. This enable the provision of event and statistic management information via theVAMP engine 114 in a management interface as a web page. A simple mail transfer protocol (SMTP)client 124 is provided to enable e-mail communication with the device. - Embedded
web data 125 stores web information for the construction of web page interfaces as an interface to the device. Ascripting engine 126 provides for scripting and a scheduler 127 schedules certain actions under the control oftimer services 128. -
FIG. 16 illustrates the operation of the device acting as a web server to display management information in the form of a web page for a feature x. - The
HTTP server 111 receives an HTTP get request for the web page for management information on feature x via the TCP/IP stack computer 170.Computer 170 comprises can comprise any web enabled computer. - The request is passed on to a
VAMP engine 114 to provide the management functionality. Embeddedweb information 125 is used by theVAMP engine 114 to construct the hypertext transfer mark up language (HTML) i.e. the web page to be returned. TheVAMP engine 114 also requests information from themanagement request broker 116. The management request broker returns meta data which is used by theVAMP engine 114 to construct the web page. Thus the meta data stored by themanagement request broker 116 controls the user interface by configuring the form of the web page. The meta data can control the order in which items appear, the text to appear after items, and the language used. Themanagement request broker 116 also returns configuration data which comprises the actual values for parameters. The web page constructed by theVAMP engine 114 is then returned to thecomputer 170 for display as a web page. - In this embodiment illustrated in
FIG. 16 ,management request broker 116 is able to respond to the request for management information from theVAMP engine 114 using configuration data stored within themanagement request broker 116. -
FIG. 17 illustrates an example where the management information required in the HTTP request from thecomputer 170 is not all contained within the configuration data within themanagement request broker 116. For example, the information required could include status data. In this embodiment theHTTP server 111 receives the request and passes toVAMP engine 114. The VAMP engine uses the meta data from themanagement request broker 116 to determine whether the information requested is present within the configuration data. If, using the meta data, it does identify that the attributes requested are present in the configuration data but must be obtained from the hardware platform on which thecode module 1 15 is being implemented, a callback is invoked by themanagement request broker 116 through the configuration instrumentation broker 117, theinterprocess communication 104 and theconfiguration glue 111 to theplatform application software 100. The requested attribute information is returned to themanagement request programme 116 and passed on to theVAMP engine 114 for inclusion within the web page as described with reference toFIG. 16 . - Thus in the embodiments of
FIG. 16 andFIG. 17 , a web page interface is provided for management information thus allowing local or remote access to management information on the network device. - In the embodiments illustrated in
FIGS. 16 and 17 , the scripting engine 136 stores code for the dynamic generation of web pages. However, it is possible also for static embedded web pages to be used. -
FIG. 18 is a diagram of the operation of the device when performing an auto provisioning function. When the device is in an initial factory configured state, the device executes a script within the scripting engine 136 which causes theVAMP engine 114 to controlHTTP server 111 to generate and an HTTP get request to theVAMP server 54 in thedevice manager 50 for configuration and management information. The requested information is returned by theVAMP server 54 in thedevice manager 50 and is received at theVAMP engine 114 via theHTTP server 111. TheVAMP engine 114 then stores the retrieved configuration and management data within themanagement request broker 116. It can also store downloaded web page data in the embeddedweb store 125. Thus in this way the device can be initially configured automatically. -
FIG. 19 is a diagram illustrating the modification of parameters under the control of the device configurator acting as aVAMP client 54 within thedevice manager 50. The VAMP client sends an HTTP request with attributes that are received in theVAMP engine 114 viaHTTP server 111. Themanagement request broker 116 invokes call backs into theapplication software 100 in order to attempt to modify an attribute in theplatform application software 100. A response is then returned to the VAMP client 74 within thedevice manager 50 via theVAMP engine 114. The state of the object is then stored by themanagement request broker 116. Thus the management data is only updated if the request was successful e.g. if the request was to disable a circuit but the circuit was busy, the device will not action the request and the management data must reflect this. - The
VAMP client 54 within thedevice manager 50 can also retrieve configuration data from the management request broker without performing the modification of the attributes in a similar manner to that described with reference toFIG. 19 except that no callback is invoked into theplatform application software 100. Instead the configuration data is used to return the requested attributes as a HTTP response to theVAMP client 54 within thedevice manager 50. -
FIG. 20 illustrates the process of implementing or registering a feature in the device. Themanagement request broker 116 includes meta data and configuration data for the feature. Theconfiguration instrumentation broker 119 initiates the callbacks for the registration process in order to pass the necessary attributes. Thus using callbacks, the implementation of feature X can be configured in the device. -
FIG. 21 illustrates the provision of a command line interface capability within the device to allow the fetching of attributes. Acommand line interface 115 is provided to enable a TELNET session to be used for communication with the device. In this embodiment acomputer 170 establishes a TELNET session over the TCP/IP stack TELNET server 112. TheTELNET server 112 passes on the command line input to thecommand line interface 115. Thecommand line interface 115 interacts with themanagement request broker 116 in order to determine if necessary responses can be provided from the configuration data using the meta data. Thecommand line interface 115 then generates a text response that is passed by theTELNET server 112 as a response in the TELNET session to thecomputer 170. -
FIG. 22 illustrates the use of thecommand line interface 115 to modify attributes in theplatform application software 100. A TELNET session is established by acomputer 170 with theTELNET server 112 over the TCP/IP stack command line interface 116 which uses the meta data to determine whether the response can be fulfilled by the configuration data. In this case it could not and a callback is invoked by themanagement request broker 116 through theconfiguration instrumentation broker 119 to theplatform application software 100 in order to pass on the attribute modification. The response is received to confirm the modification and thecommand line interface 115 responds with an appropriate response that is passed by theTELNET server 112 to thecomputer 170. -
FIG. 23 illustrates the use of the command line interface for retrieving management information i.e. on-line help for users of the command line interface. A user types in a component name e.g. set feature X, but cannot remember the attribute. A request for information on feature X is sent as a command line instruction over a TELNET session on thecomputer 170 via theTELNET server 112 to thecommand line interface 115. Thecommand line interface 115 retrieves the necessary information from meta data within themanagement request broker 116 in order to return the information. In this case the attributes for a component are the returned information. A user can select one to complete the command. -
FIG. 24 is a schematic diagram illustrating the flexibility of thecode module 115. This can be installed in anynetwork device 150 to provide the management and configuration function. The management and configuration function can be provided by connecting acomputer 170 using the web browser over thenetwork connection 160 to interface to thecode module 105. Thecode module 105 can either be loaded into thedevice 150 or can be provided on a separate physical device e.g. an internal card, or an external module. - This enables the provision of a web interface for existing products, providing a management and configuration function that can easily be accessed as web page data.
- Although the present invention has been described hereinabove with reference to specific embodiments, it will be apparent to a skilled person in the art that modifications lie within the spirit and scope of the present invention.
- The present invention is application to any device that can be managed centrally such as a networked device.
- The management data can comprise any function or parameters that require monitoring or control. The management parameters can include statistics, notifications from the devices, device performance parameters, and/or device status parameters.
Claims (99)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/136,639 US20090019422A1 (en) | 2001-07-27 | 2008-06-10 | Device configuration and management development system |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0118377A GB2380004A (en) | 2001-07-27 | 2001-07-27 | A configuration and management development system for a netwok of devices |
GB0118377.1 | 2001-07-27 | ||
PCT/GB2002/003338 WO2003012635A2 (en) | 2001-07-27 | 2002-07-23 | A device configuration and management development system |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/136,639 Continuation US20090019422A1 (en) | 2001-07-27 | 2008-06-10 | Device configuration and management development system |
Publications (2)
Publication Number | Publication Date |
---|---|
US20060101375A1 true US20060101375A1 (en) | 2006-05-11 |
US7467372B2 US7467372B2 (en) | 2008-12-16 |
Family
ID=9919333
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/484,871 Expired - Fee Related US7467372B2 (en) | 2001-07-27 | 2002-07-23 | Device configuration and management development system |
US12/136,639 Abandoned US20090019422A1 (en) | 2001-07-27 | 2008-06-10 | Device configuration and management development system |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/136,639 Abandoned US20090019422A1 (en) | 2001-07-27 | 2008-06-10 | Device configuration and management development system |
Country Status (5)
Country | Link |
---|---|
US (2) | US7467372B2 (en) |
EP (1) | EP1442366A2 (en) |
AU (1) | AU2002317375A1 (en) |
GB (1) | GB2380004A (en) |
WO (1) | WO2003012635A2 (en) |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040059813A1 (en) * | 2002-09-19 | 2004-03-25 | Bolder Ron Scott | Methods and apparatus for configuration change management in communications networks |
US20050256973A1 (en) * | 2004-04-21 | 2005-11-17 | Microsoft Corporation | Method, system and apparatus for managing computer identity |
US20060288016A1 (en) * | 2005-06-16 | 2006-12-21 | Cisco Technology, Inc. | System and method for coordinated network configuration |
US20090063563A1 (en) * | 2007-08-31 | 2009-03-05 | International Business Machines Corporation | Common configuration framework for applications to configure database objects and resources |
US7518986B1 (en) | 2005-11-16 | 2009-04-14 | Juniper Networks, Inc. | Push-based hierarchical state propagation within a multi-chassis network device |
WO2009070866A1 (en) * | 2007-12-06 | 2009-06-11 | Ati Technologies Ulc | Method and apparatus utilizing profiles to reduce software complexity |
US7552262B1 (en) | 2005-08-31 | 2009-06-23 | Juniper Networks, Inc. | Integration of an operative standalone router into a multi-chassis router |
US7606241B1 (en) * | 2005-08-12 | 2009-10-20 | Juniper Networks, Inc. | Extending standalone router syntax to multi-chassis routers |
US7747999B1 (en) | 2005-09-26 | 2010-06-29 | Juniper Networks, Inc. | Software installation in a multi-chassis network device |
US7804769B1 (en) | 2005-12-01 | 2010-09-28 | Juniper Networks, Inc. | Non-stop forwarding in a multi-chassis router |
KR101049848B1 (en) * | 2007-02-09 | 2011-07-15 | 후지쯔 가부시끼가이샤 | Automatic output-value adjustment method for reader/writer |
WO2011103100A2 (en) * | 2010-02-22 | 2011-08-25 | Microsoft Corporation | Incrementally managing distributed configuration data |
US8082364B1 (en) | 2002-06-10 | 2011-12-20 | Juniper Networks, Inc. | Managing state information in a computing environment |
US8135857B1 (en) | 2005-09-26 | 2012-03-13 | Juniper Networks, Inc. | Centralized configuration of a multi-chassis router |
US8799511B1 (en) | 2003-10-03 | 2014-08-05 | Juniper Networks, Inc. | Synchronizing state information between control units |
US20150019199A1 (en) * | 2013-07-09 | 2015-01-15 | Allied Telesis Holdings Kabushiki Kaisha | Command line interface |
US20150172105A1 (en) * | 2013-12-12 | 2015-06-18 | Dell Products L.P. | Methods and systems for deploying network configuration information for multiple information handling systems |
US20170031881A1 (en) * | 2015-07-31 | 2017-02-02 | Cheng Shiu University | Method for creating web program and corresponding table interface according to column comment |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10361802B1 (en) | 1999-02-01 | 2019-07-23 | Blanding Hovenweep, Llc | Adaptive pattern recognition based control system and method |
US7966078B2 (en) | 1999-02-01 | 2011-06-21 | Steven Hoffberg | Network media appliance system and method |
GB2380004A (en) * | 2001-07-27 | 2003-03-26 | Virtual Access Ireland Ltd | A configuration and management development system for a netwok of devices |
US7890303B2 (en) * | 2004-02-03 | 2011-02-15 | Zuken Inc. | Parameter managing method, design parameter managing system, program and computer readable recording medium |
US8161402B1 (en) * | 2004-03-24 | 2012-04-17 | The Mathworks, Inc. | Methods and apparatus for graphical test and measurement |
US20050229096A1 (en) * | 2004-04-09 | 2005-10-13 | Alcatel | Custom attributes and operator notes in an object information window |
KR20060059782A (en) * | 2004-11-29 | 2006-06-02 | 엘지전자 주식회사 | Method for supporting scalable progressive downloading of video signal |
US8554883B2 (en) * | 2008-08-06 | 2013-10-08 | Cisco Technology, Inc. | Apparatus and method for sharing a generic configuration across a group of network devices |
US9524506B2 (en) * | 2011-10-21 | 2016-12-20 | Bigmachines, Inc. | Methods and apparatus for maintaining business rules in a configuration system |
US9172612B2 (en) | 2009-02-12 | 2015-10-27 | Hewlett-Packard Development Company, L.P. | Network device configuration management by physical location |
US20100281429A1 (en) * | 2009-04-30 | 2010-11-04 | Bigmachines, Inc. | Methods and apparatus for configuring a product using an array of configuration sets |
US8392614B2 (en) | 2009-07-27 | 2013-03-05 | Sandisk Il Ltd. | Device identifier selection |
US8312088B2 (en) * | 2009-07-27 | 2012-11-13 | Sandisk Il Ltd. | Device identifier selection |
FR2952775B1 (en) * | 2009-11-19 | 2012-01-13 | Infovista Sa | PERFORMANCE MEASURING SERVER AND QUALITY OF SERVICE MONITORING USING A CONTROL LINE INTERFACE. |
US8375123B2 (en) | 2010-05-04 | 2013-02-12 | International Business Machines Corporation | Remote session management |
US9544193B2 (en) | 2013-10-02 | 2017-01-10 | International Business Machines Corporation | Synchronizing configurations amongst multiple devices |
GB201419021D0 (en) * | 2014-10-24 | 2014-12-10 | Goodmark Medical International Ltd | System and method for generating patient test data processing code |
Citations (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3557598A (en) * | 1969-03-04 | 1971-01-26 | Kaiser Aluminium Chem Corp | Electromagnetic feeding device |
US3911706A (en) * | 1973-04-09 | 1975-10-14 | Murray W Davis | Method and apparatus for forming metal |
US5339435A (en) * | 1991-02-28 | 1994-08-16 | Hewlett-Packard Company | Heterogenous software configuration management apparatus |
US5442782A (en) * | 1993-08-13 | 1995-08-15 | Peoplesoft, Inc. | Providing information from a multilingual database of language-independent and language-dependent items |
US5515524A (en) * | 1993-03-29 | 1996-05-07 | Trilogy Development Group | Method and apparatus for configuring systems |
US5715461A (en) * | 1994-05-16 | 1998-02-03 | Fujitsu Limited | System for managing software development in distributed development environment |
US5761673A (en) * | 1996-01-31 | 1998-06-02 | Oracle Corporation | Method and apparatus for generating dynamic web pages by invoking a predefined procedural package stored in a database |
US5898835A (en) * | 1996-08-16 | 1999-04-27 | Electronic Data Systems Corporation | System and method for remotely executing a command |
US5956487A (en) * | 1996-10-25 | 1999-09-21 | Hewlett-Packard Company | Embedding web access mechanism in an appliance for user interface functions including a web server and web browser |
US5956513A (en) * | 1997-08-07 | 1999-09-21 | Mci Communications Corporation | System and method for automated software build control |
US5960439A (en) * | 1995-12-22 | 1999-09-28 | Intel Corporation | Defining a schema for a database representing a model of a computer network |
US5996010A (en) * | 1996-08-29 | 1999-11-30 | Nortel Networks Corporation | Method of performing a network management transaction using a web-capable agent |
US5999941A (en) * | 1997-11-25 | 1999-12-07 | Micron Electronics, Inc. | Database access using active server pages |
US6003077A (en) * | 1996-09-16 | 1999-12-14 | Integrated Systems, Inc. | Computer network system and method using domain name system to locate MIB module specification and web browser for managing SNMP agents |
US6002854A (en) * | 1993-03-29 | 1999-12-14 | Trilogy Developmetn Group, Inc. | Method and apparatus for configuring systems |
US6006242A (en) * | 1996-04-05 | 1999-12-21 | Bankers Systems, Inc. | Apparatus and method for dynamically creating a document |
US6008805A (en) * | 1996-07-19 | 1999-12-28 | Cisco Technology, Inc. | Method and apparatus for providing multiple management interfaces to a network device |
US6012152A (en) * | 1996-11-27 | 2000-01-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Software fault management system |
US6044217A (en) * | 1997-03-27 | 2000-03-28 | International Business Machines Corporation | Hierarchical metadata store for an integrated development environment |
US6058400A (en) * | 1998-04-28 | 2000-05-02 | Sun Microsystems, Inc. | Highly available cluster coherent filesystem |
US6115547A (en) * | 1993-03-29 | 2000-09-05 | Trilogy Development Group, Inc. | Flash configuration cache |
US6151023A (en) * | 1997-05-13 | 2000-11-21 | Micron Electronics, Inc. | Display of system information |
US6237135B1 (en) * | 1998-06-18 | 2001-05-22 | Borland Software Corporation | Development system with visual design tools for creating and maintaining Java Beans components |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE951407C (en) | 1952-11-08 | 1956-10-25 | Metallspritz Und Schweisstechn | Method and device for the forward movement of wires, rods or pipes of any material, in particular in metal spray guns |
FR1543492A (en) | 1967-09-15 | 1968-10-25 | Somenor Soc Metallurg Du Nord | Electromagnetic device for tensioning, braking or driving metallurgical products |
DE1959873A1 (en) | 1968-11-28 | 1970-06-04 | Linnman Sven Nils Johannes | Device for transporting wire or powder |
FR2669446A1 (en) * | 1990-11-16 | 1992-05-22 | Cit Alcatel | METHOD FOR DEVELOPING SOFTWARE. |
US5557775A (en) * | 1994-02-23 | 1996-09-17 | International Business Machines Corporation | Expert system for designing computer networks |
DE69631278T2 (en) * | 1995-10-23 | 2004-11-18 | Interuniversitair Micro-Electronica Centrum Vzw | Design system and method for the combined design of hardware and software |
EP0983547A2 (en) * | 1997-05-21 | 2000-03-08 | BRITISH TELECOMMUNICATIONS public limited company | Operational analysis of software-controlled systems |
CA2263571A1 (en) * | 1997-06-18 | 1998-12-23 | Andrew Albert Zander | System development tool for distributed object oriented computing |
US6061721A (en) * | 1997-10-06 | 2000-05-09 | Sun Microsystems, Inc. | Bean-based management system |
US6349332B2 (en) * | 1998-07-29 | 2002-02-19 | Nortel Networks Limited | Mechanism for integration of management functionality in communications networks |
GB2344963A (en) * | 1998-12-17 | 2000-06-21 | Northern Telecom Ltd | Object-oriented network management system |
GB2380004A (en) * | 2001-07-27 | 2003-03-26 | Virtual Access Ireland Ltd | A configuration and management development system for a netwok of devices |
-
2001
- 2001-07-27 GB GB0118377A patent/GB2380004A/en not_active Withdrawn
-
2002
- 2002-07-23 US US10/484,871 patent/US7467372B2/en not_active Expired - Fee Related
- 2002-07-23 WO PCT/GB2002/003338 patent/WO2003012635A2/en not_active Application Discontinuation
- 2002-07-23 AU AU2002317375A patent/AU2002317375A1/en not_active Abandoned
- 2002-07-23 EP EP02745662A patent/EP1442366A2/en not_active Withdrawn
-
2008
- 2008-06-10 US US12/136,639 patent/US20090019422A1/en not_active Abandoned
Patent Citations (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3557598A (en) * | 1969-03-04 | 1971-01-26 | Kaiser Aluminium Chem Corp | Electromagnetic feeding device |
US3911706A (en) * | 1973-04-09 | 1975-10-14 | Murray W Davis | Method and apparatus for forming metal |
US5339435A (en) * | 1991-02-28 | 1994-08-16 | Hewlett-Packard Company | Heterogenous software configuration management apparatus |
US5515524A (en) * | 1993-03-29 | 1996-05-07 | Trilogy Development Group | Method and apparatus for configuring systems |
US6115547A (en) * | 1993-03-29 | 2000-09-05 | Trilogy Development Group, Inc. | Flash configuration cache |
US6002854A (en) * | 1993-03-29 | 1999-12-14 | Trilogy Developmetn Group, Inc. | Method and apparatus for configuring systems |
US5442782A (en) * | 1993-08-13 | 1995-08-15 | Peoplesoft, Inc. | Providing information from a multilingual database of language-independent and language-dependent items |
US5715461A (en) * | 1994-05-16 | 1998-02-03 | Fujitsu Limited | System for managing software development in distributed development environment |
US5960439A (en) * | 1995-12-22 | 1999-09-28 | Intel Corporation | Defining a schema for a database representing a model of a computer network |
US5761673A (en) * | 1996-01-31 | 1998-06-02 | Oracle Corporation | Method and apparatus for generating dynamic web pages by invoking a predefined procedural package stored in a database |
US6006242A (en) * | 1996-04-05 | 1999-12-21 | Bankers Systems, Inc. | Apparatus and method for dynamically creating a document |
US6008805A (en) * | 1996-07-19 | 1999-12-28 | Cisco Technology, Inc. | Method and apparatus for providing multiple management interfaces to a network device |
US5898835A (en) * | 1996-08-16 | 1999-04-27 | Electronic Data Systems Corporation | System and method for remotely executing a command |
US5996010A (en) * | 1996-08-29 | 1999-11-30 | Nortel Networks Corporation | Method of performing a network management transaction using a web-capable agent |
US6003077A (en) * | 1996-09-16 | 1999-12-14 | Integrated Systems, Inc. | Computer network system and method using domain name system to locate MIB module specification and web browser for managing SNMP agents |
US5956487A (en) * | 1996-10-25 | 1999-09-21 | Hewlett-Packard Company | Embedding web access mechanism in an appliance for user interface functions including a web server and web browser |
US6012152A (en) * | 1996-11-27 | 2000-01-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Software fault management system |
US6044217A (en) * | 1997-03-27 | 2000-03-28 | International Business Machines Corporation | Hierarchical metadata store for an integrated development environment |
US6151023A (en) * | 1997-05-13 | 2000-11-21 | Micron Electronics, Inc. | Display of system information |
US5956513A (en) * | 1997-08-07 | 1999-09-21 | Mci Communications Corporation | System and method for automated software build control |
US5999941A (en) * | 1997-11-25 | 1999-12-07 | Micron Electronics, Inc. | Database access using active server pages |
US6058400A (en) * | 1998-04-28 | 2000-05-02 | Sun Microsystems, Inc. | Highly available cluster coherent filesystem |
US6237135B1 (en) * | 1998-06-18 | 2001-05-22 | Borland Software Corporation | Development system with visual design tools for creating and maintaining Java Beans components |
Cited By (37)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8082364B1 (en) | 2002-06-10 | 2011-12-20 | Juniper Networks, Inc. | Managing state information in a computing environment |
US20040059813A1 (en) * | 2002-09-19 | 2004-03-25 | Bolder Ron Scott | Methods and apparatus for configuration change management in communications networks |
US8799511B1 (en) | 2003-10-03 | 2014-08-05 | Juniper Networks, Inc. | Synchronizing state information between control units |
US20050256973A1 (en) * | 2004-04-21 | 2005-11-17 | Microsoft Corporation | Method, system and apparatus for managing computer identity |
US8554889B2 (en) * | 2004-04-21 | 2013-10-08 | Microsoft Corporation | Method, system and apparatus for managing computer identity |
US7685316B2 (en) * | 2005-06-16 | 2010-03-23 | Cisco Technology, Inc. | System and method for coordinated network configuration |
US20060288016A1 (en) * | 2005-06-16 | 2006-12-21 | Cisco Technology, Inc. | System and method for coordinated network configuration |
US8040902B1 (en) * | 2005-08-12 | 2011-10-18 | Juniper Networks, Inc. | Extending standalone router syntax to multi-chassis routers |
US7606241B1 (en) * | 2005-08-12 | 2009-10-20 | Juniper Networks, Inc. | Extending standalone router syntax to multi-chassis routers |
US7899930B1 (en) | 2005-08-31 | 2011-03-01 | Juniper Networks, Inc. | Integration of an operative standalone router into a multi-chassis router |
US7552262B1 (en) | 2005-08-31 | 2009-06-23 | Juniper Networks, Inc. | Integration of an operative standalone router into a multi-chassis router |
US8904380B1 (en) | 2005-09-26 | 2014-12-02 | Juniper Networks, Inc. | Software installation on a multi-chassis network device |
US7747999B1 (en) | 2005-09-26 | 2010-06-29 | Juniper Networks, Inc. | Software installation in a multi-chassis network device |
US8135857B1 (en) | 2005-09-26 | 2012-03-13 | Juniper Networks, Inc. | Centralized configuration of a multi-chassis router |
US8370831B1 (en) | 2005-09-26 | 2013-02-05 | Juniper Networks, Inc. | Software installation in a multi-chassis network device |
US7518986B1 (en) | 2005-11-16 | 2009-04-14 | Juniper Networks, Inc. | Push-based hierarchical state propagation within a multi-chassis network device |
US8149691B1 (en) | 2005-11-16 | 2012-04-03 | Juniper Networks, Inc. | Push-based hierarchical state propagation within a multi-chassis network device |
US8483048B2 (en) | 2005-12-01 | 2013-07-09 | Juniper Networks, Inc. | Non-stop forwarding in a multi-chassis router |
US20110013508A1 (en) * | 2005-12-01 | 2011-01-20 | Juniper Networks, Inc. | Non-stop forwarding in a multi-chassis router |
US7804769B1 (en) | 2005-12-01 | 2010-09-28 | Juniper Networks, Inc. | Non-stop forwarding in a multi-chassis router |
KR101049848B1 (en) * | 2007-02-09 | 2011-07-15 | 후지쯔 가부시끼가이샤 | Automatic output-value adjustment method for reader/writer |
US8549144B2 (en) | 2007-08-31 | 2013-10-01 | International Business Machines Corporation | Common configuration framework for applications to configure database objects and resources |
US20090063563A1 (en) * | 2007-08-31 | 2009-03-05 | International Business Machines Corporation | Common configuration framework for applications to configure database objects and resources |
KR101500636B1 (en) * | 2007-12-06 | 2015-03-09 | 에이티아이 테크놀로지스 유엘씨 | Method and apparatus utilizing profiles to reduce software complexity |
WO2009070866A1 (en) * | 2007-12-06 | 2009-06-11 | Ati Technologies Ulc | Method and apparatus utilizing profiles to reduce software complexity |
US20090150817A1 (en) * | 2007-12-06 | 2009-06-11 | Ati Technologies Ulc | Method and Apparatus Utilizing Profiles to Reduce Software Complexity |
US20110208841A1 (en) * | 2010-02-22 | 2011-08-25 | Microsoft Corporation | Incrementally managing distributed configuration data |
WO2011103100A3 (en) * | 2010-02-22 | 2011-11-17 | Microsoft Corporation | Incrementally managing distributed configuration data |
US8595334B2 (en) | 2010-02-22 | 2013-11-26 | Microsoft Corporation | Incrementally managing distributed configuration data |
US9755890B2 (en) | 2010-02-22 | 2017-09-05 | Microsoft Technology Licensing, Llc | Incrementally managing distributed configuration data |
US10587461B2 (en) | 2010-02-22 | 2020-03-10 | Microsoft Technology Licensing, Llc | Incrementally managing distributed configuration data |
WO2011103100A2 (en) * | 2010-02-22 | 2011-08-25 | Microsoft Corporation | Incrementally managing distributed configuration data |
US20150019199A1 (en) * | 2013-07-09 | 2015-01-15 | Allied Telesis Holdings Kabushiki Kaisha | Command line interface |
US11216293B2 (en) * | 2013-07-09 | 2022-01-04 | Allied Telesis Holdings Kabushiki Kaisha | Command line interface |
US20150172105A1 (en) * | 2013-12-12 | 2015-06-18 | Dell Products L.P. | Methods and systems for deploying network configuration information for multiple information handling systems |
US9148339B2 (en) * | 2013-12-12 | 2015-09-29 | Dell Products L.P. | Methods and systems for deploying network configuration information for multiple information handling systems |
US20170031881A1 (en) * | 2015-07-31 | 2017-02-02 | Cheng Shiu University | Method for creating web program and corresponding table interface according to column comment |
Also Published As
Publication number | Publication date |
---|---|
WO2003012635A3 (en) | 2004-05-06 |
EP1442366A2 (en) | 2004-08-04 |
US20090019422A1 (en) | 2009-01-15 |
GB0118377D0 (en) | 2001-09-19 |
AU2002317375A1 (en) | 2003-02-17 |
US7467372B2 (en) | 2008-12-16 |
GB2380004A (en) | 2003-03-26 |
WO2003012635A2 (en) | 2003-02-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7467372B2 (en) | Device configuration and management development system | |
US6356931B2 (en) | Method and system for remotely browsing objects | |
US7912935B2 (en) | Development and deployment of mobile and desktop applications within a flexible markup-based distributed architecture | |
US20030078949A1 (en) | Automatic generation of forms with input validation | |
US6851118B1 (en) | Remote object access | |
US20040205525A1 (en) | Automatic identification of form contents | |
EP0909057B1 (en) | Bean-based management system | |
CA2604108C (en) | System and method of representing data entities of standard device applications as built-in components | |
US7861243B2 (en) | Automatically deploying program units to a cluster of networked servers | |
US20030078960A1 (en) | Architecture and process for creating software applications for multiple domains | |
US20030163807A1 (en) | Weighted selection of target systems for distributed software installation | |
EP1457877A2 (en) | Architecture for distributed computing system and automated design, deployment, and management of distributed applications | |
EP1455484A2 (en) | Integrating design, deployment, and management phases for systems | |
US20060248121A1 (en) | System and method for supporting packaging, publishing and republishing of wireless component applications | |
US20040158575A1 (en) | Distributed computer platform with flexible configuration | |
US20120233330A1 (en) | Discovering and identifying manageable information technology resources | |
US20060235882A1 (en) | System and method for developing arbitrary and efficient mappings between complex message structures | |
US20060248467A1 (en) | Framework for declarative expression of data processing | |
US20030189585A1 (en) | Template-driven process system | |
US20020194263A1 (en) | Hierarchical constraint resolution for application properties, configuration, and behavior | |
US20030009433A1 (en) | Automatic identification of computer program attributes | |
US20080005305A1 (en) | Method and apparatus for providing a consolidated namespace to client applications in multi-tenant common information model (CIM) environments | |
US9049044B1 (en) | Method of management and distribution of device adapters for element management systems | |
US8171122B2 (en) | Visualization of web services distributed management (WSDM) resources | |
CA2543959C (en) | System and method for developing arbitrary and efficient mappings between complex message structures |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: VIRTUAL ACCESS TECHNOLOGY LIMITED, IRELAND Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LOUGHLIN, THOMAS;SLABY, JOHN;REEL/FRAME:015111/0640;SIGNING DATES FROM 20040819 TO 20040824 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20201216 |