Object attribute handler5878430Abstract A object oriented attribute handle for parsing and packing object attributes for communication thereof between virtual and physical devices in an object oriented programming environment. The handle comprising the steps of creating a plurality of attribute description files for each class of object instances and either parsing or packing instance attributes in accordance with a corresponding one of the plurality of attribute description files. The handle using a suite of routines to parse or pack instance attributes in accordance with the corresponding predefined attribute description file. Claims What we claim is: Description FIELD OF INVENTION
TABLE 1
______________________________________
Device Class Attributes
Attribute
ID Name Data Type
Description of Attribute
______________________________________
1 Revision UINT Revision of this object
______________________________________
Similarly, a device object may contain the following instance attributes indicated in table 2 below.
TABLE 2
______________________________________
Device Instance Attributes
Attribute
ID Name Data Type Description of Attribute
______________________________________
1 Vendor UINT Identification of each vendor
by number
2 Product Type
UINT Indication of general type of
product
3 Product Code
UINT Identifies a product among a
particular product type
4 Revision STRUCT of:
Major Rev. USINT Series Number
Minor Rev. USINT Revision Number
5 Status WORD
6 Serial.sub.-- Number
UDINT Product Serial No.
7 Product name
STRUCT of:
Product Name
Length USINT
Contents STRING›32!
______________________________________
In general, each class attribute and instance attribute is defined by an attribute ID, attribute name, attribute data type and of course the attribute data which is represented in a format defined by the data type. The abbreviations found in the column labeled data type generally follow IEC 1131-3 entitled Industrial Control and Systems Programmable Languages published by NEMA, Washington, D.C. wherein the term UINT refers to an unsigned integer comprising 16 bits and the term USINT refers to unsigned short integer comprising 8 bits. Similarly, the declaration STRUCT specifies that data elements of that type contain sub-elements of specified types which can be accessed by the specified attribute names. Attributes may be further defined by the services they support. For example, as discussed below, when a particular class or instance supports any variation of the Get.sub.-- Attributes.sub.-- All or Set.sub.-- Attributes.sub.-- All services the attributes will further be defined by a Get.sub.-- Attributes.sub.-- All position 370 as shown in FIG. 3. Position 370 is used by the table driven routines when packing and parsing serialized data that is being transmitted or received respectively. Corresponding to object instance 310, ADF 320 comprises several pieces of information including attribute names 330, data types 340, radix information 350, size information 360, Get.sub.-- Attributes.sub.-- All positions 370 and attribute numbers 380. Attribute information 330-370 is generic to any particular instance 310 contained within class 300 and thus is reusable for all instances of that class. Attribute name 330 is an alpha-numeric string and in the case where the instance is a device instance the attribute names may be any of those listed in table 1 and 2 above. In addition to the description above data type 340 also indicates the number of bits the attribute data will comprise and the radix 350 indicates the base, such as hex, upon which to interpret the bits. Size 360 indicates the number of bytes the attribute comprises and Get.sub.-- Attributes.sub.-- All position 370 indicates the location within a serialized string a particular attribute resides when a response is received to the Get.sub.-- Attributes.sub.-- All service described below. Additionally, attribute numbers 380 are part of the ADF information and are generated when the ADF is loaded into memory for use by the parsing and packing routines in conjunction with the services described below. Table 3 below sets forth a plurality of services that may be supported by a class of object instances. For the purposes of this specification the services 400-700 depicted herein are described with reference to the "Device" class of object instances for exemplary purposes only, however, the invention is not limited to such. Importantly, some classes may not support all services. With reference to table 3, the four services set forth are all related to transmitting or receiving instance attributes between a workstation and a module. For example each of the services shown may be requested by an operator located at workstation 60 to set or get attributes associated with the physical automation controller module 20.
TABLE 3
______________________________________
Services Supported by Certain Class Objects
Service
Code Service Name Description of Service
______________________________________
01.sub.hex
Get.sub.-- Attributes.sub.-- All
Returns contents of all attributes in an
object
02.sub.hex
Set.sub.-- Attributes.sub.-- All
Sets contents of all attributes in an
object
03.sub.hex
Get.sub.-- Attributes.sub.-- List
Returns contents of specified attributes
in an object
04.sub.hex
Set.sub.-- Attributes.sub.-- List
Sets contents of specified attributes in
an object
______________________________________
With reference to FIG. 4 there is shown a flow diagram of the Get.sub.-- Attributes.sub.-- List service 400 identified in table 3 above. An operator or requester of service 400 who may be located at workstation 60, for example, inputs the service code for the service requested, the internal object identifier (IOI) of the instance to be acted upon and in the case where the service is the Get.sub.-- Attributes.sub.-- List service 400 the requester also inputs an attribute list 410 which comprises an attribute.sub.-- count and attribute.sub.-- list as shown in table 4 below.
TABLE 4
______________________________________
Service Request Parameters for Get.sub.-- Attributes.sub.-- List
Name Data Type
Description of Parameter
______________________________________
attribute.sub.-- count
UINT Number of attribute numbers in the attribute
list
attribute.sub.-- list
Array of List of the attribute numbers of the attributes
UINT's to get from the class or object
______________________________________
In response, an I/O service request containing the service code, IOI and parameters identified in table 4 are loaded from the workstation's 60 memory into a local communication module 465 which transmits the service request over link 70 to module 40. In turn, module 40 communicates the request over the backplane of chassis 30 to the automation controller module 20 which produces a response to the request. The serialized response is then communicated in the reverse order back to the local communication module 465. As shown in tables 5 and 6 the serialized response comprises an attribute.sub.-- count and data.sub.-- of.sub.-- attribute structure comprising the attribute.sub.-- numbers, attribute.sub.-- values and status information (not shown in the table) for the list of attributes requested. Thereafter, the ADF 420 corresponding to the IOI specified class and the structure 430 corresponding to the IOI specified instance are loaded into the memory of workstation 60. Structure 430 is a pre-defined space in the memory of the workstation where the instance attributes are stored. Subsequently, table driven routines parse the serialized data according to the information contained within the ADF and output the parsed attributes to the structure 430
TABLE 5
______________________________________
Response Parameters for Get.sub.-- Attributes.sub.-- List
Name Data Type
Description of Parameter
______________________________________
attribute.sub.-- count
UINT Number of values being returned
data.sub.-- of.sub.-- attribute
STRUCT
______________________________________
With reference to FIG. 5 there is shown a flow diagram of a Get.sub.-- Attributes.sub.-- All service 500. In general, the Get.sub.-- Attributes.sub.-- All service 500 returns the contents of all the gettable attributes of an IOI specified instance from controller 20. Since all of the instance attributes are being requested the service request parameters only require the service code and the IOI of the target instance. Similar to service 400, the service request parameters are loaded from the workstation's 60 memory to the local communication module 565 which transmits the request over link 70 to module 40. Module 40 then communicates the service request over the backplane of chassis 30 to automation controller 20. The automation controller 20 processes the request and responds with a serialized response which is communicated in the reverse order back to the workstation's 60 local communication module 565. The serialized reply comprises the attribute.sub.-- data structure as shown in table 7. Thereafter, the ADF 520 corresponding to the IOI specified class and the structure 530 corresponding to the IOI specified instance are loaded into memory. Subsequently, table driven routines 510 parse the serialized data according to the attribute information contained within the ADF and output the parsed attributes to the structure 530.
TABLE 7
______________________________________
Response Parameters for Get.sub.-- Attributes.sub.-- All
Description
Name Data Type of Parameter
______________________________________
attribute.sub.-- data
Object/class attribute specific
Data is specific to the
STRUCT as defined in Table 2.
attributes
______________________________________
Similar to the "Get" type services mentioned above the device class objects may further support the Set.sub.-- Attributes.sub.-- List service 600 shown in FIG. 6. Service 600 permits an operator located at workstation 60, for example, to set or change particular attributes of an IOI specified instance. As with the "Get" type services, the requester of service 600 which may be an operator located at workstation 60 inputs the service code for the service requested, the IOI of the instance to be acted upon and in the case where the service is the Set.sub.-- Attributes.sub.-- List service 600 the requester also inputs an attribute list 610 which comprises attribute.sub.-- count and attribute.sub.-- number information as shown in tables 8 and below. The data.sub.-- of.sub.-- attribute parameter comprises the attribute.sub.-- numbers and attribute.sub.-- values that the requester wishes to set in the IOI specified instance.
TABLE 8
______________________________________
Service Request Parameters for Set.sub.-- Attributes.sub.-- List
Name Data Type Description of Parameter
______________________________________
attribute.sub.-- count
UINT Number of attribute
numbers in the attribute
list
data.sub.-- of.sub.-- attributes
Array of system-defined
Array of structures
STRUCT specific to this service.
______________________________________
Once the attribute count and data.sub.-- of.sub.-- attributes is input by the operator or other source, the Set.sub.-- Attributes.sub.-- List service 600 loads the device structure 620 and corresponding ADF 630 into the memory of workstation 60. Thereafter, table driven routines 630 pack attribute list data 610 into a serialized output which is loaded into the workstation's local communication module 640 for communication over link 70 to I/O module 40. In turn, module 40 communicates the message over the backplane of chassis 30 to automation controller module 20 where the listed attributes are set according to the attribute.sub.-- value information obtained from the device structure 620. Once the attributes are successfully set module 20 responds back to workstation 60 indicating that the attributes have been successfully loaded into the controller. With reference to FIG. 7 there is shown a flow diagram of the Set.sub.-- Attributes.sub.-- All service 700 which permits the requester of the service to set all of the attributes for an IOI specified instance. In use, the requester of service 700 inputs the service code for the service requested and the IOI of the instance to be acted upon. Thereafter, the corresponding ADF 720 and device structure 730 which comprises the attribute.sub.-- data as shown in table 10 are loaded into memory and table driven routines 710 parse the attribute.sub.-- data into a serialized stream for transmission via the local communication module 740 to the automation controller 20.
TABLE 10
______________________________________
Service Request Parameters for Set.sub.-- Attributes.sub.-- All
Description of
Name Data Type Parameter
______________________________________
attribute.sub.-- data
Object/Class attribute-specific
Sequence of attribute
STRUCT data
______________________________________
TABLE DRIVEN ROUTINES With respect to FIG. 8 there is shown a serialized stream of reply data 800 sent from a module 20 in response to the Get.sub.-- Attributes.sub.-- List service 400 shown in FIG. 4. The reply data 800 is generally comprised of four types of information 810-840. Specifically, data 810 is a two byte field which represents the number of attribute values returned in the reply data 800. Data 820 represents the attribute number associated with the next attribute value 840. Data 830, comprises a minimum two byte field containing status information which indicates whether their are any errors in the transmitted attribute value 840. In particular, when the two bytes are 00 00 the foregoing attribute value 840 is deemed error free. However, a non zero data indicates a variable length data field which will be stripped off the reply data 800 as discussed below. Finally, the last data 840 is the attribute value which may vary in length depending on the particular attribute. Subsequent to the receipt of reply data 800 a first routine is executed which strips the data 810, 820 and 830 from data 800 resulting in the serialized stream of data 900 as shown in FIG. 9. Thereafter, the filtered reply data 900 is parsed one attribute value 840 at a time and each attribute value is moved into the empty device attribute structure 430 shown in FIGS. 4 and FIG. 10. More specifically, the corresponding ADF 420 for the object class is loaded into memory for access by the table driven routines 440. Additionally, the attribute list 410 which comprises the attribute.sub.-- list service request parameter shown in table 4 is input to the table driven routines 440. Importantly, the order of the attributes in the attribute.sub.-- list service request parameter dictates the order of the attributes in the reply data 800 and subsequently the order of the attribute values 840 shown in FIG. 9. Using the attribute list information 410 comprising the attribute.sub.-- list service request parameters, table driven routines 440 identify the order of the attribute numbers in the attribute.sub.-- list service request parameter and then locate the corresponding attribute information 330-370 in the ADF 420 based on each attribute number 380. Once the information is read from the ADF 420, table driven routines 400 can look up the size 360 of each attribute 840 and parse off the appropriate number of bytes from the stream of bytes 900 shown in FIG. 9. For example, when the first attribute in the attribute.sub.-- list request parameter is attribute number 1, table driven routines 440 identify the size 360 of the corresponding attribute data 840 which in this case is two bytes. Accordingly, the first two bytes, 01 00, are parsed off of the stream 900. Thereafter, the bytes are loaded into the structure 430 at offset 0 as 0001 as described below. It is important to note that the byte order is encoded low to high in the reply data. In a similar manner, the process continues for each attribute in the attribute list 410 until each attribute 840 has been parsed off the stream of bytes 900. Once parsed from the stream 900 the attribute number identified from the attribute.sub.-- list request parameter is further used to identify the relative offset from the beginning of the device attribute structure 430 in which to store the attribute value 840. Moreover, the offset is calculated using the size 360 in bytes of each previous attribute as defined in the ADF 420 to determine where in the structure 430 to place the attribute value 840. In particular, the position of each attribute value 840 in the structure 430 is calculated using the size 360 in bytes of each previous attribute in the ADF 420. An example of the calculated offsets for each attribute value 840 in the device structure 430 are shown in table 11. Once the offset has been calculated, the structure 430 is appropriately loaded with each of the attribute values 840 using standard C and C++ routines for a typical data structure as is shown in FIG. 10. Importantly, the order of attributes in the ADF and therefore, the Device Instance Attribute table (Table 2), are not required to be in any particular order. Similarly, the order of the attributes in the Get.sub.-- Attributes.sub.-- List service request parameters does not have to be sequential as shown in the example given in FIGS. 9 and 10. As a result there is greater flexibility when setting up attribute lists.
TABLE 11
______________________________________
Device Structure
Attribute Name Offset
______________________________________
Vendor 0
Product Type 2
Product Code 4
Device Revision Structure
Major Revision 6
Minor Revision 7
Status 8
Serial Number 10
Product Name.sub.-- Length
14
Product Name 15
______________________________________
The table driven parsing and packing routines 510 are slightly modified when parsing the reply data received in response to the Get.sub.-- Attributes.sub.-- All service request 500. In particular, as discussed above and shown in FIG. 5 the Get.sub.-- Attributes.sub.-- All service does not utilize an attribute.sub.-- list as part of its request parameters. Accordingly, the order of the attribute data cannot be derived from the order of the attribute numbers set forth in the request parameters. Rather, as shown in FIG. 3 the ADF 520 (FIG. 5) contains the Get Attributes All position 370 which defines the order of the attribute numbers and therefore the attribute values in the reply data 1100 as shown in FIG. 12. The response data for the Get.sub.-- Attributes.sub.-- All is a stream of bytes 1200 comprising only attribute values 1130. Subsequently, the table driven routines use the Get Attributes All Position 370 to determine the size 360 of each successive attribute and subsequently parse it off the stream 1200. Finally, as in the Get.sub.-- Attributes.sub.-- List service 400 the parsed attributes are loaded into the structure 530 by adding up the size 360 of all the preceding attributes to determine the offset in bytes from the beginning of the structure 530 in which to place each attribute value 1130. The Set.sub.-- Attributes.sub.-- List service 600 is implemented by the table driven routines 640 in the manner described below. Service 600 permits the operator at workstation 60 to change all or some of the settable attributes in a particular object instance. When an object instance is modified in the virtual device or workstation 60, the changed attributes must be changed in the physical device if the virtual device is intended to match the physical device. Accordingly, the Set.sub.-- Attributes.sub.-- List service 600 is invoked to pack the changed attributes into a serialized stream for transmission to the physical device. The packing routines which are part of the table driven routines 610 are implemented in a similar manner to the "Get" type routines described above. Importantly, the routines 610 are generic to all object instances of all classes and utilize an ADF to determine a particular instance's attribute format information. With reference to FIG. 12 there is shown a device attribute structure 1300 which corresponds to either device structure 620 or 730 in FIGS. 6 and 7 respectively. Device structure 1300 is shown for example purposes only when describing the Set.sub.-- Attributes.sub.-- List service 600 and the Set.sub.-- Attributes.sub.-- All service 700. With reference to FIG. 13 there is shown a stream of serialized Set.sub.-- Attributes.sub.-- List command data packed by table driven routines 610 in response to the Set.sub.-- Attributes.sub.-- List service request 600. In the example shown, the operator has selected to set the first six attributes in the physical device to those shown in the structure 1300. In accordance with the flow diagram shown in FIG. 6 the operator inputs the service code and attribute list comprising the attribute numbers of those attributes intended to be set in the physical device. Thereafter the device structure 620, or for the purposes of this example structure 1300, and the ADF 630 corresponding to the device class objects are loaded into memory. Subsequently, table driven routines 650 use the ADF 630 in conjunction with the attribute numbers in the attribute list 610 to pack the attribute values 1310 located in device structure 1300 into a serialized stream 1400 for communication to the physical device via communications module 640. In addition to the attribute values, the serialized stream 1400 also comprises the number of attributes 1410 in the serialized stream as well as the attribute numbers 1320 of each attribute value 1310. In particular, table driven routines 600 use the attribute number provided in the attribute list 610 to look up its corresponding attribute description in the ADF 630. Once the corresponding attribute number is located in the ADF the relative offset of the corresponding attribute value 1310 from the beginning of the device attribute structure is calculated by summing the size 360, in bytes, of each previous attribute in the ADF. Thereafter, the attribute value 1310 is moved (or packed) from the device attribute structure 1300 into the serialized command data stream 1400 for transmission to the target module. Moreover, each attribute, one at a time is taken from the device attribute structure 1300 and moved into the serialized command data stream 1400 in the manner described above. For example, the first attribute in the list is attribute number 01 00, the vendor, and its size is two bytes. Accordingly, the attribute value 1310, bytes 01 00, are moved from the structure 1300 at offset 0 as 00 01 into the serialized command data stream 1400. This process continues for the number of attributes in the list. Importantly, the order of attributes in the ADF file is not required to be sequential. Additionally, the order of attributes in the Set.sub.-- Attributes.sub.-- List request parameters (i.e. the attribute list 610) need not be sequential either. The latter provides greater flexibility when setting up attribute lists. FIG. 14 depicts the serialized command data stream 1500 generated in response to the Set.sub.-- Attributes.sub.-- All service 700 shown generally in FIG. 6. Similar to the Get.sub.-- Attributes.sub.-- All service 500, service 700 does not require an attribute list or attribute numbers as part of the service request parameters. Rather, since all settable attributes are going to be packed into the serialized stream 1500 (FIG. 15) the Get.sub.-- Attribute.sub.-- All.sub.-- Position so only the ADF 720 and the structure 1300 are required. More specifically, the attribute values 1310 correspond to the Get.sub.-- All.sub.-- Attribute.sub.-- Position in the ADF 720. Therefore, the table driven routines 710 look up the first attribute in the ADF 720 and determine its size 360 and subsequently move or pack the corresponding number of bytes, at the appropriate offset, from the structure 1300 into the serialized stream 1500. As before the offset is determined by summing up the size, in bytes, of all the previous attributes in the ADF 720. Since the attribute numbers are not included in the serialized stream 1500, the order of the attributes 1310 in the stream are in the same order as in the Get.sub.-- All.sub.-- Position in the ADF 720. For clarity table driven routines 440, 510, 650 and 710 are generally intended to refer to a single collection of software routines which perform the functions as discussed above. Also the ADF's 420, 520, 630 and 720 are all the same file since a device class object is used for all the examples in the preferred embodiment. However, other ADF's are required for other classes of objects and those ADF's will correspond to the general format shown in FIG. 3. Various modifications and alterations in the described method will be apparent to those skilled in the art from the foregoing description which does not depart from the spirit of the invention. For this reason, these changes are desired to be included in the scope of the appended claims. The appended claims recite the only limitations of the present invention and the descriptive matter which is employed for setting forth the present embodiment and is to be interpreted as illustrative and not limitative.
|
Same subclass Same class Consider this |
||||||||||