Home Cart Quotation About-Us
www.ChineseStandard.net
SEARCH

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 IDUSDBUY PDFLead-DaysStandard Title (Description)Status
GB/T 40015-2021874 Add to Cart 7 days Information technology - Telecommunications and information exchange between systems - Control and management of community energy-saving control network Valid

Similar standards

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 foll......
Image     

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 Sales@ChineseStandard.net. 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.