HOME   Cart(1)   Quotation   About-Us Policy PDFs Standard-List
www.ChineseStandard.net Database: 189759 (19 Oct 2025)

GB/T 40017-2021 English PDF

US$624.00 · In stock
Delivery: <= 6 days. True-PDF full-copy in English will be manually translated and delivered via email.
GB/T 40017-2021: Information technology - Telecommunications and information exchange between systems - Heterogeneous networks convergence and scalability of community energy saving control network
Status: Valid
Standard IDContents [version]USDSTEP2[PDF] delivered inStandard Title (Description)StatusPDF
GB/T 40017-2021English624 Add to Cart 6 days [Need to translate] Information technology - Telecommunications and information exchange between systems - Heterogeneous networks convergence and scalability of community energy saving control network Valid GB/T 40017-2021

PDF similar to GB/T 40017-2021


Standard similar to GB/T 40017-2021

GB/T 37685   GB/T 37684   GB/T 38322   GB/T 40020   GB/T 40015   

Basic data

Standard ID GB/T 40017-2021 (GB/T40017-2021)
Description (Translated English) Information technology - Telecommunications and information exchange between systems - Heterogeneous networks convergence and scalability of community energy saving control network
Sector / Industry National Standard (Recommended)
Classification of Chinese Standard L79
Word Count Estimation 33,389
Issuing agency(ies) State Administration for Market Regulation, China National Standardization Administration

GB/T 40017-2021: Information technology - Telecommunications and information exchange between systems - Heterogeneous networks convergence and scalability of community energy saving control network



---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
(Information technology Remote communication and information exchange between systems Community energy saving control Heterogeneous network integration and scalability) ICS 35.110 L79 National Standards of People's Republic of China Remote communication and information exchange between information technology systems Community Energy Saving Control Heterogeneous Network Convergence and Scalability Released on 2021-04-30 and implemented on 2021-11-01 State Administration of Market Supervision and Administration Issued by the National Standardization Management Committee

Table of contents

Foreword Ⅰ 1 Summary 1 1.1 Scope 1 1.2 Objective 1 2 Normative references 1 3 Terms, definitions and abbreviations 1 3.1 Terms and definitions 1 3.2 Abbreviations 2 4 Overview 2 4.1 Background 2 4.2 Requirements and design principles 3 5 Architecture 4 5.1 Overview 4 5.2 Reconfigurable Resolution Server (RRS) 6 5.3 Intelligent Application Resolver (IAR) 11 6 Primitive data types 16 6.1 Primitive data type definition 16 6.2 The primitive data type expression in IEEE1888 17 6.3 Data Type Management Using Registrar 18 7 Import fieldbus data type 19 8 Security considerations 20 Appendix A (informative appendix) ID mapping configuration between fieldbus and IEEE1888 21 Appendix B (informative appendix) Conversion rules 23 Appendix C (informative appendix) Field data model based on Chapter 7 25 Appendix D (informative appendix) IAR extensible operation using the domain name system 28 Appendix E (informative appendix) IAR as a read service requester 29 Appendix F (informative appendix) Reference 30 Remote communication and information exchange between information technology systems Community Energy Saving Control Heterogeneous Network Convergence and Scalability

1 Summary

1.1 Scope On the basis of IEEEStd1888TM, this standard extends the definition of components and data types, message formats, and applications for heterogeneous network integration. Compliance and scalability communication procedures. This standard also describes the interconnection issues and requirements of heterogeneous networks. In addition, this standard specifies System architecture and solutions to improve heterogeneous network convergence and scalability, while providing robustness and more robustness in system operation and management Good performance. 1.2 Purpose This standard provides guidelines for the integration and scalability of ubiquitous green community control networks, enhances the interconnectivity of heterogeneous networks, and increases system flexibility. active. This standard describes the enhancement of the network convergence and availability of the ubiquitous green community control network (UGCCNet) heterogeneous network interconnection. Scalability. This standard provides enhanced efficiency, flexibility and scalability to build a safe, manageable and compatible system.

2 Normative references

The following documents are indispensable for the application of this document. For dated reference documents, only the dated version applies to this article Pieces. For undated reference documents, the latest version (including all amendments) is applicable to this document. IEEEStd1888TM Ubiquitous Green Community Control Network Protocol (IEEEStandardforUbiquitousGreenCommunity ControlNetworkProtocol) IEEEStd1888.3TM Ubiquitous Green Community Control Network Protocol. Security (IEEE Standard for Ubiquitous Green CommunityControlNetworkProtocol.Security) XMLSchemaPart 2.DatatypesSecondEdition,PVBironandA.Malhotra,eds.,October 3 Terms, definitions and abbreviations 3.1 Terms and definitions The following terms and definitions apply to this document. For terms not defined in this clause, it is advisable to consult the IEEE online standard dictionary. 3.1.1 Applicationdatatype Data types that are closely related to a specific application or a specific fieldbus. 3.1.2 Applicationdatatypedomainapplicationdatatypedomain A set of application data types defined by a specific organization. 3.1.3 Applicationdomain Another expression of the application data type domain. 3.1.4 Field-bus Working in the field, it provides an interconnected access network for sensors and actuators, including physical layer links, network layer protocols and application protocols. 3.1.5 Fieldbus data type field-busdatatype A type of application data related to a specific fieldbus. 3.1.6 ID mapping configuration IDmappingconfiguration A content object that defines the binding between the IEEE1888TM point identifier and the fieldbus-level identifier (for example, the transmission on the fieldbus) Identifiers of sensors and actuators). 3.1.7 Translationrule A content object defines the value mapping from one application data type set to another application data type set in different application domains. 3.2 Abbreviations The following abbreviations apply to this document. APP. application (application) CSV. comma-separated values (comma-separatedvalues) CUI. character-userinterface DNS. domain name system (domainnamesystem) GUI. graphical user interface (graphic-userinterface) GW. gateway HVAC. heating, ventilation, air-conditioning (heating, ventilating, air-conditioning) IAR. Intelligent Application Resolver (inteligentapplicationresolver) NAT. network address translation (networkaddresstranslation) PLC. Programmable Logic Controller (programmablelogiccontroler) RRS. Reconfigurable Resolution Server (reconfigurableresolutionserver) UGCCNet. Ubiquitous Green Community Control Network (ubiquitousgreencommunitycontrolnetwork) URI. uniform resource identifier (uniformresourceidentifier) XML. Extensible Markup Language (extensiblemarkuplanguage)

4 overview

4.1 Background 4.1.1 There is no general ID mapping configuration between the fieldbus on the gateway and the IEEE1888 system Gateways of different vendors have different configuration interfaces. The configuration interface may provide a graphical user interface (GUI) or a character user interface (CUI). The configuration format may be CSV, XML or other formats. Currently, it is not used between fieldbus and IEEE1888 system Configure the general interface and data format of ID mapping, so it is generally not possible to manage ID mapping, nor can it be remotely configured. 4.1.2 The coexistence of various application data types in IEEE1888 The IEEE1888 standard has achieved access and interoperability with a variety of fieldbus systems, including building automation and control networks (such as BACnet), local operating network (such as LonWorks), MODBUS system, ZigBee device, ECHONET, PLC or other compatible 容网络。 Content network. However, the definition of the content and semantics of the data exchanged in IEEEStd1888TM has not yet been completed. For example, in the same The BACnet data and LonWorks data in the IEEE1888 data memory coexist at the same time, but the data "1" in the BACnet means adding Heat mode and HVAC_HEAT mode in LonWorks. Therefore, the application software has to recognize these differences in order to properly process them. Understand its meaning. 4.1.3 Values have different expressions at the primitive level In many fieldbus systems, Boolean, integer, real number and character string are the basic data types. Because IEEEStd1888TM is very To undefined primitive data types, these data types may produce values in some unexpected expression form, or if the application (APP) just assumes a small set of expressions, this kind of APP may not be able to parse these values. 4.1.4 Fieldbus data types that are not clearly managed in IEEE1888 The pointer ID in IEEE1888 usually represents a sensor or actuator on the fieldbus. In IEEEStd1888, it is not clear Describe and manage the type of data generated by such sensors. Therefore, when developing and reconfiguring the IEEE1888 system, System integrators need to manage this type of data. 4.2 Requirements and design principles 4.2.1 Support remote configuration of IEEE1888 gateway for binding fieldbus and IEEE1888 system This standard defines the ID mapping between fieldbus and IEEE1888 system (that is, the mapping between fieldbus ID and pointer ID). Radio) IEEE1888 gateway configuration interface and format. This supports GW remote configuration by changing the fieldbus-level configuration --- Add new sensors on the fieldbus. This standard recommends the CSV format and provides examples in Appendix A. 4.2.2 Allow value conversion between different application data types Some applications are specifically designed for specific application data types (such as manufacturer A's BACnet data type). Such Specially designed applications are not always easy to adapt to heterogeneous data types (such as not only BACnet data types, but also LonWorks data types). Data types, ECHONET data types, and other private data types). Some common primitives in the meta definition (such as HVAC heating module Formula), which means that different expressions can be exchanged with each other. Of course, some application data types cannot be converted to other data type systems. This standard allows the mapping between data types (such as the mapping of BACnet data types to LonWorks data types), and a type of data The data type is converted to other data types. For example, allow "1" in BACnet to be converted to "HVAC_COOL" in LonWorks. 4.2.3 Allow remote configuration of conversion rules This standard defines the interface and format of the remote configuration conversion rules, and provides examples of the CSV format, see Appendix B. 4.2.4 Define common raw data types for heterogeneous networks There are some common primitive data types. For example, many heterogeneous networks usually use boolean, integer and real number types. This standard defines these primitive data types and their expressions, and they should usually be used in the IEEE1888 system. This standard focuses on one Group primitive data types, because it is impossible to define comprehensive data types that cover all heterogeneous fieldbus protocols. The definition of this standard supports Support based on the same native data format. Designers of GWs for heterogeneous networks should adopt this rule in order to enhance primitive-level interoperability. 4.2.5 Clearly present the fieldbus data type on the registrar Fieldbus usually defines its own application data type. IEEE1888 supports the gateway (GW) defined by IEEEStd1888 The architecture contains this data. However, this standard does not define how to identify these data types. This standard supports the processing of these data and its data types type. The method is to define corresponding name spaces and attributes for these heterogeneous networks and (application-specific) data types. Appendix C is the main The fieldbus data model provides representation rules.

5 Architecture

5.1 Overview In order to achieve the requirements pointed out in the previous article, this standard introduces two new IEEE1888 components. Reconfigurable Resolution Server (RRS) And Intelligent Application Parser (IAR). The definitions of RRS and IAR are as follows. ---RRS manages ID mapping configuration between fieldbus and IEEE1888 point ID, and manages between different application data type domains The value conversion rules; ---IAR performs value conversion between domains of different application data types. Figure 1 describes the working process of RRS and IAR in the IEEE1888 architecture. The following description only provides an example For detailed description, see 5.2 and 5.3.The RRS manages the configuration and conversion rules of the GW. information. Such as. \u003ctransport\u003e \u003cbody\u003e \u003cpointid=″http.//example.org/gwA/idMap″\u003e \u003cvaluetime=″2013-01-01T00.00.00 08.00″\u003e Refer to Appendix A for ID mapping content \u003c/value\u003e \u003c/point\u003e \u003c/body\u003e \u003c/transport\u003e On the GW gateway or IAR, when the previously received time attribute changes, they should use the value content as the configuration. because GW or IAR only use the latest configuration (i.e. if they only accept updated configuration), when RRS sends outdated configuration by mistake, i.e. The configuration of GW or IAR cannot be changed even if RRS has the correct time. 5.2.3 Configuration based on read (FETCH) Based on the read configuration process, the GW initiates a read request (FETCHrequest) and obtains the ID mapping from the RRS. In the same way Type, IAR (if the dynamic update conversion rule is enabled) can also read the request to obtain the conversion rule from the RRS. This process usually occurs when the device or system is started. After that, they will periodically read the configuration (especially when the network address After translation (NAT), the device or system is redeployed] to check the configuration changes. The read request shall specify the value of the attribute attrName The value of "Time" and attribute select is "maximum". 5.2.4 WRITE-based configuration In the write-based configuration process, RRS initiates a write request (WRITErequest) to configure the GW for ID mapping. To In the same way, RSS can also initiate a write request to set the conversion rule in IAR (if the dynamic update of the conversion rule is enabled). When the IEEE1888 system administrator changes a configuration or part of the configuration, RRS will execute the write configuration process. However, some nets The gateway will not perform configuration write function or be deployed behind NAT or firewall, at this time they should perform configuration read service. 5.2.5 Automatic binding of RRS and GW/IAR based on registrar 5.2.5.1 Overview of automatic binding In order to make ID mapping configuration and conversion rules expandable, this standard allows multiple RRSs in the network to coexist. In this case, manually The cost of configuring remote IEEE1888 components (ie RRS, GW, IAR) will be very high. Therefore, system integrators should introduce registrars to automatically Bind RRS and GW/IAR. Registration and search of RRS and GW/IAR should follow the provisions of 5.2.5.2 and 5.2.5.3. 5.2.5.2 Register RRS and GW/IAR If the registration operation mode is enabled, RRS will use the point ID to register, and the attribute stream of the point ID should be equal to "in". In this kind of In operation mode, if the registrar operation mode is enabled, RRS shall register with the point ID managed by the specified stream="in". In this kind of fuck In operation mode, only when GW realizes the write target function, it uses the specified stream=”out” to register itself as ID=”ID_ THAT_REPRESENTS_GW/idMap". IAR registers itself as ID="ID_THAT_REPRESENTS_IAR/ translationRule", and specify stream="out". According to the parameter configuration in Table 1 and Table 2, the following example shows the request message that RRS registers itself with the registrar.

Tips & Frequently Asked Questions:

Question 1: How long will the true-PDF of GB/T 40017-2021_English be delivered?

Answer: Upon your order, we will start to translate GB/T 40017-2021_English as soon as possible, and keep you informed of the progress. The lead time is typically 4 ~ 6 working days. The lengthier the document the longer the lead time.

Question 2: Can I share the purchased PDF of GB/T 40017-2021_English with my colleagues?

Answer: Yes. The purchased PDF of GB/T 40017-2021_English will be deemed to be sold to your employer/organization who actually pays for it, including your colleagues and your employer's intranet.

Question 3: Does the price include tax/VAT?

Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countries

Question 4: Do you accept my currency other than USD?

Answer: Yes. If you need your currency to be printed on the invoice, please write an email to [email protected]. In 2 working-hours, we will create a special link for you to pay in any currencies. Otherwise, follow the normal steps: Add to Cart -- Checkout -- Select your currency to pay.