HK1232355B - Application environment for lighting sensor networks - Google Patents

Description

Application Environment of Lighting Sensor Networks

Related applications

This application claims the benefit of priority to U.S. Patent Application No. 14/639,872, filed on March 5, 2015, and to U.S. Provisional Application No. 61,948,856, filed on March 6, 2014, each of which is incorporated herein by reference in its entirety.

This provisional application is related to U.S. non-provisional patent application No. 14/024,561, entitled “Networked Lighting Infrastructure for Sensing Applications,” filed on September 11, 2013, and its related U.S. provisional application No. 61/699,968, the contents of which are attached as Appendix A.

Technical Field

Embodiments of the present invention generally relate to processing sensor data, and more particularly, but not by way of limitation, to processing sensor data at sensor nodes within a network.

Background Art

Sensor networks are currently being used in a wide range of applications. For example, data collected by sensor networks can be used for environmental monitoring, security and surveillance, logistics and transportation, control and automation, and traffic monitoring. Sensor networks consist of sensor nodes that communicate with a central server via a network. This allows the devices to store and process sensor data using more resources. However, some types of sensors generate large amounts of sensor data (without modifying the data), which can be difficult to transmit to a central server or platform that processes the sensor data for use by software applications.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which:

FIG. 1A is a diagram of a lighting sensor network suitable for use in various embodiments.

1B illustrates a block diagram of a lighting node in communication with a service data platform, according to an example embodiment.

2A illustrates a diagram of a service endpoint platform that receives high-bandwidth data from sensors and provides low-bandwidth data to a network, according to an example embodiment.

2B illustrates a block diagram of a service data platform having multiple servers, according to an example embodiment.

3A illustrates a diagram of an exemplary software architecture that enables an endpoint application framework to communicate with a service data platform to process sensor data at a lighting node, according to an example embodiment.

3B illustrates a diagram of an endpoint application framework with multiple containers, according to an example embodiment.

4A illustrates a block diagram of a lighting network having multiple lighting fixtures, according to an example embodiment.

4B illustrates a block diagram of a lighting node with a service endpoint platform in communication with sensors, according to an example embodiment.

4C illustrates a block diagram of a lighting node, according to an example embodiment.

5A illustrates a diagram of a lighting node having multiple components, according to an example embodiment.

5B illustrates a diagram of a service data platform having multiple components, according to an example embodiment.

5C is a diagram of an exemplary software application for processing sensor data at a lighting node, according to an example embodiment.

6 illustrates an example of a tree used by a service data platform to organize and manage lighting nodes within a lighting network.

7 illustrates a diagram of a service data platform using an application programming interface (API) and a lighting network to communicate with users, according to an example embodiment.

8 illustrates a block diagram of a service data platform in communication with lighting nodes within a lighting network, according to an example embodiment.

9A is a flow chart illustrating a method for processing sensor data at a lighting node within a network, according to an example embodiment.

9B is a flow diagram illustrating a method for deploying software to lighting nodes in a network, according to an example embodiment.

10 is a block diagram illustrating an example of a software architecture that may be installed on a machine, according to some example embodiments.

11 illustrates a diagrammatic representation of a machine in the form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed according to an example embodiment.

The headings provided herein are for convenience only and do not necessarily affect the scope or meaning of the terms used.

DETAILED DESCRIPTION

The following description includes systems, methods, techniques, instruction sequences, and computer program products that embody illustrative embodiments of the present invention. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. However, it will be apparent to those skilled in the art that embodiments of the inventive subject matter may be practiced without these specific details. Generally, well-known instruction examples, protocols, structures, and techniques need not be presented in detail.

In a lighting sensor network, sensor data is collected at endpoints within lighting nodes (referred to as service endpoint platforms). The sensor data (e.g., processed and raw sensor data) is forwarded to a central server (referred to as a service data platform), which collects and stores the processed and raw sensor data from the nodes. The central server can also process the sensor data and provide access to the sensor data or applications that utilize it. Various embodiments described below enable the execution of third-party software applications at lighting nodes (or other nodes). Third-party software applications can be used to customize data results at endpoints of the lighting sensor network using specialized heuristics.

The various embodiments of the lighting sensor networks described in this specification provide many of the following features: providing a secure application execution environment for third-party software applications at lighting nodes; providing node-based sensor data to third-party software applications while managing data security and privacy at the lighting nodes; providing site-based sensor data to third-party applications while managing data security and privacy; using programming interfaces to provide support for management functions of third-party application software; managing data communication between third-party software application scripts and third-party applications uploaded to a service data platform in the cloud; managing the deployment of third-party application software to lighting nodes; and managing the coexistence of multiple third-party software applications on endpoints (e.g., a service endpoint platform).

Various techniques are disclosed that enable third parties (e.g., application developers, etc.) to access sensor data (including raw sensor data and sensor data events) and execute third-party software on lighting nodes within a lighting sensor network. The executed third-party software may include applications, scripts, routines, programs, etc.

Third-party application developers may be able to formulate rule sets for generating heuristics and other analyses of specific types of sensor data collected at various lighting nodes within the lighting sensor network. Examples of sensor data include motion detection data, ambient light sensor data, audio data, image data, video data, and accelerometer data.

With access to the lowest level sensor data available at the lighting nodes (eg, sensor data that has not been filtered, aggregated, or otherwise altered by the various devices within the light sensor network), third parties may develop third party software that utilizes this lowest level sensor data for various purposes.

In various embodiments, the lighting node may be configured to execute third-party software in an operating environment in which various applications may not affect each other or the normal operation of the lighting node. In other words, the lighting node may provide a sandbox for safely allowing third-party software to execute without affecting the output or operation of the lighting node.

In some embodiments, a computing device within the service data platform (e.g., a cloud server, etc.) can be configured to accept third-party software targeted for deployment at lighting nodes. The computing device within the service data platform can scan, profile, debug, process, and/or otherwise analyze the third-party software to identify issues or potentially harmful content before distributing the software to the various lighting nodes for execution. For example, the third-party software can be identified as potentially malicious software or other software capable of generating a network attack or equipment shutdown.

The lighting sensor network can provide an application scripting environment in which third parties can access detailed sensor data collected from lighting nodes and perform node-based processing on the detailed sensor data without adding unnecessary congestion to the lighting network. In addition, third parties can provide third-party software (e.g., scripts) that can be customized to provide different entities or pursuits with relevant or desired information.

In various embodiments, a lighting network (including lighting nodes) may be located at a customer site. The customer may authorize a third party to access and process raw sensor data at the lighting nodes within the lighting network located at the customer site, with or without payment. An example may be a parking garage service company that desires to access raw sensor data at lighting nodes within a parking garage located at the customer site. The parking garage customer site authorizes the parking garage service company to deploy a third-party software application at the lighting nodes located at the customer parking garage site and then access and process the raw sensor data by executing the third-party software application at the lighting nodes located at the parking garage customer site.

In an exemplary embodiment, deployment of third-party software applications and access to node-based processed sensor data is performed via a service data platform residing in a cloud computing environment. Various embodiments provide methods, devices, systems, and non-transitory processor-readable storage media for an application scripting environment utilized within a lighting sensor network.

Examples of such lighting sensor networks are described in U.S. non-provisional patent application Ser. No. 14/024,561, filed Sep. 11, 2013, and entitled “Networked Lighting Infrastructure for Sensing Applications,” and in its related U.S. provisional application Ser. No. 61/699,968, filed Sep. 12, 2012, the contents of which are incorporated by reference in their entireties.

The NetSense light sensor network platform developed by Sensity Systems, Inc. of Sunnyvale, Calif., provides an example of a lighting sensor network that can be used to implement the various described embodiments. The NetSense framework enables deployment of a variety of sensors using a lighting infrastructure that allows applications to access sensor data at the nodes.

1A illustrates an implementation of a light sensor network 160 suitable for use in various embodiments. The lighting sensor network 160 enables deployment of a variety of sensors using a lighting infrastructure that allows applications running on lighting nodes associated with the lighting infrastructure to securely access sensor data for processing.

1A shows various components of a lighting sensor network 160. The lighting sensor network 160 represents a lighting infrastructure networked with a service data platform 140. The lighting nodes 105 (which, according to one embodiment, include sensors 416 and a service endpoint platform 110) can communicate via a network, such as a wide area network (WAN) 130, to communicate with the service data platform 140, which can reside in a cloud computing environment.

Lighting fixtures are included within the lighting infrastructure. The lighting infrastructure may be referred to as or located at a customer site. In various embodiments, the service data platform 140 may be owned and operated by an entity (e.g., Sensity Systems), and the owner of the lighting infrastructure may be a customer of that entity. The service endpoint platform 140 may be installed at each lighting fixture. In alternative embodiments, only some of the lighting fixtures within the lighting infrastructure include the service endpoint platform 140. The service endpoint platform 140 may provide the functionality described below.

The service endpoint platform 110 includes networking capabilities that connect light fixtures (within the lighting infrastructure) with the service data platform 140 in the cloud and supports communications between light fixtures or lighting nodes 105. The service endpoint platform 110 provides a computing platform for managing communications, sensor data, and processing at the lighting nodes 105. The service endpoint platform 110 further provides a sensor interface that allows sensors 416 to be connected to the service endpoint platform 110 within the lighting nodes 105.

The service data platform 140 provides the functionality described below. In an exemplary embodiment, the service data platform 140 represents a centralized server in the cloud that communicates with the lighting nodes 105 having the service endpoint platform 110. Sensor data provided by the lighting nodes 105 is collected and stored in the service data platform 140. The sensor data provided by the lighting nodes 105 may have some processing performed at the lighting nodes 105 by one or more of the sensor applications 120. In particular, sensor data received at the lighting nodes 105 at high bandwidth rates (in which case it may be difficult to transmit such large amounts of raw sensor data over a network (e.g., WAN 130)) may be processed at the lighting nodes 105. The results of the node-based processed sensor data may then be transmitted over WAN 130 to the service data platform 140 (where the node-based processed sensor data is collected and stored) and may be accessed by authorized users or applications.

The service data platform 140 can process the sensor data provided by the lighting nodes 105. The sensor data processed by the service data platform 140 includes node-processed sensor data and sensor data that has not been processed by the lighting nodes 105. In some examples, the data received by the service data platform 140 may include compressed data or other forms of altered raw sensor data. The sensor data received by the service data platform 140 may also be processed by the service data platform 140. In various embodiments, the processing performed by the service data platform 140 may include: performing analysis on the sensor data by the analysis server 266 shown in Figure 2B, which accesses the sensor data from the database 291 via the database server 290.

The service data platform 140 also provides both programmatic access via an API server and web access via a web server to data stored in the service data platform 140. For example, the service data platform 140 may provide an aggregated data API 141 for third-party applications to access sensor data stored in the service data platform 140. In another example, the service data platform 140 may also provide access to sensor data via a web server 280. The service data platform 140 may also provide an application management API 142 for uploading applications to be deployed at the lighting nodes 105. The aggregated data API 141 and the application management API 142 are shown in FIG. 1B .

FIG1B illustrates a high-level block diagram illustrating a lighting sensor network 160, according to an example embodiment. The lighting sensor network 160 may include lighting nodes 105 in communication with a service data platform 140. In an example embodiment, each of the service endpoint platforms 110 (shown in FIG1A ) in the lighting nodes 105 may execute one or more sensor applications 120 deployed by the service data platform 140 for node-based sensor processing. Node-based sensor processing is commonly used to perform analysis on sensor data available at the lighting nodes 105 and is particularly well-suited for sensors that provide high-bandwidth data that is not easily transmitted over a network without compression or other modifications to the sensor data.

The sensor applications 120 running on the lighting nodes 105 can be developed by third parties that want to access sensor data and perform analytics on the sensor data available from the lighting sensor network 160 (specifically, sensor data for analytical processing at the lighting nodes 105). The results of the analytical processing at the lighting nodes 105 are transmitted via the WAN 130 to the service data platform 140 for storage.

One or more sensor applications 120 may be executed on each of the lighting nodes 105. In various embodiments, the sensor applications 120 may be implemented using a scripting language. Each sensor application 120 on the lighting node 105 executes within a separate container to create a secure operating environment for each of the sensor applications 120. In various embodiments, the execution of one of the sensor applications 120 does not interfere with the operation of other sensor applications 120 running at the lighting node 105, nor does it interfere with or hinder the normal operation of the lighting node 105 or any lighting fixtures associated with the lighting node 105. Each of the sensor applications 120 may be executed in a sandbox to provide a secure environment for the sensor application 120 to be executed at the lighting node 105.

Referring to FIG3B , according to an embodiment, an endpoint application framework 310 includes multiple sensor applications 220 through 222, each within a separate container 320 through 322. Sensor applications 220 through 222 may represent sensor application 120. Container 320 manages resources for running sensor applications, which may be implemented using a scripting language (sometimes referred to as an application script). For example, a container can be used to define resource limits for its associated sensor application (e.g., central processing unit (CPU), memory, access to data and files), and prevent corrupted code from corrupting sensor applications in other containers. In an exemplary embodiment, each application script runs in a separate application container (e.g., container 320). Sensor applications 220 through 222 represent application scripts or other software programs executable within endpoint application framework 310. FIG3B also shows an interface 360 that can be used to provide a management API 340, an application API 350, and a sensor data API 330.

The endpoint application framework 310 provides a framework for executing sensor applications 220-222 or other software programs that provide node-based processing of sensor data by managing the containers 320-322 and the interface 360. In various embodiments, the lighting node 105 may be configured to execute various third-party software in an operating environment in which the various applications may not affect each other or the regular operation of the lighting node 105. In other words, the lighting node 105 may provide a sandbox for securely allowing third-party software to execute without affecting the output of the lighting node 105 or the operation of the lighting node 105.

Referring back to FIG. 1B , lighting nodes 105 are included in a lighting network 100. The lighting network 100 may include lighting fixtures. The lighting nodes 105 may be directly or indirectly connected to the lighting fixtures. In example embodiments, some lighting nodes 105 may not be directly connected or associated with a lighting fixture. In other embodiments, the lighting nodes 105 within the lighting network 100 may communicate with each other to transmit sensor data from one lighting node 105 to another lighting node 105 for node-based processing of the sensor data and transmission to the WAN 130. In other embodiments, some or all of the lighting nodes 105 may provide node-based processing of the sensor data via the sensor application 120.

The lighting nodes 105 may be associated with lighting fixtures by being directly or indirectly attached to the lighting fixtures, or may be remotely connected to the lighting fixtures. In various embodiments, some of the lighting nodes 105 may not be associated with lighting fixtures and may communicate via other lighting nodes 105. In alternative embodiments, an infrastructure including fixtures without lights may be used, provided that the infrastructure can provide power and networking capabilities to the nodes (which receive sensor data). For example, the infrastructure may be a utility infrastructure with utility poles or an air conditioning infrastructure with air conditioning units. In these examples, the nodes may be attached (directly or indirectly) to the utility poles or air conditioning units. In various embodiments, the lighting nodes 105 represent sensor nodes that are not associated with light fixtures or light sensors.

1B , the service data platform 140 provides a platform for sensor applications to be uploaded to the service data platform 140 using an application management API 142. The application management API 142 provides an API for third parties to upload sensor applications 120 to the service data platform 140. The API provided by the service data platform 140 may be a general API or a custom API.

The service data platform 140 includes a deployment module (e.g., the deployment module 520 shown in FIG5B ) that provides functionality to deploy the sensor applications 120 to the various lighting nodes 105. The deployment module 520, alone or in combination with a node management module (e.g., the node management module 540 shown in FIG5B ), determines which lighting nodes 105 within which lighting networks 100 will deploy which of the sensor applications 120. One or more of the sensor applications 120 may be deployed at each of the lighting nodes 105.

In various embodiments, before the sensor application 120 is deployed via the service data platform 140 , the service data platform 140 evaluates or screens the sensor application 120 to determine that the sensor application 120 is unlikely to cause harm to the lighting node 105 when executed or deployed on the lighting node 105 .

FIG1B also shows an aggregated data API 141 for users or applications to access sensor data (node-based processed sensor data or server-based processed sensor data). Server-based processing of sensor data can be performed by the analysis server 266 shown in FIG2B. As discussed above, node-based processing of sensor data is performed by the sensor application 120 running on the lighting node 105. In various embodiments, sensor data can be accessed using the aggregated data API 141.

2B , the processed sensor data is stored in a database 291 and accessed through a database server 290. In an example embodiment, the application server 260 communicates with other networked devices over the WAN 130 via an API server 270 or a Web server 280.

In various embodiments, the owner of the lighting network 100 authorizes a third party to install and execute the sensor application 120 at the lighting nodes 105 within the lighting network 100. The sensor application 120 utilizes sensor data collected and processed at the lighting nodes 105 for use by the authorized third party. The results of the node-based processed sensor data are transmitted to the service data platform 140. In various embodiments, the authorized third party accesses the node-based processed sensor data through the service data platform 140 via a sensor data API. In various embodiments, the service data platform 140 is owned and operated by a service provider or other entity that manages various aspects of the lighting nodes 105, the data provided by the lighting nodes 105, and the deployment and execution of the sensor application 120 at the lighting nodes 105.

The service data platform 140 will be discussed in further detail below in conjunction with FIG. 2B , FIG. 5B , and FIG. 6 - 8 .

FIG2A illustrates a service endpoint platform 210 that receives high-bandwidth data (or large amounts of data) from sensors and provides low-bandwidth data that can be transmitted over a network, according to an example embodiment. As discussed above, a lighting node 105 may include a plurality of sensors 416, also referred to as sensor devices. Examples of sensors 416 include lighting sensors, audio sensors, camera sensors, video sensors, and the like.

FIG2A illustrates sensor drivers 230 and 231 receiving sensor data from sensors and providing high-bandwidth sensor data to applications 220 and 221 using a sensor data API 330, according to an example embodiment. Sensor drivers 230 and 231 may be implemented as software within the service endpoint platform 210, underlying the sensor data API 330. Sensor applications 220 and 221 generate multiple results from node-based processing of the sensor data. These results are transmitted as low-bandwidth data to WAN 130 via paths 250 and 251. In various embodiments, the low-bandwidth data may represent insights from the sensor data generated by sensor applications 220 and 221 using high-bandwidth data.

In various embodiments, the algorithms implemented by sensor applications 220 and 221 represent analytical processing that can be performed at a lighting node 105. A camera may represent a sensor device capable of capturing video with audio and image data. The image data from the camera may represent raw sensor data, representing high-bandwidth data in the megabits per second or gigabit per second range. Image data from a camera is difficult to transmit over a network (e.g., WAN 130) without compressing the image data or otherwise reducing its size for efficient transmission. While compressing the image data is possible, such compression may result in a loss of some detail in the image data. Instead of transmitting the raw image data, sensor application 220 or 221 may perform analysis on the raw image data and then send the results of the node-based processed raw image data to the network (e.g., WAN 130). Node-based processing of the raw image data can preserve nearly 100% of the detail from the raw image data.

Another example of a sensor device that generates high-bandwidth data is an accelerometer that measures vibration. An accelerometer can measure vibration at a fast sampling rate (e.g., 100 samples/second). The raw sensor data may be too large or received at too fast a rate to be efficiently transmitted over a wireless network in order to gain insight into the raw sensor data. For example, the desired insight from the raw sensor data may include peak acceleration or spectral content. Sensor applications 220 and 221 may perform node-based sensor processing to determine occasional peaks or snapshots, where the results of the node-based processing may be transmitted to the network (e.g., WAN 130).

Audio data from audio sensors can also provide high-bandwidth sensor data. Audio analysis can include listening for a person screaming, breaking glass, a car crash, a gunshot, and the like. Audio analysis determines when a specific event occurred. Instead of sending audio recordings (which, in some cases, represent high-bandwidth data) over a network (e.g., WAN 130) for analysis and processing to determine whether a specific event occurred, sensor applications 220 or 221 can perform node-based sensor processing to detect the occurrence of a specific event. The results from the node-based sensor processing are then transmitted over the network (e.g., WAN 130) to the service data platform 140 for access by authorized users.

In the various high-bandwidth data examples described above, the data analysis results (generated by application 220 or 221) are transmitted via the network to the cloud where service data platform 140 resides. Service data platform 140 may represent a centralized server for lighting sensor network 160. The results are then stored in service data platform 140. Processed sensor data can be accessed from service data platform 140 by authorized users using a web API or a programmatic API. The owner of service data platform 140 may provide authorized users with a web application for accessing processed sensor data. Some users may create their own applications and access processed sensor data via other APIs.

FIG2B illustrates a service data platform 140 according to an exemplary embodiment. The service data platform 140 includes an API server 270 and a web server 280, which can be coupled to one or more application servers 260 and provide a programming interface and a web interface, respectively, to the one or more application servers 260. The service data platform 140 can be hosted on dedicated or shared server machines that are communicatively coupled to enable communication between the server machines. Each of the servers can include one or more modules or applications, and each of the one or more modules or applications can be embodied in hardware, software, firmware, or any combination thereof.

The application server 260 is further shown coupled to one or more database servers 290 that facilitate access to one or more information repositories or databases 291. In the exemplary embodiment, the database 291 is a storage device that stores sensor information and sensor analysis information. The application server 260 includes a graphics server 262, a device server 264, and an analysis server 266. These servers will be discussed in further detail in conjunction with Figures 7-8.

Figure 3A illustrates software components within an endpoint application framework 310 implemented at a lighting node 105, according to an example embodiment. Figures 4A-4C illustrate various hardware embodiments of a lighting node 105. In an exemplary embodiment, the endpoint application framework 310 manages functionality for supporting application scripting functionality or node-based processing of sensor data within the light sensor network 160.

FIG3A illustrates various software components within the endpoint application framework 310 layer of a lighting node 105, according to an example embodiment. Within the endpoint application framework 310 resides a container 320 for sensor applications 220, a management API 340, an application API 350, and a sensor data API 330. The container 320 for sensor applications 220 manages the sensor applications 220. In various embodiments, the sensor applications 220 are implemented using a scripting language. For example, the container 320 is used to start, stop, restart, download, or reload scripts based on requests 366 made to the container 320 via the management API 340. The management API 340 provides requests from the service data platform 140 via path 365. These requests may be referred to as management or configuration requests. The service data platform 140 is responsible for deploying software applications to the lighting node 105. Sensor applications 220 can be deployed by sending files from the service data platform 140 to the sensor applications 220 using the management API 340.

Sensor applications 220 provided by third parties may be received by the service data platform 140 using the application management API 142 and then downloaded or uploaded (using the management API 340 ) for node-based processing of sensor data and sensor events.

The endpoint application framework 310 is also responsible for managing various interfaces including a management API 340 , an application API 350 , and a sensor data API 330 .

As discussed above, management or configuration request 366 is provided using management API 340. Service data platform 140 manages request 366 and sends a communication including request 366 to endpoint application framework 310 via path 365.

The sensors provide raw sensor data 363 and sensor data events 364 to the sensor application 220 using the sensor data API 330. The sensor application 220 may provide a request 368 to the sensor data API to retrieve the raw sensor data 363 and sensor events 364. The raw sensor data 363 and sensor events 364 are provided to the sensor application 220 via a response 369. The sensor application 220 may run analytics on the raw sensor data 363 and sensor data events 364 received via the sensor data API 330 to generate results based on the processed sensor data of the node.

The results of the node-based processed sensor data are transmitted to the service data platform 140 via the application API 350 on path 367. A user can use the aggregated data API 141 to access the results of the node-based processed sensor data.

FIG4A illustrates a lighting network 100 according to an example embodiment. The lighting network 100 illustrates a plurality of lighting fixtures 305 and 425. The number of lighting fixtures in the lighting network 100 may vary depending on the needs of the client. Furthermore, not all lighting fixtures include a lighting node 415 attached thereto, either directly or indirectly. For example, the lighting fixture 425 does not include a lighting node 415 attached thereto. However, in some embodiments, the lighting fixture 425 may communicate with a remote lighting node. In alternative embodiments, other types of fixtures may be used that provide power and networking capabilities to the lighting nodes 415. In other embodiments, the lighting nodes 415 may be referred to as sensor nodes or nodes.

Both lighting fixtures 305 include a light source 411, a support structure 412, a power supply 413, and a lighting node 415. In some embodiments, the lighting node 415 may include a local storage device (not shown) for storing sensor data (including raw sensor data and processed sensor data). The lighting node 415 includes the service endpoint platform 210 and sensors 416 to provide sensor data for detecting various conditions and events.

4B illustrates a service endpoint platform 210 within a lighting node 415 according to an example embodiment. The service endpoint platform 210 includes a sensor data API 330 for receiving sensor data (raw sensor data and sensor data events), a computing platform 450 for processing the sensor data at the lighting node 415, and a network interface 440. The network interface 440 can be used to send the sensor data processed by the computing platform 450 to the service data platform 140 via a network (e.g., WAN 130).

In an example embodiment, the computing platform 450 is responsible for processing sensor data at the lighting nodes 415. One or more hardware components shown in FIG4C (e.g., the node application controller 470) along with software represented by the endpoint application framework 310 and the sensor application 120 may be used to implement the computing platform 450 shown in FIG4B.

FIG4C shows an exemplary block diagram of an embodiment of a lighting node 415. In some embodiments, the lighting node 415 may be controlled by a node application controller 470, which may consist of software running on a microcontroller (referred to as node application controller 470) connected to volatile and non-volatile memory (not shown). In various embodiments, the sensor application 220 is installed on memory in the node application controller 470 and executed by the node application controller 470. The node application controller 470 may provide functionality for executing the software application 120. In another embodiment, the node application controller 470 may consist of firmware running on a field programmable gate array (FPGA). The node application controller 470 may communicate over a LAN via a network interface 440 compatible with a selected LAN network protocol. The node application controller 470 may read data from the sensor 416 and may store the data in its memory (not shown). The node application controller 470 may also forward the data to the service data platform 140 over the LAN. The node application controller 470 can also send output signals to the controller 480 to change the settings of the connected controlled device (e.g., LED light 411). The node application controller 470 can also be connected to the network interface 440 (e.g., the uplink transceiver 164 that communicates with the service data platform 140 using a wireless uplink antenna). In various embodiments, the devices on the lighting node 305 can be powered by the power input terminal 490 that provides power to one or more power supplies 413 within the lighting node 305.

FIG5A illustrates a lighting node 415 having multiple components, according to an example embodiment. The lighting node 415 includes an endpoint application framework 310, which provides a framework for implementing node-based processing of sensor data by the sensor application 120. The endpoint application framework 310 manages various functions for managing node-based processing of sensor data. As discussed above, the endpoint application framework 310 manages multiple interfaces, such as an interface between the sensor 416 and the sensor application 120 and an interface between the lighting node 415 and the service data platform 140. The sensor driver 505 uses the sensor data API 330 to provide sensor data from the sensor 416 for processing by the sensor application 120. The network interface 440 provides an interface between the lighting node 415 and the service data platform 140.

FIG5B illustrates a service data platform 140 having multiple components, according to an example embodiment. An application management API 142 provides an interface for users (e.g., third parties) to upload sensor applications 120 that the user wants to deploy at lighting nodes 415 within the lighting network 100. Once the sensor data is processed by the sensor applications 120 deployed at the lighting nodes 105, the user can access the node-based results of the processed sensor data from the service data platform 140 via the aggregated data API 141. An application database 530 stores the results of the processed sensor data. The application database 530 may represent one or more of the databases 291 shown in FIG2B. Returning to FIG5B, a deployment module 520 may provide functionality for deploying the sensor applications 120 to one or more selected lighting nodes or groups of lighting nodes. The deployment module 520 and the node management module 540 will be discussed in further detail below in conjunction with FIG6-8.

5C is a diagram of an exemplary sensor application that enables the endpoint application framework 310 to manage the processing of sensor data at a lighting node 105 within the lighting network 100. The sensor data API 330 and the application API 350 represent some of the components in the endpoint application framework 310. The sensor application 120 includes various software components.

5C , the sensor application 120 can be installed on two lighting nodes 105 (referred to as a first lighting node and a second lighting node). The sensor data API 330 provides an interface for the sensor application 120 to receive sensor data. The raw sensor data is sent (via path 583) to the sensor analysis unit 560 for analysis. The raw sensor data is sent (via path 584) to the sensor analysis unit 565 for analysis.

Sensor analysis units 560 and 565 represent software layers responsible for processing raw sensor data and applying algorithms to locate, classify, or correlate the information to produce node-based processed results for the sensor data. In various examples, sensor software 501 provided by third-party application developers may represent a set of rules for generating heuristics or other analyses of specific types of sensor data (e.g., motion detection data, ambient light sensor data, etc.) collected at various lighting nodes 105 within the lighting sensor network 160. Examples of sensor data processed by sensor analysis units 560 and 565 include data from environmental sensors (e.g., temperature and humidity), gases (e.g., CO2 and CO), data from accelerometers (e.g., vibration), particulates, power, RF signals, ambient light, and motion detection, still images, video, and audio. The information generated by sensor analysis units 560 and 565 is provided to application API 350 via communication path 580 and further to service data platform 140 via communication path 581.

A container (not shown in FIG. 5C ) manages the execution of sensor applications 501 , with a separate container for each software application.

FIG6 illustrates an example of a tree used by the service data platform 140 to organize and manage lighting nodes within a lighting network 100. The tree 600 is a data structure generated and utilized by the service data platform 140 to manage the lighting nodes 105 in many lighting networks 100. The graph server 262 may be used to manage the grouping of nodes in a hierarchical tree structure, such as the tree 600. The nodes within the tree may be used to track information about the lighting nodes 105 within the lighting network 100 by geographic location and user information, among other information. The tree is useful in tracking permissions to determine, for example, which lighting nodes 105 will deploy sensor applications 220.

Tree 600 includes node 601, which represents the root node in tree 600. The number and type of nodes in the tree can vary. Nodes 610, 611, and 612 represent nodes with location information. For example, node 610 represents California (CA), node 611 represents Santa Clara, and node 612 represents Westfield Mall Valley Fair. In one example, by selecting node 612 via a user interface presented to a user (e.g., a system administrator of service data platform 140) on a client device (not shown), a lighting network 100 including an associated lighting node 105 at Westfield Mall Valley Fair is selected. By selecting node 612, the system administrator of service data platform 140 can deploy sensor application 220 to lighting node 105 located at Westfield Mall Valley Fair in lighting network 100.

Nodes 620, 621, and 622 represent user information. In one example, node 620 may represent a user authorized to request a system administrator of the service data platform 140 to deploy a sensor application 220 to a lighting node 105 in the lighting network 100 at a Silicon Valley shopping center. Nodes 621 and 622 represent specific users, Kent and Bob, respectively, in the authorized user group.

In various embodiments, the tree 600 may be presented to a user as a graphical user interface to allow a system administrator to view the lighting nodes 105 by geographic location, customer, or owner of the lighting node 105, thereby tracking permissions (e.g., permissions granted to a third party to deploy the sensor application 220) and other information for managing many lighting networks 100 having multiple lighting nodes 105 at various customer sites across different geographic locations.

As indicated above, the service data platform 140 can deploy one or more sensor applications 220 to each lighting node 105, assuming that the administrator of the service data platform 140 is authorized by the owner of the lighting network 100 at the customer site. Third-party application developers of sensor applications 220 can specify which devices (e.g., lighting nodes 105, service endpoint platform 210, and endpoint application framework 310, as well as components within these devices) are compatible with the sensor applications 220 that the third-party application developers want to deploy at the lighting nodes 105. System administrators of the service data platform 140 manage the deployment of sensor applications 220 to various nodes. The service data platform 140 allows third-party application developers (or other users) to upload sensor applications 220 and assign the sensor application code to devices (e.g., lighting nodes 105) within range. The service data platform 140 (for example) provides users with the ability to group lighting nodes 105 by assigning one or more sensor applications 220 to groups of lighting nodes 105 using a tree 600. The service data platform 140 further provides users with the ability to push sensor applications 220 to assigned lighting nodes 105. In various embodiments, the service data platform 140 uses the management API 340 (shown in FIG3A ) to upload the sensor applications 220. Once the sensor applications 220 are deployed by the service data platform 140, the lighting nodes 105 execute the sensor applications 220.

7 illustrates a block diagram of a service data platform 140 having various components according to an example embodiment. The service data platform 140 includes an aggregate data API 141 and an application management API 142, a graph server 262 coupled to a graph database 291 a, and a device manager 710. In some embodiments, the graph database 291 a represents one or more of the databases 291 shown in FIG 2B.

In various embodiments, the aggregated data API 141 and the application management API 142 are implemented using the API server 270. The APIs 141 and 142 provide external APIs to authorized users of the service data platform 140 to access node-based processed sensor data or upload sensor applications 120 for deployment at lighting nodes 105, respectively. The APIs 141 and 142 are communicatively coupled to the graph server 262.

The graph server 262 provides functionality to group the lighting nodes 105 by geographic information and user information provided by a hierarchical tree structure, such as the tree 600. The lighting nodes 105 within the lighting network 100 are managed by groups using the graph server 262. In various embodiments, the sensor applications 220 are managed by the groups, for example, during deployment of the sensor applications 220.

The device manager 710 provides functionality to manage the lighting nodes 105 (which may be referred to as devices). The device manager 710 includes a device server 264 and interfaces with the lighting nodes 105a-105c. The device manager 710 may communicate with the lighting network 100 via a network (eg, a WAN).

FIG8 illustrates a block diagram of a service data platform 140 having various servers in communication with each other, according to an example embodiment. An API server 270 communicates with a graphics server 262, which communicates with a device server 264. The device server 264 communicates with a network (e.g., WAN 130, not shown). In the example shown in FIG8 , API servers 270 a through 270 c each communicate with graphics servers 262 a through 262 b. Graphics servers 262 a through 262 b each communicate with device servers 264 a through 264 b. The device servers 264 a through 264 b communicate with lighting nodes 105 a through 105 c.

9A-9B illustrate flow diagrams of methods 900 and 910 implemented in various embodiments. In some embodiments, additional operations may be added to each of methods 900 and 910, or one or more operations may be deleted from each of methods 900 and 910. In other embodiments, methods 900 and 910, or variations thereof, may be combined. The operations performed in methods 900 and 910 may be performed by one or more components or modules within lighting sensor network 160.

FIG9A depicts a method 900 for processing sensor data at a lighting node 105 within a network (e.g., lighting network 100), according to an example embodiment. Method 900 includes operations 901 through 905. At operation 901, a first request is received from a service data platform 140 using a management API 340 to upload a sensor application 220 to a lighting node 105. At operation 902, a second request is received from a service data platform 140 using a management API 340 to execute a sensor application 220. At operation 903, sensor data representing high-bandwidth data is collected from sensor devices (e.g., 416) using a sensor data API 330. At operation 904, the sensor application 220 is executed to generate analytics data at the lighting node 105 based on the sensor data, the generated analytics data representing low-bandwidth data. At operation 905, the generated analytics data is transmitted to the service data platform 140 using an application API 350.

In other example embodiments, the method 900 for processing sensor data at a lighting node 105 includes receiving, using the management API 340 , additional requests from the service data platform 140 to perform management functions on the sensor application.

In an exemplary embodiment, the sensor data includes at least one of raw sensor data and sensor event data. In other embodiments, the sensor data represents collected sensor data that has not been filtered, aggregated, or otherwise altered by devices within the network. In some embodiments, the sensor application 220 represents a script. In another embodiment, the lighting node 105 represents a sensor node. In some embodiments, the sensor application 220 represents software developed by a third party to run on the lighting node 105 to perform node-based processing on the unaltered sensor data collected at the lighting node 105.

In other embodiments, receiving a first request from the service data platform 140 using the management API 340 to upload the sensor application 220 to the lighting node 105 includes receiving a file containing the sensor application 220 and installing the sensor application 220 from the file onto the lighting node 105. In an example embodiment, collecting sensor data using the sensor data API 330 includes requesting sensor data from a sensor device using the sensor data API 330 and receiving a response from the sensor device (e.g., 416) containing the requested sensor data. In other embodiments, collecting sensor data using the sensor data API 330 includes collecting sensor data at a data transfer rate such that the amount of collected sensor data is too large to be efficiently transferred to the service data platform 140 via a network (e.g., WAN 130) in near real time. In another embodiment, collecting from a sensor device using the sensor data API includes collecting sensor data from a sensor device (e.g., 416) located at the lighting node or at a remote lighting node.

In other embodiments, executing the sensor application 220 to generate analytics data at the lighting node 105 based on the sensor data includes generating the analytics data based on the unaltered sensor data at a data transfer rate such that the amount of generated analytics data can be transmitted in near real-time to the service data platform 140 via a network (e.g., WAN 130). In various embodiments, executing the sensor application 220 to generate analytics data at the lighting node 105 based on the sensor data received at the lighting node 105 includes generating the analytics data based on the unaltered sensor data to generate low-bandwidth data.

In various embodiments, executing the sensor application 220 to generate analytics data at the lighting node based on the sensor data includes executing the sensor application 220 within a container 320 to limit resources utilized by the sensor application 220 and provide a secure operating environment for the sensor application 220. In an exemplary embodiment, executing the sensor application 220 to generate analytics data at the lighting node 105 based on the sensor data includes generating analytics data by applying algorithms to locate, classify, and correlate information. In another embodiment, executing the sensor application 220 to generate analytics data at the lighting node 105 based on the sensor data includes executing the sensor application 220 without affecting other software executing at the lighting node 105. In yet another embodiment, executing the sensor application 220 to generate analytics data at the lighting node 105 based on the sensor data further includes generating analytics data without affecting normal operation of the lighting node 105.

9B depicts a method 910 for deploying software to lighting nodes 105 in a network (e.g., lighting sensor network 160) according to an example embodiment. Method 910 includes operations 911 through 914. At operation 911, software uploaded by a third party using a management application API 142 provided by the service data platform 140 is received by the service data platform 140. At operation 912, a group of lighting nodes 105 to which the uploaded software is to be distributed is identified. At operation 913, a determination is made that the uploaded software is safe for deployment to the identified group of lighting nodes 105. At operation 914, the uploaded software is distributed to the identified group of lighting nodes 105 using the management API 340.

In various embodiments, the method 910 of deploying software to lighting nodes 105 includes managing the execution of software installed on an identified group of lighting nodes 105 using the management API 340 by providing management function requests.

In other embodiments, the method 910 of deploying software to a lighting node 105 includes: receiving node-processed sensor data generated by an identified group of lighting nodes 105 from the identified group of lighting nodes 105 using the application API 350; and storing the node-processed sensor data from the identified group of lighting nodes 105 in a database (e.g., 291) located at the service data platform 140. In yet another embodiment, the method of deploying software to a lighting node 105 includes: providing access to the stored node-processed sensor data requested by an authorized third party using the aggregated data API 141. In some embodiments, the software represents a sensor application 220. In other embodiments, the sensor application 220 is written in a scripting language.

FIG10 is a block diagram 1000 illustrating a software architecture 1002 that may be installed on any one or more of the devices described above. FIG10 is merely a non-limiting example of a software architecture, and it will be appreciated that many other architectures may be implemented to facilitate the functionality described herein. The software 1002 may be executed on hardware (e.g., the machine 1100 of FIG11 , which includes a processor 1110, a memory 1130, and I/O components 1150). In the example architecture of FIG10 , the software 1002 may be conceptualized as a stack of layers, each of which may provide specific functionality. For example, the software 1002 may include multiple layers, such as an operating system 1004, a library 1006, a framework 1008, and an application 1010. In operation, the application 1010 may invoke application programming interface (API) calls 1012 via the software stack and receive messages 1014 in response to the API calls 1012.

The operating system 1004 can manage hardware resources and provide common services. For example, the operating system 1004 can include a kernel 1020, services 1022, and drivers 1024. The kernel 1020 can serve as an abstraction layer between the hardware and other software layers. For example, the kernel 1020 can be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and the like. Services 1022 can provide other common services for other software layers. Drivers 1024 can be responsible for controlling or interfacing with the underlying hardware. For example, drivers 1024 can include a display driver, a camera driver, a driver, a flash memory driver, a serial communication driver (e.g., a universal serial bus (USB) driver), a driver, an audio driver, a power management driver, and the like.

Libraries 1006 may provide low-level, common infrastructure that can be utilized by applications 1010. Libraries 1006 may include system libraries 1030 (e.g., the C standard library), which may provide functionality such as memory allocation, string manipulation, and mathematical functions. Additionally, libraries 1006 may include API libraries 1032, such as media libraries (e.g., libraries to support rendering and manipulation of various media formats such as MPREG4, H.264, MP3, AAC, AMR, JPG, and PNG), graphics libraries (e.g., the OpenGL framework that can be used to render 2D and 3D graphics content on a display), database libraries (e.g., SQLite that can provide various relational database functions), web libraries (e.g., WebKit that can provide web browsing functionality), and the like. Libraries 1006 may also include a variety of other libraries 1034 that provide many other APIs to applications 1010.

The framework 1008 may provide a high-level, common infrastructure that may be utilized by the applications 1010. For example, the framework 1008 may provide various graphical user interface (GUI) functions, advanced resource management, advanced location services, etc. The framework 1008 may provide a wide range of other APIs that may be utilized by the applications 1010, some of which may be specific to a particular operating system or platform.

Applications 1010 include a browser application 1054, an analytics application 1056, a sensor application 1058, and various other applications (e.g., third-party applications 1066). FIG11 is a block diagram illustrating components of a machine 1100 capable of reading instructions from a machine-readable medium (e.g., a machine-readable storage medium) and performing any one or more of the methodologies discussed herein, in accordance with some example embodiments. Specifically, FIG11 shows a diagrammatic representation of a machine 1100 in the form of an example computer system within which instructions 1116 (e.g., software, programs, applications, applets, application software, or other executable code) may be executed for causing the machine 1100 to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine 1100 operates as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine 1100 may operate in the role of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine 1100 may include, but is not limited to, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook computer, a set-top box (STB), a personal digital assistant (PDA), an entertainment media system, a cellular phone, a smart phone, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, web appliances, a network router, a network switch, a network bridge, or any machine capable of executing, sequentially or otherwise, the instructions 1116 that specify actions to be taken by the machine 1100. Further, while a single machine 1100 is illustrated, the term "machine" shall also be taken to include any machine 1100 that individually or jointly executes instructions 1116 to perform any one or more of the methodologies discussed herein.

The machine 1100 may include a processor 1110, memory 1130, and I/O components 1150 that may be configured to communicate with each other via a bus 1102. In an exemplary embodiment, the processor 1110 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor 1112 and a processor 1114 that may execute instructions 1116. The term "processor" is intended to include multi-core processors, which may include two or more independent processors (also referred to as "cores") that may execute instructions simultaneously. Although FIG11 shows multiple processors, the machine 1100 may include a single processor with a single core, a single processor with multiple cores (e.g., multi-core processing), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

The memory 1130 may include a main memory 1132, a static memory 1134, and a storage unit 1136, which are accessible to the processor 1110 via the bus 1102. The storage unit 1136 may include a machine-readable medium 1138 having stored thereon instructions 1116 embodying any one or more of the methodologies or functions described herein. The instructions 1116 may also reside, completely or at least partially, within the main memory 1132, within the static memory 1134, within at least one of the processors 1110 (e.g., within a cache memory of the processor), or within any suitable combination thereof during execution thereof by the machine 1100. Thus, the main memory 1132, the static memory 1134, and the processor 1110 may be considered to be a machine-readable medium 1138.

As used herein, the term "memory" refers to a machine-readable medium 1138 capable of storing data, either temporarily or permanently, and may be considered to include, but not be limited to, random access memory (RAM), read-only memory (ROM), buffer memory, flash memory, and cache memory. Although the machine-readable medium 1138 is shown as a single medium in the exemplary embodiment, the term "machine-readable medium" should be considered to include a single medium or multiple media (e.g., a centralized or distributed database, or associated cache memory and servers) capable of storing instructions 1116. The term "machine-readable medium" should also be considered to include any medium or combination of multiple media capable of storing instructions (e.g., instructions 1116) for execution by a machine (e.g., machine 1100), such that when executed by one or more processors (e.g., processor 1110) of machine 1100, the instructions cause machine 1100 to perform any one or more of the methodologies described herein. Thus, "machine-readable medium" refers to both a single storage device or apparatus as well as a "cloud-based" storage system or storage network comprising multiple storage devices or apparatuses. The term "machine-readable medium" shall accordingly be taken to include, but not be limited to, one or more data storage libraries in the form of solid-state memory (e.g., flash memory), optical media, magnetic media, other non-volatile memory (e.g., erasable programmable read-only memory (EPROM)), or any suitable combination thereof. In particular, the term "machine-readable medium" itself does not include non-statutory signals.

I/O components 1150 may include a variety of components for receiving input, providing output, generating output, transmitting information, exchanging information, acquiring measurements, and the like. It will be appreciated that I/O components 1150 may include many other components not shown in FIG. 11 . To simplify the following discussion, I/O components 1150 are grouped solely by functionality, and such grouping is in no way limiting. In various exemplary embodiments, I/O components 1150 may include output components 1152 and input components 1154. Output components 1152 may include visual components (e.g., displays such as plasma display panels (PDPs), light emitting diode (LED) displays, liquid crystal displays (LCDs), projectors, or cathode ray tubes (CRTs)), acoustic components (e.g., speakers), tactile components (e.g., vibration motors), other signal generators, and the like. Input components 1154 may include alphanumeric input components (e.g., a keyboard, a touch screen configured to receive alphanumeric input, an optical keyboard, or other alphanumeric input components), point-based input components (e.g., a mouse, touch pad, trackball, joystick, motion sensor, or other pointing instrument), tactile input components (e.g., physical buttons, a touch screen or other tactile input components that provide location and force of a touch or touch gesture), audio input components (e.g., a microphone), and so on.

In other exemplary embodiments, the I/O components 1150 may include a biometric component 1156, a motion component 1158, an environmental component 1160, or a positional component 1162, among numerous other components. For example, the biometric component 1156 may include components for detecting various expressions (e.g., hand expressions, facial expressions, voice expressions, body posture, or eye tracking), measuring biosignals (e.g., blood pressure, heart rate, body temperature, sweat, or brain waves), identifying people (e.g., voice recognition, retinal recognition, facial recognition, fingerprint recognition, or electroencephalogram-based recognition), and the like. The motion component 1158 may include an acceleration sensor component (e.g., an accelerometer), a gravity sensor component, a rotation sensor component (e.g., a gyroscope), and the like. For example, the environment component 1160 may include a light sensor component (e.g., a photometer), a temperature sensor component (e.g., one or more thermometers that detect ambient temperature), a humidity sensor component, a pressure sensor component (e.g., a barometer), an acoustic sensor component (e.g., one or more microphones that detect background noise), a proximity sensor component (e.g., an infrared sensor that detects nearby objects), a gas sensor (e.g., a gas detection sensor that detects the concentration of hazardous gases for safety purposes or measures pollutants in the atmosphere), or other components that can provide indications, measurements, or signals corresponding to the surrounding physical environment. The location component 1162 may include a location sensor component (e.g., a global positioning system (GPS) receiver component), an altitude sensor component (e.g., an altimeter or a barometer that detects air pressure, which can be derived based on altitude), an orientation sensor component (e.g., a magnetometer), and the like.

Communication can be implemented using a variety of technologies. I/O components 1150 may include a communication component 1164 operable to couple machine 1100 to network 130 or device 1170 via coupling 1182 and coupling 1172, respectively. For example, communication component 1164 may include a network interface component or other suitable device for interfacing with network 130. In other examples, communication component 1164 may include a wired communication component, a wireless communication component, a cellular communication component, a near-field communication (NFC) component, a component (e.g., low power), a component, and other communication components for providing communication via other modalities. Device 1170 may be another machine or any of a variety of peripheral devices, such as a peripheral device coupled via a universal serial bus (USB).

Furthermore, the communication component 1164 can detect an identifier or include a component operable to detect an identifier. For example, the communication component 1164 can include a radio frequency identification (RFID) tag reader component, an NFC smart tag detection component, an optical reader component (e.g., an optical sensor for detecting one-dimensional barcodes such as Universal Product Code (UPC) barcodes, multi-dimensional barcodes such as Quick Response (QR) codes, Aztec codes, Data Matrix, Dataglyph, MaxiCode, PDF417, Ultra Code, UCC RSS-2D barcodes, and other optical codes), or an acoustic detection component (e.g., a microphone for identifying tagged audio signals). Furthermore, various information can be derived via the communication component 1164, such as location via Internet Protocol (IP) geolocation, location via signal triangulation, location via detection of NFC beacon signals that can indicate a specific location, and the like.

In various exemplary embodiments, one or more portions of network 130 may be an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), the Internet, a portion of the Internet, a portion of a public switched telephone network (PSTN), a plain old telephone service (POTS) network, a cellular telephone network, a wireless network, a network, another type of network, or a combination of two or more such networks. For example, network 130 or a portion of network 130 may include a wireless or cellular network, and coupling 1182 may be a code division multiple access (CDMA) connection, a global system for mobile communications (GSM) connection, or other type of cellular or wireless coupling. In this example, coupling 1182 may implement any of a variety of types of data transfer technologies, such as single-carrier radio transmission technology (1xRTT), evolution-data-optimized (EVDO) technology, general packet radio service (GPRS) technology, enhanced data rates for GSM evolution (EDGE) technology, the 3rd Generation Partnership Project (3GPP) including 3G, fourth generation wireless (4G) networks, Universal Mobile Telecommunications System (UMTS), high-speed packet access (HSPA), worldwide interoperability for microwave access (WiMAX), long-term evolution (LTE) standards, other technologies defined by various standards-setting organizations, other long-term agreements, or other data transfer technologies.

The instructions 1116 may be transmitted or received over the network 130 via a network interface device (e.g., a network interface component included in the communication component 1164) using a transmission medium and utilizing any of several well-known transfer protocols, such as the Hypertext Transfer Protocol (HTTP). Similarly, the instructions 1116 may be transmitted or received using a transmission medium via a coupling 1172 (e.g., a peer-to-peer coupling) to the device 1170. The term "transmission medium" shall be taken to include any intangible medium capable of storing, encoding, or carrying the instructions 1116 for execution by the machine 1100, and includes digital or analog communication signals or other intangible media used to facilitate communication of such software.

Furthermore, machine-readable medium 1138 is non-transitory (in other words, does not possess any transitory signals) because it does not embody a propagating signal. However, designating machine-readable medium 1138 as "non-transitory" should not be construed to mean that the medium cannot be moved; the medium should be considered transportable from one physical location to another. Furthermore, because machine-readable medium 1138 is tangible, the medium can be considered a machine-readable device.

Throughout this specification, multiple examples may implement components, operations, or structures described as a single example. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations can be performed simultaneously, and the operations need not be performed in the order illustrated. Structures and functionality presented as separate components in the example configurations may be implemented as combined structures or components. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements are within the scope of the subject matter herein.

Although an overview of the inventive subject matter has been described with reference to specific exemplary embodiments, various modifications and changes may be made to these embodiments without departing from the broader scope of the embodiments of the present invention. Such embodiments of the inventive subject matter may be referred to herein individually or collectively by the term "invention," which is merely for convenience and is not intended to automatically limit the scope of this application to any single invention or inventive concept if more than one invention or inventive concept is actually disclosed.

The embodiments illustrated herein are described in sufficient detail to enable those skilled in the art to practice the disclosed teachings. Other embodiments may be used and derived from the present invention, such that structural and logical substitutions and changes may be made without departing from the scope of the present invention. Therefore, the detailed description should not be taken in a limiting sense, and the scope of the various embodiments is defined solely by the appended claims, along with the full scope of equivalents to which such claims are entitled.

As used herein, the term "or" may be understood as inclusive or exclusive. In addition, multiple instances may provide resources, operations, or structures described herein as single instances. In addition, the boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary, and specific operations are illustrated in the context of a specific illustrative configuration. Other functional allocations are envisioned and may fall within the scope of various embodiments of the present invention. In general, structures and functionality presented as separate resources in an exemplary configuration may be implemented as combined structures or resources. Similarly, structures and functionality presented as single resources may be implemented as separate resources. These and other variations, modifications, additions, and improvements all fall within the scope of embodiments of the present invention as represented by the appended claims. Therefore, the specification and drawings should be regarded as illustrative rather than restrictive.

Claims (10)

1. A method for processing sensor data using lighting fixtures within a network, comprising: The machine receives a first request via one or more processors to deploy a first sensor application to a first group of lighting fixtures, each of the first group of lighting fixtures including a corresponding sensor that generates sensor data and a corresponding server endpoint platform. The machine receives a second request, via one or more processors, to deploy a second sensor application to a second group of lighting fixtures, each lighting fixture in the second group including a corresponding sensor and a corresponding server endpoint platform, the first group of lighting fixtures and the second group of lighting fixtures sharing a first lighting fixture having a first sensor and a first server endpoint platform; In response to the first request and the second request, one or more processors of the machine load the first sensor application and the second sensor application into the first server endpoint platform of the first lighting fixture, and provide access by the first sensor application and the second sensor application to at least one level of sensor data to generate customized results based on the sensor data; This causes the first server endpoint platform of the first lighting fixture to execute the first sensor application in a first container environment and the second sensor application in a second container environment, the first container environment being different from the second container environment. The execution of the first sensor application generates a first analysis result based on raw data from the first sensor, and the execution of the second sensor application generates a second analysis result based on raw data from the first sensor. Each container manages resources associated with the container for running a sensor application having access to at least one level of sensor data; and The first analysis result is sent to the first publisher of the first request and the second analysis result is sent to the second publisher of the second request. 2. The method of claim 1, further comprising receiving the first sensor application from the first publisher before loading the first sensor application onto the first server endpoint platform. 3. The method of claim 1, further comprising performing a malware scan on the first sensor application before loading the first sensor application onto the first server endpoint platform. 4. The method of claim 1, wherein the first sensor application or the second sensor application includes a script. 5. The method according to claim 1, wherein: The first request to deploy the first sensor application to the first group of lighting fixtures was received via an application programming interface (API); and The resulting first analysis result is transmitted to the first publisher of the first request via the API. 6. The method according to claim 1, wherein: The second request to deploy the second sensor application to the second group of lighting fixtures was received via a web server; and The resulting second analysis result is transmitted via the web server to the second publisher of the second request. 7. The method according to claim 1, wherein: The first sensor application executes exclusively within the first container environment; The second sensor application executes exclusively within the second container environment; and The execution of the first sensor application in the first container environment, which produces the first analysis result, has no effect on the execution of the second sensor application in the second container environment, which produces the second analysis result. 8. The method according to claim 1, wherein: The first sensor application executes exclusively within the first container environment; The second sensor application executes exclusively within the second container environment; and The execution of the first sensor application in the first container environment, which produces a first analysis result, does not have the right to store the second analysis result produced by the execution of the second sensor application in the second container environment. 9. A system for processing sensor data using lighting fixtures within a network, comprising: Sensor devices; and An endpoint application framework, implemented by one or more processors, configured to perform operations including: Receive a first request to deploy a first sensor application to a first group of lighting fixtures, each of the first group of lighting fixtures including a corresponding sensor that generates sensor data and a corresponding server endpoint platform; Receive a second request to deploy a second sensor application to a second group of lighting fixtures, each lighting fixture in the second group of lighting fixtures including a corresponding sensor and a corresponding server endpoint platform, the first group of lighting fixtures and the second group of lighting fixtures jointly sharing a first lighting fixture having a first sensor and a first server endpoint platform; In response to the first request and the second request, the first sensor application and the second sensor application are loaded into the first server endpoint platform of the first lighting fixture, and access to at least one level of sensor data by the first sensor application and the second sensor application is provided to generate customized results based on the sensor data; This causes the first server endpoint platform of the first lighting fixture to execute the first sensor application in a first sandbox environment and the second sensor application in a second sandbox environment, the first sandbox environment being different from the second sandbox environment. The execution of the first sensor application generates a first analysis result based on raw data from the first sensor, and the execution of the second sensor application generates a second analysis result based on raw data from the first sensor. Each container manages resources for running the associated sensor application of that container, which has access to at least one level of sensor data; and The first analysis result is sent to the first publisher of the first request and the second analysis result is sent to the second publisher of the second request. 10. A non-transitory machine-readable medium storing instructions that, when executed by one or more processors of the machine, cause the machine to perform operations, the operations including: Receive a first request to deploy a first sensor application to a first group of lighting fixtures, each of the first group of lighting fixtures including a corresponding sensor that generates sensor data and a corresponding server endpoint platform; Receive a second request to deploy a second sensor application to a second group of lighting fixtures, each lighting fixture in the second group of lighting fixtures including a corresponding sensor and a corresponding server endpoint platform, the first group of lighting fixtures and the second group of lighting fixtures jointly sharing a first lighting fixture having a first sensor and a first server endpoint platform; In response to the first request and the second request, the first sensor application and the second sensor application are loaded into the first server endpoint platform of the first lighting fixture, and access to at least one level of sensor data by the first sensor application and the second sensor application is provided to generate customized results based on the sensor data; This causes the first server endpoint platform of the first lighting fixture to execute the first sensor application in a first sandbox environment and the second sensor application in a second sandbox environment, the first sandbox environment being different from the second sandbox environment. The execution of the first sensor application generates a first analysis result based on raw data from the first sensor, and the execution of the second sensor application generates a second analysis result based on raw data from the first sensor. Each container manages resources for running the associated sensor application of that container, which has access to at least one level of sensor data; and The first analysis result is sent to the first publisher of the first request and the second analysis result is sent to the second publisher of the second request.