Wiesław Wiśniewicz
Digital Twin Engineer · MLOps & Digital Engineering
Warsaw, Poland
Digital Twin Engineer responsible for building and maintaining digital twin representations of in-service aircraft engines and systems. Integrates real-time telemetry from ACARS and test cell DAQ systems into Azure Digital Twins, enabling real-time fleet health monitoring, predictive maintenance, and what-if simulation. Focuses on scalable twin architectures that can represent individual components through to full fleet hierarchies.
Expertise
- Azure Digital Twins platform
- IoT data integration (MQTT, OPC-UA)
- engine and fleet health digital twin
- real-time telemetry processing
- digital twin ontology modeling
Technologies
Work History
2025-01
Fleet predictive maintenance integration — connected digital twin telemetry to the predictive maintenance AI models (EGT margin trend, vibration anomaly detection). Implemented alert generation and maintenance action recommendation workflow.
Challenge: Alert routing from the digital twin to the maintenance system (AMOS) required integration with a legacy SOAP API that had rate limits and unreliable connectivity. Implemented a Kafka-based asynchronous bridge with retry and dead-letter queue to decouple alert generation from AMOS delivery.
Learned: Legacy MRO system integration (AMOS, CAMP, SAP PM) requires asynchronous decoupling from the digital twin alerting layer. Synchronous API calls to legacy systems create reliability dependencies that can block the entire alerting pipeline — always buffer alerts in a message queue with retry and dead-letter handling.
2024-05
Engine thermal state digital twin — integrated the reduced-order thermal model (from thermal team) into Azure Digital Twins as a property computation model. Twin computes estimated metal temperatures in real time from ACARS operational parameters.
Challenge: The reduced-order thermal model required calibration parameters specific to each engine serial number (accounting for manufacturing variation). Storing and retrieving per-engine calibration parameters in Azure Digital Twins required a twin property schema extension that was not in the original ontology design.
Learned: Digital twin models that incorporate physics models with per-instance calibration parameters need a calibration property namespace in the DTDL schema. Design the ontology to distinguish instance-specific calibration properties from generic model parameters from the start — retrofitting this into an established ontology is disruptive.
2023-11
Real-time ACARS telemetry ingestion pipeline — built a Python service that decodes incoming ACARS messages (ARINC 620 format), maps parameters to the Azure Digital Twins ontology, and streams to InfluxDB for time-series storage.
Challenge: ACARS message deduplication was required — aircraft retransmit the same message if an acknowledgement is not received, resulting in duplicate telemetry records. Implemented a deduplication key based on aircraft tail number + message sequence number + timestamp with a 10-minute window cache in Redis.
Learned: ACARS telemetry pipelines must implement message deduplication from the start. ACARS retransmission is protocol-specified and will always produce duplicates at low signal quality conditions. A sliding window deduplication cache is essential — attempting to detect duplicates in the database after ingestion is much more expensive.
2023-04
Azure Digital Twins ontology design for turbofan engine fleet — modeled engine hierarchy (fleet → aircraft → engine → LRU → component) as DTDL (Digital Twins Definition Language) models with relationship types, property schemas, and telemetry definitions.
Challenge: DTDL relationship cardinality constraints prevented modeling an engine component that is shared between two engine positions (APU cross-start system). Required a workaround using an intermediate 'shared system' twin node with explicit partOf relationships to both engines.
Learned: DTDL relationship modeling for physically shared components requires intermediate node patterns. Azure Digital Twins does not natively support many-to-many component ownership — design intermediate abstract twin types to represent shared system scope before finalizing the ontology.