## 5 OpEc  
### OpEc Architecture  
The system view of the dynamic street light control and management solution is illustrated on Figure 10. The solution takes advantage of the IoT paradigm in order to collect sensor data, analyze them, make a decision on the needs of street light intensity and send commands to an actuator that control the light intensity of luminaires. The system is composed of the following parts. * Central platform: Analyzes the data sensed by the sensors and relayed to a central platform. Its main objective is to \"understand\" the environmental context and, thus, to determine the real needs for lighting intensity, _i.e._ intense/low activity, good/bad visibility, _etc._
* Sensors that deliver: \[ \begin{array}{l}\cap\\ \cap\\ \cap\end{array} \] environmental indicators, e.g., luminosity, weather forecast; and \[ \begin{array}{l}\cap\\ \cap\\ \end{array} \] activity indicators, e.g., pedestrian, traffic;* Luminaires: Receive the command to regulate the light intensity according to the determined needs. The different parts will be presented in detail below. The proposed light management and control solution is based on technological components inspired from the Internet of Things (IoT) paradigm, presented in [39]. A set of sensors are deployed in the field to measure street light relevant indicators which are processed and analyzed with the objective to accurately estimate the real need related to light intensity for a given context. Finally, a command is sent to an individual or a group of luminaires for dynamically setting the needed light intensity. The IoT platform built around a set of building blocks for each layer of the IoT technological stack is used to integrate the DSL solution. The platform is conceived and built to flexibly and seamlessly integrate new communicating objects with minimal effort. Indeed, the platform addresses the IoT fragmentation challenge, which is caused the lack of standards in communication protocols and data format to conceive and build IoT solutions. Our platform is implemented around the following modules. Communicating Devices. The sensors and actuators are integrated on a single embedded device able to forward the measured values and to receive the commands. Gateway. A ubiquitous processing unit capable of communicating with the end devices and to push the measured values to the central platform. Further, the gateway is able to pull the commands to the end devices. In order to facilitate the connection and the integration of different devices that use different communication protocol, the Gateway relies on communication agents that are able to understand various protocols and extract relevant sensor data from the protocol's payload. These communication agents allow the seamless integration of communicating devices. On top of the Java VM, the framework Open Services Gateway initiative (OSGi) [40] has been installed. OSGi is a java-based execution environment suitable for deploying and running modular and loosely coupled services implemented in the form of bundles. Further, OSGi allows the realization and the execution of applications, which are conform to the Service Oriented Architecture (SOA) principles and able to run on a resources-constrained hardware. In order to avoid the manual implementation and management of low-level services like device abstraction, connectivity management, _etc._, the proposed solution makes extensive use of the Kura framework [41]. Broker. It is a message broker capable of forwarding the data between the gateway and the central platform based on the <<publish/subscribe>> principle. The underlying asynchronous communication mechanism assures a high performance of the data transfer. Figure 10: Dynamic street lighting system overview. Rules engine. The dynamic street light application relies on an engine based on Drools (Red Hat Inc. or third-party contributors, Raleigh, NC, USA). It combines the different sensor data and infers a decision regarding the light intensity to configure on the luminaire.