Expanding Moeve’s Energy Parks with a bring-your-own-map tracking solution

Background

Moeve, with nearly 100 years of experience, has established itself as one of the leading energy companies globally. For much of its history, the company has been a leader in the oil and gas sector, but today it is undergoing a transformation toward clean and sustainable energy, which is essential for combating climate change and reducing carbon emissions. Its sustainability strategy, called “Positive Motion,” not only promotes the production of green molecules, but also directly contributes to the decarbonization of hard-to-electrify sectors, such as air transport, while creating quality jobs and supporting sustainable development in key regions.

One of the major milestones of this strategy is the construction of its new second-generation biofuels (HVO) plant, a strategic project for both Spain and Europe. Alongside this, Moeve has begun developing green hydrogen projects, a key resource for the global energy transition. Both initiatives position Moeve as a leader in renewable energies and facilitate the transformation of its Energy Parks into clean and sustainable energy production centers, all aligned with the European Green Deal’s targets to achieve climate neutrality by 2050, a fundamental pillar in achieving these goals is digitalization.

In this context, the company has decided to implement Track & Trace, starting with the development of a pilot at its La Rábida Energy Park (EPLR). The approach taken is “think big, start small, and scale fast”, focusing on scalable solutions that can be rapidly expanded across the project instances at any of its sites. Moeve selected Amazon Web Services (AWS) for this, given the unmatched portfolio of cloud services of AWS and alignment with Moeve’s approach.

Digitalization acts as an accelerator of Moeve’s energy transition, allowing the company to implement innovative technologies that optimize both processes and operations, while reducing emissions more quickly and effectively. Moeve has adopted a digital approach that is transforming its operations to improve energy efficiency, safety, and sustainability. Through digitalization, the company has successfully integrated advanced solutions such as Internet of Things (IoT) technologies, artificial intelligence, and data analytics, enabling more efficient management of its Energy Parks. These tools not only optimize clean energy production but also allow for dynamic, real-time control of operations, maximizing safety and operational efficiency. It’s not just about modernizing infrastructure, but about leveraging digitalization as a key tool to achieve Moeve’s sustainability goals and lead the way toward a cleaner, more responsible energy future.

Track & Trace enables real-time tracking of assets, the creation of circulation plans and evacuation routes (with a differentiation between paths for pedestrians and vehicles), and the establishment of dynamic geofences that issue alerts to prevent unauthorized access to hazardous or restricted areas. Furthermore, the solution maintains a positioning history that facilitates post-analysis and resource optimization.

The solution is the result of a collaboration with key partners on AWS: Keepler as the system integrator, Tektelic as the device provider using Semtech LoRa® chipsets, and Everynet as the LoRaWAN® network provider.

Figure 1. Pictures from the Energy Park in La Rábida (Huelva, Spain).

Link to geographic location.

Challenges and benefits of the solution

With its continuous improvement and excellence-driven spirit, Moeve faces the challenge and is fully committed to maximizing efficiency and safety in the development and execution of all its projects.

Digitalization has become a key pillar for Moeve, driving the achievement of optimization goals while making sure that safety remains a top priority. As of this writing, Track & Trace is in its trial phase at the La Rábida Energy Park, with the aspiration of becoming a fundamental tool across the Moeve construction projects, thereby making sure of more efficient and safer project instance.

Among its key functionalities, Track & Trace offers real-time asset tracking, the creation of circulation plans and evacuation routes, the differentiation between paths for pedestrians and vehicles, and the issuance of automatic notifications for any unauthorized access attempts. Additionally, the solution maintains a positioning history that facilitates post-analysis and resource optimization.

From a technical standpoint, Track & Trace addresses several challenges:

Advanced maps: One of the main challenges relates to the capabilities and functionalities of the maps for daily operations. Moeve is building new roads as part of its expansion, and these new roads do not yet exist in available location platforms. To overcome this, the solution supports the import of private maps (“bring-your-own-map”) to enable real-time tracking and path calculation on these custom maps. For these critical tasks, Moeve has used Amazon Location Service to make sure of accuracy and reliability.
Network coverage: The new area of expansion needs to be equipped with Internet of Things (IoT) connectivity in a fast and cost-effective method. For the La Rábida project, Moeve is using Everynet’s public LoRaWAN® coverage. The LoRaWAN® standard, recognized by the ITU-T for secure, carrier-grade IoT LPWAN connectivity, is a perfect fit for these applications thanks to the long range and low power performance it provides. The network coverage has been expanded into the Energy Park with the deployment of two new gateways. Everynet’s network is already integrated with AWS IoT Core for LoRaWAN through a roaming agreement in Spain, as described in this AWS developer guide.
Device cost and battery life: Another significant challenge relates to the total cost of ownership (TCO) of devices and the battery life. Regularly recharging large numbers of devices can be cumbersome. To address this, Moeve has used Semtech’s LoRa Edge™ technology, combined with AWS IoT Core Device Location’s solvers, to streamline devices. This approach allows the devices to send raw scanned data to the cloud, where the actual location is resolved, rather than computing the position locally. This results in more cost-effective devices and extends battery life by approximately 40%.

The system also allows data to be exported in various formats, ranging from printable reports to app-based access, thus improving real-time management and communication between different teams.

The key benefits of the solution are:

Operational efficiency: Optimizes on-site circulation, reducing downtime and improving resource usage.
Enhanced safety: Dynamic geofences and automatic alerts minimize risks and make sure of a secure environment.
Data-driven decisions: The positioning history provides detailed analysis for optimizing resources and timelines.
Automation: Digitalized processes save time, reduce errors, and eliminate manual tasks.
Effective communication: Real-time access to information improves coordination and transparency between teams.

Figure 2. Pictures from the Energy Park in La Rábida (Huelva, Spain).

Solution description

The following figure shows the solution architecture deployed. It benefits from the operational savings of a fully serverless architecture on AWS cloud.

Figure 3. Solution architecture

In the next sections we go through the building blocks of the solution.

AWS IoT Core and devices
For the connection of the tracker devices to AWS we’re using AWS IoT Core for LoRaWAN, a fully managed LoRaWAN Network Server (LNS) to connect the LoRaWAN-enabled wireless devices provided by Tektelic, as shown in the following figure.

Figure 4. Solution for IoT management on AWS

AWS IoT Core for LoRaWAN supports Everynet’s network coverage in Spain (among other countries), so there is no need to use private LNS. Therefore, Moeve can reduce the maintenance, operational costs, and setup time, as well as avoid upfront costs. Everynet’s coverage map can be found here.

We have enhanced the coverage inside the Energy Park with the deployment of a local gateway. Specifications of the local gateway are available here.

The following picture shows the local gateway as deployed in the field.

Figure 5. LoRaWAN IoT Gateway deployed in the field

The Spreading Factor (SF) is a parameter that controls data transmission speed and chirp rate. It also influences range, congestion, time-on-air, battery life, and receiver sensitivity. LoRa modulation has a total of six spreading factors from SF7 to SF12, with SF7 providing the highest bit rate. The point of maximum distance measured was at 2.26Km from the gateway, which is a good enough value. It is showed in a red square in the following table:

Table 1. Measures taken in the field

We have deployed two models of devices provided by TEKTELIC Communications, a premier supplier of best-in-class LoRaWAN and other IoT sensors, gateways, and custom end-to-end solutions.

Figure 6. A Tektelic Seal device

Those models are Seal and Stork.

Seal devices receive the GPS signals, calculate their position, and send it to AWS IoT Core. They come with a Semtech modem for LoRaWAN communication. Geolocation messages are encoded in big endian format and base64 so a “Lambda decoder”, as shown in Figure 4, does the decoding and sends the coordinates (longitude and latitude) to Amazon Location.

fn: function(arg) {
  if (!decoded_data.hasOwnProperty('coordinates')) {
        decoded_data['coordinates'] = {};
     }
   decoded_data['coordinates']['latitude'] = (decode_field(arg, 8, 63, 40, "signed") * 0.00001072883606).toFixed(7);
   decoded_data['coordinates']['longitude'] = (decode_field(arg, 8, 39, 16, "signed") * 0.00002145767212).toFixed(7);
   decoded_data['coordinates']['altitude'] = (decode_field(arg, 8, 15, 0, "unsigned") * 0.144958496 + -500).toFixed(2);
    return 8;
                    }

The configuration of Seal devices is explained in the product manual, and shown in the following figure.

Table 2. Configuration of a Seal device

Stork devices are built on the Semtech LR1110 chip. The LR1110 does a low-power scanning of GNSS (GPS and BeiDou constellations) and sends the scanned raw data to AWS IoT Core Device Location for position computation in the cloud. This corresponds to the upper branch of Figure 4.

The configuration of Stork devices is explained in the product manual, and shown in the following figure.

The position reporting period is configurable. Different values can be established for devices in movement and still.

GPS position data is sent on port 192 as shown in the following table.

Table 3. Configuration of a Stork device

The main configuration parameters for AWS IoT Core LoRaWAN are:

Service profiles: They describe the communication parameters the device needs to communicate with the application server. We have specified that we want to use Everynet’s public network.

Device profiles: They define the device capabilities and boot parameters that the network server uses to set the LoRaWAN radio access service. We have configured the same for all of the devices, with an operation frequency in Europe of EU868, class A device, and same MAC version.

Destination: AWS IoT Core for LoRaWAN destinations describe the AWS IoT rule that processes a device’s data for use by AWS services. There is no need to specify a topic in the SQL query. The following rules have been defined:

- Rule 1, for Seal devices. It comes with two actions:
  - - Action 1: Send raw data to an Amazon S3 bucket for backup and troubleshooting purposes.
    - Action 2: Send data to AWS Lambda for message decoding, storage in Amazon S3 (after decoding), and forwarding of the position to Amazon Location.

- Rule 2, for Stork devices. It comes with one rule so raw data is sent to an S3 bucket.
- Rule 3, for Stork position.

The Stork devices deployed are compatible with AWS IoT Core Location. To set them up, we have activated the Geolocation option and we have established the AWS IoT Core rule “tps-track-and-trace-iot-destination-stork-location-poc” as the destination of the positioning data.

Figure 7. AWS IoT Core destination

Then, the AWS IoT Core rule comes with two actions.

Action1: Send data to a tracker in Amazon Location.
Action 2: Send decoded data to an S3 bucket.

Devices: Every device has been onboarded following the indications in this AWS developer guide.

Web application

The web application allows authorized users to visualize devices on the maps, create and visualize geofences, create and visualize paths, calculate routes over the paths, and manage the devices. Those capabilities are available with a graphical user interface. The front end is hosted in an S3 bucket, whereas the backend consists of a Python API Flask deployed on Amazon Elastic Container Service (Amazon ECS), which calls Amazon Location and Amazon DynamoDB. The Python API on Amazon ECS is connected with an API Gateway that is configured as the Origin of the Amazon CloudFront distribution. This is shown in the following figure.

User authentication is done with Amazon Cognito.

Figure 8. Web application on AWS

The following screenshots from the web applications correspond to the most relevant features. The following figure shows the private map from the expanded Energy Park integrated with the satellite imagery public map provided by HERE Technologies. The three red icons represent a vehicle, a piece of heavy machinery, and a pedestrian worker respectively. The green circle around the heavy machinery icon is a geofence, which is dynamically updated when the heavy machinery changes its position.

Figure 9. Imported private map integrated with satellite imagery public map

The web application allows users to draw new roads and save them so that they become available for routing. Figure 10 on the left shows in red a new road being created by the user, and Figure 11 on the right shows how it has been incorporated into the network of roads


Figure 10. Creation of a new road on the map	Figure 11. The new road is now part of the available paths

The small gaps that would typically appear with the manual drawing are automatically removed with the algorithm developed so that the new segments are properly connected.

# Intersection logic
def process_line_intersections(gdf, factor_lane_union):
    # Extend all lines by adding an additional segment of length 'factor_lane_union'
    gdf['geometry'] = gdf['geometry'].apply(
        lambda geom: _extend_line(geom, factor_lane_union) if isinstance(geom, LineString) else geom
    )

    # Calculate the intersections between the lines
    intersections = _find_intersections(gdf['geometry'].tolist())

    # Trim lines if the intersection point lies in the extended segment
    trimmed_lines = _trim_lines(gdf['geometry'].tolist(), intersections)

    # Remove lines if the extension did not result in intersections
    cleaned_lines = _remove_added_ends(trimmed_lines)

    # Ensure the graph is fully connected by adding intersection points to relevant lines
    connected_lines = _add_intersection_points_to_lines(cleaned_lines, intersections)

    # Remove duplicate vertices within the lines
    final_lines = _remove_duplicate_vertices(connected_lines)

    return final_lines

Path calculation or routing over the new roads is supported. In the following sequence a user selects the origin and destination for routing, which are displayed as green dark circles in Figure 12. The tool indicates the shortest path in dark green (Figure 13). In case a geofence is covering a road, the calculated path avoids that road as shown in Figure 14.


Figure 12. Origin and destination for path calculation	Figure 13. Calculated route – short path	Figure 14. New calculated route avoiding a geofence

def get_route():
    calculator_name = request.args.get('calculator_name')
    front_geofence_collection = request.args.get('front_geofence_collection')
    outer_geofence_collection = request.args.get('outer_geofence_collection')

    # Extract origin and destination points
    origin = _get_point_from_args('origin')
    destination = _get_point_from_args('destination')

    # Load geofence-data from S3
    geo_json = _load_geojson_from_s3(BUCKET_NAME, FILE_KEY)

    # Convert geo-json to GeoDataFrame and set the CRS
    gdf = _convert_geojson_to_gdf(geo_json)

    # Calculate UTM CRS based on the centroid of the area
    utm = _calculate_utm_crs(gdf)

    # Create nodes and edges for graph
    nodes, edges = _generate_graph_components(gdf, utm)

    # Get exclusion areas (geofences) and project them
    exclusion_areas = _get_exclusion_areas(
        front_geofence_collection, outer_geofence_collection, utm
    )

    # Filter nodes based on exclusion areas
    active_nodes, active_edges = _filter_excluded_areas(nodes, edges, exclusion_areas, utm)

    # Extend graph components to include origin and destination
    active_nodes, active_edges = _extend_graph_with_origin_destination(
        origin, destination, active_nodes, active_edges, utm
    )

    # Generate the graph and compute the shortest route
    route_geojson = _generate_route(active_nodes, active_edges, origin, destination)

    # Parse and return the response
    return parse_response(json.loads(route_geojson), 200)

Advanced geofencing is a key feature when expanding an Energy Park. From the web application it is possible to define different types of geofences: free-form polygonal geofences as shown in Figure 15, and dynamic circular geofences around heavy machinery as shown in Figure 16.


Figure 15. Manual drawing of a polygonal geofence from the web application	Figure 16. Dynamic geofence around a heavy machinery

The web application includes a dashboard to assign tracking devices to vehicles, workers, and heavy machinery, as shown in the following figure. Every tracking device reports their position to an Amazon Location tracker. This information is stored in a DynamoDB table.

Figure 17. Mapping between devices and assets for reassignment

Location capabilities
Amazon Location is at the core of the solution and provides key features that the front-end exposes:

Figure 18. Amazon Location key features used

Bring-your-own-map

The solution developed allows Moeve to import their private maps. This makes the tracking of devices and path calculation possible over the imported private maps.

This project includes a conversion tool that converts AutoCAD KML output to GeoJSON suitable for display on a web map (such as streamlining and shrinking the output while preserving style attributes).

Transforming complex AutoCAD drawings originally intended for other purposes into map-ready overlays involves a series of data conversions and clean-ups. We begin by exporting geo-referenced AutoCAD designs as KML (because that's what it supports out of the box), which includes some styling information and elevation data. Then, the KML is converted to GeoJSON (which is more suitable for use with open-source mapping libraries), thus preserving the style attributes as properties. To make the resulting large file (10s of MB) usable, we use a custom Python script using the Shapely library to clean up the data by streamlining and merging geometries and dropping elevation values, significantly reducing file size (to under 1 MB) while retaining the details we care about. When we have a suitably small GeoJSON file, we load it into a map using MapLibre, where custom styling expressions recreate some of the visual characteristics of the original AutoCAD drawing. This process enables the incorporation of complex architectural plans into interactive mapping environments.

The tool is available through this GitHub.

Tracking

Amazon Location trackers store position updates for a collection of devices. A tracker can be used to query the devices' current location or location history. For the project we have defined three trackers, as shown in the following figure:

●tps-track-and-trace-tracker-test-person-poc: For pedestrian workers.

● tps-track-and-trace-tracker-test-static-poc: For static and semi-static equipment such as heavy machinery.

● tps-track-and-trace-tracker-test-truck-poc: For trucks and other vehicles.

Figure 19. Trackers in Amazon Location

A device sends its position updates to a unique tracker. A device can be reassigned to a different user type. For example, from a vehicle to a pedestrian.

Advanced geofencing

We have defined three collections of geofences with Amazon Location, as shown in the following figure.

Collection1: tps-track-and-trace-geofence-collection-frontend. Manually created from the front end. Polygonal free forms are supported.
Collection2: tps-track-and-trace-geofence-inner-static. Auxiliar inner circular geofence around a heavy machinery. It is used to trigger the update of the outer geofence when the heavy machinery exits the inner geofence.
Collection3: tps-track-and-trace-geofence-outer-static.

Circular geofence around the heavy machinery. They are used for two use cases: 1, to alert pedestrians and vehicles when getting close, and 2, as inputs to the routing algorithm so that evacuation paths avoid geofences.

Figure 20. Geofences in Amazon Location

The following sequence shows a heavy machinery represented with a red circle, an inner geofence in green, and an outer geofence in grey. The outer geofence is the relevant one for alerting workers and the one to be avoided for route calculation. The inner geofence has been created as an auxiliary one to determine when the outer geofence should be updated. This approach avoids unnecessary updates to the outer geofence caused by insignificant or minor changes in the position of the heavy machinery. Rather than continuously polling for position updates, we follow an event-driven pattern where the event that triggers an update to the outer geofence is the heavy machinery exiting the inner geofence. The radius of both inner and outer geofences remains unchanged, and only the positions of their centers are updated. The following figure illustrates the process. In sequence 2, the heavy machinery moves within the inner geofence. The outer geofence remains unchanged. Then, in sequence 3, the heavy machinery crosses the inner geofence, which triggers an update for both geofences (inner in green and outer in grey), as shown in sequence 4.

Figure 21. Sequence for the dynamic geofencing.

Figure 22. Dynamic geofencing on AWS

1) Heavy machinery updates its position – the ingestion comes from AWS IoT Core.
2) The Amazon Location Tracker receives the position updates of the heavy machinery.
3) The new position is evaluated against the inner geofence associated with the heavy machinery.
4) In case the geofence is crossed (exited) an event is sent to Amazon EventBridge.
5) The event triggers the running of a Lambda to calculate the new geofence.
6,7) The new geofence calculated is ingested into Amazon Location both for visualization and for monitoring of new events.

The following is a code snippet of the “Geofence Computing” Lambda:

if innerGeofenceId == geofenceId and eventType == "EXIT":
logger.info(f"Event from the inner geofence: {eventType}")
# URLs for GET and POST requests
get_urls = {
'inner': f"{apidns}geofences/{innerGeofenceId}?geofence_collection={geofenceInnerCollection}",
'outer': f"{apidns}geofences/{outerGeofenceId}?geofence_collection={geofenceOuterCollection}"
}
post_urls = {
'inner': f"{apidns}geofences?geofence_collection={geofenceInnerCollection}",
'outer': f"{apidns}geofences?geofence_collection={geofenceOuterCollection}"
}
logger.info(f"Fetching geofence data from {apidns}")
responses = {key: requests.get(url).json() for key, url in get_urls.items()}
# Prepare data for updating geofences
def prepare_data(response):
return {
"geofence_id": response["data"]["geofence_id"],
"geofence_type": "circle",
"center": center,
"radius": response["data"]["coordinates"]["Radius"]
}
inner_data, outer_data = prepare_data(responses['inner']), prepare_data(responses['outer'])
# Post updated geofences
update_inner = requests.post(post_urls['inner'], json=inner_data)
update_outer = requests.post(post_urls['outer'], json=outer_data)
logger.info(f"Inner update status: {update_inner.status_code}, Outer update status: {update_outer.status_code}")
# Check if updates succeeded
if update_inner.status_code == 200 and update_outer.status_code == 200:
moved_center = [center[0] + 0.000001, center[1] + 0.000001] # Slight move to bypass filters
updates = [{"DeviceId": deviceId, "Position": moved_center, "SampleTime": datetime.now()}]
updated = location.batch_update_device_position(TrackerName=tracker, Updates=updates)
logger.info(f"Device location updated: {updated}")
else:
logger.error("Error updating geofences")

Path calculation:

As indicated before, the new roads being built for the expansion of the Energy Park aren’t available yet from the map providers that Amazon Location uses. The solution developed allows Moeve to calculate paths for evacuation over private imported maps. The project includes a routing engine that operates over a limited area while supporting dynamic exclusion areas, either provided as input or as Amazon Location geofences.

The route engine is provided as a CDK app and is available through this GitHub.

Conclusions

Moeve, one of the leading energy companies globally, needed a fully functional, scalable, and cost-effective track and trace solution for the construction of their new second-generation biofuels (HVO) plant, a strategic project for both Spain and Europe. Using their partnership with AWS and Keepler, Moeve deployed a serverless solution on AWS with services such as AWS IoT Core for LoRaWAN with support for Everynet’s network and Amazon Location Service to provide real-time visibility, dynamic geofencing, and routing capabilities – with the ability to import and use Moeve's private maps. The solution was developed and deployed in only six weeks, enabling Moeve to efficiently and safely manage the construction of their strategic energy plant.

Call to action

This is a game changer for many different industries with private facilities. You can now address advanced geolocation use cases in record time using a comprehensive ecosystem solution on AWS.

AWS for Industries