Graph-Based Computational Methods for Efficient Management and Energy Conservation in Smart Cities

Abstract

Computational methods play a significant role in reducing energy consumption in cities. Many different sensor networks (e.g., traffic intensity sensors, intelligent cameras, air quality monitoring systems) generate data that can be useful for both efficient management (including planning) and reducing energy usage. Street lighting is one of the most significant contributors to urban power consumption. This paper presents a summary of recent attempts to use computational methods to reduce energy usage by lighting systems, with special focus on graph-based methods. Such algorithms require all the necessary data to be integrated, in order to function properly: this task is not trivial, and is very time-consuming; therefore, the second part of the paper proposes a novel approach to integrating urban datasets and automating the optimisation process. In two practical examples, we show how spatially triggered graph transformations (STGT) can be used to build a model based on the road network map, sensor locations and street lighting data, and to introduce semantic relations between the objects, including utilisation of existing infrastructure, and planning of development to maximise efficiency.

1. Introduction

Computational methods have great potential to improve the energy efficiency of cities—the most obvious approach being to reduce the consumption of power by the operating infrastructure, which includes various types of systems, such as public utility buildings, transportation and street lighting. As shown below, it is lighting that has perhaps the greatest potential to reduce energy consumption.

This paper aims to provide a broad overview of approaches to various aspects of road lighting optimisation, while also providing insight into its significance with regard to economic and environmental effects. Graphs and graph transformations are useful tools for implementing power-saving solutions. This paper provides a summary of existing graph-based approaches to urban infrastructure optimisation, primarily focused on the aforementioned example of road lighting.

The applicability of the presented methods is also covered, as they can only be used if all the data necessary to perform computation-based optimisation are available. Static data—such as GIS datasets, statistics and infrastructure inventory—constitute the basis for better understanding of city characteristics, and should facilitate the decision-making processes. Dynamic data, usually produced by various types of sensors, provide an insight into the processes, and model the behaviour of both the inhabitants and the technical infrastructure.

One key issue that arises during attempts to use spatial data for analytic or optimisation purposes is the difficulty of dataset integration; hence, most pilot implementations described here required a significant workload with regard to data preparation.

For instance, a city may have separate datasets modelling the static infrastructure (roads, buildings, etc.), the locations of traffic intensity sensors (as points with geographic locations) and the locations of street lights (again, as points); however, there are usually no indications regarding which street area is illuminated by a given lamp, or which road carries the traffic flow measured by a particular sensor.

As a natural follow-up to the presented, existing approaches, a new approach is proposed: this structure materialises the relationships between objects in separate datasets that model distinct layers of the city infrastructure. It involves creating a “digital twin” of the city, using graph formalism. The concept is presented, and followed by two simple practical examples.

The rest of the paper is structured as follows: Section 2 provides more insight into the significance of the proposed methods in the area of power efficiency improvement; Section 3 provides a structure, and an extensive review of recent advancements in the use of computational methods for energy conservation, with special focus on graph-based algorithms; Section 4 introduces the concept of a graph model for a digital twin of the city, and provides two practical examples of its application; Section 5 concludes the presented work, and outlines the planned next steps of the research.

2. Motivation

The European Union’s energy policy includes the need for secure energy supplies, sustainable energy consumption, lower fossil fuel dependence and improvements in energy efficiency. The Fraunhofer Institute [1] showed the levelised costs of electricity (LCOE) for different electricity sources in 2018, and its prediction up to 2035. The LCOE of onshore wind turbines ranges between EUR 39.9/MWh and EUR 82.3/MWh in 2018: as a result, PV systems and onshore wind turbines are, on average, the least expensive technologies in Germany, both among renewable energy technologies and fossil fuel power plants. The LCOEs for other sources are as follows:

• photo-voltaic (PV) systems—from EUR 37.1 to EUR 115.4/MWh;
• offshore wind turbines—from EUR 74.9 to EUR 137.9/MWh;
• biogas power plants—from EUR 101.4 to EUR 147.4/MWh;
• conventional power plants:

  -

  brown coal—from EUR 45.9 to EUR 79.8/MWh;

  -

  hard coal—from EUR 62.7 to EUR 98.6/MWh;

  -

  combined cycle power plants—from EUR 77.8 to EUR 99.6/MWh;

• PV home storage systems—from EUR 163.4 to EUR 473.4/MWh; both the costs of electricity generation and storage.

In [2], a new methodology was proposed, to compute the LCOE for a street lighting system. The analysis yielded several observations:

• street lighting retrofit unquestionably offers the highest energy-reduction-to-investment-cost ratio: the LCOE is in the EUR 23.06–EUR 54.64/MWh range;
• the presented values were validated using several dozen real-life lighting modernisation projects;
• because LED technology is already stable, and lighting requirements are precisely specified by the EN 13201 standard, the difference between the upper and lower bound of the LCOE is due to the quality of the lighting system design: these issues are discussed in more detail later in the paper.

From this perspective, street lighting, including its design and control, is an aspect of the smart city concept that can have a strong economic impact.

It should be noted that the share of public lighting in electricity consumption reaches 19% of its global volume and 30–50% of a typical city’s energy bill [3]: for this reason, public lighting is subject to intense research that covers a wide spectrum of topics, including hardware development, optimising design and control, and enhancing factors that have an indirect influence on lighting performance. Lighting costs represent up to 25% of the total budget for management of the road network; the rate is even higher in the case of road tunnels, which require illumination both to work around the clock and to comply with safety-related requirements—factors that make tunnel lighting systems highly energy-consuming.

It is also important to see the citywide lighting infrastructure as a whole—that is, as a system consisting of multiple elements (layers) that play separate roles in it: light sources; sensor layer; control modules at the level of lamps and cabinets; control logic; communication layers, etc. All of the above have to be supported by an efficient data processing layer, and organised in some scalable architecture. An interesting discussion of this aspect of lighting systems can be found in paper [4].

Infrastructural data underlying public lighting design and management are strongly coupled to other aspects of the smart city environment: street/walkway topology; traffic flow patterns; and characteristics of particular areas (crowds, accidents, air pollution, etc.). Consequently, lighting infrastructure assets can be integrated into other layers of the smart city architecture, e.g., CCTV cameras or sensors: this follows a common trend towards collective data exploitation that integrates knowledge from different domains [5], so as to provide added value.

In general, smart city concepts revolve around proper digital twin models and data acquisition, including its interpretation and inference [6,7]: such information, often referred to as knowledge, is expressed both semantically and spatially in the form of graphs or nets [8]. Although there has been lots of research conducted in this domain, actual economical benefits can be hard to establish, either because they are difficult to measure—being subjective, especially when they are stretched over considerable time—or because some other objectives take precedence over economy, such as safety, convenience or comfort [9]. Similarly, the main objective might be to fit a new policy into a framework of constraints: for example, accommodation of low-carbon communal heating for housing with electric vehicle chargers within the current power grid [10], rather than cost optimization.

Smart city modelling is based on established theories drawn from physics, engineering, economics, geography and urban planning, which are complemented by data science techniques, particularly machine learning, which produces added knowledge [11], being a progressive process. Some benefits are more subtle, such as identification of system-level risks and inefficiencies of development: these should lead to policy changes, which in turn impact economy, in which case, once again, the economic impact is deferred, and is not easy to estimate, especially as it is not the main goal. An example is the Cambridge Digital Twin [11], the purpose of which is to provide consistent policy for transport, housing, environment and energy in the Cambridge sub-region, by developing scenarios that test the impact of infrastructure constraints on the future locations of businesses, and on employment, households and travel choices, which will subsequently be integrated into the local authority processes. The main goal is to improve urban development.

One smart city aspect that could be economically measurable, the effects of which are comparable to those of street lighting, is the intelligent optimisation of building management: this includes internal comfort, climate control and renewable energy production [12]. The goal is to increase the effectiveness and efficiency of such buildings, in terms of energy and maintenance costs. As a result, energy consumption can be reduced by 32%, thanks to smart planning and control [13].

3. Computational Optimisation of Lighting Systems

This paper presents recent approaches to optimising the energy efficiency of lighting systems by means of computational methods. In the review, we focused on street lighting, as it is one of the most significant contributors to urban energy consumption (see Section 2), with great potential for improvement. As the presented methods have a very broad spectrum of applications, the summary has been structured into individual sections.

3.1. Design Process

As previously mentioned, street lighting installations should or must meet performance requirements, specified e.g. by the CEN 13201-2:2015 [14] standard (or one of its localised versions). These requirements—which are subdivided into three main categories—M for roads, C for conflict areas and P for pedestrian areas—and in each category, the individual lighting classes are ordered, from the most demanding one (e.g. M1), with high luminance level requirements , to the lowest (e.g. M6), with the lowest demands. Obviously, the higher the luminance levels, the higher the related power usage. The particular lighting class is selected using several parameters, such as traffic volume and composition, presence of carriageway separation, density of junctions, presence of parked vehicles, ambient luminosity, navigational task conditions, etc.

When designing a lighting installation, either from scratch or during a retrofit, an engineer is supported by industry standard software, such as DIALux, AGi32 or Relux  [15,16,17]. Nevertheless, preparing a standards-compliant and energy-optimized design for a single street requires choosing appropriate values for multiple parameters, such as lamp pole height, arm length, fixture inclination, dimming level, lamp setback (if a lamp location is subject to change) and so forth: for large-scale design, covering thousands of lighting situations, this becomes infeasible within a reasonable time. For that reason, a designer assumes “conservative” installation settings, in particular an overestimated fixture power, which allows for compliance with the performance requirements for the assigned lighting class. In most cases, this implies meeting standard constraints without additional tuning. Such an approach, however, implies designs that are not energy-efficient, and also that the entire design preparation period can be measured in weeks, which is not acceptable from the business perspective.

In turn, automated, computer-based design have been developed; however, these encounter complexity-related problems. Applying the method of brute force search to finding the optimal solution would require testing ${10}^{21}$ possible variants (the number of elements in a Cartesian product of all relevant degrees of freedom), which makes this approach practically inapplicable. This drawback has inspired researchers to look for other, heuristic methods that avoid browsing the entire solution space. Rabaza proved in his work [18] that applying a differential evolution algorithm to the planning of public lighting for streets, roadways and motorways can lead to maximising the energy efficiency of an installation, and to complying with CIE-115 [19], which is another, alternative, lighting standard issued by the International Commission on Illumination. The algorithm Rabaza used was applied to a model based on new relationships between the energy efficiency of street lighting systems and layout parameters, including street width, pole height and lamp spacing. The algorithm input was the lighting class or illuminance level, street width and other lamp parameters. The results of this algorithm consisted of the lamp arrangement (one-sided, bilateral staggered or bilaterally symmetrical), pole height, lamp type and lamp spacing of the most energy-efficient installation. The analysis of the obtained results showed that they were compliant with the recommendations of [19].

Another approach was developed by researchers from AGH University, who focused on resolving complexity issues by constraining the number of considered configurations: this was achieved by rejecting all non-applicable ones (e.g., low-height poles for widely-spaced lamps). The set of “correct” setups was generated by applying graph transformations. This approach is used now in the commercial software packaged, PhoCa, which can produce lighting designs with power usage reduced by 65% to 75%, depending on the original lighting configuration (for comparison: a human designer is capable of achieving $\sim 50\%$ energy savings). Scientific results relating to this approach have been published in over 80 papers: a selection of those will be discussed in the next part of the article.

The first time the PhoCa software prototype was used was in 2013, in an international R&D project carried out by AGH University, EANDIS—the Belgian grid operator (integrated with Infrax, in 2018, as Fluvius) and other industry and municipal partners [20]. The optimisation was performed according to user-defined criteria, and supported by graph transformations that reduced the energy usage. Tests performed against real-life data supplied by EANDIS established 5–8% power usage reduction for HID (high-intensity discharge) lamp-based installations (no HID-to-LED lamp replacement was performed).

The following works focused on the following two areas:

• improving the lighting design methodology, in terms of the energy efficiency of the resultant installations;
• finding graph models that were expressive enough for problem specification while being computationally efficient; in particular, the problems of automated parallelisation of data processing were considered.

As mentioned above, a human designer imposes “conservative” installation settings, to make sure that the performance of the resultant installation meets the requirements of the standards. Let us take the example of evenly spaced poles with an (aggregated) spacing value set to the maximum of actual ones: for instance, a row of lamps with spacings (in metres) 32-33-31-30-33 is simplified by taking 33 m or even 35 m for each lamp-to-lamp distance in the row (the latter, even higher value can be taken to create a single design template covering multiple cases and, thus, to reduce the overall design preparation time). As spacings between consecutive lamps are increased, it is obvious that the final energy requirements usage will rise as well. Let us note that, in contrast to a lighting engineer, a computer system can perform all underlying calculations using actual data instead of the aggregated (e.g. maximum) values, thus avoiding power usage overestimation.

In our paper [21], we proposed photometric computations compliant with the CEN 13201-3 standard [22], and addressing lighting situations that are not uniform—that is, when neither the luminaire spacing nor the road width are constant. Such an approach differs from the typical usage of the CEN 13201-3 method, where both spacings and road width are taken as uniform aggregates. Using actual data instead of aggregated data [23] resulted in a significant reduction of the power usage, which reached nearly 15% for the considered cases. Tests showed that this ratio grows with increasing standard deviations of luminaire spacing and road width. On the other hand, the obtained results were notably better, in terms of energy efficiency, than those produced by industry-standard software.

To illustrate the complexity problem related to the proposed approach, let us suppose that a retrofit of $n=200$ street lamps is performed, including replacement of fixtures, poles and arms. To find the optimal solution, one has to check all possible variants, as follows: (i) pole height of 8–12 m with 0.5 m step (9 variants); (ii) arm length of 0.5–3 m with 0.5 m step (6 variants); (iii) fixture mounting angle of 0${}^{\circ }$–15${}^{\circ }$ with 5${}^{\circ }$ step (4 variants); (iv) dimming level of 0–50% with 1% step (51 variants; we assume that higher dimming may be rejected a priori); (v) fixture model—a set of 500 models/photometric solids (500 variants). The total number of scenes to be tested is N = 5,508,000, when a uniform lighting situation is assumed, or N = 5,508,000 × 200 ≈ 1.1 ×${10}^9$ when we admit deviations from uniformity (each lamp needs to be considered separately). Such complexity may lead to problems with practical usage of the approach unless appropriate computation methods are applied.

Practical solutions to this problem were verified [24] during a public lighting retrofit project sponsored by the Polish National Fund for Environmental Protection and Water Management, carried out for 3,766 lamps illuminating 237 streets in Kraków, Poland. The goal of this retrofit, except for replacing HID lamps with LEDs, was to implement dynamic lighting control (discussed in the next section). This required the preparation of three standard-compliant designs for each lighting situation: one for “regular” traffic conditions (e.g., M3), and two for lowered classes (e.g., M4 and M5, respectively), which were applied during periods of decreased vehicle traffic intensity.

In addition to typical adjustment of pole heights, arm lengths, etc., appropriate fixtures (photometric curves) had to be selected for particular lighting situations. In this phase, 2,000 fixtures were tested, which had to be matched appropriately to area types: walkways; parking zones; streets, parks, etc.

Due to the non-homogeneous geometries of streets, they had to be logically subdivided into over 600 sections (in total) with uniform layouts. The most frequent layout contained a single carriageway, with walkways on both sides. Each situation was separately ascribed a suitable lighting class (and two lowered, for control purposes). In terms of photometric computations, the design covered approximately 3 [classes] × 600 [lighting situations] = 1800 [projects]. The design was drawn up independently by a designer team, in a traditional way, and by the PhoCa software, using the aforementioned methodology: the latter achieved 15% energy savings compared to the solution produced by the former.

Regarding enhanced graph models and mechanisms, the focus was on introducing parallel derivation in graph grammars, rather than preparing synchronisation algorithms, customized for processed data. The concept of replicated complementary graphs [25] was very useful here. In this model of graph distribution, one divides a centralised graph into several subgraphs (complementary graphs), where a dividing line passes through graph nodes (see Figure 1): thus, vertices located along it (referred to as the border nodes) may fall into several subgraphs. Each complementary graph is maintained by a computing agent, which applies graph transformations to it. If all nodes required for launching a graph transformation are present in a given complementary graph, then an agent can trigger a production without the risk of time-dependent errors; otherwise, if some required nodes are located in the other subgraph, an agent moves the missing nodes to its own subgraph in order to obtain exclusive access to all the vertices needed for initiating a transformation. When moving vertices between subgraphs, it uses system multi-agent cooperation functions based on a two-phase commit-like protocol.

Thanks to the concept of Replicated Complementary Graphs, it is possible to develop graph grammars, and to carry out conceptual works on a centralised graph  [26]. The results, in turn, can be tested straightforwardly in a distributed environment in the parallel manner.

Modification of the above graph distribution method was introduced in [24]. In this case, a dividing line passes through graph edges rather than its nodes (see Figure 2). As each edge can be shared by at least two subgraphs (referred to as slashed graphs), it allows decreasing subgraph coupling: this becomes noticeable when an agent intends to gather exclusive access to foreign nodes, at which point the number of involved parties becomes significantly lower than in the case of replicated complementary graphs.

3.2. Dynamic Control

Outdoor lighting control can be based either on scheduling (static control) or sensor data (dynamic control). The scheduling approach is commonly used, and may be implemented either at the main control system level or only for particular lamps, through their programmable modules.

Unfortunately, basing control solely on statistics is not acceptable in the context of existing lighting standards (such as EN 13201), which assume that the lighting level may change only when specific factors influencing the selection of the lighting class change: these factors include changes in traffic intensity, navigational difficulty, traffic composition (e.g., the presence of non-motorised vehicles) or the presence of parked vehicles.

Lighting control that is reliant on sensor data works on the basis of information gathered by sensors [27]: the data trigger the system to adapt lighting levels accordingly, thus using energy in accordance with actual needs [28,29,30]. Such solutions are already commercially available from multiple vendors, including Owlet (Schréder), LightGrid (General Electric) and CityTouch (Philips/Signify). Infrastructural data underlying public lighting design and management are strongly coupled to other aspects of the smart city environment: street topology; traffic flow patterns; and characteristics of particular areas [31]; therefore, there are several technical problems that need to be solved:

• diagnosing the changes, which requires building or adapting a sensor system (e.g., for traffic intensity, these may include induction loops or cameras);
• providing telecommunications infrastructure to handle delivering commands to each lamp;
• determining the scope of changes – preparing designs for the base (highest) lighting class and the lower classes (see Section 3.1 for the notion of a lighting class);
• binding the sensors with lit areas and lighting devices that illuminate them.

The process of infrastructure deployment—both the sensors and the communication devices—is beyond the scope of this paper. Developing multiple variants of photometric designs for each street was rendered possible by the aforementioned automation of the design process (which would be too time-consuming if performed by hand).

This section discusses the issues of controlling the lighting level based on data received from the sensor systems (treated as a set of sensors).

The first attempt at utilising graph formalisms for lighting control used the example of a petrol station [32]: it defined a graph modelling the connections between sensors and lighting devices; it also presented the graph transformations triggered by a sensor change, which modified the graph edges and nodes—which, in practice, was equivalent to altering the lighting level. The goal of the paper was to prove the usefulness of graph transformations by means of a simple, small-scale example.

In [33], it was shown that patterns of road traffic intensity differ not only on various days of the week, but also depending on the season and other factors, as shown in Figure 3.

Statistically, according to the 2004 version of the EN 13201 standard, for the testbed of Kraków, Poland, the ME2 class was used 46.5% of the time; the more energy-efficient ME3 was used 15% of the time; and the most efficient ME4 was used 38.5% of the time. The conclusion was that for over half of the operating time, energy consumption could be lowered, which would translate to 24% energy savings. Using a dimming scheme based on statistics is, of course, easier (as it does not require sensors or real-time data analysis), but bears the risk of breaking the EN 13201 standard requirements if the actual situation does not correspond to the historical data used to develop the schedule.

It seemed reasonable, therefore, to build a system that would bind the traffic intensity data with the lighting level. In [33], a new graph structure, the Control Availability Graph (CAG), that stored the current state of the system, was proposed. A single intersection included around 30 nodes, representing sensors, lamps and intermediary control structures. Every sensor data change (recorded in a 15-min interval) triggered one of four predefined transformations. As a result, the prevalence of lighting classes was shifted to: ME2—27%; ME3—14%; ME4—34%, which further increased the energy savings to 34%.

This concept was further developed, to increase the efficiency of both the design process (i.e., to reduce the workload of the human designer) and the data processing phase (reduction of the graph size, due to the dual graph grammar concept [34]). Using single graph grammar to describe several data structures simultaneously makes the resulting graphs unclear for the designer, and hard to manage [33]. In particular, the nodes representing sensors are connected to several (sometimes over 10) nodes representing lamps. Such a structure cannot be used to determine the influence of sensor readings on the dimming level, which requires analysis/computations performed using node and edge attributes.

A new concept was proposed, therefore, which involved separating the sensor structures and lighting devices into two separate grammars. In the case of the sensor structure, it was the DSG grammar, determining the traffic flow for a street segment, using an arithmetic formula: sum, difference and min/max functions for appropriate sensors. This value was stored in a special node, called the virtual sensor. The lighting structure was the well-known CAG, with added virtual road segments connected to every lighting segment.

The dual graph grammar automatically synchronises the operations on the common structure – in the case cited, the common structure was a set of virtual sensors. The DCG ensured that any modification of the virtual sensor node (by a transformation within the first graph grammar) forced execution of the other transformation within the second grammar. As noted above, the basic goal was to simplify the designer’s work, by improving graph readability, making the approach scalable. Practical tests showed that the final graph became smaller, and that the processing time was reduced by 2.8 times. As these calculations were repeated every 15 minutes, this improvement was significant, and contributed to the scalability of the solution.

It is interesting to compare the 2004 and 2014 versions of the EN 13201 standard, with regard to dynamic lamp dimming [35]. An intelligent street lighting project, carried out by the City of Kraków in cooperation with AGH University from 2014 to 2017, was initially based on the older (2004) version of the standard, and yielded energy savings of 34%. Later, the design process was repeated, using the 2014 standard. While the lamp configurations for the ME (2004) and M (2014) lighting class pairs were very similar, there were significant differences with regard to class applicability, i.e., what traffic conditions enabled the application of a given lighting class. Consequently, the estimated energy savings by dimming performed according to the newer (2014) standard rose to 40.82%.

3.3. Device Development

In this area, the focus is, among other aspects, on improving light source technology, in a broad sense—the most known and common example of which is replacing high-intensity discharge lamps (HID), such as Mercury-vapour or Sodium-vapour, with LEDs: such retrofit alone yields at least a 50–60% reduction in power usage. The next field of technological progress is improving lamp luminous efficiency, i.e., the ratio of luminous flux to power. Another important property of a fixture is its photometric solid: this term refers to the spatial distribution of the emitted light. Although it does not have a direct impact on the final power usage, using appropriate light distribution curves during the lighting design process prevents over-lighting, and thus achieves power savings. The next field of device optimisation is reducing the generation of the capacitive reactive power: these improvements, in turn, are focused on the lamp’s power supply/driver module, rather than on its optics, and are necessary, as producing reactive power (the side-effect of LED usage) is subject to penalty charges. Reactive power compensation can be also achieved at the level of particular power circuits (or power cabinets): such an approach, based on an infrastructure graph model, was presented and discussed thoroughly in paper [36].

3.4. Tunnel Illumination

As mentioned in Section 2, retrofitting lighting installations—i.e., replacing sodium lamps with LEDs, combined with lighting control (both discussed above)—yields even more significant savings in road tunnels.

In 2018, the public Italian road infrastructure operator, ANAS, began a program of modernisation of lighting systems in more than 700 tunnel tubes all over the country, subdivided into eight regions [37]: each region contained between 39 and 145 tubes, with a total of 708 tubes (532 km). The program goal was to reduce electric power consumption, and to improve the management of lighting systems while minimising the impact of works: this was to be achieved by retrofitting high-intensity discharge lamps (usually sodium ones) with light-emitting diode (LED) luminaries, keeping their previous locations. It also retained the number of fixtures unchanged.

The project costs were EUR 155M, with an expected payback period of less than seven years. The first phase of the project, involving 147 tubes, aimed to save 28 GWh annually (on average 55% of the actual consumption) against a EUR 30M investment [37].

Further strategies to decrease the power consumption of the lighting installations of road tunnels have been proposed in recent years, with a significant increase in the last decade [38]: for example, the traffic-weighted method, which was used to calculate the actual luminance levels for a tunnel entrance zone; in turn, a new transition zone, which decreased the luminance curves, was obtained, and was compared with the existing ones. As a result, a new switching control was proposed and programmed for a tunnel SCADA (Supervisory Control and Data Acquisition) system [39]. Regarding light injection, the reliability of light-pipes to light the interior of tunnels was analysed and presented in [40]; this strategy of using natural light in indoor infrastructures had not previously been proposed for road tunnels. The results of this paper were improved in paper [41], where the main shortcomings of the technique (the efficient injection of light into the light-pipes) were solved by the coupling of heliostats aligned with the light-pipes. More recently [42], a ground-breaking technique of injecting light was proposed: rather than hanging from the ceiling, the light-pipes were run on the ground. This technique used an ad hoc surface of the vault to reflect and distribute the injected light on the pavement.

Further methods of tunnel lighting optimisation include mitigating the light level in the tunnel access zone, and ensuring its homogeneity, by building pergolas preceding a portal gate [43,44] or coating the road with special asphalt featuring a high reflection coefficient [45], which allows for reducing light absorption and loss.

4. Further Steps: Data Integration

Section 3 presented several areas where computational techniques are used to reduce the energy requirements of city systems, with street lighting being one of the major contributors to urban power consumption.

While most of the presented approaches have already been implemented by testing in real-life environments, all of these implementations were pilot projects of limited scope: this was because, even though the methods scaled well—with regard to design, communications and data processing capacity—in practise, data preparation is often the most time-consuming phase.

As outlined in Section 1, straightforward integration of smart city datasets is usually not possible, because the only “common denominator” among them is the spatial (GIS) component, i.e., the locations (shapes) of the objects.

As we demonstrated in [46]—in which we described a large-scale attempt to determine the areas illuminated by each lamp in Washington, D.C.—a sophisticated sequence of spatial, statistical and numerical analysis procedures can lead to satisfactory results, which may at least allow for better planning and estimation of potential power savings. However, the procedure needs to be carried out by an analyst, who has to be proficient in computer-aided spatial analysis tools, in Python programming and in the basics of lighting engineering. The procedure is complex, and its development involved numerous backtracks, which have rendered the process error-prone, and put a heavy burden on the operator, with regard to documenting the experiments and versioning of the tools.

GIS analysis procedures, such as spatial joins, are also time-consuming; therefore, it seems beneficial to store (materialise) the detected relationships between objects (e.g., the distances between them), as that information can be used to speed up subsequent attempts, even in the case of a rollback.

To this end, we propose an improved version of spatially triggered graph transformations (STGT), first introduced in [47]—a methodology whereby specialised tools are used to detect spatial relationships in raw data, and rules defined as graph productions are later used to supplement these relationships with semantic annotations.

In essence, the methodology can be used to correctly integrate spatial datasets that are not linked otherwise than by the shapes and locations of the objects they describe.

This approach is not limited to integrating separate datasets: even in a single dataset, such as a map of the city, the proposed methodology can be used to provide added value. Map data often originate from sources such as OpenStreetMap (https://www.openstreetmap.org, accessed on 6 January 2023), an open geographic database updated and maintained by a community of contributors. The data are very detailed, and cover a broad range of objects.

Let us take the example task of identifying street fragments which run alongside schools: this information can be important for increasing the intensity of road lighting in such places, as advised by the EN 13201 standard (see Section 4.1.1). However, in the OSM dataset, buildings are not linked to other objects, so the fact of a building being close to a street needs to be inferred by means of spatial analysis.

4.1. The Digital Twin Graph

This section defines the layer structure of the digital twin graph, and enumerates the data sources considered by the expert system used to generate the graph.

4.1.1. Area

Firstly, we will generate the formal representation of the city streets and objects, such as buildings. In this example, public utility buildings will be associated with the streets which run past them.

For this graph, we will use three nodes, $St,Cr,Pu\in V_{{\mathrm{\Omega }}_1}$, and three edges, $mr,sr,ti\in E_{{\mathrm{\Omega }}_1}$, where

• $St$ represents the part of the street between two crossroads;
• $Cr$ represents a crossroad;
• $Pu$ represents a public utility building, generating an increased flow of pedestrian traffic;
• $mr$ represents a main road (edge directions correspond to traffic flow directions), and joins a $St$ node with a $Cr$ node;
• $sr$ represents a sub-road road (edge directions correspond to traffic flow directions), and joins a $St$ node with a $Cr$ node;
• $ti$ represents traffic intensity generated by a public utility building, and joins $Pu$ with $St$.

The primary node attribute is its GIS geometry—a linestring for $St$, and a point for others.

Let us consider an intersection of two streets, as well as one public utility which generates increased pedestrian traffic. Initially, the graph consists of one node, representing the crossroad. The expert system, analysing both the street and the buildings, generates the formal graph representation, using the production described in Figure 4c: if it determines that a one-way street is connected with the crossroad, production $P_1$ is fired; for a two-way sub-road street, $P_2$ is fired, and for a two-way main road, it will fire $P_3$. In practice, a set of productions similar to $P_1$ has to be defined, taking into account the direction and the kind of road. Finally, as the expert system identifies increased pedestrian traffic caused by the presence of the public utility building (which will increase the difficulty of the navigational task, resulting in increased lighting requirements according to the EN 13201 standard) on roads (4) and (5), production $P4$ is fired twice.

This leads to the digital twin graph notation presented in Figure 4c, representing four intersecting streets, where (2) and (5) are two-way main roads, and the others are sub-roads; however, (4) represents a one-way road coming to the crossroad. The public utility building (6) increases pedestrian traffic intensity.

4.1.2. Lighting Segments

In this layer, we extend the knowledge about the uniform parts of streets (fragments with identical lighting requirements according to the EN 13201 lighting standard). Several factors may influence the lighting requirements, including the road width, existence of pavement, presence of parked vehicles and separation of the carriageway. Other attributes may also be provided during this operation, such as the number of lanes and the speed limit. An example of a lighting segment is presented in Figure 5.

The expert system will divide a part of a street (represented by the node labelled $St$ in the graph) into segments (labelled by S, and connected with $St$ node by $in$ edge). The adjacent segments in the part of the street are connected by an $adj$ edge; the outer segments inherit the edge connecting $St$ and $Cr$.

These attributes allow for designating the lighting class of the road according to the EN 13201 Standard.

At this level, we add the lamps, and store their locations, pole height, overhangs and other parameters, as attributes of L nodes. Each lamp is associated with the road segment it illuminates, using an $il$-edge, as shown in Figure 6. The graph grammar productions used for segment generation and lamp assignment are similar to the ones presented in the previous section (Figure 4).

4.1.3. Sensors

Sensors provide the data vital for any city, because they model its dynamics and behaviour.

In the digital twin model, we will consider many classes of sensors associated with influenced objects, such as motor vehicle traffic sensors (labelled as $MS$) or air quality sensors (labelled as $AS$): these are associated with the streets or public utility buildings using edges labelled $if$ (meaning “influences”), as shown in Figure 7.

In real life, sensors are usually associated with a limited number of objects. In Figure 7, traffic sensors are associated with the streets indexed 1, 2 and 4, but no sensor is associated with the street indexed 5. On the other hand, we are able to estimate the traffic intensity in the street indexed 5 as a simple calculation $mvmnt\left(7\right)+mvmnt\left(8\right)-mvmnt\left(10\right)$ (where $mvmnt\left(x\right)$ is a sensor value in node x). As pointed out in [48], the introduction of virtual sensors ($VM$), and using a separate graph grammar to control the way they are calculated, simplifies the notation of the graph transformation system; the method for synchronisation of both graph grammars is called dual graph grammar, and is described in [48]. This leads to more than 10% energy savings.

4.2. Practical Examples

To provide better intuition, with regard to the possible applications of the proposed methodology, let us provide two practical, real-life examples.

Both examples pertain to the problem of introducing dynamic dimming to the lighting system. Traffic intensity is used as the input, and existing traffic intensity sensors can be utilised for that purpose. Conversely, most modern LED street lights have control abilities, but they are usually only used for fixed-schedule control, which may violate the requirements of the lighting standards [33]. By exploiting and integrating the two systems, the city can achieve additional energy savings without the need to invest in any new infrastructure, merely by deploying software systems that read sensor data from one system and apply the appropriate control to the other system.

The first example (Section 4.2.1) presents a rather simple case of integrating the data of separate, already existing smart city systems. The second example (Section 4.2.2) expands this concept on a larger scale, supporting the planning of sensor infrastructure development in a way that maximises the energy benefits.

For clarity, the graph transformations used in these examples are provided as informal, easy-to-follow descriptions.

4.2.1. Example 1: Sensor Data Integration

When developing dynamic dimming systems for street lights, usually the most influential factor is the traffic intensity, as it varies greatly, especially during the operating hours of lighting, which cover both late-afternoon peaks and occasional traffic at night-time. Assuming that the individual lamps have been assigned to the street areas they illuminate, as presented in Section 4.1, the traffic sensors need to be bound to the streets as well. Such a task was crucial for the aforementioned intelligent street lighting project, carried out by the City of Kraków in cooperation with AGH University, from 2015 to 2017. As the presented methodology was not implemented at the time, the integration of the sensors needed to be performed manually.

It is common practice to use a general-purpose map (GIS dataset) as the means of integrating other, specialised datasets: in this case, we will use OpenStreetMap, mentioned in Section 4.

Let us consider a simple case of assigning a dataset, containing six traffic intensity sensors, to streets and individual lanes. All the sensors are located in a single inlet of a 4-inlet intersection in Kraków, Poland. The sensors were initially intended solely as vehicle counters for control of traffic lights, and were only later used for control of street lighting.

The street data are provided as a GIS dataset containing linestring geometries, while the sensor dataset contains point locations for each sensor.

The situation in question is presented in Figure 8. The lines representing roads originated as OpenStreetMap `ways’, and the parameters of four ways taken in further consideration (highlighted by colour in the figure) are presented in

Table 1. Parameters of OSM ways under consideration.

OSM ID	Symbol	Colour	Lane Count	Lane Designations	One-Way
277424366	$S{t}_1$	red	3	left, straight, straight+right	yes
1070812770	$S{t}_2$	blue	2	—	yes
21929772	$S{t}_3$	green	2	—	yes
759900797	$S{t}_4$	orange	2	—	no

. For clarity of further presentation, the roads, identified by their OpenStreetMap identifiers (OSM ID) have been also assigned short symbols ($S{t}_1$–$S{t}_4$).

The sensors are labelled according to their system identifiers (D2_11, D2_21, etc.). For clarity, they have also been assigned short symbols ($S_1$–$S_6$), as presented in

Table 2. Traffic intensity sensors.

Identifier	Symbol
D2_11	$S_1$
D2_21	$S_2$
D2L_1	$S_3$
D2L_2	$S_4$
D2_12	$S_5$
D2_22	$S_6$

.

The next step involves creating a graph. At this point, the graph only contains nodes (ways $S{t}_1$–$S{t}_4$ and sensors $S_1$–$S_6$) along with their attributes (including their locations).

Later, as described in Section 4.1, an external tool is used to determine spatial relationships between the objects in the graph. In this case, the analytic procedure will involve a spatial analysis tool, such as PostGIS (https://postgis.net/docs/; accessed on 20 December 2022) or Shapely (https://shapely.readthedocs.io/en/stable/; accessed on 20 December 2022), and can be expressed as:

Create a proximity relationship between a sensor and a way, for sensors that are not further than 20 metres from the way, and indicate the distance (d), side (positive/negative d) and the offset of the sensor’s projection on the way linestring from its beginning (o).

The graph, after applying such a procedure, is presented in Figure 9a. At this point, the fact of a sensor being within proximity of a road, and the crucial parameters of their relationships, are materialised in the graph.

This means that further processing and inference can be carried out solely by using graph transformation rules. Examples of such rules include:

1.

For each way ($St$), create n new nodes L, where n is the number of lanes for a given way, and create a belongs to relationship between lanes and ways, e.g., $L_1,L_2,L_3\to S{t}_1$, $L_4,L_5\to S{t}_2$, etc.

2.

For each sensor (S), select the candidate way (W) that is closest to the sensor, and delete the other candidate relationships, e.g., for sensor $S_5$, keep its relationship with $S{t}_2$, and delete the edge to $S{t}_1$.

3.

As every sensor is now connected to only one way, group the sensors by their way, and cluster them according to the value of the offset (o) attribute; in our example, this will create the following groups:

$$(S_1,S_2,S_3),\left(S_4\right),(S_5,S_6).$$

4.

Within each cluster, create a measures relationship between the sensors and the individual lanes, e.g., $S_3\to L_1$, $S_2\to L_2$, $S_1\to L_3$, etc.

5.

For ambiguous situations, e.g., $S_4$ (which is the only cluster member), use the values of the other, already-assigned sensors in the same way, to estimate the most probable lane for the sensor; in our example, its d value of $-3.89$ is closest to that of $S_3$ in the first cluster ($d=-4.47$), and the sensor will (correctly) be assigned to lane $L_1$.

6.

Remove all proximity relationships, as they are now redundant.

The graph modelling the assignment of sensors to the lanes and, subsequently, to ways, is presented in Figure 9b. This simple example shows how the results of spatial analysis can be materialised in the form of a graph, and then later elaborated using rules expressed as graph transformation productions.

4.2.2. Example 2: Development of Sensor Network

In the above example (Section 4.2.1), we showed how a graph model based on the STGT methodology can be used to assign sensors to the corresponding road segments and individual lanes. However, when implementing dynamic dimming systems for street lights, the intention is usually to cover as many streets as possible.

As deploying a camera or other traffic intensity sensors on every road segment is not feasible, it is crucial to utilise the full potential of the existing sensor infrastructure, and to choose new sensor locations in a way that maximises their usability.

Let us consider the example of the city of Siechnice, a town in the Lower Silesian Voivodeship, with a population of ca. 9,300, which neighbours Wrocław, the regional capital. The local authorities are keen on innovation and, in the years 2019–2022, Siechnice introduced several intelligent solutions in cooperation with AGH University, as part of the Human Smart Cities project.

The city deployed six cameras in four locations. The cameras were highly configurable, and their features included, among others, the ability to count the vehicles passing through defined areas of the streets: these areas are provided as GIS coordinates, similarly to the previous example.

The process of assigning the sensors to the streets is, therefore, largely identical. However, in order to evaluate the sensor coverage within the entire city, we will further exploit the OpenStreetMap data in the graph building process. Namely, we will create a follows relationship between each pair of streets $(S{t}_i,S{t}_j)$, such that, when travelling along street $S{t}_i$, one can then continue along street $S{t}_j$. For illustration purposes, the follows relationships for the road network of the city of Siechnice are presented in Figure 10a.

Now, for road segments which are monitored directly by traffic intensity sensors, we will set the certainty attribute to $1.0$ (`certain’), and apply the following graph productions:

1.

For road $S{t}_i$, if there is only one road $S{t}_j$ such that $S{t}_i\stackrel{\mathrm{follows}}{\to }S{t}_j$, set the certainty attribute of $S{t}_j$ to that of $S{t}_i$, if it does not have a higher value already.

2.

For road $S{t}_i$, if there are n ($n>1$) roads following it (i.e., it is an intersection with multiple possible turns), divide the certainty attribute of $S{t}_i$ by n, and apply it to these roads if they do not have higher values already.

By applying these productions as long as there are any updates, we end up with a graph modelling the certainty of traffic intensity information for the entire area. The resulting graph is shown on a map in Figure 10b. The locations of the existing sensors have been marked with red stars, and the colour of the lines denotes the certainty of traffic measurement (where red is the lowest and blue is the highest).

Such information can be crucial for the city authorities, when deciding on the locations for newly installed cameras: it follows that the most desirable streets to include in the traffic monitoring system are those with the lowest certainty, which have been marked with the red colour.

5. Conclusions and Future Work

This paper provides a summary of existing research on using graph-based methods to improve the energy efficiency of cities, and shows how spatially triggered graph transformations (STGT) can be used to create a digital twin graph model of a city. Such a model includes the topography (roads, buildings and other objects), sensor networks and controllable smart devices.

Often, the only link between objects in separate GIS datasets are their shapes and locations: this makes it impossible to directly integrate the data, e.g., by using attribute values. STGT allows the detected spatial relationships between objects to be materialised as relationships (edges) in a graph, so that they can be further analysed and used in the inference process.

The formal background and the digital model model structure are presented, followed by two illustrative examples: using STGT to locally assign traffic intensity sensors to individual lanes; then, extending it to the scale of the entire city, in order to support strategic decisions regarding the expansion of the sensor network. As road lighting is one of the main contributors to energy consumption in cities, reduction of its power usage can provide significant savings. Integration of the traffic intensity data into the street network and lighting infrastructure data allows for introduction of dynamic dimming, which can significantly reduce power consumption while still meeting required road safety standards and maintaining the comfort of road users. As long as the sensor data coverage is sufficient, such modification can be implemented without any infrastructure investments, as most LED lamps are already equipped with remote control systems.

Future work will focus on improving the presented preliminary process, including its automation and expansion. The analysis methodology, presented on the scale of a small town, will be tested in the city of Kraków, on a system consisting of over 20,000 street lights. We are also working on including more GIS datasets in the process, in order to be able to detect areas where the driver’s attention must be higher (as shown in the public utility buildings example), or to analyse light-pollution-related issues.

Work is also being done to expand STGT to analytic methods other than those that are GIS-related: for instance, relationships between sensors may be created based on the similarity of their characteristics, inferred, e.g., using time series comparison algorithms such as dynamic time warping [49].

Another issue is the number of air pollution sensors, which is quite often not sufficient, especially when we want to know the air quality at specific points: playgrounds; schools; malls, etc. The concept of the virtual sensor, the same as in the case of movement sensors, provides a promising prospect. The problem is that we are not able to calculate virtual readings based only on a pollution detector’s location [50]: other factors, such as terrain shape or wind direction and velocity, have to be taken into consideration. Providing such a combined, interdisciplinary infrastructural and environmental model requires further research.