Keywords

1 Introduction

A significant part of every lighting design modernization project is the phase when the appropriate fixtures models and their parameters must be determined. This phase is often based on photometric calculations, and is called the design phase. Traditional approaches which rely on human-operated tools are time-consuming, especially when sensor-based dynamic dimming of lamps is considered. Then, each street needs not one, but several dozen designs, to account for different lighting classes assigned to streets at various times, as well as other parameters, such as the level of ambient light.

Preparing advanced, well suited lighting designs covering entire cities or at least whole districts, is a very demanding task. Its complexity originates from several sources: computational complexity, structural complexity of data, a need of using distributed processing supported by sophisticated heuristics and artificial intelligence-based methods. The key issue is a problem size in terms of the input data volume. An additional challenge is implementation of a lighting control system which uses pre-computed presets obtained in the result of a design process for all available states of roads, squares, walkways and so on. Due to the high computational complexity and practically unpredictable number of possible environment states for the case of an entire city area, the typical method assuming making designs for all possible environment conditions first and then starting control actions, is not doable. Instead we propose using the approach relying on a reversed scheme of cooperation between design and control modules.

Initially only the presets (setups computed for particular lamps) for main control patterns are precalculated. We assess that those cases cover 90–95% of a lighting installation’s working time. The remaining patterns of environment’s states are handled in-the fly by the control system: if it lacks appropriate response for an actual environment state (for example, some combination of traffic flow and ambient light level) then a request to the design subsystem is submitted to find suitable adjustments for relevant luminaires.

A response for such request is prepared, in turn, using AI based methods based on self-learning algorithms or prediction-based techniques (out of the scope of this work) to reduce the response time to an acceptable value. Obviously, this requires historical data stored in an inventory.

A lighting design in the precalculation phase can be generated twofold, either making the “classical” single-scene photometric computations, as made by industry-standard software [6] or applying the customized approach [17, 18].

Preparation of such a design can be aimed at determining photometric conditions for an assumed luminaire setup, but also its objective can be finding an optimal setup, giving the lowest power consumption for instance. Both scenarios will be discussed in the next sections.

The main difference is that in the classical approach, each street is considered separately and as a whole with adjacent row(s) of lamps. In the so-called custom approach, the lamps and streets are regarded as separate entities. In particular, one luminaire can illuminate several neighboring streets. Therefore, the configurations of lamps for a given lighting class on a given street must take into account the currently-assigned lighting classes for its neighbors to avoid over-lighting in overlapping regions.

In the first case (classical design), the number of presets is limited to a few dozen profiles per road, so an agent-based system such as GRADIS (formerly PhoCa [11]) can compute the design without any problems. At the same time, it must be noted that the task is already overwhelming for a human designer.

In the custom case, the entire combined state of an intersection consists of a million or more possible combinations. However, because the set of reachable states is much smaller, the search space can be still reduced.

The structure of the article is following. In Sect. 2 we give a brief overview on design methods and their objectives. Section 3 contains basic concepts and notions underlying lighting control. In particular, it highlights the role of an inventory in design and control actions. In Sect. 4 we discuss the method of overcoming the combinatorial explosion caused by huge number of states to be processed by a control/design system. In the last section the final conclusions are given.

2 State of Art

In this section we present the basics of design process in both classical and custom approach.

2.1 Photometric Computations for a Single Lighting Situation

Photometric computations are necessary step in preparation of a lighting infrastructure compliant with mandatory standards (see e.g., [2, 7, 9]) describing required illumination levels for roads, streets, pedestrian traffic zones, residential areas and so forth. In the simplest and the most frequently applied approach, a layout of each street or road is simplified in the sense that it is regarded as structurally uniform: with constant road width, lamp spacing, lamp parameters etc. Thus, the input data for a single pass of calculations made on a single road (see Fig. 1) consist of such parameters as: carriageway width, predefined reflective properties of a carriageway, number of lanes, pole setback, pole height, arm length, arm inclination, fixture model, fixture inclination, rotation and azimuth, fixture dimming (applies mainly to solid state lighting). It should be noted that to each road or walkway a row(s) is (are) ascribed. Each lamp in such a row is located with the same setback as others. We neglect here all meta-data related to database internal structure such as keys, indexes, timestamps etc.

Fig. 1.
figure 1

The sample lighting situation with parameters being taken into account during computations: H – pole height, S – luminaire spacing, a – arm length, \( \alpha \) – arm inclination, F – fixture model, w – carriageway width

Full size image

When one deals with an optimization process which aims at finding such luminaire adjustments that the resultant power usage is minimized, for instance, then instead of single values the ranges for optimization variables appear in the above list:

  • pole height \( \rightarrow \) pole height[from, to, step],

  • arm length \( \rightarrow \) arm length[from, to, step],

  • arm inclination \( \rightarrow \) arm inclination[from, to, step],

  • fixture model \( \rightarrow \) \( \mathbf{fix }_1,\mathbf{ fix }_2,\dots \mathbf{fix }_N \),

  • fixture inclination, rotation and azimuth \( \rightarrow \) [from, to, step] for each angle type,

  • fixture dimming (applies mainly to solid state lighting) \( \rightarrow \) fixture dimming [from, to, step].

In other words, the input contains the Cartesian product of optimization variables. The high-level structure of output data for single pass computation (in contrast to optimization) links a set of adjustments with resultants photometric parameters. At the low level we obtain particular parameter values. For example, according to the EN 13201-2:2015 standard [7] for motorised traffic routes one has five parameters describing the lighting infrastructure performance, namely average luminance (\(L_{avg}\)), overall uniformity (\(U_o\)), longitudinal uniformity (\(U_l\)), disability glare (\(f_{\mathrm {TI}}\)) and lighting of surroundings \(R_{EI}\).

Table 1. M – lighting classes (for traffic routes) according to the EN 13201-2:2015 standard. \(L_{avg}\) – average luminance, \(U_o\) – overall uniformity, \(U_l\) – longitudinal uniformity, \(f_{\mathrm {TI}}\) – disability glare, \(R_{EI}\) – lighting of surroundings
Full size table
Table 2. C – lighting classes (for conflict areas) according to the EN 13201-2:2015 standard. \(\bar{E}\) – minimum allowable average horizontal illuminance, \(U_o\) – overall uniformity of horizontal illuminance
Full size table

In turn, each optimization process produces a Cartesian set (or its subset if some heuristics were applied for restricting a search space) of such output sets.

Such an approach being used by market available software [6] simplifies and thus shortens the design process flow. On the other side it yields designs which are not optimized with respect to the power usage so if an objective is energy-efficiency optimization then the customized lighting design [17] has to be applied.

2.2 Customized Computations for a Single Lighting Situation

The only but fundamental difference between regular and customized photometric computations is that a lighting situation such as street, roadway or bike lane is not regarded as uniform anymore. Instead its real layout is taken including such elements as area boundaries, locations and orientations of luminaires, individual properties of particular lamps etc. Having those data a system splits a road into multiple consecutive segments being lighting situations (Fig. 2). Additionally, we consider roads and luminaires as two separate sets. The lamps are ascribed to a particular segment on the basis of certain spatial conditions which have to be satisfied [4] (this assignment can be analytically derived from spatial data).

Fig. 2.
figure 2

The sample roadway in customized approach. The roadway area is subdivided (dotted lines) into segments \( S_1,\dots , S_4 \). Hexagonal symbols denote location of luminaires and gray shaded area covers all luminaires relevant to the segment \( S_2 \).

Full size image

All spatial data referencing roads and luminaires are geolocalised. This high granularity approach allows to obtain up to 15% of power usage reduction [18].

The output set structure for customized computations also diff ers from the case of regular ones. The key differences are:

  1. 1.

    Per segment results rather than per road (street, walkway, etc.). Individual resultant photometric parameter values are assigned to all consecutive segments which constitute a given roadway.

  2. 2.

    Separate, individual set of adjustments for each relevant (i.e., being ascribed to a considered segment) luminaire, instead of one set for entire row of lamps.

To support the above computation scheme one needs do deploy additional agents on the per-segment basis. Also the optimizing process requires using appropriate heuristics to restrict a search space size. The example is an observation that all luminaires located along a street (and thus, the corresponding segments) have the same values of most luminaire adjustments (except dimming value). Such constraints but also other, imposed by some business requirements, have to be also stored in an inventory and accessible for computing agents.

3 Lighting Control

Another use case for an inventory is a lighting control [3, 19, 20]. The concept of an adaptive control is based on the notion of a lighting profile. The starting point for this is the observation that an environment state is given as a convolution of various parameters such as traffic flow intensity, ambient light level, presence of pedestrians, weather conditions and so on. Those parameters are tracked by telemetric layer (e.g., rain sensors, induction loops and others). Any change of the above shifts an environment to another state. The control system performance relies on adaptation of a lighting system to such changes triggered by sensors. It should be remarked that the term environment used here denotes each area type (street, road, intersection, walkway, parking zone etc.). The lighting profile then is understood as an environment state together with the corresponding luminaires’ adjustment, satisfying lighting standard requirements.

Such a control is more and more feasible due to rapidly developing IoT (Internet of Things) devices and sensor nets. It leads to broad availability of relevant data [5, 13, 16]. The main drivers are safety, convenience and energy savings [8, 10]. Currently available control systems are often based on rules and configured for particular deployments [1, 12, 14, 15]. However, they lack underlying formal models. It increases risk of not meeting lighting standards and costly adjustment to evolving requirements or deployment at new locations. Having the proposed environment model supported by photometric calculations mitigates these risks.

Fig. 3.
figure 3

The sample intersection (I) of several streets (\( R_1,\dots , R_5 \)). Particular calculation fields are delimited with the black lines

Full size image

Let us consider a design process preparing lighting profiles for the street \( R_1 \) shown in Fig. 3. For simplicity we assume that an environment’s state is defined solely by the ambient light level which is discretized to 20 levels (1– no ambient light, 20 – ambient light delivers all lighting necessary) and the traffic flow intensity. The latter parameter decides which lighting class from the series M1, \( \dots , \)M6 (see Table 1) has to be selected. For those assumptions we obtain \(6 \times 20 = 120\) possible profiles for each street. Analogously, for the intersection I for which the EN 13201-2:2015 standard specifies the lighting classes C0, C1, \( \dots , \) C5 (see Table 2) we have also 120 possible profiles. Thus for the area shown in Fig. 3, regarded as a whole, the number of states (profiles) is

$$\begin{aligned}&(\mathrm {number\, of\, states\, for\,a\, street/intersection})^ \mathrm {(number\,of\,streets\,and\,intersections )}= \\&\qquad \qquad \qquad \qquad \qquad \quad =120^6 \approx 3\times 10^{12}. \end{aligned}$$

Remark

The above formula expressing an estimation of a number of available lighting profiles should not be confused with a number of possible lamp configurations discussed in Subsect. 2.1.

Application of heuristics such as the traffic flow conservation law or constraints imposed on ambient light correlation among particular areas allow reducing the number of states, which limits the combinatorial explosion of states to analyze and leads to both design and control optimization.

3.1 Supporting Calculations Using Inventory Data

Any automated process requires a reliable source of data to yield appropriate results. In case of lighting calculations, this involves integration of various types of data:

  • Road network. As traffic intensity is the key factor used to alter the lighting class, and the sensors are usually sparse, it is crucial to model traffic flow using road network graphs. Also, data available in road maps can serve as an aid for selection of lighting classes.

  • Geodetic data. For detailed calculations, it is crucial to use realistic road and sidewalk shapes. This data may be available as CAD files, or it can be regenerated in an interactive process using map data-based reasoning and aerial imagery.

  • Infrastructure data. Obviously, all lighting point details need to be maintained, including pole and arm geometry, fixture details, etc.

  • Calculation results. Lamp settings needed to achieve a given lighting class on a given road segments are needed by the control module.

To allow for efficient support of the design phase and dynamic control of the lamps, all this data needs to reside in a coherent, spatially-enabled repository. This allows for analysis based not only on lamp data (distance, spacing, height, etc.), but also on spatial relationships between the lamps and the lit areas. This characteristic is crucial to allow for optimizations described in Sect. 4.

4 Making Design and Control Viable

The combinatorial explosion of states described above makes the design process longer and the control process more computational resource hungry. It puts forward two goals: 1. minimize number of states in terms of combination of neighboring lighting classes to calculate photometry for; 2. minimize number of states in terms of lighting profiles for the control system to manage.

Fig. 4.
figure 4

Design process upgrade to reduce combinatorial explosion of states.

Full size image

As a result the design process has to be optimized as it is showed in Fig. 4. Both spatial and photometric optimizations are taken into account. The classical approach assumes that lighting classes, coupled with road parameters, are delivered to the design process. The design provides a massive set of profiles by performing photometric calculations which are stored back in the inventory. Subsequently the profiles are used by the control. The optimized approach is driven by the aforementioned goals. The set of classes is reduced thanks to spatial relationships among luminaires, traffic flow statistics, and imposed traffic laws at given locations. As a result the set of classes is significantly reduced, purging all those states which are not reachable which addresses the goal number 1. This reduced set of classes is delivered to the design process which calculates photometry, thus provides lighting profiles. Since the energy usage differences among some lighting profiles might be insignificant they are reduced further addressing the goal number 2. Such a reduced set of profiles is stored back in the inventory and subsequently passed to the control.

For the example given in Fig. 3 the number of states is reduced from \( 2.99\times 10^{12} \) to \( 54 \times 10^6 \) which is 55,296 times. Such a reduction makes both the photometric design and control viable.

5 Conclusions

Pre-calculating lighting profiles to provide precise lighting design and control at intersections is a very complex task for large-scale systems. It is due to combinatorial explosion of search space. The problem is tackled twofold.

First, by changing the design-control paradigm: a design does not cover all possible control scenarios anymore but most of them. The remaining states are calculated on demand in in-the-fly mode using AI-based techniques rather than photometric computations, to reduce the response time. Those requests are submitted by a control system which plays a role of an initiator.

The second method of reducing complexity is using additional data such as a geo-spatial distribution of light points, traffic intensity statistics, and traffic law regulations. Those data impose constraints which significantly restrict a search space. On top of these there is an additional optimization performed which merges similar states together where similarity is measured by energy consumption.

Altering the design process results in the state space reduction which makes the design and control processes to be feasible.

The proposed approach is intended to be applied in the R&D project being in the development phase, co-financed by National Centre for Research and Development (Poland). Its objective is creating a high-quality (with respect to energy efficiency), large-scale, smart lighting system.