香京julia种子在线播放

Due to the increasing size and flexibility of wind turbine rotor blades, it is becoming more and more important to measure and monitor their aerodynamic and acoustic behaviour operation (Schepers and Schreck, 2019). This can help wind turbine manufacturers (OEMs) to improve their aerodynamic models and blade designs, owner/operators to optimise operation and researchers to understand complex aerodynamic phenomena. The complexity of the installation and use of such measurement systems means that there have not yet been a large number of publications on the topic, despite the increasing demand. For example, the DanAERO project from 2013–2016 investigated the aerodynamic and acoustic properties of wind turbine blades in wind tunnel and field tests (Madsen et al., 2016; Troldborg et al., 2013). The field tests included instrumenting a 2 MW wind turbine rotor blade with 50 flush-mounted microphones. It was shown that such aero-acoustic field measurements have the potential to provide a high added value to the wind industry through furthered understanding of three-dimensional effects. Furthermore, the international collaboration IEA Wind Task 47 aims to cooperate and share experiences in aerodynamic measurements on Megawatt-scale wind turbines ¹ . A more detailed study of previous literature can be found in the introduction of a recent paper by the current authors (Barber et al., 2022). It can be summarised that there is a large unmet need for easy-to-install and affordable rotor blade aerodynamic monitoring systems in the sector.

Digital twins are a promising technology for creating value from wind turbine monitoring, such as rotor blade aerodynamic monitoring, particularly when a scale-up of a single measurement campaign is desired. A “digital twin” is a top-level conceptualisation based on two fundamental principles: “duality” and “strong similarity” (Grieves, 2022). The digital twin paradigm thus spans such a broad range of applications that two particular implementations may share few - or no - technological solutions between them. Recently, the current authors proposed a digital twin classification system based on a Simple Knowledge Organisation System (SKOS) (W3C, 2009) data model, to act as a starting point for the development of digital twins by allowing comparison or solution re-use between implementations (Marykovskiy et al., 2023a). An excerpt from the classification system is presented in Figure 1, referencing some digital twin types that have previously been described in literature, such as DigitalTwinPrototype and DigitalTwinInstance described by Grieves and Vickers (2017), DigitalModel, DigitalShadow, DigitalTwin described by Kritzinger et al. (2018), and various types categorised by their functionalities as described by Wagg et al. (2020).

When classified based on their functional capabilities (Wagg et al., 2020), digital twins can range from ‘Supervisory’, in which data from measurements is simply ingested and stored, to ‘Operational’, in which analysis of the operational data is undertaken, to ‘Simulation/Prediction’, in which models, simulations, validation, and verification and uncertainty quantification enhance the measurements, to ‘Intelligent/Learning’, which includes Decision Support Systems (DSS), and finally to ‘Autonomous/Management’, in which autonomous asset control is implemented. According to Wagg et al. (2020), the main transformative aspect of a digital twin is to improve the predictive capability of a system by augmenting computational models with data to create a virtual prediction tool that can evolve over time. ‘Intelligent/Learning’ digital twins have recently been shown to allow accelerated and informed decision-making related to physical systems by representing them virtually and including a continuous feedback loop between the virtual representation and a physical system (Arista et al., 2023; D’Amico et al., 2022; Grieves, 2022; Wagg et al., 2020; Zheng et al., 2021).

Recently, publications related to digital twins and DSS in wind energy were reviewed by Marykovskiy et al. (2024) in the broader context of artificial intelligence systems and domain semantics. Most digital twin implementations in wind energy were found to belong to the functional levels ‘Supervisory’ (26 out of 111), ‘Operational’ (22) or ‘Simulation-Prediction’ (60). Only three papers belong to the functional levels ‘Intelligent-Learning’ (2) and ‘Autonomous-Management’ (1). For wind energy Operations and Management (O&M), previous ‘Supervisory’ or ‘Operational’ digital twins included continuous structural monitoring of a wind farm (Hines et al., 2023). ‘Simulation/Prediction’ digital twins included an augmented Kalman filter with a reduced mechanical model to estimate tower wind turbine loads (Branlard et al., 2020), integration of degradation processes in a strategic offshore wind farm O&M simulation model using a Markov process for blade degradation (Welte et al., 2017), and modelling the probabilistic characteristics of mooring line fatigue stresses for the purpose of risk-based inspection (Lone et al., 2022). ‘Intelligent/Learning’ digital twins include a probabilistic framework for updating the structural reliability of offshore wind turbine substructures based on digital twin information (Augustyn et al., 2021).

This distinction based on functional capabilities, however, is not the only possible classification of digital twin implementations. As we can see from Section 1.2, it is also possible to distinguish and group digital twins based on the manner in which the connection between the physical object and its digital representation is achieved or based on the fidelity levels of simulations employed. Here, the specific technological solutions used in composing the system into the one whole will highly depend on the use case and its requirements.

The sheer variety of different types and applications of digital twins has left many wind energy domain specialists struggling to clarify development processes that suit their specific needs: the passage from the conceptual idea of a digital twin to a functional implementation is often unclear. There exist a myriad of technology stacks, modelling and simulation tools, algorithms and system integration requirements, the selection of which is nuanced and made more complex by technical and specialised jargon. This is not helped by the focus of previous literature on the physical models, rather than on the system architecture.

In its core, the digital twin conceptual model does not necessarily imply an introduction or development of new modelling techniques or simulation applications. However, practical solutions to integrate all the digital twin components into a holistic system, with all of its constituents interconnected and valorised, remain obscure. For instance, one possibility to enable system orchestration is through the use of semantic artefacts. The term ‘semantic artefact’ is used to denote conceptualisations with various degree of expressiveness, such as controlled vocabularies, taxonomies, schemas and ontologies (Le Franc et al., 2020). However, in the aforementioned review by Marykovskiy et al. (2024), a lack of adoption of semantic artefacts in the research of digital twin and DSS was found, reflected by the low number of publications that refer to them (35 out of 181). This can be attributed to multitude of factors that plague multi- and interdisciplinary developments such as a natural tendency towards knowledge siloing within organisations and communities (wind energy from information technology professionals, industry from academia, etc.) as well as to the overall digitalisation challenges in the areas of data, culture and coopetition (Clifton et al., 2023). There is therefore a high value for the wind energy community to present developed digital twin instances from system architecture and technology implementation points of view.

The Aerosense system was developed to address the high demand for easy-to-use and cost effective rotor blade aerodynamic monitoring systems combined with a high potential of digital twin applications in this field, as mentioned in the previous two sections. Aerosense is a cost-effective microelectromechanical systems (MEMS)-based aerodynamic and acoustic wireless measurement system that is thin, non-intrusive, easy to install, low power, and self-sustaining, which was previously introduced by the authors of this present paper (Barber et al., 2022). The hardware is composed of sensor nodes installed on the blade and a base station receiving and sending the data to the cloud (Figure 2A). Figure 2B shows a sensor node of the Aerosense measurement system installed on a wind turbine blade.

Previous publications related to this work have focused strongly on the hardware development, showing that the sensors are capable of delivering relevant results continuously in the wind tunnel (Barber et al., 2022; Polonelli et al., 2023a). Additionally, various methods for using the measurements to provide added value to the wind energy industry have been introduced, including Leading Edge Erosion (LEE) detection and classification (Duthé et al., 2021), inferring angle of attack and wind speed (Marykovskiy et al., 2023c), detecting structural damage (Abdallah et al., 2022) and flow-field reconstruction (Duthé et al., 2023). The overall design of the digital twin, including software integration and the cloud data storage design, has not yet been discussed.

In this paper, we present and demonstrate the top-level system design of a digital twin for wind turbine rotor blade aerodynamic monitoring, which was developed as part of the Aerosense project. By providing a practical solution to integrating all the digital twin components into a holistic system, we aim to help wind energy specialists learn how to transform a conceptual idea of a digital twin into a functional implementation for any application. In Section 2 we present the system architecture of the Aerosense digital twin from a conceptual point of view. Then, we discuss the system design in Section 3, with a focus on the cloud data storage solution and the software integration. In Section 4 we present the results of a field test case, including the test set-up, the measurement results, and the demonstration of added value. In Section 5 we discuss its wider application, and in Section 5.3 we present the conclusions.

In order to define the priority use case for the Aerosense project, a design thinking strategy was applied. Design thinking is an iterative methodology for framing problems and co-creating implementable solutions using visual thinking and prototyping (Pearce, 2020). It consists of the phases “Empathise”, “Define”, “Ideate”, “Prototype”, “Test” and “Implement”. For the “Empathise” phase, extensive “user story” interviews were carried out with potential customers from both industry and academia at the beginning of the project, in which several imagined but realistic “user stories” were presented and discussed. The results were used to define and prioritise the most important use cases for the “Define” phase. Through this process, we discovered that the Aerosense system has a high potential to provide OEMs, owner/operators and researchers with added value, including to improve aero-elastic models, detect and classify surface damage, and even detect structural damage. For the remaining phases, we applied a design pattern methodology, as discussed in the next sections.

Analysing a variety of use cases revealed one foundational application. Since wind turbines have grown larger and more flexible in recent years, established 2D assumptions used for aerodynamic tools have become less likely to hold valid (Bangga et al., 2017). Thus, one of the use cases, “improving aerodynamic models”, was seen as most important, underpinning further analysis or damage detection methods. The beneficiaries, value statements and required outputs of this use case are given in Table 1. This information was used as a design basis for the system, and will be revisited in Section 4.

The required outputs from Table 1 can be summarised as functionality requirements for interactive dashboards (required outputs indicated by letter ‘a’) and Colab notebooks, which is a cloud-hosted Jupyter notebooks service (required outputs indicated by letters ‘b’ through ‘e’). For dashboards, these functionalities include visualisation, exploration, and inspection of sensors’ time series data and pressure coefficient distributions through interactive plots. Colab notebooks, on the other hand, allow for more flexible and custom uses, more accommodating of the defined user stories. Here, the main functionality to ensure is access to the sensor data, data processing algorithms, and simulations for further data transformation and analysis. The data processed in Colab notebooks can also be visualised, explored, and inspected through interactive plots.

Comparing the digital twin classifications of Figure 1 to the required outputs from the use case exercise in Table 1, the DigitalTwinType of the Aerosense digital twin was classified as follows:

• PhysicalSystemLifetimeStageType: DigitalTwinInstance

Each of the aforementioned types is accompanied by a specific design pattern (Tekinerdogan and Verdouw, 2020) reflected in the overall digital twin architecture and system hardware implementations as discussed in the following section.

Generally, a digital twin system can be conceptually divided into three main sub-systems: physical system, digital system, and connection system. Sensors, in general, are considered to be a part of the physical system (Singh et al., 2021; Tao et al., 2018) or its interface. However, this conceptual division may not always coincide with the boundaries of the actual physical hardware (a more convenient division) requiring some pragmatism in classifying system components. ² A conceptual diagram of the Aerosense digital twin system and its hardware is shown in Figure 3. It comprises sensor node, base station, and cloud infrastructure sub-systems, which are classified and described below.

Before formally defining a co-design problem, it is necessary to formalise a single design problem with implementation (DPI): DPI = F , R , I , p r o v , r e q where:

• F , R , I are posets, called Functionality, Resources, and Implementation spaces respectively;

A co-design problem, then, is defined as a multigraph of design problems. This allows to treat an overall design of the system in a compositional manner (i.e., divide the system into its components) and to introduce different levels of abstraction.

In the case of the Aerosense digital twin, the constraints on the Functionality and Requirement spaces are presented in Table 2. These are specific quantitative (when possible) and qualitative top-level constraints resulting from the use-story studies, described previously in Section 2.1. The overall system co-design problem can be visually represented using the graphical language as in Figure 4, with an abstraction on the hardware components and digital system levels. In these type of figures, the co-design graph is presented, allowing for an immediate overview of various interdependences in the system. Each labeled node represents an Implementation of a component or an assembly, while the edges can be of either Functionality or Recourse type. To which degree an assembly should be split to sub-assemblies and sub-sub-assemblies is arbitrary, enabling various levels of abstraction. For example, it is possible to consider the senor node(s) as a whole or, as an assembly of sensors, power, housing, compute, and transmission assemblies. In the next three sections, the design of the three main components, senor node(s), base station, and cloud infrastructure and digital system is presented.

The development of the sensor node is the most complex part of the Aerosense system design. From a system point of view, it requires a close collaboration between teams of diverse backgrounds and expertise such as development of integrated circuit boards and relative firmware (Center for Project Based Learning at ETH Zurich), experimental and computational fluid dynamics (Institute for Energy Technology at OST), structural health monitoring and machine learning (Structural Mechanics and Monitoring at ETH Zurich), data engineering (Octue), and additive manufacturing (Institute of Materials Engineering and Plastics Processing at OST). Hence, here we describe the design constraints and implementation characteristics on a system level. A detailed description of the sensor node design from an electronics point of view is available in the relevant preceding publications (Polonelli et al., 2023a).

The functionality and resources graph defined by each team during sensor node design is visualised in Figure 5. In addition to the overall design constraints already defined in Table 2 it illustrates the interdependence between various components within the sensor node design problem. For instance, a change to the desired measurement data characteristics inevitably updates the constraints on compute, power, and transmission systems. This, in turn, may influence the housing design, for example, by requiring it to provide more useable volume for a bigger battery. In terms of actual implementations, which provide the desired functionalities within the bounds of available required resources, the sensor node components have the characteristics described hereinafter.

Measurement data is the key functionality of the sensor node component, as it also constitutes a required resource for the digital system and its services. The types of sensors utilised, measurement characteristics (precision, accuracy, sampling frequency), and measurement session periods are all ultimately driven by necessity to capture the physical system state in sufficient resolution to describe the underlying phenomena. This process is at the core of the digital twin concept in that of the physical system being twinned to its digital representation. The fidelity and the resolution of this digital representation, in the end, should provide the functionalities and the added value desired by the digital twin users. The reader may refer directly to Section 3.4.3, which discusses digital system services, for more information on the intended use of the measurement data.

In terms of the sensor suite, the hardware implementation is the following. An array of 40 MEMS absolute pressure sensors (ST LPS27HHW) are distributed along the chord of the blade, sampling at 100 Hz. Following thorough calibration, an absolute accuracy of 11 Pa is achieved. Given the expected dynamic pressure of 1,000 Pa on a 5 MW wind turbine, (Deparday et al., 2022), it suggests that a precision of 1% can be reached in pressure measurements. Five differential pressure sensors measure differences of pressure around the leading-edge. The sensors have an accuracy of 0.25% Full Scale, +1 Last Significant Bit, at 25°C and a sampling frequency of 1.2 kHz, sufficient to resolve fast dynamics of the turbulent inflow. Ten acoustic sensors (Vesper VM2020) sampling at 16 kHz are installed at the trailing edge. An Inertial Measurement Unit (IMU) is included, comprising an accelerometer, a gyroscope and a magnetometer (Bosch BMX160). The IMU data is sampled at 100 Hz.

On-board compute, sensor controls, and data transmission are provided by a CC2652P microcontroller by Texas Instruments. It embeds a 48 MHz ARM Cortex-M4 processor, and a Bluetooth Low Emission (BLE) wireless interface to capture data from the individual sensors and communicate with the base station. This solution provides a low power consumption for sensor readout, and a long-range transmission with a range up to 400 m at a rate up to 2 Mbps (Fischer et al., 2021). This allows for a flexible base station placement even on a large-scale wind turbines. The implementation of the BLE is a result of the power consumption requirement. However, this implementation results in a significant data throughput limitation. This design problem does not have a data streaming solution with the current technology. Instead, a batch processing approach was adopted, in which sampling periods (i.e., measurement sessions) are intermittent with data transfer periods. The manner in which this conditioned the development of the Aerosense system is further described in Section 3.3 and Section 3.4.

The housing for the sensors, integrated circuits, and power module is implemented with a custom-made PolyJet 3D-printed sleeve, which is flexible enough to bend around airfoil section where the system may be potentially installed. To provide necessary adhesion characteristics, the sleeve is fixed onto the blade with the same type of adhesion tape that is used for leading edge protection of wind turbine blades. This solution also ensures an easy installation by a technician even on mounted blades, and the possibility of the system removal without damaging the blade.

The design of the base station is less complex compared to the other parts of the Aerosense system. The constraints imposed (see Figure 4) are also less restrictive, with multiple possible solutions in terms of hardware and software implementations. Hence, in the case of the Aerosense digital twin, there is no necessity to formalise the design of individual components of the base station as a co-design problem, maintaining a higher abstraction level. The base station hardware comprises a BLE transceiver, a local computing unit running the gateway software (on a Linux distribution), and a mobile network modem which provides a connection to cloud resources. The open-source gateway software ⁵ was implemented as a Command Line Interface (CLI) in python, with a multi-threaded implementation (to stream packets from the node whilst simultaneously caching, batching and uploading their data contents). Software was deployed using balena.io, which allowed automated update across multiple prototypes as well as facilitating remote connection via Secure Shell Protocol (SSH). The gateway uploads data files (containing batches of sensor values) to the Data Ingress area (see Figure 7), and interfaces with the API to retrieve and update installation configurations (containing information related to equipped sensors, geolocation of the site, sensor geometry and so on) (Clark and Lugg, 2022).

The cloud infrastructure provides the necessary resources for the digital system implementation (see Figure 6). From the top level point of view, the required functionalities of the cloud infrastructure include data storage, management and querying for the data system. At the same time, cloud infrastructure provides necessary compute and orchestration capabilities for digital system services. Lastly, for models, there is a requirement of management solutions. In terms of resources required by the cloud infrastructure itself, the main limitation is imposed by the operational costs, as modern cloud solutions are capable of managing Big Data type datasets and providing high performance computing (HPC).

For the Aerosense digital twin, Figure 7 shows a more detailed view of the cloud infrastructure supporting the implementation of the digital system, highlighting the data storage, retrieval and data processing services that comprise the digital twin. This architecture was determined from a bottom-up analysis of the data requirements discussed in Section 3.4.1, and is described in more details in the following sub-sections.

After some initial tests of the robustness of the housings and the power consumption of the Aerosense system (Polonelli et al., 2023a), a field test campaign was carried out with the final Aerosense prototype (Figure 11). As mentioned in Section 2.3.1, the design specifications enable the use of the system on multi-Megawatt scale wind turbines. However, for practical and cost considerations, these initial field tests were performed on a 6 kW Aventa wind turbine. The turbine delivers 10-min averaged SCADA data including the active power, the nacelle wind speed and wind direction, the blade pitch angle and the generator temperature. The sensor node was installed at a radial position of 74% of the blade length (6.7 m from the centre of rotation) on one blade. It is shown attached to the blade in Figure 11A. Several measurement campaigns were carried out between July 2022 and April 2023; however, with several improvements being made to the hardware and firmware. This results in several weeks of useable barometer, differential pressure sensor, microphone, and IMU data during this time, which is available in Marykovskiy et al. (2023b). All the samples are timestamped with UTC time. Wind turbine, sensor location and sensor properties metadata is provided as JSON files. The wind turbine metadata follows the WindIO schema and the pressure sensor locations metadata follows the Aerosense sensor geometry schema. The pressure sensor locations were calculated as described in Section 3.4.2 with a photogrammetry process ¹⁸ , reconstructing the sensor node and the blade shape, as demonstrated in Figure 11B. An accuracy in the order of 1 mm was achieved, enabling accurate positioning of the aforementioned sensors and the use of this information in post-processing or transformation of measurement data.

The field test allowed us to demonstrate the value of the use case introduced in Section 2.1 according to the outputs in Table 1. As described in the aforementioned section, the two main modes to use and analyse the data are the dashboard and the Colab notebooks. Here, we limit the demonstration to these two functionalities of the digital twin, while the detailed analysis of the data itself merits a separate study to thoroughly explore the insights gained from the field tests.

The main focus of the design thinking methodology in this work was on the “Empathise” phase, in which “user stories” were explored in order to then define the foundational use case that was used as a basis for the design of the Aerosense digital twin. It proved as essential tool for providing the required amount of focus to then apply the design patterns methodology, as discussed below. Furthermore, a range of other use cases were defined, which could be used to further develop the present solution.

In the Aerosense project, when approaching the development of the digital twin from a systems architecture perspective, the authors adopted well-established twin types as well as common conceptualisation schemes such as the 5-dimension digital twin model. These conceptual models have provided an initial indication on the overall design patterns, to serve as a blueprint for further development. Currently, “the catalogue” of solution patterns is rather limited and only a few digital twin type definitions are commonly accepted and recognised across engineering domains. A more fine-grained and widely accepted digital twin classification can facilitate more streamlined digital twin development by applying proven methodologies. Additionally, this approach opens avenues for collaborative innovation. By utilising a classification system that is acknowledged across industries, future digital twin projects can increase interoperability and knowledge exchange, thus gaining access to otherwise untapped resources.

Furthermore, the use of a standardised classification schemes aids in documenting and communicating the functionality and scope of digital twins more effectively, both within and across industries. This not only enhances the visibility of research outcomes but also aids in selection and adoption of technical solutions, making them more accessible to domain experts from different sectors, and facilitating cross-domain knowledge transfer. An example of such knowledge transfer is the adoption of digital twin technology innovations in the manufacturing sector by the wind energy domain, where the principles of operational efficiency and predictive maintenance are equally valuable.

During the design of individual system components, the discussion centered around the component assemblies and their physical boundaries, rather than conceptual division into physical, digital and connection systems. This type of compositional thinking finds its fundamental basis in category theory. Co-design formalisation originally proposed by Zardini et al. (2021) in the context of robotics and autonomous systems also lends itself to the digital twin development. The theoretical grounding of this framework serves as means of knowledge representation for functional and resource requirements for a given digital twin, its components or component assemblies. Additionally, this formal basis allows for multiple solution searches and optimisations as a twin evolves to include new uses cases or technology implementations.