chore(deps): update dependency io.github.wldt:wldt-core to v0.6.0

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
io.github.wldt:wldt-core	0.3.0 → 0.6.0

---

Release Notes

wldt/wldt-core-java (io.github.wldt:wldt-core)

v0.6.0

WLDT - 0.6.0

Version 0.6.0 introduces a major architectural refactoring of the WLDT core framework alongside critical bug fixes and functional enhancements. This release focuses on improving semantic clarity, fixing data accessibility issues, and enhancing adapter capabilities.

Core Architecture Refactoring

Comprehensive reorganization of Digital Twin components with clearer naming (DigitalTwinKernel and DigitalTwinModel) that accurately distinguishes orchestration from behavioral logic.

The key architectural changes are:

1. DigitalTwinModel → DigitalTwinKernel: The core orchestrator has been renamed to accurately reflect its role as the fundamental nucleus coordinating all DT components
2. ShadowingFunction → DigitalTwinModel: The behavioral definition component now properly claims the "Model" terminology, representing the actual logic that defines how the Digital Twin behaves

Bug Fixes & Enhancements

This release focuses on stability improvements and expanded extensibility for multi-adapter
configurations. Key highlights include the resolution of known storage query limitations,
the introduction of Physical Adapter lifecycle callbacks, automatic source identification
in multi-adapter setups, and richer metadata support in PhysicalAssetEvent.

In particular we have in the release:

• Storage Query Limitations Resolved: A set of limitations affecting storage queries has been identified and resolved. Queries that previously returned incomplete or inconsistent results under specific conditions now behave
  correctly, ensuring reliable access to persisted Digital Twin state, events, and lifecycle data.
• Physical Adapter Lifecycle Callbacks: Physical Adapters now expose lifecycle callbacks, giving developers explicit hooks into the adapter's initialization, execution, and termination phases. This enables more fine-grained control over adapter behavior and simplifies the implementation of setup and teardown logic directly within the adapter itself.
• Automatic Source Identification for Multi-Adapter Configurations: In scenarios where multiple Physical Adapters are active simultaneously, the framework now automatically identifies and associates the source adapter for each incoming event or update.
  This removes the need for manual tagging at the application level and improves traceability in complex, multi-source Digital Twin architectures.
• Content-Type Support in PhysicalAssetEvent: A new contentType field (String) has been added to the PhysicalAssetEvent class. This field allows Physical Adapters to communicate the content type of the event body (e.g.
  application/json, application/cbor) to the Shadowing Function and downstream consumers. The field can be set directly by the developer and is accessible via standard getter and setter methods.

v0.5.0

WLDT v0.5.0

WLDT v0.5.0 introduces significant enhancements to the Digital Twin framework, emphasizing flexible resource management and a modular logging system. This release enables runtime-configurable resources that can be managed internally by Digital Twin logic and accessed externally via a customizable Management Interface. The new logging layer has been designed to make the library independent from external logging frameworks while allowing developers to fully customize how logs are generated and which logging libraries to use.

Resource Management

New classes introduce a unified, runtime-configurable resource model for Digital Twins (DTs). Resources can be managed internally by DT logic and accessed or updated externally through an abstract Management Interface. The system supports CRUD operations, observers for change notifications, and flexible integration with protocols like REST, MQTT, or gRPC. Key classes include ManagedResource, ResourceManager, ResourceRequest, ResourceResponse, and ManagementInterface. Resources can be dynamically configured at startup or during runtime, enabling adaptable DT behavior and external interaction.

Logging

WLDT now provides a modular logging layer designed for flexibility and easy integration. Developers can use the default console-based logger or implement custom loggers through the WldtLogger, WldtLoggerFactory, and WldtLoggerProvider interfaces. This layer supports multiple log levels, timestamped output, and can be seamlessly replaced or extended to integrate with frameworks like SLF4J, Log4j, or Logback without changing core DT code.

v0.4.0

New Features

WldtEventObserver

A new class called WldtEventObserver has been introduced to allow a simplified observation of target specific events generated by the Digital Twin and its components such as adapters and the model. Main mapped events and filters are:

• State Events: State Update and State Event Notifications
• Physical Asset Events: Physical Property Variation, Physical Event Notification, Physical Relationship Instance Creation and Deletion
• Physical Asset Action Events: Physical Action Trigger
• Digital Action Events: Digital Action Event
• Physical Asset Description Events: Physical Asset Description Available and Updated
• Life Cycle Events: Digital Twin Life Cycle Events
• Query Request Events: Storage Query Request Events (See next sections for additional information)

For each event type dedicated observation and un-observation methods (e.g., observePhysicalAssetEvents() and unObservePhysicalAssetEvents()) are available in order to create an instance of the observer and decide which events to receive.

To build a WldtEventObserver a dedicated listener IWldtEventObserverListener should be implemented by the developer to receive the callbacks related to the incoming events. All the events are of the generic type WldtEvent and it is up to the developer the validate and check the received object and if it match with the expected one.

The WldtEventObserver has been currently used internally within the library to simplify the implementation and usage of the Storage Layer and the associated Storage Query System as described in the dedicated sections.

Storage Layer

A new storage layer has been integrated into the core WLDT library, enabling Digital Twins (DTs) to store data related to the evolution of their state, generated events, and any variations involving properties, events, actions, relationships, and life cycle. The Storage Layer consists of two main components:

• Storage Manager: This is the central component of the storage system, facilitating the structured and modular storage and retrieval of information. It allows developers to create and utilize various storage systems (e.g., in-memory, file-based, or DBMS) simultaneously. The Storage Layer is accessible in both read and write modes internally by the DT's Model, and in read-only mode via the Query System by Digital Adapters.
• Query System: To delegate and encapsulate the responsibility of data storage within the DT's model, a query system has been integrated. This system enables Digital Adapters to retrieve stored data and expose it according to their specific logic and implementation.

The storage layer is designed for easy extension, allowing developers to create and share new storage layers (e.g., using Redis, MySQL, or MongoDB). The provided in-memory implementation serves only for basic development and testing purposes. Similarly, the Query Manager can be extended and customized by developers to implement additional query management features or to enhance the default functionalities provided by the library.

Migration Info: 0.3.0 - 0.4.0

• Now PhysicalAssetRelationship constructor has also the type in order to match the DigitalTwinStateRelationship and simplify its management
• The method notifyDigitalTwinStateEvent throws only the Exception WldtDigitalTwinStateEventNotificationException while EventBusException has been removed

Additional Improvements & Fixed Bugs

• Synchronized the update of the current DT Life Cycle State in order to avoid wrong data
• The WldtEventBus now supports the use of topics Wildcard (at the moment only multi-level with the character *). For example with this approach is possible to subscribe to all the events associated to property variations (topic: dt.physical.event.property.*). New methods added to WldtEventBus are:
  • matchWildCardType(String eventType, String filterType): Check if the provided event type match the WildCard Type
  • isWildCardType(String filterEventType): Check if the provided event type is a WildCard Type
• The class WldtEventTypes has been introduced to contain all the event types in the WLDT Framework and support internal message exchange. Includes types for events associated and adopted by: i) Physical Adapters; ii) Model and Shadowing Function; and iii) Digital Adapters.
• The EventManager class has been added to centralize and simplify the event management in the WLDT Framework providing a set of static methods to publish events associated to a target digital twin and publisher (e.g., the physical adapter of the twin).
• Now PhysicalAssetRelationship class has also the type in order to match the DigitalTwinStateRelationship and simplify its management
• The internal class ModelEngine has been renamed into DigitalTwinModel as an initial update for further development of the next version 0.5.0 where the structure of the DT's Model and the associated classes will be improved

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud