ANSI ESTA E1.30-1-2010 EPI 23 Device Identification Subdevice (Formerly PLASA E1.30-1).pdf

《ANSI ESTA E1.30-1-2010 EPI 23 Device Identification Subdevice (Formerly PLASA E1.30-1).pdf》由会员分享，可在线阅读，更多相关《ANSI ESTA E1.30-1-2010 EPI 23 Device Identification Subdevice (Formerly PLASA E1.30-1).pdf（10页珍藏版）》请在麦多课文档分享上搜索。

1、ANSI E1.30-1 - 2010, EPI23 Device Identification SubdeviceANSI E1.30-1 - 2010EPI 23. Device Identification SubdevicePart of the E1.30 Project, Application level equipment interoperability for control of commonly encountered entertainment technology devices using E1.17.TSP document ref. CP/2008-1004r

2、3Copyright 2011, the PLASA North America. All rights reserved.Approved by the ANSI Board of Standards Review on 6 January 2011.AbstractThis EPI specifies a collection of properties which may be exposed by a DMP device to provide detailed information on the manufacturer, model, serial number, hardwar

3、e and software revisions and other administrative details of the device. These properties are described in a standard format as a templated DDL (sub)device.CP/2008-1004r3pub Page 1ANSI E1.30-1 - 2010, EPI23 Device Identification SubdeviceRevision HistoryRevision 3 2010-01-06Revision 2 2009-03-02Revi

4、sion 1 2008-05-01Revision 0 2008-03-28Revision 0pre4 2008-03-05Revision 0pre3 2008-02-25Revision 0pre2 2007-11-14Revision 0pre1 2007-10-16Table of ContentsAbstract1Foreword ACN EPIs31. Introductory Discussion32. Device Identification Model.32.1. Device Name (User Assigned Component Name or UACN)32.2

5、. The Default Device Name42.3. The Model Name Fixed Component Type Name (FCTN).42.4. The Manufacturer.42.5. The Manufacturer URL42.6. Hardware Version.42.7. Software Version42.8. Serial Number.53. The DDL.53.1. Behaviors Needed.53.2. Device Identification Device DDL.5Notes:.73.3. Languageset for Dev

6、ice Identification Device74. Use as a subdevice8Notes:.8Annex A. Definitions10Annex B. Normative References10CP/2008-1004r3pub Page 2ANSI E1.30-1 - 2010, EPI23 Device Identification SubdeviceForeword ACN EPIsE1.17 is the “Architecture for Control Networks” standard ACN. It specifies an architecture

7、including a suite of protocols and languages which may be configured and combined with other standard protocols in a number of ways to form flexible networked control systems.E1.17 Profiles for Interoperability (EPIs) are standards documents which specify how conforming implementations are to operat

8、e in a particular environment or situation in order to guarantee interoperability. They may specify a single technique, set of parameters or requirement for the various ACN components. They may also specify how other standards (including other EPIs) either defined within ACN or externally are to be

9、used to ensure interoperability. 1. Introductory DiscussionDevice Description Language DDL provides the facility to describe devices such that one device, previously described, may be embedded within another device. Such a device is termed a sub-device, and the device it is embedded in a parent devi

10、ce. This allows common descriptions to be reused. It also allows applications to provide services specific to a particular sub-device, rather than having to divine the purpose of a group of properties from first principles.NoteThis EPI refers extensively to elements and constructions which are part

11、of the DDL standard DDL. To understand this specification will require some knowledge of DDL and its terms. Also since DDL is founded on XML, that pervasive standard also needs to be understood.This particular sub-device is intended to provide a common set of properties to identify for a user a part

12、icular instance of an ACN device, its hardware, software, and other information. In order to aid configuration, certain properties are writeable.2. Device Identification ModelThis section summarizes the model of the Device Identification device which a conforming device presents to a controller, wit

13、hout reference to specific DDL which will be shown in later sections.2.1. Device Name (User Assigned Component Name or UACN).EPI 19 DiscoveryIP requires every compliant component to maintain a persistent component name called the User Assigned Component Name (UACN). This name shows up in discovery a

14、nd may be assigned by the user with any string value to suit the system role of that component. EPI19 DiscoveryIP does not specify any method to configure the value of this name, but for any device complying with this EPI the UACN must be accessible and modifiable using DMP via this property. The ma

15、ximum size of the UACN property is parameterized but must be at least 64 octets.In many implementations the UACN may be configurable by other methods (local controls, web-pages etc.) and so this property may be declared as volatile. It is also required to be persistent.When the UACN is changed (whet

16、her by writing to this property or otherwise) the device must re-register itself and modify its advertisements as necessary to ensure that the new name is propagated throughout the ACN system. This same consideration will apply to any other discovery mechanism which uses the UACN.CP/2008-1004r3pub P

17、age 3ANSI E1.30-1 - 2010, EPI23 Device Identification Subdevice2.2. The Default Device NameThe template also specifies the default value of the UACN. This is the value of the name as supplied from the factory and following a “reset defaults” operation and may be a null string.2.3. The Model Name Fix

18、ed Component Type Name (FCTN)EPI 19 DiscoveryIP also defines a Fixed Component Type Name (FCTN) which is the string representing the model name and/or number of the device. It cannot be changed. Manufacturers use widely varying formats for this string. The model name is an immediate value provided a

19、s a template parameter. This allows a controller which has processed the device description offline to know in advance what FCTN received during discovery corresponds to this device. Note that while this facility is invaluable for presenting a human readable model name, it should not be used for aut

20、omated identification there are UUID UUID based mechanisms for this.2.4. The ManufacturerThis is the string representing the name of the manufacturer of the device. It cannot be changed. The manufacturer shall take reasonable steps to ensure that this string is unique to them (e.g. “ABC Lighting Con

21、trols Inc.” rather than “ABC” or “ALC”). The manufacturer name is an immediate value provided as a template parameter.2.5. The Manufacturer URLThis is the string representing the URL of the manufacturer of the device. It is intended to lead the user to further information. Manufacturers should ensur

22、e that, as a minimum, this URL leads to resources which provide the user with contact information for sales and support of the device. The manufacturer URL is an immediate value provided as a template parameter.2.6. Hardware VersionThis is a string representing the hardware version of the device. It

23、 cannot be changed. Manufacturers use widely varying version formats, so this property uses a string rather than a number to accommodate those formats. For software-only devices, (e.g. such as would run on PCs), the hardware version is frequently unknown or meaningless. In these cases it shall be an

24、 empty string.Hardware version is included as a constant network readable property. This means that different instances of the same device type can have differing hardware versions. Note though that by the rules of DDL, if two hardware versions have sufficiently differing functionality to require di

25、fferent treatment of any kind by a controller, then a revised device description should be applied.2.7. Software VersionThis is a string representing the version of the software of the device. It cannot be changed. Manufacturers use widely varying version formats, so this property uses a string rath

26、er than a number to accommodate those formats.Software version is included as a constant network readable property. This means that different instances of the same device type can have differing software versions. Note though that by the rules of DDL, if two software versions have sufficiently diffe

27、ring functionality to require different treatment of any kind by a controller, then a revised device description should be applied.CP/2008-1004r3pub Page 4ANSI E1.30-1 - 2010, EPI23 Device Identification Subdevice2.8. Serial NumberThis is a string representing the serial number of the device. It can

28、not be changed. Manufacturers use widely varying serial number formats, so this property uses a string to accommodate those formats.Manufacturers shall ensure that each instance of any device has a unique serial number within their own organization. This ensures that the combination of Manufacturer

29、Name and Serial Number will be globally unique.Products without serial numbers shall return a null string for this property.As with the Model name, the serial number is suitable for human interaction, but automated algorithms for identification of specific ACN components should use the CID.3. The DD

30、LThe following is a listing of two DDL documents which define this device. These documents are available under their UUID identifiers from ESTA and may be available in a variety of encodings or formats subject to the rules of DDL DDL.The combination of these two DDL documents and the referenced beha

31、vior descriptions and label form a normative description of this device. Any discrepancies between the DDL and this EPI are errors and should be reported to ESTA.3.1. Behaviors NeededAll behaviors used by these documents are defined in the ACN Base Behaviorset ACNbase which is separately available u

32、nder its own UUID.Note on Draft DDLThe “provider” attribute in these DDL documents is given as “http:/www.esta.org/ddl/draft/” which in accordance with EPI32 DraftDDL indicates that these descriptions are in draft form and may change. On approval of this standard, the provider attribute must be chan

33、ged to “http:/www.esta.org/ddl/final/” and this note removed.3.2. Device Identification Device DDL64256volatileNULLCP/2008-1004r3pub Page 5ANSI E1.30-1 - 2010, EPI23 Device Identification SubdeviceCP/2008-1004r3pub Page 6ANSI E1.30-1 - 2010, EPI23 Device Identification SubdeviceNotes: The DMP addres

34、ses for network accessible properties all use the relative format of DDL so that the entire sub-devices address map may be relocated when it is included, however since they are not parameterized it is not possible to change their relative arrangement from instance to instance All four network proper

35、ties are strings which use the variable length encoding of DMP. The devicename property value is persistent because its “UACN” behavior refines “persistent” behavior.3.3. Languageset for Device Identification DeviceLabels for Device ID deviceDevice ID deviceUser assigned component name (UACN)also ap

36、pears in discoveryDefault value for UACN nameonly used in new devices or on reset defaultsoperation.Manufacturers model namealso appears in discoveryManufacturerURL of ManufacturerHardware version stringSoftware version stringSerial number of deviceBeschriftung der GerteID des GertsGerte ID des Gert

37、sBenutzer-definierter Gerte-Nameerscheint auch in DiscoveryVorgabe-Wert fr den Gerte-Namenerscheint nur bei neuen Gerten und bei Verwendungder “reset defaults“ Funktion.Hersteller Modell-Nameerscheint auch in DiscoveryHerstellerURL des HerstellersHardware-Versions BezeichnungSoftware-Versions Bezeic

38、hnungSerien-Nummer des GertesCP/2008-1004r3pub Page 7ANSI E1.30-1 - 2010, EPI23 Device Identification Subdevice4. Use as a subdevice.This Device Identification Device description is a template which requires instantiating to supply the values for immediate properties and other parameters.Here is an

39、example where the device is just inserted into another devices description:ESTA Example Device For EPI 23128ESTA Example Device For EPI 23Entertainment Services Technology Association (ESTA)http:/www.esta.org/tsp/Notes: In this example, the default volatile behavior of the Device Name property is pr

40、eserved. If parameter “devicename-volatile-behavior” were set to “NULL” instead of the default “volatile”, this would imply that accessing this property via DMP is the only way to change its value. The example device has a maximum length for the device name string of 128 octets which is longer than

41、the default 64. Since this string is UTF8 encoded, the number of complete characters that 128 octets can represent is variable and may be anything from 128 down to 42. The childrule_DMP element provides an offset for the relative addresses used in the template meaning that in this example the networ

42、k properties are laid out as follows:CP/2008-1004r3pub Page 8ANSI E1.30-1 - 2010, EPI23 Device Identification SubdeviceProperty xml:id DMP locationAccessdevicename 10,000 Read/Writehardwareversion 10,001 Read onlysoftwareversion 10,002 Read onlyserialno 10,003 Read only It is likely that manufacture

43、rs have more detailed information per device than the Device Identification device currently holds. These may be added in the same device which instantiates the Device ID template, in a template that contains the Device ID template, or in a template that extends the Device ID template.CP/2008-1004r3

44、pub Page 9ANSI E1.30-1 - 2010, EPI23 Device Identification SubdeviceAnnex A. DefinitionsCID: Component Identifier. A UUID UUID identifying a particular ponent: The process, program or application corresponding to a single ACN endpoint. All messages in ACN are sent and received by a component which i

45、s identified by a CID. See Arch for a more complete definition. See also CID.Annex B. Normative ReferencesACN Entertainment Services and Technology Association, since 1 January 2011 PLASA NA http:/tsp.plasa.org. ANSI E1.17 - 2010, Entertainment Technology - Architecture for Control Networks.Arch Ent

46、ertainment Services and Technology Association, since 1 January 2011 PLASA NA http:/tsp.plasa.org. ANSI E1.17 - 2010, Entertainment Technology Architecture for Control Networks. “ACN” Architecture. DDL Entertainment Services and Technology Association, since 1 January 2011 PLASA NA http:/tsp.plasa.o

47、rg. ANSI E1.17 - 2010, Entertainment Technology - Architecture for Control Networks. Device Description Language. DiscoveryIP Entertainment Services and Technology Association, since 1 January 2011 PLASA NA http:/tsp.plasa.org. ANSI E1.17 - 2010, Entertainment Technology Architecture for Control Net

48、works. EPI 19 ACN Discovery on IP Networks. DraftDDL Entertainment Services and Technology Association, since 1 January 2011 PLASA NA http:/tsp.plasa.org. E1.30-10 - 2009. EPI 32, Identification of Draft Device Description Language Modules. ACNbase Entertainment Services and Technology Association,

49、since 1 January 2011 PLASA NA http:/tsp.plasa.org. ACN base behaviorset. urn:uuid:71576eac-e94a-11dc-b664-0017316c497d.UUID Internet Engineering Task Force (IETF) http:/ietf.org/. RFC 4122 http:/ietf.org/rfc/rfc4122.txt. P. Leach, M. Mealling, and R. Salz. A Universally Unique IDentifier (UUID) URN Namespace. July 2005.CP/2008-1004r3pub Page 10