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

GB/T 40015-2021 English PDF

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

PDF similar to GB/T 40015-2021


Standard similar to GB/T 40015-2021

GB/T 37685   GB/T 37684   GB/T 38322   GB/T 40020   GB/T 40017   

Basic data

Standard ID GB/T 40015-2021 (GB/T40015-2021)
Description (Translated English) Information technology - Telecommunications and information exchange between systems - Control and management of community energy-saving control network
Sector / Industry National Standard (Recommended)
Classification of Chinese Standard L79
Word Count Estimation 46,417
Issuing agency(ies) State Administration for Market Regulation, China National Standardization Administration

GB/T 40015-2021: Information technology - Telecommunications and information exchange between systems - Control and management 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 network control and management) 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 network control and management Released on 2021-04-30 2021-11-01 implementation 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 Architecture 2 4.1 General requirements 2 4.2 System Architecture 3 4.3 General workflow of sensor and actuator management 4 5 Management and Control Unit (MCU) 5 5.1 Overview 5 5.2 Frame 5 5.3 Typical MCU communication sequence 6 6 Gateway (GW) 7 6.1 Overview 7 6.2 Gateway Framework 8 6.3 Access Control 8 6.4 Event handling 9 7 Gateway (GW) control and management 9 7.1 Overview 9 7.2 Setting the configuration and running status of GW 10 7.3 Get the configuration and running status of GW 12 7.4 Send control request information to the actuator 12 7.5 Read real-time sensor data 13 8 Service Agreement 14 8.1 Definition of agreement 14 8.2 Data structure 15 9 WRITE, FETCH and TRAP protocol extension 20 9.1 General requirements 20 9.2 Data format 20 9.3 Redefine the Header class 21 9.4 Control class 22 10 Compatible with IEEEStd1888-2011 22 11 Security considerations 23 Appendix A (informative appendix) Typical process of MCU providing services 24 Appendix B (informative appendix) Recommended component model for component management 27 Appendix C (informative appendix) Access control list code 33 Appendix D (informative appendix) The process of MCU providing ACL to components 39 Appendix E (informative appendix) Import SNMP management information base 41 Appendix F (informative appendix) Reference 42 Remote communication and information exchange between information technology systems Community energy-saving control network control and management

1 Summary

1.1 Scope This standard expands the interface protocol and message format in the ubiquitous green community control network (UGCCNet) on the basis of IEEE1888TM. The central access control strategy and management strategy of the gateway are defined by the type and interactive processing mechanism. This standard expands the original interface protocol and message format It mainly specifies the gateway information used for access control, registration management, status query, event reporting, remote management, etc. Number stream. 1.2 Purpose This standard aims to provide an open and standardized gateway management interface protocol for service providers, system integrators, equipment manufacturers, etc. By extending the original interface protocol, it supports remote control and monitoring of the gateway and other facilities in the green community, such as heating, ventilation and air conditioning equipment. Equipment (HVAC), lighting system, energy equipment.

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-2011 Ubiquitous Green Community Control Network Protocol (IEEE Standard for Ubiquitous Green CommunityControlNetworkProtocol) 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 Management and control unit; MCU As the central management unit of the IEEE1888 network, it provides services such as control/management resources for other components. 3.1.2 Operation management and maintenance operation administration and maintenance; OAM A module of the management and control unit, used to operate and maintain gateways, sensors/actuators. 3.1.3 Operation service provider; OSP A module of the management and control unit that provides services for the requested components. 3.1.4 Resource Access Manager resourceaccessmanager; RAM A module of the management and control unit for access control of management components. 3.2 Abbreviations

4 Architecture

4.1 General requirements The management and control of components in UGCCNet is necessary. Effective component management and control can improve system operation Users provide efficient operation. At the same time, it is deployed in buildings with restricted access (such as offices, hotels, schools, shops, homes, factories, etc.). It is also necessary to effectively check the health status of the gateway and connected sensors/actuators. Without entering the restricted area, GW, storage The configuration changes of storage and APP are also very important. In order to achieve such management and control, this standard specifies the following general requirements. a) Make the configuration, status and events of GW and connected devices easy to manage and control. 1) The configuration information and operating status of components (especially GW) can be obtained; 2) The configuration information and operating status of the components (especially GW) can be set; 3) It can notify the change of the operating state of the component (especially GW); 4) It can manage the session control of the communication process of WRITE (write), FETCH (read) and TRAP (subscribe); 5) Allow two-way communication, for example, allow two-way management and control of dedicated network components through a network address translator (NAT). b) Provide various services for components. 1) It can handle data control and management from multiple sensors; 2) It can support sending control signals to multiple actuators. c) Prevent unauthorized components (such as APP, GW, storage, etc.) or devices from accessing the network, and prohibit them from performing control in the system Command. 1) It can provide component-level access control management; 2) Only GW and connected sensors/actuators can be accessed. d) Provide original information for system expansion to maintain system interoperability and backward compatibility. 1) Provide an extensible management and control information model and access control model; 2) Allow communication between components specified by IEEEStd1888-2011; 3) Provide manageable and controllable components, Simple Network Management Protocol (SNMP) Management Information Base (MIB) and access control Information model in list (ACL) format. The management rules of data status and the access records of UGCCNet components will be defined in future standards. 4.2 System Architecture In order to achieve control and management functions and meet operational requirements, a management and control unit (MCU) is introduced into the system to assume control and management UGCCNet component (especially GW) and sensor/actuator equipment connected to GW management tasks. The determined management and control system architecture is shown in Figure 1.Figure 1 mainly explains the network communication related to this specification. this The communication of IEEEStd1888-2011 is also supported in the network. The MCU manages multiple GWs, storages, and APPs deployed at remote sites. This standard refers to the components under MCU control as "manageable "Management" components, for example, managed GW, and a group of components managed by the MCU is called the "manageable domain." GW, storage and APP, this standard sometimes explicitly refers to them as "non-manageable" components, such as. non-manageable APP. Around the MCU The typical communication of management and control is shown in Figure 1. The following examples describe the behavior and role of the MCU in general. Example 1.MCU provides management and control services, processes data from sensors and sends control command data to actuators. in In this case, APP uses the services provided by MCU. Note. APPs in non-manageable networks can also use these services. Example 2.MCU obtains the configuration and operating status of the UGCCNet component, and sets its configuration and operating status. MCU can Status change notification to the remote component. The managed objects (such as configuration and operating status) include product information, working mode, health status, alarms, Logs, ACLs, etc. The MCU can also access. a) Read the GW of the sensor and control actuator; b) Used to obtain historical data; c) APP used to report events to remote sites. Example 3.Direct communication from non-manageable APP to manageable GW. In the manageable component, this access is controlled by the ACL configuration. The configuration of ACL is managed by MCU. Example 4.The MCU queries the registry for required component or point information. In order to meet the above management and control requirements, the system architecture. a) Define a set of procedures in the context of management and control; b) A new method of "service" is defined for the management and control of various facilities (a group of sensors and actuators); c) Defines a message format for service method invocation; d) Provide examples of information models for management and control (including health checks, working mode configuration, access and control management, etc.). 4.3 General workflow of sensor and actuator management 4.3.1 APP requests MCU service In the scenario in Figure 2, the APP requests the MCU to provide services (step 1), such as reading or controlling a certain sensor/actuator. MCU slave Get GW information from the registrar, see step 2.(If the MCU knows the GW that manages the sensors and actuators, step 2 is optional) According to the situation of the APP request, the MCU will execute step 3 or step 3'after making a decision. For example, if the APP only requests GW (or connect The information of the sensor/actuator) or the buffer information in the MCU, the MCU will directly send the information back to the APP (step 3'). otherwise, The MCU sends the command to the corresponding GW (step 3). Note. The invocation of the service method can be asynchronous. Figure 2 MCU service call 4.3.2 APP directly communicates with GW In the scenario in Figure 3, APP directly accesses GW to read sensors or control actuators. ---Before APP accesses the GW, the MCU has updated the ACL of the GW (step 1). Step 1 should be when GW starts to run Execute and execute again when ACL is updated. ---If the APP does not know the specific address of the GW it is looking for, it will find the GW information by querying the registry (step 2). ---APP visits GW (step 3). GW verifies according to the ACL set by the MCU in step 1 and other related security measures APP permissions. The security content of information transmission shall meet IEEE1888. ---APP gets the access result from GW (step 4). Note 1.ACL is the access authorization of components, see 6.3 for details. Note 2.The ACL of GW is installed from MCU. 5 Management and Control Unit (MCU) 5.1 Overview On the basis of IEEEStd1888-2011 network architecture, this standard introduces MCU module to manage components (such as GWs) And other devices to get a better operation and management network. Any registered and verified GW will be controlled by the MCU. by Authorization mechanism, MCU performs GW access control to prevent unauthorized operations. MCU also provides public services to achieve reliable and effective GW is running. As a management unit, MCU can monitor and collect GW runtime information. Based on this information, it can access remote configuration or Send an alert message. MCU plays a key role in network operation. It plays a role of management and control; through the network, to the GW and its connection Sensor/actuator equipment for abstract resource and equipment management; simplifies the security and security of commands and data between the application and the GW can. In order to effectively manage and control the GW, the MCU uses the SERVICE protocol to provide public services. Chapter 8. In the direct or indirect participation process of the MCU, the authenticated and authorized APP can read data from or to the device through the GW Write data. That is, when it is necessary to control energy-consuming equipment or nodes, the MCU must be a participant in the communication. The communication process is shown in Figure 8 in 7.1. 5.2 Framework MCU should implement three basic functions. resource access manager (RAM), operation management and maintenance (OAM), and operation service provision (OSP), as shown in Figure 4. a) Access control between RAM management components and GW. It treats all components (eg GW) and nodes as resources. If already Configure the access rights to the ACL, then the APP managed by the MCU can obtain data or send data from the GW and connected devices. It sends commands. RAM is also responsible for setting up network security policies. For example, it can be adjusted according to different safety requirements. Same authorization strategy. RAM can set different security levels according to these requirements. b) OAM is mainly used for component configuration, running status and control management. OAM maintains the gateway list, that is, the gateway management list (GML). The GW in the list has passed identity authentication, and the GW in the ACL comes from GML and is controlled by the MCU. with At this time, OAM monitors the message interaction between GW and other components to keep the node running normally. See Chapter 7 for details. ---Get data from sensors/actuators; --- Convert the "device-aware" data into IEEE1888 protocol messages and forward them to other components; ---Accept effective control commands and forward them to the actuator; ---Monitor and record the operating status of itself and the sensors/actuators connected to it; ---Send an alert message when a specific event occurs. GW can have built-in access strategy, but the access strategy needs to be managed by MCU so that MCU can directly or indirectly participate in all GWs activity. 6.2 Gateway Framework Figure 7 shows the logical frame structure of GW, these logical modules implement the basic functions specified in 6.1. Figure 7 GW framework The access control module (AC module) is used to control the access of the GW and contains a list of authorization information managed and configured by the MCU. If the MCU knows that the authorization of the GW has changed, it will notify the relevant GW and update the authorization list, see 6.3. The configuration module maintains the working mode of GW, including sensor/actuator settings. MCU get and set configuration information see 7.2 and 7.3.See Appendix C for sample configuration. The field device module is used to maintain sensor/actuator or point information. GW needs to maintain sensor/actuator or point information to perform reading The action of writing sensor/actuator data. The alarm module is used to manage the alarm information (the alarm information can come from the sensor/actuator device or the GW itself). Alerts can inform status Status changes, such as health check information. Before sending an alarm, you need to define rules in the alarm module, and analyze the data according to these rules (including GW Working status). If the data meets the trigger conditions, an alarm message will be generated according to the rules and sent in accordance with the IEEEStd1888-2011 format Sent to subscribers, see 6.4. In order to communicate with MCU and sensors/actuators at the same time, GW should have two external physical interfaces, namely. a) Connect the southbound interface of different fieldbuses; b) Connect the northbound interface of other components of UGCCNet. If the network is homogeneous, the two interfaces may be the same. 6.3 Access control When it becomes a manageable node, the GW should be kept in the GML of the MCU, and the MCU maintains the ACL of each manageable GW. The GW checks the ACL to determine whether to allow component access. The access from the MCU should also be checked. Access verification within the component The process is outside the scope of this standard. The MCU should maintain the entire ACL in the manageable system and provide a corresponding ACL set for each component. The message format of ACL is not Within the scope of this standard. Appendix C gives examples of ACL encoding methods. GW provides two methods for maintaining AC modules. a) The MCU sends the updated ACL set to the associated GW; b) GW can request MCU to provide its own ACL. ACL should be able to express arbitrary access of any component to any node. In order to enable the MCU to update the ACL, the initial ACL only allows an appropriate MCU to access. This is because the MCU needs to set up, get the configuration and running status on the component, but In the initial stage of installation, the components must be protected from any other access. Note. In a manageable system, other components (applications, storage) should have their own ACLs and should also follow this rule. 6.4 Event handling According to the source of the event, GW events can be divided into two categories. a) Events triggered by changes in GW's own status or parameters; b) Connect events caused by sensor/actuator parameter changes. At the same time, event trigger types can also be divided into two categories. a) Conditional, the event is triggered only when the relevant parameters meet specific conditions; b) Unconditional, trigger an event whenever the parameter changes. Events can be pre-defined, and their trigger conditions are pre-defined by the GW provider and cannot be modified. These events can only be subscribed. Also allowed in Events defined at runtime (called user-defined events). The trigger conditions and parameters of the event should be passed to the GW before the event is subscribed. When certain conditions are met, the subscription event will be triggered and the subscriber will receive a notification, see 7.3 for details. 7 Gateway (GW) control and management 7.1 Overview This chapter mainly describes the GW control and management process. The access of GW is controlled by ACL, which is set by MCU. Detailed description See 6.3. GW management functions include. ---Set the configuration and running status of GW; ---Retrieve the configuration and operating status of GW; ---Send control command data to the actuator; ---Monitor real-time data from sensors. The workflow of GW access, control and management is shown in Figure 8. GW configuration, you can also call the query method and use the TRAP protocol to initiate a request to the MCU to obtain the appropriate Configuration. In some cases, the MCU can request the GW to change the working mode, enter the sleep state from the running state or resume the normal running state. state. The periodic operation of GW is an energy-saving management policy. The working modes of GW (e.g. sleep, running, etc.) are as follows. ---Hibernation. Sleep mode means that the GW is working in energy-saving mode. In this mode, GW's interface module still works, but It is the logic-related processing module that stops working. ---Run. GW works normally. See Appendix B for an example of GW configuration settings. GW can work in running, sleeping, initializing or offline state. MCU can use the data method to send configuration commands to change the GW Working mode. For example, when the GW is in the "running" mode, the MCU can send a command to the GW (value = "sleep") to change its work The mode is sleep. When GW is in "sleep" mode, MCU can send commands to GW (value = "wake up") to change its working mode For running. In sleep mode, the GW will not respond to any requests, except for the query method or data method from the MCU (value = "Operation Row"). Figure 9 shows the flow of setting up the GW configuration and changing its operating state. Figure 9 Setting GW configuration and running status through MCU Example A. Describe how the MCU modifies the GW configuration. Example B. Describe how the application program modifies the GW configuration. When GW responds to a request from APP, GW will first use AC The module verifies the authorization and only responds to those requests that pass the verification. Example C. Describe how the GW initiates a request to obtain the appropriate configuration (such as ACL) from the MCU. Note. The above management process can also be applied to other components (such as memory). 7.3 Get the configuration and running status of GW The MCU can obtain the configuration settings or running status of the GW through a query method. See 7.2 for GW configuration information. GW monitored The operating status may include working mode, health information, statistical information, etc. Health information may include memory usage, CPU usage, magnetic Disk usage, etc. Statistics may include the number of FETCH requests received, the number of WRITE requests received, and the number of received The number of TRAP requests, etc. This type of management can also be applied to other components (see the GW statistical information example in Appendix B). Figure 10 shows the process of obtaining the configuration and running status of the GW. Figure 10 The process of obtaining the configuration and running status of GW The MCU should use the FETCH protocol to obtain the operating status and configuration (shown in example A) or use the TRAP protocol to subscribe to the operating status (Shown in example B). The situation that MCU uses TRAP protocol to subscribe to the running status of GW is called event processing. For details, see 6.4. 7.4 Send control request information to the actuator All control commands of the actuator are managed by GW. The command may be to start the device, shut down the device, and so on. If there is such a service For services, APP can directly initiate control to GW using data methods, or require MCU to perform operations using service methods. There are three methods that can be used to control the drive, as shown in Figure 11. Figure 11 Sending commands to the actuator Example A. APP uses service method to send control commands to MCU, and MCU uses data method to send corresponding control commands to GW Command to control a specific actuator. This process can be synchronous (A') or asynchronous (A). Example B. APP uses the data method to send control commands to the GW, requesting the GW to control the designated actuator. Example C. The GW uses the query method to send an information request (for example, the configuration of the GW) or a control command request to the MCU, and the MCU will use the query method to send an information request (for example, the configuration of the GW) or a control command request. Use the data method to respond to the GW information. Note. The communication between the GW and the actuator is not within the scope of this standard. 7.5 Read real-time sensor data The APP can call the MCU service method to obtain specific real-time sensor data, or visit when GW information is needed. Ask the relevant GW. The application can retrieve real-time data directly from GW, or subscribe to data from GW. The process is shown in Figure 12. Figure 12 GW real-time data retrieval Example A. APP calls the MCU service method to obtain the specified real-time data, and then the MCU uses the query method to check the relevant GW Inquire the corresponding callback URL indicated by the original APP. After GW retrieves the real-time data from the sensor, it uses the data method to send it to the APP data. Example B. The APP calls the MCU service method for the specified real-time data, and the MCU returns the corresponding GW information to the APP or Visit GW to retrieve data. APP can use instance C or instance D to read data. Example C. APP uses the FETCH protocol to call the query method of GW. The GW will use the AC module to verify the request. If this is For a valid request, GW will send the required real-time data back to the APP. Example D. APP uses TRAP protocol to call the query method of GW. The GW will use the AC module to verify the request. If this is a For a valid request, GW first sends a response to APP. After receiving the real-time data, GW sends the data back to APP.

8 Service Agreement

8.1 Definition of Agreement The SERVICE protocol is used to call the services defined in the MCU. Any component can initiate communication. When the MCU is connected When receiving the protocol request, the MCU should start the pre-defined process specified at the time of the call. The behavior of the predefined process is outside the scope of this standard. The interaction process between components (such as APP) and MCU is shown in Figure 13. Phase 1.The component calls the service method of the MCU by specifying the service name defined on the MCU. Component can choose service request The types are "inquiry" and "operation". If it is an "operation" request, the component also needs to provide a call service parameter. Phase 2.The MCU sends the result of the service call. If the MCU successfully accepts the request, it will return information in the Header section "OK". If it encounters an error in the process of accepting the request, it will return the message "error" in the Header section. If this request is a An "inquiry" request, which returns the parameters associated with the specified service. If this request is an "operation" request, a package may be returned The Value object contained in the Point object in the Body part of the response. The MCU may reply immediately after accepting the request, or keep this A response until the request is fully processed. 8.2 Data structure The message of the service agreement (SERVICE agreement) should be organized according to the following categories, the namespace of these categories is not in this standard definition. The class name should start with an uppercase letter, and the XML element name should start with a lowercase letter. Starting from the second letter, the class name and The XML name should be the same. However, if the first two letters of the class name are capitalized (that is, the OK class), the first letter of the XML should also The capitalization. The various message classes of the service agreement are given below.

Tips & Frequently Asked Questions:

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

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

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

Answer: Yes. The purchased PDF of GB/T 40015-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.