CN108093020B

CN108093020B - Data processing method and device

Info

Publication number: CN108093020B
Application number: CN201611051525.3A
Authority: CN
Inventors: 周明春; 鲁国良
Original assignee: Alibaba Group Holding Ltd
Current assignee: Zhejiang Tmall Technology Co Ltd
Priority date: 2016-11-23
Filing date: 2016-11-23
Publication date: 2020-12-18
Anticipated expiration: 2036-11-23
Also published as: CN108093020A

Abstract

The embodiment of the application discloses a data processing method and a data processing device, wherein the method comprises the following steps: three types of entities of Haystack are realized under an oBIX specification, wherein the three types of data entities comprise a geographical position entity, an equipment entity and an equipment function point location entity; performing unified description on data related to the underlying basic equipment to generate the metadata; providing an Application Programming Interface (API) so as to utilize the API and the metadata to develop an upper-layer application program; when a call request of an upper application program to the API is received, a target entity under an oBIX specification inherited by a target operation object and a target label under a Haystack specification are determined according to metadata carried in the request, so that the operation object is operated according to the target entity and the target label. By the embodiment of the application, the efficiency of inquiring and exchanging data can be improved, and meanwhile, the metadata scheme based on the mixed tags ensures barrier-free interaction of data among various devices.

Description

Data processing method and device

Technical Field

The present application relates to the field of data processing technologies, and in particular, to a data processing method and apparatus.

Background

From the realization technology, the Intelligent Building (IB) system is a real-time, accurate and efficient comprehensive control and management system established by organically applying advanced sensor technology, communication technology, network technology, automatic control technology, computer technology, data processing technology and the like to the operation and management process of a building, and aims to enhance the performance of the building and improve the productivity of the building.

Although the current intelligent building management system carries out centralized management on subsystems such as a Building Automation System (BAS), a fire fighting system (FAS), a security system and the like, each subsystem is controlled in the vertical field of the same equipment category, the difficulty of transverse interconnection and intercommunication of basic data of each subsystem equipment is substantially increased, the phenomenon of information isolated island is objectively caused, the real intellectualization is difficult to realize, and the maintenance cost of the later-period system is very high. In addition, the system solution is not reproducible and requires a separate custom integration at each project.

Disclosure of Invention

The application provides a data processing method and device, which can improve the efficiency of inquiring and exchanging data, and simultaneously ensure barrier-free interaction of data among various devices based on a metadata scheme of a mixed label.

The application provides the following scheme:

a method of data processing, comprising:

three types of entities of Haystack are realized under the open building information exchange oBIX specification, wherein the three types of data entities comprise a geographical position entity, an equipment entity and an equipment function point location entity;

performing unified description on data related to the underlying basic equipment through the three types of entities to generate the metadata;

providing an Application Programming Interface (API) so as to utilize the API and the metadata to develop an upper-layer application program;

when a call request of an upper application program to the API is received, a target entity under an oBIX specification inherited by a target operation object and a target label under a Haystack specification are determined according to metadata carried in the request, so that the operation object is operated according to the target entity and the target label.

A data processing apparatus comprising:

the system comprises an entity realization unit, a data processing unit and a data processing unit, wherein the entity realization unit is used for realizing three types of entities of Haystack under the open building information exchange oBIX specification, and the three types of data entities comprise a geographical position entity, an equipment entity and an equipment function point location entity;

the metadata generation unit is used for performing unified description on the data related to the underlying basic equipment through the three types of entities to generate the metadata;

an API providing unit for providing an application programming interface API so as to develop an upper application program by using the API and the metadata;

and the call request processing unit is used for determining a target entity under an oBIX specification inherited by a target operation object and a target label under a Haystack specification followed by the target operation object according to metadata carried in a request when receiving a call request of an upper application program to the API, so as to operate the operation object according to the target entity and the target label.

According to the specific embodiments provided herein, the present application discloses the following technical effects:

through the embodiment of the application, the mature building industry label library of the HayStack is integrated, and the definition of a HayStack site/query/point three-layer data entity under the OBIX specification is specifically implemented, so that an API (application program interface) following the HayStack specification can be used as a unified entry point, the compound query under the OBIX specification is realized, and the efficiency of querying and exchanging data can be improved. Meanwhile, the metadata scheme based on the mixed tags ensures barrier-free interaction of data among various devices.

In addition, due to the fact that the h-prefix label of the HayStack is added, a platform user can query the equipment level by level through the OBIX Location position, and can comprehensively query all the equipment with the label through the label characteristic of the HayStack.

Of course, it is not necessary for any product to achieve all of the above-described advantages at the same time for the practice of the present application.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.

FIG. 1 is a schematic diagram of a system provided by an embodiment of the present application;

FIG. 2 is a flow chart of a first method provided by an embodiment of the present application;

FIG. 3 is a flow chart of a second method provided by embodiments of the present application;

FIG. 4 is a flow chart of a third method provided by embodiments of the present application;

FIG. 5 is a schematic diagram of a first apparatus provided by an embodiment of the present application;

FIG. 6 is a schematic diagram of a second apparatus provided by an embodiment of the present application;

fig. 7 is a schematic diagram of a third apparatus provided in an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments that can be derived from the embodiments given herein by a person of ordinary skill in the art are intended to be within the scope of the present disclosure.

Example one

In the first embodiment of the present application, in order to solve the information islanding problem in the prior art, an intelligent building control system is provided, in which data collection may be performed on bottom-layer basic devices (including air conditioners, lamps, and the like) inside a building, or a control instruction may be sent, and an API (application programming interface) may be provided for an upper-layer application service, so that the upper-layer application service may obtain data of the bottom-layer basic devices in an API call manner, or send the control instruction to the bottom-layer basic devices. To achieve the above object, in particular, with reference to fig. 1, the system may comprise:

the gateway middleware 101 is positioned inside the building and used for controlling access of bottom foundation equipment of a plurality of different equipment types inside the building and carrying out unified processing on data of different bottom foundation equipment in the same equipment type;

and

and the control server 102 is located at the cloud end and is used for providing an Application Programming Interface (API), receiving a call request of an upper application program to the API, and issuing the call request to the corresponding bottom-layer basic equipment through the gateway middleware so as to operate the bottom-layer basic equipment.

In specific implementation, the bottom foundation equipment in the building can include two major types, one type is sensor equipment, including a temperature sensor, a humidity sensor, a photosensitive sensor, face recognition equipment, license plate recognition equipment and the like; another class is executive class devices including air conditioners, lighting, access control devices, and the like. The sensor equipment is mainly used for collecting environment data inside the building and can be submitted to the cloud control server. In the process of realizing the functions of the execution equipment, the execution equipment can also submit data generated by the execution equipment to the cloud control server, or execute a specific instruction under the control of the cloud control server.

In practical application, in order to continuously sample and continuously optimize and control bottom layer equipment data through a cloud platform, the purposes of most effectively utilizing energy sources, reducing operation and maintenance costs and the like are achieved, the layout and the like of bottom layer basic equipment can be standardized, and the bottom layer basic equipment in a building can be deployed according to specific standard. The method specifically comprises the steps of indoor lighting design rules, electric power subentry measurement design standards, selection principles and spatial arrangement rules of environment comprehensive sensor data acquisition points, variable air volume air conditioning systems, fan coil and fresh air system design guide rules, wireless WIFI design guide rules, requirements of intelligent buildings on electromechanical equipment data access and the like. Specific rules or specification contents can be specified according to actual needs, and are not detailed here.

The upper application program can comprise native applications developed by a cloud platform, and in addition, the upper application program can also comprise third-party applications developed by some third-party developers, and the specific upper application program can specifically realize lamp control, access identification, station time-sharing lease, parking space reservation and the like.

The embodiment of the application adds two layers between the bottom layer basic device and the upper layer application program, wherein one layer is a gateway layer, and the other layer is a control layer of a cloud. The gateway layer may be configured with one or more gateway devices (the specific number of gateway devices may be determined according to the number of bottom layer infrastructure devices in the building, etc.), and a preset gateway middleware is installed in the gateway device, various bottom layer infrastructure devices in the building may be accessed into the gateway, data generated by the bottom layer infrastructure devices may be uploaded to a control server in the cloud through the gateway middleware, and a control instruction generated by the control server may also be issued to the bottom layer infrastructure devices through the gateway middleware.

Specifically, the gateway middleware may be mainly used to unify data of different underlying basic devices in the same device class (also referred to as industries generally, for example, the lighting device class is also referred to as lighting device industry, the air conditioning device class is also referred to as fresh air industry, and the like). This is because, regarding various types of underlying basic devices, the devices can be classified into different device types from the viewpoint of device types, including devices of lighting device types, devices of fresh air device types, and so on. Furthermore, in the same building, there may be differences in data expression and the like between devices of the same device type and between different manufacturers and different types of devices even if they belong to the same device type. For example, also for lighting devices, different manufacturers may have different definitions for the range of brightness values, wherein manufacturer A is defined as 0-100, manufacturer B is defined as 0-10, and so on. Therefore, in order to facilitate uniform control, the gateway middleware can perform uniform processing on data of different types of devices of different manufacturers in the same device class, so that the upper layer application program can control the devices in the same device class through uniform instructions. For example, the range of the brightness value of each lighting device manufacturer can be uniformly represented as 0-100, and in the gateway middleware, the data expression modes originally defined by different manufacturers can be stored, and when a control instruction issued by an upper application program is received, the gateway middleware can perform data conversion first and then issue the control instruction to a specific bottom-layer basic device. For example, if the originally defined brightness value of a certain underlying basic device is in the range of 0 to 10, and the received control command is to adjust the brightness of the underlying basic device to "80", the adjustment may be performed first, and when the adjustment command is specifically sent to the underlying basic device, the adjusted target brightness value may be converted to "8", and so on.

During specific implementation, the gateway middleware can also store the numerical ranges defined by various manufacturers and the corresponding relationship between the unified numerical ranges, so as to convert the numerical ranges in a specific query or control process. For example, for the foregoing example of the lighting device, it can be specifically as shown in the following table 1:

TABLE 1

In addition to the lighting devices, regarding the temperature adjustment range of the temperature control device, the humidity adjustment range of the humidity control device, the signal intensity range of the network device, and the like, the differences between different manufacturers may be unified in the above manner, and corresponding mapping relationships may be stored. For example, with respect to a temperature control device, the stored mapping may be as shown in table 2 below:

TABLE 2

With respect to the humidity control apparatus, the stored mapping relationship may be as shown in the following table 3:

TABLE 3

In addition, the gateway middleware may also have functions of authority management, data caching, local service data processing, and the like, for example, regarding the data caching function, the acquired data of the underlying basic device may be cached locally in the gateway, so that when an upper application program needs to query some data, a response may be directly provided according to the cached data, and the like. And will not be described one by one here.

Regarding the cloud control server, the most core part in the cloud platform may be referred to as the "brain" of the whole smart building, and since the control server is located in the cloud, the control server may also be referred to as the "cloud brain" which may control the underlying infrastructure devices in a plurality of different smart buildings. In addition, in the embodiment of the application, the cloud control server may be mainly used to provide an API (application programming interface) for an upper application program, so that the upper application program may be constructed through the API, and then, in the running process of the application program, a corresponding operation request may be sent to the cloud control server in a manner of calling the API, so that the cloud control server may issue the operation request to the corresponding bottom-layer basic device through the gateway middleware to obtain related data of the corresponding bottom-layer basic device or issue a control instruction to the corresponding bottom-layer basic device.

In a specific implementation, regarding the provision of the API, in an implementation, a general API may be provided, and in this case, the name, the type, and the like of the controlled object may be specified when the application calls the API. However, this approach has the disadvantage that the developer of the application needs to have a corresponding knowledge of the name, type, and function point of the specific underlying infrastructure, which raises the knowledge threshold for the developer. For example, for the above general API call, it is usually necessary to uniquely locate a specific device through multiple parameters, such as (device ID, device type, state/action name), etc. The specific device ID, device type, and state/action name need to be specified by the developer in the program.

In order to reduce the knowledge threshold of the developer, so that a technician who does not have sufficient knowledge of the names, types, function points, and the like of the underlying basic devices can also perform development work of the application program, in the embodiment of the present application, corresponding improvements can be performed on a protocol level, and specifically, metadata for uniformly describing data generated by the underlying basic devices of each device type can be provided, where the metadata is also called intermediary data and relay data, and is data (data about) describing data, in the embodiment of the present application, the metadata is data for describing various items of data in the intelligent building system, and for example, a specific underlying basic device can correspond to a unique metadata. Thus, by using the metadata, the upper application can call the API by using the metadata as a parameter without setting a plurality of parameter values.

In order to implement data identification by means of metadata, in the embodiment of the present application, three types of entities of the Haystack may be implemented under the open building information exchange oBIX specification, where the three types of entities include a geographic location entity, an equipment entity, and an equipment function point location entity.

For ease of understanding, the relevant knowledge of the software level involved in the smart building cloud platform and the oBIX specification, the Haystack tag, are briefly introduced below.

In order to construct a complete intelligent building system, the BACnet standard is generated in the prior art, so that the intelligent building self-control network is changed from a proprietary type to an open type. On the basis of open standards, information of various intelligent building subsystems can be shared, so that a complete integrated intelligent building system can be constructed theoretically. In fact, however, even the accepted BACnet standard has difficulty in achieving seamless integration between different standards due to differences between the different standards. Therefore, if a common integration interface is established and all autonomous network standards support the common integration interface, the integration can be efficiently performed through the common integration interface.

With the demand for integration of enterprise applications (e.g., human resources, customer relations, financial management, etc.), there is an increasing demand for access of smart building systems to enterprise Management Information Systems (MIS) in order to fully analyze all operational information and make decisions of the enterprise. In addition, with the rapid development of a larger number of "machine-machine (M2M)" communication services, development of a "platform-independent, language-independent, and protocol-independent" system integration technology is also required. In the development process of the Internet, the XML/Web Services technology gradually becomes the focus of enterprise application integration by virtue of the characteristics of platform independence, language independence and protocol independence. The technology is widely applied in the IT industry due to openness, standardization and simplicity, and is permeating to the field of intelligent building automatic control and system integration application thereof at a high speed. The specific expression of the development trend is to integrate the intelligent building automatic control system by using the XML/Web Services technology, which represents the development direction of the intelligent building automatic control system integration technology.

Due to the advantages of the XML/Web Services technology, some standards organizations and equipment type academy have expanded the existing intelligent building automatic control network standard with the XML/Web Services technology or made a new XML/Web Services technology application standard. Among them, the CABA (continental north america Building automation) association initiated and formulated an open Building Information exchange standard obix (open Building Information exchange) based on XML/Web Services technology.

The oBIX standard is an intelligent building system integration technology with multidisciplinary intersection and fusion, has clear operation management function and comprehensive characteristics, has the functions of shielding the difference of different building automatic control network standards and providing a unified and open intelligent building system integration technology, and has the significance that the intelligent building system is used as a subsystem for enterprise application integration and is seamlessly integrated into an enterprise management information system, so that the intelligent building system has wider application.

As can be seen from the development process of the intelligent building system integration technology, the oBIX standard is an intelligent building system integration technology standard based on modern IT technology. Just like other system integration technologies, the oBIX standard defines contents such as an Information Model (Information Model), an Interoperation Mode (Interoperation Mode), and Network Transport (Network Transport) of Interoperation semantics of the smart building system by using core contents such as a data description function and an Interoperation mechanism of an XML/Web Services technology, thereby forming a basic system and corresponding basic contents thereof. In the oBIX standard, the information model is an object model based on an object (object) and a contract (contract), and the interoperation mode is a Read (Read), Write (Write), and Invoke (call) based interoperation mode established on the object model.

In the oBIX standard, an object is a low-level XML vocabulary or namespace that is "application-domain independent" and is a component element item (element) of an oBIX XML document. The object model can be used for describing information of other automatic control fields besides the information of the intelligent building system. All oBIX XML documents may be composed of an XML vocabulary or namespace specified by the object model. In addition, since the oBIX standard is composed of oBIX objects, in order to identify different types of oBIX objects, the oBIX standard employs a URI (Uniform Resource Identifier) identification manner.

Contract (Contract) is an XML document that consists of oBIX objects in the syntax specified by the oBIX standard, and is an application-specific semantic "object" model. That is, the contract is an XML document with an interoperation semantic described by an object model, or an oBIX object with a certain interoperation semantic, and the role of the contract is to standardize the description of the basic unit of the intelligent building system, so that users who implement or refer to the contract can know the interoperation semantic described by the contract, which makes the contract an interoperation semantic entity related to the application, that is, the contract is a high-level oBIX object with an interoperation semantic established on a low-level object model. For example, the contract named as oBIX, Alarm is a standard description unit of information related to Alarm in the oBIX standard, and the contract describes information such as Alarm source, Alarm time, Alarm receiver and the like by using an oBIX object model, so that users who realize and quote the contract can use and interpret the contract according to the standard structure of the contract and the interoperation semantics contained in the contract, thereby realizing the integration and interoperation of the system.

As can be seen from the effect of the contract, the contract is a higher-level semantic oBIX description standard unit. The relationship between the contract and the object model is just like the relationship between the basic data type and the object type of an object-oriented computer programming language (such as C + +, Java and the like), although the basic data type in the programming language is limited and fixed, the object type created by using the basic data type is not rigidly specified by the programming language, any application-related object type can be created by using the basic data type only according to the grammar rules of the programming language, and all the object types meeting the grammar rules of the programming can be identified and compiled by the same compiler (compiler). The object model and contract of the oBIX standard also adopt the idea that although the oBIX object model defines limited basic object types, any type of contract related to the application can be constructed by using the limited basic object types and contract object types under the XML syntax constraint specified by the oBIX standard, so that the oBIX standard has a powerful extension mechanism in description function.

By utilizing the idea, anyone can construct any type of contract according to application requirements. In order to standardize the common contract types, the oBIX standard is abstractly summarized, and the common contract types are defined as "standard type contracts", for example, oBIX: Point, oBIX: Alarm, oBIX: History and the like are standard contract objects. In the oBIX standard, the standard contract defined by the oBIX standard may also be referred to simply as "contract", whereas the contract defined by the user or building automation equipment manufacturer on the basis of the application itself is often referred to as "extended contract".

In an interoperation mode, the oBIX standard adopts a client/server (C/S) model, and summarizes all interoperation processes into three operation processes of Read, Write and Invoke. The Read is used for the client to Read the oBIX information of the server, the Write is used for the client to Write the oBIX information into the server, and the Invoke is used for the client to call the operation process of the server. This manner of interoperation is commonly referred to in the Web network environment as the rest (representational State transfer) manner. The REST mode is a general name of the above resource access modes, is a design mode oriented to network resource access, and any resource operation conforming to the access mode can be called as the REST mode.

As can be seen from the above description, the oBIX standard in the prior art has the characteristic of strong expansibility, but the inventors of the present application find that, in the process of implementing the embodiments of the present application, oBIX has the following disadvantages: lack of a certain service API, and are not flexible enough when querying, setting and other operations are performed on data. In other words, the oBIX standard is more suitable as a specification in industrial applications, but when the oBIX standard is directly applied to the smart building system, it is not flexible enough to provide a specific API on the basis of the specification.

Therefore, in the embodiment of the application, the characteristic of strong expansibility of the oBIX standard can be combined, and the oBIX standard is expanded on the basis of the original oBIX standard, so that the expanded standard has the characteristics of concise and light data and the like on the basis of the original advantages, thereby facilitating the realization of a specific API and providing more convenient conditions for the integration of upper-layer application programs. In particular, the inventors of the present application have conceived the HayStack tag because of its advantages in data compactness, portability, and maturity of device class tags. The HayStack abstracts the business objects into three types of entities, namely site (geographical/building position), inquiry (equipment entity) and point (functional point location), and allows an association relationship to be established between the entities, and the data format is concise and clear. Therefore, in the embodiment of the present application, the oBIX standard and the HayStack label may be combined, and the three types of entity structures of the HayStack are implemented under the oBIX specification, that is, the device class label of the HayStack is used as the extended service data, and the three layers of data entities, namely site/query/point, are specifically implemented under the oBIX specification.

Specifically, each layer of data entity may be expanded by the following methods:

(1) regarding Site tags in HayStack, a Location class can be extended from oBIX, which can be the top-level parent class of all the geo-Location objects, following the Site tags of HayStack, and in addition, includes a sublocation pointing to the lower layer, an uplocation pointing to the upper layer, a business entity entityCollect pointing to the associated business entity on the Location, and so on. That is, by instantiating the Location class, it can be used to represent a geo-Location object, such as a particular building, a floor, an area, etc.

(2) Regarding the Equip label of HayStack, a commEntity class may be implemented in oBIX, which may be a common parent for all device objects. That is, by instantiating the class, it can be used to represent a particular underlying infrastructure device, e.g., a certain air conditioner, a certain lighting device, etc. In specific implementation, for the commEntity class, different device class templates can be generated for different device classes, and specifically, when a certain underlying basic device is expressed, description can be performed by inheriting the template of the corresponding device class.

(3) Point label for HayStack. A commPoint class can be extended in the oBIX, the class can be a top-level abstraction of function points of the equipment, all Point templates can inherit the combPoint class, the Point instance inherits the corresponding template, and a main member of the Point instance can be a reference pointing to the equipment on the upper layer, which indicates that any Point belongs to a specific equipment. For example, for the "air conditioner" category of equipment, the equipment function points may be: and 8 functional points such as "power", "speed", "highspeed", "minute", "lowspeed", "model", "temp", "value", and the like, may be set with corresponding templates for the functional points, respectively. The devices of different device types have different function point locations, and therefore, corresponding templates can be generated for the function point locations corresponding to the devices of the device types respectively. In particular implementations, dependencies between device metadata may also be defined. For example, a certain equipment information template is a fresh air industry template AirCondition, and the is field of the new air industry template is h: equip h: hvac obix/def/extract/commEquip, which indicates that the template inherits the equip template of the obix and also follows the equip label and the hvac label of the HayStack label library, and thus the equipment instance is ensured to meet the data specification of the HayStack.

In this way, data in the system can be represented by metadata, and each type of data object can be identified by URI because of compliance with the oBIX specification.

For example, for a geographic location object "west region of first floor, second floor", the labels may be: "href": "http: while the specification that the object specifically conforms to and the HayStack label are also described through the field of "is". For example, "is": "h: site oBIX/def/contact/location ", from which the" is "field, the object inherits the oBIX location class and follows the site tag of the HayStack tag library.

As another example, for a specific underlying infrastructure device named "th _001_ XYZ", the URI identification thereof can be: "http: // … obix/ings/th _001_ XYZ ", the specification to which the object specifically conforms, and the HayStack label carried thereby, can also be described by the" is "field. For example, "is": the oBIX/def/schema/information oBIX/def/contact/siteRef h: equ h: hvac, from which the object inherits the information device class template of oBIX and the siteRef template and follows the equ tag and the hvac tag of the HayStack tag library. In addition, the device has 8 function point objects (Power, Speed, HighSpeed, MinSpeed, LowSpeed, Model, Temp, Value).

Through the method, the cloud control server can instantiate the geographical position objects, the basic devices and the function point positions on the devices in the specific intelligent building according to the method, namely, each geographical position, each basic device and each specific function point position in the intelligent building can correspond to the URI of each geographical position, each basic device and each specific function point position. Thus, if the upper layer application program needs to obtain the data of a specific object or control a specific object, the URI of the object can be used as a parameter to call the relevant API.

The specific API may be various, for example, GET, PUT, POST, and the like, and an internal implementation of each API may be defined in the cloud control server, that is, a specific processing flow when the specific API is called. For example, for the air conditioner th _001_ XYZ, if a certain upper application needs to acquire its temperature data, it can be realized by the following:

GET http://beehive/obix/things/th_001_XYZ/temp

after receiving the call request, the cloud control server can query according to the URI in the request, and can determine that the object inherits the information equipment type template and the siteff template of oBIX through the field of 'is' of the object and follows the equ tag and the hvac tag of a HayStack tag library, so that the air conditioning equipment of a specific fresh air equipment type can be identified, then the request can be correspondingly processed according to a specific processing flow defined in the API, an instruction for acquiring the temperature data of the equipment is sent to the corresponding gateway middleware, and after the gateway middleware uploads the specific temperature data, the temperature data is provided for a specific upper application program.

As another example, if a certain upper application needs to set the temperature of the air conditioner th _001_ XYZ to 38 degrees, the following sentence can be implemented:

it should be noted that, the process of querying or setting the data of the function point of the certain device is generally performed during the running process of the upper layer application, that is, a specific API call statement is already written in the code of the upper layer application, and a URI of a specific operation object is written in a parameter value of the statement.

In addition, by adding the h: prefix tag of the HayStack, the platform user can not only query the equipment level by level through the oBIX Location position, but also comprehensively query all the equipment with the tag through the tag characteristic of the HayStack, for example, query all the light sensor (lights tag) equipment located in the first floor and the second floor (siteff: 0102):

POST http://beehive/obix/compoundQuery

{“tag”:h:“lights”,siteRef:“0102”}

after receiving the request, the control server in the cloud may return a list of all light sensor devices located on first and second floors:

[{“obix”:“obj”,“name”:“th_001_ABC”,href＝“obix/things/th_001_ABC”...}]

moreover, through the h-prefix tag of the HayStack, a platform user can comprehensively query all functional point positions of certain equipment through the tag characteristics of the HayStack, such as:

GET http://beehive/obix/things/th_001_XYZ/

after receiving the request, the control server in the cloud may return a list of all function point location identifiers associated with the device:

[http://beehive/obix/things/th_001_XYZ/Power，http://beehive/obix/things/th_001_XYZ/Speed，http://beehive/obix/things/th_001_XYZ/HighSpeed，http://beehive/obix/things/th_001_XYZ/MinSpeed，http://beehive/obix/things/th_001_XYZ/LowSpeed，http://beehive/obix/things/th_001_XYZ/Model，http://beehive/obix/things/th_001_XYZ/Temp，http://beehive/obix/things/th_001_XYZ/Value]

it should be noted that, in specific implementation, the comprehensive query based on the tag characteristic is usually related in the process of developing the application program, for example, the embodiment of the present application may provide a development platform for a developer of the application program, and through the development platform, a developer may query which devices of a specific device category are located at a certain position by inputting the query statement, or query which function points are specifically located in a certain device, and then write a specific data query or control statement according to a query result, and so on.

As can be seen from the above, by combining the label attributes (Site location, equipment type, Point function Point) of the HayStack in the oBIX specification, a specific operation object can be queried and controlled more flexibly, and only by using one operation object URI as metadata, all required information can be obtained, or control over the operation object can be achieved. Therefore, whether the application program is native to the platform or the application program developed by a third-party developer, the specific application program can be realized in an API calling mode without understanding information such as the device type, the functional attribute and the like of the specific device.

In addition, through this kind of mode, also can better realize the linkage between the equipment of different equipment categories. Specifically, the operation request submitted by the application program in the operation process last time may include an operation request for operating a plurality of bottom-layer basic devices in different device categories, and at this time, the control server in the cloud may issue the operation request to each corresponding bottom-layer basic device through the gateway middleware, so as to obtain related data of each bottom-layer basic device or issue a control instruction to each bottom-layer basic device respectively. For the upper application program, a sentence for operating each underlying basic device may be implemented, and a specific linkage rule is set through the sentence, for example, when the brightness of the lighting device in a certain area reaches a certain first value, the temperature of the air conditioning device in the certain area is adjusted to a certain second value, and so on. Alternatively, in order to further simplify the operation of the developer, the above-described sentence may be subjected to a componentization process so that the developer can set the association rule by selecting a component. This kind of control mode of linkage can realize real intellectuality, for example, through the combination control to software and hardware such as no card video identification parking system, property management, meeting room use management, little post office, WIFI access, printer, make the user can easily accomplish a large amount of work in the building fast, the property managers can be in very convenient ground to the building maintenance update simultaneously, practices thrift the operation cost, etc..

It should be noted that, in the embodiment of the present application, implementation forms of specific upper layer applications may not be limited, and both the platform itself and a third-party developer may be programmed based on an API opened by the platform to provide specific services for users in the smart building. For example, the platform itself may provide some native applications or services, which may include: the gateway middleware collects data of each device in the building and performs data analysis (including energy consumption analysis and the like), and specific data analysis results can be provided for application programs to use or can also be provided for managers of the building, and the like. The application program developed by the third party can be more flexible and diversified, and for example, the application program can comprise automatic lamp control, reservation and meal ordering, face recognition, station time-sharing leasing, visitor self-service, reverse car searching, parking space reservation and the like. The specific control logic and the like in the application program may be set by the developer, and is not limited here.

In a word, the sensor is used as a sense organ of the building, and can collect various basic data (environment, people and facility equipment) in the building, the basic data reach the control server at the cloud end through the gateway equipment of the building, and the control server at the cloud end opens various API interfaces for developers to develop and use the basic data so as to provide better service for users and owners of the building. By the aid of the platform open standard, data generated by basic equipment of each equipment type can be comprehensively used by upper-layer application programs, and linkage control can be performed on equipment of each equipment type, so that information isolated islands can be avoided, users can be perceived, the users can be perceived, and the periphery can be perceived. Meanwhile, by depending on the own ecosystem, a third-party organization/person can be attracted to enter the building, and infinite and continuous evolving services are provided for the building, the person and equipment, so that the requirements of diversification and individuation of the person in the building are continuously met, and the whole building forms an organic, continuous evolving and open life body.

Example two

The second embodiment corresponds to the first embodiment, and provides an intelligent building control method from the perspective of the cloud control server, referring to fig. 2, where the method specifically includes the following steps:

s201: the control server located at the cloud end provides an Application Programming Interface (API);

s202: when a call request of an upper application program to the API is received, determining a target intelligent building and target gateway middleware deployed in the target intelligent building;

s203: and issuing the calling request to corresponding bottom-layer basic equipment through the target gateway middleware so as to operate the bottom-layer basic equipment.

In specific implementation, in order to implement API call more conveniently, metadata for performing unified description on data generated by the underlying base device of each device class may be further provided, so that the upper application program calls the API with the metadata as a parameter.

Specifically, three types of entities of the Haystack can be realized under the open building information exchange oBIX specification, the three types of data entities include a geographical position entity, an equipment entity and an equipment function point location entity, and then, data related to the underlying basic equipment is subjected to unified description through the three types of data entities to generate the metadata.

In this case, when receiving a call request of the upper application to the API, the target entity under the oBIX specification inherited by the requested operation object and the target tag under the Haystack specification followed may be determined according to metadata carried in the call request, and then the target entity and the target tag are provided to the target gateway middleware, so that the target gateway middleware issues the operation request to the corresponding underlying base device according to the target entity and the target tag.

During specific implementation, the call request comprises a request for acquiring relevant data of a target function point location of target bottom-layer basic equipment, and at this time, the request for acquiring the relevant data can be issued to the corresponding bottom-layer basic equipment through the target gateway middleware, so that the bottom-layer basic equipment returns the relevant data of the target function point location, and the target gateway middleware returns the relevant data to the control server; and then, providing the relevant data returned by the target gateway middleware to the upper application program.

Or, the call request includes a request for setting a target function point location of a target underlying basic device, and at this time, the setting request may be issued to the corresponding underlying basic device through the target gateway middleware, so that the underlying basic device sets the target function point location according to the request.

In addition, through the use of the Haystack tag, more convenient query can be realized, and specifically, a request for querying the information of the equipment object with the target Haystack tag at the target geographic position can be received, and the metadata of each equipment object with the Haystack tag is provided. Or, a request for querying function point location information associated with a target device object may also be received, and metadata of each function point location associated with the target device object is provided.

EXAMPLE III

In a third embodiment, which is also corresponding to the first embodiment, from the perspective of the gateway middleware, there is provided an intelligent building control method, specifically, referring to fig. 3, the method may include:

s301: the gateway middleware positioned in the building unifies the data expression modes of different bottom layer basic devices in the same device type in the building;

s302: receiving an API (application program interface) calling request sent by a control server of a cloud; the API call request is sent by an upper application program;

s303: determining target bottom-layer basic equipment according to the calling request;

s304: and sending the calling request to the target bottom-layer basic equipment so as to operate the target bottom-layer basic equipment.

The calling request comprises a request for acquiring relevant data of a target function point position of target bottom-layer basic equipment, at the moment, after the relevant data returned by the target bottom-layer basic equipment is received, data conversion can be carried out according to the data expression mode after unified processing, and then the converted data is returned to the cloud control server so as to be returned to the upper-layer application program by the cloud control server.

Or, the call request includes a request for setting a target function point location of the target underlying basic device, and at this time, before the call request is sent to the target underlying basic device, a numerical value carried in the request may be converted according to the data expression mode after the unification processing and the original data expression mode of the target underlying basic device, so that the setting request is sent to the target underlying basic device by using the converted numerical value, and the target underlying basic device executes a setting operation according to the setting request.

For the second embodiment and the third embodiment, specific implementation details may be referred to the description in the first embodiment, and are not described herein again.

Example four

In the foregoing embodiments, the specific implementation manner is described based on the intelligent building control system. In practical applications, the description manner of "metadata" provided in the embodiment of the present application may also be applied to other systems, and for this reason, the embodiment of the present application further provides a data processing method, see fig. 4, where the method may include the following steps:

s401: three types of entities of Haystack are realized under the open building information exchange oBIX specification, wherein the three types of data entities comprise a geographical position entity, an equipment entity and an equipment function point location entity;

s402: performing unified description on data related to the underlying basic equipment through the three types of entities to generate the metadata;

s403: providing an Application Programming Interface (API) so as to utilize the API and the metadata to develop an upper-layer application program;

s404: when a call request of an upper application program to the API is received, a target entity under an oBIX specification inherited by a target operation object and a target label under a Haystack specification are determined according to metadata carried in the request, so that the operation object is operated according to the target entity and the target label.

In a specific implementation, the geolocation entity includes a top-level parent class Location of the geolocation object, and its members include a sublobtion class pointing to the lower layer, an uplocation class pointing to the upper layer, and a clastyselect class pointing to the geolocation object associated device object.

The device entity may include a device class template respectively established for each device class, and a member of the device entity includes a function point location of a device corresponding to the device class, so as to generate metadata of the device object by inheriting the device class template corresponding to the device class.

The member of the device function point location entity comprises a reference pointing to the upper layer device.

In specific implementation, the call request includes a request for obtaining data related to a target function point location of a target underlying basic device, and specifically, when the operation object is operated according to the target entity and the target tag, the data related to the target underlying basic device at the target function point location may be obtained according to the target entity and the target tag, and provided to the upper application program.

The system comprises a target intelligent building, a data storage device and a data processing device, wherein the target intelligent building comprises a plurality of pieces of bottom foundation equipment, the bottom foundation equipment comprises the bottom foundation equipment in the target intelligent building, a gateway middleware is also deployed in the target intelligent building, and the data expression modes of different bottom foundation equipment in the same equipment category are unified through the gateway middleware;

at this time, specifically, when the relevant data of the target underlying basic device at the target function point is obtained according to the target entity and the target tag, a request for obtaining the relevant data may be first sent to the gateway middleware according to the target entity and the target tag, so that after the gateway middleware receives the data submitted by the target underlying basic device, data conversion is performed according to the data expression manner after the normalization processing, and the converted data is returned, and then, the relevant data, which is provided by the gateway middleware and is related to the target underlying basic device at the target function point, may be received.

In addition, the call request may also include a request for setting a target function point location of a target underlying basic device, and at this time, when the operation object is operated according to the target entity and the target tag, the setting request may be issued to the target underlying basic device according to the target entity and the target tag, so that the target underlying basic device sets the target function point location according to the request.

Similarly, if the bottom foundation equipment comprises bottom foundation equipment in a target intelligent building, wherein a gateway middleware is also deployed in the target intelligent building, and the data expression modes of different bottom foundation equipment in the same equipment category are unified through the gateway middleware; specifically, when the setting request is issued to the target underlying basic device, the setting request may be sent to the gateway middleware according to the target entity and the target tag, so that the gateway middleware converts the numerical value carried in the request according to the data expression mode after the unification processing and the original data expression mode of the target underlying basic device, sends the setting request to the target underlying basic device by using the converted numerical value, and executes the setting operation according to the setting request by the target underlying basic device.

Therefore, by combining label attributes (Site location, equipment type and Point function Point) of the HayStack under the oBIX specification, the equipment can be inquired and controlled more flexibly, and the required data can be obtained or the equipment can be controlled only by one equipment object URI. In addition, by adding the h-prefix tag of the HayStack, a platform user can not only inquire equipment level by level through the OBIX Location position, but also comprehensively inquire all equipment with the tag through the tag characteristic of the HayStack.

For example, during the development phase of an application, a request to query the target geographic location for information about a device object tagged with a target Haystack tag may be received, providing metadata for the respective device object tagged with the Haystack tag.

Or, a request for querying function point location information associated with a target device object may also be received, and metadata of each function point location associated with the target device object is provided.

In a word, through the fourth embodiment, a mature building industry tag library of the HayStack is integrated, and the definition of a three-layer data entity of the HayStack site/query/point under the OBIX specification is specifically implemented, so that an API conforming to the HayStack specification can be used as a unified entry point, compound query under the OBIX specification is realized, and the efficiency of querying and exchanging data can be improved. Meanwhile, the metadata scheme based on the mixed tags ensures barrier-free interaction of data among various devices.

For specific implementation of the fourth embodiment, reference may also be made to the description in the first embodiment, and details are not described here.

Corresponding to the second embodiment, the embodiment of the present application further provides an intelligent building control device, and in particular, the device is applied to a control server located in a cloud, referring to fig. 5, and the device may include:

an API providing unit 501 for providing an application programming interface API;

a gateway middleware determining unit 502, configured to determine a target smart building and a target gateway middleware deployed therein when receiving a call request of an upper application to the API;

a call request issuing unit 503, configured to issue the call request to the corresponding bottom-layer basic device through the target gateway middleware, so as to operate the bottom-layer basic device.

In a specific implementation, the apparatus may further include:

and the metadata providing unit is used for providing metadata for uniformly describing data generated by the underlying basic equipment of each equipment type, so that the upper application program calls the API by taking the metadata as a parameter.

In an implementation manner, the metadata providing unit may specifically include:

the system comprises an entity realization subunit, a data processing subunit and a data processing subunit, wherein the entity realization subunit is used for realizing three types of entities of Haystack under an open building information exchange oBIX specification, and the three types of data entities comprise a geographical position entity, an equipment entity and an equipment function point location entity;

and the metadata generation subunit is used for performing unified description on the data related to the underlying basic equipment through the three types of entities to generate the metadata.

In specific implementation, when a call request of an upper application program to the API is received, the method further includes:

the information determining unit is used for determining a target entity under an oBIX specification inherited by the requested operation object and a target label under a Haystack specification followed by the operation object according to metadata carried in the calling request;

when the operation request is issued to the corresponding bottom-layer basic device through the target gateway middleware, the method further includes:

and the information providing unit is used for providing the target entity and the target label to the target gateway middleware so that the target gateway middleware can issue the operation request to corresponding bottom-layer basic equipment according to the target entity and the target label.

The call request includes a request for obtaining data related to a target function point location of a target underlying basic device, and the call request issuing unit may specifically be configured to:

the request for acquiring the related data is issued to corresponding bottom-layer basic equipment through the target gateway middleware, so that the bottom-layer basic equipment returns the related data of the target function point location, and the target gateway middleware returns the related data to the control server; and providing the relevant data returned by the target gateway middleware to the upper application program.

Or, the call request includes a request for setting a target function point of a target underlying basic device, and the call request issuing unit may specifically be configured to:

and issuing the setting request to corresponding bottom-layer basic equipment through the target gateway middleware so that the bottom-layer basic equipment can set the target function point location according to the request.

In addition, can also realize batch inquiry operation through the Haystack label, specifically, the device can also include:

the first query request receiving unit is used for receiving a request for querying the equipment object information of which the target geographical position is provided with a target Haystack label;

and the first query result providing unit is used for providing metadata of each equipment object with the Haystack label.

Alternatively, the apparatus may further include:

the second query request receiving unit is used for receiving a request for querying the function point location information associated with the target equipment object;

and the second query result providing unit is used for providing metadata of each function point associated with the target equipment object.

Corresponding to the embodiment, the present invention further provides an intelligent building control device, which is applied to a gateway middleware located inside a building, and referring to fig. 6, the intelligent building control device may specifically include:

the unified processing unit 601 is configured to perform unified processing on data expression modes of different underlying basic devices in the same device class in a building;

a call request receiving unit 602, configured to receive an API call request sent by a control server in the cloud; the API call request is sent by an upper application program;

a bottom-layer basic device determining unit 603, configured to determine a target bottom-layer basic device according to the call request;

a call request sending unit 604, configured to send the call request to the target underlying basic device, so as to operate the target underlying basic device.

The calling request comprises a request for acquiring data related to target function point positions of target underlying basic equipment;

at this time, the apparatus may further include:

the first conversion unit is used for performing data conversion according to the data expression mode after the unification processing after receiving the related data returned by the target bottom-layer basic equipment;

and the conversion result returning unit is used for returning the converted data to the cloud control server so as to be returned to the upper application program by the cloud control server.

Or the calling request comprises a request for setting a target function point of the target underlying basic equipment;

the device further comprises:

and a second conversion unit, configured to convert, before sending the call request to the target underlying basic device, a numerical value carried in the request according to the data expression manner after the unification processing and an original data expression manner of the target underlying basic device, so as to send the setting request to the target underlying basic device by using the converted numerical value, and execute a setting operation by the target underlying basic device according to the setting request.

Corresponding to the fourth embodiment, an embodiment of the present application further provides a data processing apparatus, and referring to fig. 7, the apparatus may include:

an entity implementation unit 701, configured to implement three types of entities of a Haystack under an open building information exchange oBIX specification, where the three types of data entities include a geographic location entity, an equipment entity, and an equipment function point location entity;

a metadata generating unit 702, configured to perform unified description on the data related to the underlying infrastructure device through the three types of entities, and generate the metadata;

an API providing unit 703 for providing an application programming interface API to perform upper application development using the API and the metadata;

a call request processing unit 704, configured to, when receiving a call request of an upper application to the API, determine, according to metadata carried in the request, a target entity under an oBIX specification inherited by a target operation object and a target tag under a Haystack specification followed by the target operation object, so as to operate the operation object according to the target entity and the target tag.

Wherein the geolocation entity comprises a top-level parent class of geolocation objects, whose members include a class pointing to a lower layer, a class pointing to an upper layer, and a class pointing to a geolocation object-associated device object.

The device entity comprises device class templates respectively established for the device classes, and the members of the device entity comprise function point positions of devices corresponding to the device classes, so that the metadata of the device object is generated by inheriting the device class templates corresponding to the device classes.

In a specific implementation, the call request includes a request for obtaining data related to a target function point of a target underlying basic device, and the call request processing unit may specifically be configured to:

and acquiring related data of the target bottom-layer basic equipment at the target function point according to the target entity and the target label, and providing the related data to the upper-layer application program.

the call request processing unit may specifically include:

a request sending subunit, configured to send, to the gateway middleware, a request for obtaining the relevant data according to the target entity and the target tag, so that the gateway middleware performs data conversion according to the data expression manner after receiving the data submitted by the target underlying basic device, and returns the converted data;

and the data receiving subunit is configured to receive the relevant data, provided by the gateway middleware, about the target underlying basic device at the target function point.

Or, the call request includes a request for setting a target function point of a target underlying basic device, and the call request processing unit may be specifically configured to set a target function point of a target underlying basic device, where the call request processing unit is configured to perform a call request

And issuing the setting request to the target bottom layer basic equipment according to the target entity and the target label so that the target bottom layer basic equipment can set the target function point location according to the request.

the call request processing unit may specifically be configured to:

and sending the setting request to the gateway middleware according to the target entity and the target label so that the gateway middleware converts a numerical value carried in the request according to the data expression mode after the unification processing and the original data expression mode of the target underlying basic device, sends the setting request to the target underlying basic device by using the converted numerical value, and executes setting operation according to the setting request by the target underlying basic device.

In addition, the apparatus may further include:

Alternatively, the apparatus may further include:

From the above description of the embodiments, it is clear to those skilled in the art that the present application can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the present application may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments of the present application.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the system or system embodiments are substantially similar to the method embodiments and therefore are described in a relatively simple manner, and reference may be made to some of the descriptions of the method embodiments for related points. The above-described system and system embodiments are only illustrative, wherein the units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

The data processing method and apparatus provided by the present application are introduced in detail, and a specific example is applied in the present application to explain the principle and the implementation of the present application, and the description of the above embodiment is only used to help understand the method and the core idea of the present application; meanwhile, for a person skilled in the art, according to the idea of the present application, the specific embodiments and the application range may be changed. In view of the above, the description should not be taken as limiting the application.

Claims

1. A data processing method, comprising:

performing unified description on data related to underlying basic equipment through the three types of entities to generate metadata;

2. The method of claim 1, wherein the geo-location entity comprises a top level parent class of geo-location objects, and wherein the members thereof comprise a class pointing to a lower layer, a class pointing to an upper layer, and a class pointing to a geo-location object associated device object.

3. The method according to claim 1, wherein the device entity comprises device class templates respectively established for the device classes, and the members of the device entity comprise function point points of devices of the corresponding device class, so as to generate metadata of the device object by inheriting the device class templates of the corresponding device class.

4. The method of claim 1, wherein the member of the device point location entity comprises a reference to its upper level device.

5. The method according to claim 1, wherein the call request includes a request for obtaining data related to target function point locations of a target underlying infrastructure, and the operating the operation object according to the target entity and the target tag includes:

6. The method of claim 5, wherein the underlying infrastructure includes underlying infrastructure within a target smart building, and wherein a gateway middleware is deployed within the target smart building, and data representation of different underlying infrastructures within the same device class is unified by the gateway middleware;

the obtaining, according to the target entity and the target tag, relevant data of the target underlying basic device at the target function point location includes:

sending a request for acquiring the related data to the gateway middleware according to the target entity and the target label, so that the gateway middleware performs data conversion according to the data expression mode after the gateway middleware receives the data submitted by the target bottom-layer basic equipment and returns the converted data;

and receiving related data provided by the gateway middleware and related to the target underlying basic equipment at the target function point.

7. The method according to claim 1, wherein the call request includes a request for setting a target function point of a target underlying infrastructure device, and wherein the operating the operation object according to the target entity and the target tag includes:

8. The method of claim 7, wherein the underlying infrastructure includes underlying infrastructure within a target smart building, wherein a gateway middleware is further deployed within the target smart building, and data representation of different underlying infrastructures within the same device class is unified through the gateway middleware;

the issuing of the setting request to the target underlying basic device includes:

9. The method of claim 1, further comprising:

receiving a request for inquiring the equipment object information with a target Haystack label at a target geographic position;

providing metadata for the respective device objects with the Haystack tag.

10. The method of claim 1, further comprising:

receiving a request for inquiring function point location information associated with a target equipment object;

and providing metadata of each function point associated with the target equipment object.

11. A data processing apparatus, comprising:

the metadata generation unit is used for performing unified description on data related to the underlying basic equipment through the three types of entities to generate the metadata;

12. The apparatus according to claim 11, wherein the call request includes a request for obtaining data related to target function point locations of a target underlying infrastructure device, and the call request processing unit is specifically configured to:

13. The apparatus according to claim 11, wherein the call request includes a request for setting a target function point of a target underlying basic device, and the call request processing unit is specifically configured to:

14. The apparatus of claim 11, further comprising:

15. The apparatus of claim 11, further comprising: