Work Packages

The SPEAR project was structured around seven tightly integrated work packages. Each one addressed a distinct layer of the overall optimisation stack, from initial configuration through to the real-time connection between simulation outputs and physical production equipment. Together, they formed a pipeline that could ingest raw machine data, build behavioural energy models, simulate entire production lines, and deliver actionable optimisation recommendations.

The first work package focused on making the SPEAR platform accessible to production engineers who may not have deep expertise in simulation modelling. The team developed guided workflows and configuration tools that helped users specify their production environment, identify key energy consumers, and set optimisation objectives. This included defining system boundaries, selecting relevant components for modelling, and establishing baseline energy profiles against which improvements could be measured.

A central outcome of this work package was the requirement specification for the entire platform architecture. By engaging end users early, the consortium ensured that technical complexity remained hidden behind intuitive interfaces, lowering the barrier to adoption across different industrial sectors.

Work Package 2 tackled the development, distribution, and scaling of energy behavioural models. Rather than using simplified lookup tables or statistical approximations, the consortium created detailed component-level models that captured the actual energy behaviour of individual machines, drives, heaters, and other production elements. These models were packaged as Functional Mock-up Units (FMUs) conforming to the Functional Mock-up Interface (FMI) standard, making them portable across different simulation environments.

A key challenge was scaling these models from individual components to full production lines. The team developed aggregation techniques that maintained sufficient accuracy while keeping computational costs manageable, especially when dozens or even hundreds of components needed to run in parallel. Partners contributed models from automotive welding stations, forging presses, and conveyor systems, creating a diverse library of reusable energy components.

The third work package concentrated on building an efficient energy simulation environment that could run in real time on cost-effective hardware. The goal was to create a digital shadow of the production system, a continuously updating representation that mirrored real energy flows as they occurred on the shop floor.

To achieve this, the team developed embedded hardware-in-the-loop (HIL) simulation capabilities that ran in parallel with the physical plant. Signals from the real Programmable Logic Controllers (PLCs) fed into the simulation, keeping the digital shadow synchronised with actual operations. This approach allowed the simulation to serve both as a monitoring tool and as a testbed for evaluating "what if" scenarios without disrupting live production. Distribution of simulation workloads across multiple nodes was handled via ROS (Robot Operating System), enabling scalable deployment.

Work Package 4 was responsible for the core intelligence of the platform: an extensible library of optimisation algorithms. These algorithms analysed the energy forecast data produced by the simulation environment and identified concrete opportunities for reducing consumption and costs.

The library included methods for load shifting (moving energy-intensive processes to time windows with cheaper or greener electricity), peak reduction (smoothing demand spikes that attract premium tariffs), and process parameter tuning (adjusting speeds, temperatures, or sequences to minimise energy waste). Because different industrial settings have different constraints, the library was designed to be modular. New optimisation methods could be added independently without modifying the rest of the platform. One of the project's post-completion outcomes was releasing core optimisation algorithms as open-source software.

The fifth work package brought together the outputs of all other packages into a cohesive, web-based optimisation platform. The team designed and implemented the user interfaces, backend services, and integration APIs that made the SPEAR system accessible as both a cloud-hosted service and a locally deployable tool.

Following a user-centred design approach with personas derived from the target user groups, the platform offered dashboards for monitoring energy consumption, tools for running simulation scenarios, and reporting features that translated optimisation results into business-relevant metrics such as cost savings and CO2 reduction estimates. The work also covered deployment infrastructure, ensuring the platform could be installed and maintained in typical industrial IT environments.

Work Package 6 addressed the challenge of connecting the SPEAR platform to actual production equipment. Industrial environments are notoriously heterogeneous, with different machines, controllers, and communication protocols coexisting on the same shop floor. The team developed data acquisition connectors that could interface with common industrial protocols and extract the signals needed to feed the energy models and keep the digital shadow up to date.

This work included signal preprocessing, data quality assurance, and buffering strategies for handling intermittent connectivity. The connectors were designed to operate with minimal impact on existing control systems, avoiding any risk of interfering with production operations while still capturing the granular data needed for accurate simulation.

The final work package served as the bridge between the simulation world and the physical production world. While Work Package 6 brought data from real machines into the platform, Work Package 7 focused on closing the loop by translating simulation results and optimisation recommendations back into actionable control parameters.

This connector layer ensured that the insights generated by the optimisation algorithms could be validated against the actual behaviour of the production system before being implemented. By comparing predicted outcomes with real measurements, the system continuously refined its models and improved the reliability of future recommendations. This feedback loop was essential for building trust in the platform's suggestions and enabling progressive automation of energy management decisions.