A device and system for generating a digital twin of a physical asset and autonomous regulatory compliance

Abstract

Described herein is a device (100) for generating a digital twin of a physical asset (200). The device (100) comprises an input interface (102) configured to receive operational signals from sensors associated with a connected physical asset (200). A standards module (107) is configured to store machine readable constraints derived from regulatory data about the physical asset (200). The regulatory data comprises at least one regulatory or operational standard applicable to the physical asset (200). A processor (112) is configured to generate or update a digital twin model of the physical asset (200) that mimics the behaviour and / or characteristics of the physical asset (200) and complies with relevant regulatory requirements of the physical asset (200). The processor (112) is also configured to compute control actions by applying the machine readable constraints to the digital twin model. An actuation interface (104) is configured to transmit the control actions to an input (204) of the physical asset (200). Execution of the control actions constrains at least one operating parameter of the physical asset (200) to remain within a tolerance band specified by the machine-readable constraints.

Description

A DEVICE AND SYSTEM FOR GENERATING A DIGITAL TWIN OF A PHYSICAL ASSET AND AUTONOMOUS REGULATORY COMPLIANCEFIELD OF THE INVENTION

[0001] The present application relates to digital twins and in particular to a device and system for generating a digital twin device of a physical instrument.

[0002] Embodiments of the present invention are particularly adapted for automatically generating a digital twin of a physical instrument for creating a corresponding digital device which mimics the operation of the physical instrument. However, it will be appreciated that the invention is applicable in broader contexts and other applications.BACKGROUND

[0003] Industries such as healthcare, manufacturing, mining, logistics, and space exploration rely on a wide variety of physical assets, equipment, and goods that must maintain regulatory compliance, traceability, and operational reliability throughout their lifecycle. Ensuring compliance and standardisation is critical not only for safety and quality but also for enabling efficient cross-border trade, resource management, and scientific research.

[0004] Another critical challenge is the limited accessibility to medical and laboratory devices, particularly in underserved or remote regions (e.g. orbiting in space), which impedes early diagnostics. This limited access hinders the early detection of diseases, which is critical for timely intervention and treatment. As a result, preventable conditions may escalate, reducing the chances of survival for affected individuals. The disparity in access to diagnostic tools not only exacerbates health inequalities but also places an undue burden on healthcare systems by increasing the prevalence of advanced-stage diseases that are costlier and more complex to treat.

[0005] Traditional compliance monitoring methods, such as on-site audits and manual documentation, are time-consuming, costly, and often lack transparency. These challenges are exacerbated in distributed, remote, or harsh environments (e.g., underground mining, microgravity, border logistics), where access to equipment and real-time data is limited.

[0006] While digital platforms, loT-enabled sensors, and Al-driven analytics have improved data collection and compliance tracking, they often fall short in providing continuous,autonomous, and context-aware compliance enforcement, orchestration, and lifecycle management across diverse assets and environments.

[0007] Digital twins are real-time virtual counterpart systems that mimic the operational behaviour, performance, and context of physical assets or processes. Examples of assets include devices such as diagnostic tools, laboratory instruments and environmental monitors. Assets also include equipment such as industrial machinery and testing platforms.

[0008] Digital twins use live data and cryptographically secure digital identities to monitor operations, adapt dynamically, and make context-aware, intelligent decisions independently. They are rapidly emerging as transformative tools for modernising operations, enhancing visibility, and improving coordination across Australia’s most critical sectors, including healthcare, laboratory research, industrial manufacturing, and national security.

[0009] Despite their potential, no national or international technical specification currently exists to guide the development, deployment, validation, or auditing of smart digital twin systems. This gap leaves organisations exposed to operational, compliance, and safety risks, while also slowing innovation and weakening Australia’s competitiveness in a rapidly evolving global market.

[0010] Any discussion of the background art throughout the specification should in no way be considered as an admission that such art is widely known or forms part of common general knowledge in the field.SUMMARY OF THE INVENTION

[0011] In accordance with a first aspect of the present invention, there is provided a device for generating a digital twin of a physical asset, the device comprising:an input interface configured to receive operational signals from sensors associated with a connected physical asset;a standards module configured to store machine readable constraints derived from regulatory data about the physical asset, the regulatory data comprising at least one regulatory or operational standard applicable to the physical asset;a processor configured to:generate or update a digital twin model of the physical asset that mimics the behaviour and / or characteristics of the physical asset and complies with relevant regulatory requirements of the physical asset;compute control actions by applying the machine readable constraints to the digital twin model; andan actuation interface configured to transmit the control actions to an input of the physical asset;wherein execution of the control actions constrains at least one operating parameter of the physical asset to remain within a tolerance band specified by the machine-readable constraints.

[0012] In some embodiments, the processor generates or updates the digital twin model through training a machine learning model to learn the behaviour and characteristics of the physical asset based on the operational signals and regulatory data.

[0013] In some embodiments, the device comprises a communications module configured to communicate with a cloud database and / or other external device / network. The communications module may be configured to upload the digital twin model to a processor embedded in the physical asset.

[0014] In some embodiments, the processor is further configured to detect non-compliance of a regulatory or operational standard and to trigger prescriptive corrective control actions comprising at least one of: a halt instruction for the physical asset, a change in state of the physical asset or operator notification. The control actions may comprise one or more of motor torque or speed setpoints, temperature setpoints, valve duty cycles, pump flow rates, or electrical drive parameters.

[0015] In some embodiments, the operational signals comprise at least one of vibration signals, acoustic emission, temperature, pressure, current draw, optical intensity, or image frames from a camera.

[0016] In some embodiments, the processor is configured to generate, update or host a virtual machine configured to emulate operational logic of the physical asset. The processor may be configured to generate, update or host multiple virtual machines on the same device.

[0017] In some embodiments, the digital twin model comprises Al clusters.

[0018] In some embodiments, the standards module stores ISO, IEC FDA or TGA standards compiled into machine readable constraints.

[0019] In some embodiments, the machine learning model receives the operational signals from the physical asset via one or more websocket APIs associated with the physical asset.

[0020] In some embodiments, the input interface and / or actuation interface comprises one or more of a USB, HDMI, Ethernet, serial RS232 or RS485 port. In some embodiments, the input interface and / or actuation interface comprises wireless communications comprising one or more of Wi-Fi, Bluetooth, Zigbee, LoRaWAN, LTE, or5G.

[0021] In some embodiments, the machine learning model comprises one or more agents that are adapted to update the model based on events detected in the operational signals received from the physical asset. In some embodiments, the machine learning model comprises a first layer that monitors compliance of the digital twin model with one or more operational standards for the physical asset and, upon detection of a lack of compliance, instructs or permits a second layer to update the digital twin model to comply with the one or more operational standards.

[0022] In some embodiments, the communications module stores a version of the digital twin model in a cloud database or in a wearable or standalone device.

[0023] In some embodiments, the digital twin comprises a digital passport including:a static section storing persistent identity and configuration data of the physical asset; anda dynamic section storing time-varying operational or lifecycle data including at least performance, maintenance, calibration or compliance state records.

[0024] The digital passport may be continuously or intermittently updated in response to operational signals from the physical asset.

[0025] In some embodiments, the device further comprises a 3D reconstruction subsystem configured to ingest multimodal inputs comprising image data from one or more cameras and non-image sensor signals indicative of the asset’s operating state. This subsystem may be integral with or performed by the processor. The 3D reconstruction subsystem may be configured to fuse the multimodal inputs to estimate geometry or pose of the physical asset and to generate a three-dimensional model associated with the digital twin. The three-dimensional model may be continuously or repeatedly updated based on new sensor or image inputs.

[0026] In some embodiments, the processor comprises a smart conversion layer configured to ingest regulatory or operational documents and convert them into machine-readable constraints. The smart conversion layer may apply one or more of text extraction, machine learning or natural-language processing techniques to identify regulatory parameters for the physical asset.

[0027] In some embodiments, the processor comprises an interoperability layer configured to automatically detect a communication protocol of a newly connected physical asset and retrieve metadata associated with the asset. The interoperability layer may apply an unsupervised machine-learning model to identify unknown data streams and group them for subsequent classification.

[0028] In some embodiments, the input interface is configured to receive image or audio data representing gestures or spoken commands, and the processor updates the digital twin based on recognized gestures or events.

[0029] In some embodiments, the processor employs one or more convolutional neural networks (CNNs) or temporal models to detect asset-related events or human interactions from image or audio data.

[0030] In some embodiments, the digital twin generates authenticated execution rules for transmission to virtual machines hosted on two or more edge devices.

[0031] In some embodiments, the physical asset comprises a personal medical device to be operated by a user. The one or more personal medical devices may comprise wearable devices. The one or more personal medical devices comprise biosensors. The one or more personal medical devices may comprise a DNA extractor. The one or more personal devices may comprise blood analysis devices.

[0032] In some embodiments, the personal medical devices comprise a processor that is adapted to receive a request from a medical practitioner to operate the personal medical device to extract data about a patient and report that data to the medical practitioner.

[0033] In some embodiments, the device is in the form of a device-on-a-chip. In some embodiments, the device is in the form of a lab-on-a-chip. The lab-on-a-chip may comprise one or more embedded sensors or actuators.

[0034] In some embodiments, the lab-on-a-chip comprises a microfluidic device.

[0035] In some embodiments, the input interface is configured to receive image data from one or more connected image sensors.

[0036] In accordance with a second aspect of the present invention, there is provided a patient device configured to interface with the device according to the first aspect. The patient device comprising:one or more sensors / actuators for interfacing with a patient or sample to obtain patient or sample data;a controller for operating the one or more sensors for diagnostics according to a digital twin model of a corresponding physical asset;memory for storing the digital twin model; anda communications module for receiving data to generate or update the digital twin model such that the patient device mimics the behaviour and / or characteristics of the physical asset and complies with relevant regulatory requirements of the physical asset.

[0037] In accordance with a third aspect of the present invention, there is provided a patient device configured to obtain patient data, the patient device comprising:one or more sensors / actuators for interfacing with a patient to obtain patient data; a controller for operating the one or more sensors according to a digital twin model of a corresponding physical asset;memory for storing the digital twin model; anda communications module for receiving data to generate or update the digital twin model such that the patient device mimics the behaviour and / or characteristics of the physical asset and complies with relevant regulatory requirements of the physical asset.

[0038] In some embodiments, the communications module is configured to store and / or download a version of the digital twin on / from a cloud database or into the wearable device.

[0039] In accordance with a fourth aspect of the present invention, there is provided a device-on-a-chip (DoC) comprising:one or more microfluidic chambers;sensors configured to generate measurements of fluid or sample conditions; actuators comprising at least one of micropumps or microvalves;an embedded processor hosting a virtual machine that interprets a protocol to generate actuator control signals; anda digital twin interface configured to compare the measurements with a stored standard profile and to adjust the protocol;wherein the DoC autonomously executes and standardises a wet-lab process on-chip using the sensors and actuators.

[0040] In some embodiments, the sensors comprise at least one of temperature, pressure, optical absorbance / fluorescence, electrical impedance, or camera-based imaging.

[0041] In some embodiments, the one or more microfluidic chambers comprise at least a sample chamber, a mixing chamber, and a detection chamber

[0042] In some embodiments, the device comprises a 3D reconstruction subsystem configured to ingest multimodal inputs comprising image data from one or more cameras and non-image sensor signals indicative of the asset’s operating state. In some embodiments, wherein the 3D reconstruction subsystem reconstructs geometry of the microfluidic chambers or components using multimodal sensor and camera inputs.

[0043] In some embodiments, the microfluidic chambers are modular and replaceable as cartridge units for reconfiguration of experimental processes.

[0044] In accordance with a fifth aspect of the present invention, there is provided a method of enforcing compliant operation of a physical asset, the method comprising:receiving sensor signals from the physical asset;forming or updating a digital twin state representing an operating condition of the physical asset;compiling a regulatory or operational standard into machine-executable constraints; computing one or more control setpoints by applying the machine-executable constraints to the digital twin state; andapplying the control setpoints to the physical asset via an actuation interface, thereby maintaining at least one operating parameter of the physical asset within a specified tolerance range.

[0045] In some embodiments, the step of compiling an operational standard comprises using a machine learning model trained from historical operational data of the physical asset.

[0046] In accordance with a sixth aspect of the present invention, there is provided a device configured to perform the method of the fifth aspect. The device may be in the form of a device-on-a-chip having edge computing functionality.

[0047] In accordance with a seventh aspect of the present invention, there is provided a non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause performance of the method of the fifth aspect.

[0048] In accordance with an eighth aspect of the present invention, there is provided a device for generating a digital twin of a physical instrument, the device comprising:one or more input ports configured to receive operational data from sensors associated with a connected physical instrument;a communications module configured to access a database to receive and compare regulatory data about the physical instrument; anda processor configured to:train a machine learning model to learn the behaviour and characteristics of the physical instrument based on the operational data and regulatory data;generate or update a digital twin model of the one or more physical instruments that mimics the behaviour and / or characteristics of the physical instrument and complies with relevant regulatory requirements of the physical instrument.

[0049] Another aspect of the present invention provides a device configured to generate or update a digital twin of a physical asset.BRIEF DESCRIPTION OF THE FIGURES

[0050] Example embodiments of the disclosure will now be described, by way of example only, with reference to the accompanying drawings in which:Figure 1 is a schematic system level diagram showing data flow between a device for generating a digital twin of a physical instrument, the physical instrument and other parties;Figure 2 is a schematic system level diagram illustrating data flow between a device for generating a digital twin and a system hosted within a regulatory environment for real time remote monitoring / auditing;Figure 3 is a schematic system level diagram illustrating data flow between a device for generating a digital twin and a system hosted within an industry environment;Figure 4 is a schematic diagram of a host device (wearable or a standalone) that can interface with samples, people and device for generating a digital twin so as to operate in accordance with a physical instrument from which the digital twin is generated;Figure 5 is a schematic diagram of the host device (wearable or a standalone) of Figure 4, illustrating various features and functional layers; andFigure 6 is a schematic diagram of a device-on-a-chip with microfluidic chambers, sensors / actuators and embedded virtual machine and digital twin.DESCRIPTION OF THE INVENTION

[0051] Embodiments of the present invention will be described herein with reference to creating digital twins and virtual machines of physical assets in the form of medical and lab-based instruments and for use of a digital twin in personal or portable medical devices. However, it will be appreciated that the invention is applicable more widely to creating digital twins and virtual machines of other types of physical assets such as machines, instruments and devices, and for using the digital twin and virtual machine to operate any form of local device in a similar manner to the original physical asset.

[0052] By way of example, the invention is applicable to areas and physical assets such as industrial machinery and equipment, automobile equipment, automative parts, food and beverage manufacturing, mining, agriculture, space industries, textiles, environmental monitoring and pharmaceutical development equipment.Device overview

[0053] Referring to Figure 1 , there is illustrated a device 100 for generating or updating a digital twin of a physical asset 200. In general, device 100 is agnostic in terms of which physical assets it can connect to. However, the physical assets 200 may represent any operable device, machine, instrument or asset that is able to interface with other devices / databases either locally or over the internet, however which is not mandatory. By way of example, in medicalapplications, physical assets 200 may be scientific or medical instruments typically found in research laboratories, hospitals or other institutions that either interface directly with humans or obtain or analyze patient materials / samples. Specific examples of physical assets 200 comprise MRI scanning machines, ECG monitors, DNA sequencers, x-ray imagers, ultrasound devices, blood monitoring devices and lab-on-a-chip devices. In other applications, physical asset 200 can be any physical asset from spacecraft or autonomous vehicles to industrial and heavy machinery. The physical assets 200 may have their own display 201 or may display data via a connected PC device.

[0054] As illustrated in Figure 1, preferably, device 100 is in the form of a “device on a chip” and may be formed as a multi-layer printed circuit board (PCB), system-on-chip, lab-on-a-chip or other integrated or modular hardware device. Device 100 preferably comprises a motherboard or integrated circuit 101 that houses various components such as a processor, sensors and memory, as described below. Device 100 comprises an input interface 102 that is configured to receive operational signals from sensors associated with the connected physical asset 200. In some embodiments, the data received from device 200 by interface 102 may comprise system information such as CAD files, operating system data, sensing board data, internal files and engineering data.

[0055] Although not illustrated, device 100 may include more sophisticated features such as micro-fluidics, dedicated chambers, motors, actuators, radiation tolerant surfaces and / or other micro-electromechanical arrangements to operate as a lab-on-a-chip. This functionality is described in more detail below. Device 100 may also include various edge-computing hardware components.

[0056] By way of example, input interface 102 may comprise one or more of USB, HDMI, display ports, serial RS232, RS485 connectors, Ethernet or other wired connections. Input interface 102 may also comprise one or more wireless adaptors that enable wireless communications with the connected physical asset 200 such as a Wi-Fi, Bluetooth, Zigbee or LoRaWAN, LTE or 5G adaptor. Input interface 102 may also comprise a wireless interface / connection. Although interface 102 is illustrated as a single connection, it will be appreciated that interface 102 may comprise any number of input ports. Input interface 102 may form an integral part of device 100 that will directly communicate with the physical asset’s electronic and central boards. Device 100 can be a small sized chip that can be incorporated within other devices as described below.

[0057] In some embodiments, device 100 comprises a smart camera 105, embedded with computer vision and / or deep learning machine learning algorithms to perform image or event processing. In some embodiments, device 100 is a standalone device without a need to attach to or physically connect with other devices.

[0058] In some embodiments, device 100 is formed on a chip or PCB that is integrated into the physical asset 200 either at manufacture or subsequently. In these embodiments, the input interface 102 may represent the electrical pins / connectors / contacts that interface with corresponding pins / sockets within the physical asset 200.

[0059] Input interface 102 connects with a corresponding output interface 202 of the connected physical asset 200 to receive operational signals. Interface 202 of physical asset 200 may comprise any of the connection types described above or other typical connections / interfaces found in physical devices.

[0060] Internally, interface 202 of the physical asset 200 may interface with a data acquisition (DAQ) system of that instrument. DAQ systems interface with sensors of device 100, which convert analog signals to digital data or programmable languages (python etc.) that can be processed by device 100. In many cases, the physical asset 200 already has its own embedded drivers and application programming interfaces (APIs) for obtaining operational signals. The transfer of data to device 100 is preferably in real-time or near real-time. However, in some embodiments, the data transfer may occur in a time delayed or batched manner. In other cases, when the PCB is an integral part of a physical asset, then twin making and communication is done continually or in an intermittent ongoing manner. When input interface 102 is connected to device interface 202, device 100 will search, locate the DAQ and other systems of device, then convert the files, specs to digital signals.

[0061] The operational signals obtained from the connected physical asset 200 via input interface 102 may comprise any information generated and collected during the normal functioning of that device and original specifications of the device. In particular, the operational signals comprise any data that provides insights into the performance, usage, and status of the device. By way of example, operational signals comprises information such as:Performance Metrics: Data related to the efficiency, accuracy, and effectiveness of the physical asset. This can include readings, measurements, and outputs that the physical asset is designed to capture.Usage Data: Information about how the physical asset is being used, such as frequency of use, duration of operation, and specific tasks performed.> Status and Health Monitoring: Data concerning the current state of the physical asset, including operational status (active, idle, or malfunctioning), error codes, maintenance logs, and diagnostic information.Environmental Conditions: Information about the conditions in which the physical asset is operating, such as temperature, humidity, pressure, or other relevant environmental parameters that might affect its performance.Configuration and Settings: Data on the current configuration, operational settings, calibration settings, and any adjustments made to the physical asset overtime. This may include physical asset parameters such as actuator positions, focal levels, voltage / current parameters, wavelengths, frequencies and amplitudes.Historical Data: Records of past performance, usage, maintenance, and any incidents that have occurred, providing a timeline of the physical asset’s operational history. > Experimental or diagnostics data of the samples: Current and past data obtained by the device and stored within memory of the device.Identity data: Data unique to the physical asset including metadata such as a unique ID, product name, product ID, sensors, manufacturer, etc. This unique data acts as a ‘digital passport’ for the digital twin and the physical asset and may persist throughout the lifetime of the asset.

[0062] In specific types of assets, the operational signals may comprise at least one of vibration signals, acoustic emission, temperature, pressure, current draw, optical intensity, or image frames from a camera such as camera 105.

[0063] All these data feed to the twin via real time or near real-time communication to the corresponding remote DT for monitoring. Although not illustrated, device 100 may also comprise one or more smart digital sensors and / or quantum sensors operatively associated with input interface 102 and other inputs importing physical asset’s information for translating and / or normalising the data into a universal / standardised data format or into computer programmable language, such as python and for twin making. As mentioned below, the interface between device 100 and physical assets 200 may comprise a Representational State Transfer (REST)APIs or other types of APIs, while device 100 connectivity to external users for remote real time data and twin communication and streaming / networking through websocket, FastAPI, Message Queuing Telemetry Transport (MQTT) or similar.

[0064] Device 100 comprises a standards module 107 configured to store machine readable constraints derived from regulatory data about the physical asset 200. The regulatory data comprises at least one regulatory or operational standard applicable to the physical asset 200. The operational standards module 107 stores standards such as ISO, IEC FDA or TGA standards compiled into machine readable constraints. New standards may be added overtime.

[0065] By way of example, in the medical device space, the following ISO standards may be used:• ISO 13485:2016 provides the quality management requirements for medical device design, manufacturing, and lifecycle control. By embedding this standard, the system helps to ensure that connected devices and processes meet internationally recognised standards for safety and effectiveness.• AS ISO 15189:2023 defines the requirements for medical laboratories to demonstrate quality and competence. By integrating this standard, the twin-enabled infrastructure allows laboratories to monitor, document, and demonstrate compliance in real time, reducing audit risks and operational overheads.

[0066] Device 100 comprises a communications module 106 configured to communicate with a cloud database and / or other external device / network. In some embodiments, the communications module 106 is configured to access a database 108 to receive and compare regulatory data about the physical asset and its performance compliance. As illustrated in Figure 1, database 108 may be remote to device 100 and contained as a regulatory database 108A hosted on a server 110 operated by a regulatory body. Server 110 represents a regulatory environment as described below. By way of example, regulatory database 108A may be hosted by organisations like the Food and Drug Administration (FDA), Therapeutic Goods Administration (TGA), European Medicines Agency (EMA), Independent Expert Scientific Committee (IESC), International Organization for Standardization (ISO) or other standards and regulatory organisations that create standards, regulators, and accrediting devices.

[0067] Alternatively, or in addition, database 108 may be a local database 108B hosted / located / embedded within device 100, compromising regulatory and ISO standards. By way of example, database 108B may be incorporated within or form part of the standards module 107. These standards can be updated over time over the internet or a network connection through sharing between the memory of device 100 and database 108A or can be embedded during the manufacturing of device 100. In this case, database 108A is embedded in device 100 in the form of firmware which can be updated remotely at predetermined times.

[0068] Most scientific and medical grade instruments must be operated in accordance with predefined operational standards of physical assets and regulatory compliance protocols (collectively referred to as “regulatory data”) to ensure the operation is safe and the data generated is accurate. The operation of communications module 106 ensures that these relevant regulatory data are applied to a digital twin of the physical asset 200 that is generated and also to the incoming performance data related to input interface 102 from the physical asset 200. In this regard, communications module 106 acts as a monitor to ensure compliance of the digital twin with regulatory requirements.

[0069] Communications module 106 is a physical component within the broader hardware of device 100, having embedded software / firmware configured to implement one or more communications protocols to communicate data to / from database 108. This may comprise communication via any internet connectivity device such as Ethernet, WiFi, Bluetooth, LTE / 5G, Zigbee, LoRaWAN or Modbus. In some embodiments, communications module 106 is integral with or comprises input interface 102.

[0070] Additionally, module 106 can have smart digital / quantum sensors embeddable with smart algorithms to monitor and compare incoming data from 200 with database 108B for performance compliance. Communications module 106 may also comprise regulatory database 108 or some or all of the information contained in regulatory database 108. In some embodiments, machine learning and / or other algorithms hosted by a processor 112 (described below) or communications module 106 continuously check device operational and other data received through input interface 102 connected to device 200 output port 202. In other instances, when the hardware 100 is a small chip, communications module 106 reads directly from the physical asset 200, and monitors compliance as per the database 108.

[0071] As mentioned above, database 108 may be hosted by a server 110 or locally on device 100 (108B). Database 108 defines a regulatory or external environment that isaccessible to healthcare regulators, instrument operators and manufacturers, auditors, external authorities such as the Therapeutics Goods Administration (TGA) or International Standards Organisation (ISO). Database 108 stores information relating to key parameters of these regulators like standards that are relevant to specific physical assets or their environment. By way of example, database 108 may store rules executable interpretation of standards. Database 108 also defines a controlled audit environment where auditors can review pre-audit files or records.

[0072] Device 100 also comprises a processor 112 configured to generate or update a digital twin model of the physical asset 200 that mimics the operational behaviour and / or characteristics of the physical asset 200 and complies with relevant regulatory requirements of the physical asset 200. This may be achieved by training a machine learning model to learn the behaviour and characteristics of the physical asset 200 based on the operational signals and regulatory data.

[0073] In this regard, processor 112 is configured to generate, host and train a machine learning model to learn the behaviour and characteristics of the physical asset 200 based on the operational signals obtained from input interface 102 and regulatory data obtained from standards module 107 and / or database 108. As device 100 represents a device on a chip design, there preferably exists a physical circuit communication between processor 112 and communications module 106. The interface 102 is preferably also circuit connected with communications module 106 and processor 112. Processor 112 and communications module 106 may also receive data from smart camera 105.

[0074] The twin generation or updating by processor 112 may be executed in real time based on the fetched data from the connected physical asset 200 through the channels mentioned above or directly and executed through a machine learning algorithm. This process is device agnostic.

[0075] Processor 112 is also configured to compute control actions by applying the machine readable constraints from the standards module 107 to the digital twin model. By way of example, control actions may include motor torque or speed setpoints, temperature setpoints, valve duty cycles, pump flow rates, or electrical drive parameters. In general, the control actions may represent any machine readable instructions that can control sensors or actuators of physical assets. With knowledge of both the operational data and regulatory data, execution ofthe control actions constrains at least one operating parameter of the physical asset 200 to remain within a tolerance band specified by the machine-readable constraints.

[0076] Device 100 also comprises an actuation interface 104 configured to transmit the control actions to an input interface 204 of the physical asset 200. Actuation interface 104 may comprise similar connection technology to that of input interface 102. By way of example, actuation interface 104 may comprise one or more of USB, HDMI, display ports, serial RS232, RS485 connectors, Ethernet or other wired connections. Actuation interface 104 may also comprise wireless connections.

[0077] The processor 112 may be further configured to detect non-compliance of a regulatory or operational standard and to trigger prescriptive corrective control actions. These corrective actions may comprise at least one of: a halt instruction for the physical asset, a change in state of the physical asset or operator notification. The corrective control actions are in the same form as a control actions described above, which are fed to the physical asset 200 via the actuation interface 104.

[0078] The processor 112 may be further configured to generate, update or host a virtual machine configured to emulate operational logic of the physical asset 200. The virtual machine may be responsible for computing the control actions and passing them to the actuation interface 104 to control operation of the physical asset 200.

[0079] As mentioned above, device 100 may comprise a camera 105 to perform image or event processing. In addition or alternatively, input interface 102 may be configured receive image data from one or more connected cameras having associated image sensors. By way of example, one or more cameras may be placed within or around physical asset 200 and positioned to monitor the operation of physical asset 200. The camera or cameras capture image data, which can be fed to device 100 via input interface 102. The image data may be fed directly to processor 112 or may be processed to determine particular operational signals before being fed to processor 112.

[0080] Object detection may be performed on the captured image data and used to identify physical assets, parts of physical assets or detect events. Event detection is used to classify actions and activities occurring around those assets and feed back to the processor 112 for updating the digital. In some embodiments, camera vision and audio are used to live-stream visual and audio (including spoken) information about the physical appearance of the asset (e.g.physical form, geometry, layout, condition and visual state), its environment, and activities occurring in the physical space.

[0081] By way of example, a camera may be positioned to monitor a door state of a physical asset. When the camera detects the door is closed, the data is fed to processor 112 to update the state representation of the digital twin to a ‘door closed’ state. Similarly, when the camera detects the door is open, the data is fed to processor 112 to update the state representation of the digital twin to a ‘door open’ state.

[0082] In some embodiments, multiple video streams are used to train convolutional neural networks (CNNs) for real time object and event detection, as well as specific gestures to interact with the physical asset. These data streams can be fed into the digital twin in real time.

[0083] Cameras may capture gestures of human hand movements such as opening or closing a door, or operating the equipment. This image data can be captured, the gestures processed and fed into the digital twin model.

[0084] The digital twin learns from these user interactions using reinforcement learning based on a reward mechanism (what is correct or not correct as per the regulatory or SOP input). When live video streams from the real environment are fed into the digital twin, the digital twin can verify whether the operation is correct and also recommend corrective actions back to the physical system.

[0085] Although only described as being connected to single physical asset, it will be appreciated that device 100 is capable of being connected to multiple physical assets. This can be achieved as input interface 102 and actuation interface 104 can have multiple connection ports. In addition, physical assets may be connected via the cloud through communications module 106. The connected physical assets may comprise different types of device such as a DNA extractor, PCR and centrifuge. Device 100 is able to bidirectionally connect sensor data across the various connected

[0086] As illustrated in Figure 1, processor 112 forms part of motherboard 101, which preferably forms a system-on-chip device having embedded sensors, processing devices, GPUs (e.g. NVIDIA GPU) and memory for storing the digital twin models. Example memory devices may comprise read-only-memory (ROM), random access memory (RAM), cache memory, high speed GPUs and mechanical or solid state hard drives. As such, functionsdescribed above may be shared between the different elements on motherboard 101 such as between processor 112 and communications module 106.

[0087] To achieve this functionality, data is fetched by input interface 102, processor 112 and communications module 106, automatically generating or updating a digital twin and then through a WebSocket or fast APIs or MQTT, Modbus or other communication protocols, the digital twin is pipelined to the cloud and then to the regulatory supervised environment 110 or industrial monitoring environment 120.Digital Twin Generation

[0088] Device 100 may comprise a machine learning-based interoperability layer that acts as a universal translator between multiple communication protocols and data formats. Communication protocols may include for example, USB, RS-232, Ethernet, UART, SPI, I2C, wireless (wi-fi, Bluetooth, Thread), etc.

[0089] The interoperability layer may be hosted on processor 112 or in a separate GPU or microcontroller of device 100. The interoperability layer automatically detects connected physical assets, identifies the communication protocol, fetches metadata (e.g. device model, data type, regulatory, sensors, digital passport, etc.) and translates different data formats into a common structure. This standardises the data into a universal format that can be communicated through a centralised API between different devices and the cloud.

[0090] The machine learning hierarchy of the interoperability layer may be a combination of supervised and semi-supervised continuous learning with human-in-the-loop. Neural network classifiers (multi-layer perceptrons (MLPs), convolutional neural networks (CNNs), or small transformers) may perform mapping / standardisation of different device outputs to a common / standardise data structure. The neural network classifiers are trained in a supervised manner, embedded in a human-in-the-loop self-learning system where new machines are integrated through human validation and incremental model updates.

[0091] When an unknown physical asset is connected to device 100, a lightweight unsupervised machine learning model (e.g. isolation forest) detects unknown inputs, groups them, followed by optional human confirmation of the standards. The data is then passed to continued incremental self-learning by the MLPs or CNNs. These models may self-learn by absorbing validated device data. The grouping of inputs may be executed through hierarchical clustering models.

[0092] The digital twin maintains a state representation (also referred to as a digital twin state or state vector) of a corresponding physical asset. The state representation may include, without limitation:• Identity and configuration data: asset identifier, model, firmware / software versions, calibration parameters, allowable operating ranges.• Live operational signals: sensor measurements (e.g., temperature, pressure, vibration spectra, acoustic emission, electrical current, voltage, optical intensity, camera frames), controller status, network connectivity, and error codes.• Derived features: rolling statistics (mean, variance), spectral features (dominant frequency and magnitude), health indices, trend slopes, confidence scores, and quality metrics.• Lifecycle records: maintenance logs, historical performance, environmental context, and usage history.

[0093] In some embodiments, the digital twin state is updated in real time or near real time from the apparatus input interfaces.

[0094] In some embodiments, device 100 comprises a 3D reconstruction subsystem configured to generate or update a three-dimensional digital representation of a physical asset. This 3D reconstruction can form part of the digital twin by generating an accurate 3D representation of the physical asset. The 3D reconstruction subsystem is able to ingest multimodal inputs comprising at least (i) image data from one or more cameras positioned with respect to the asset, and (ii) non-image sensor signals indicative of the asset’s state or environment (including, for example, vibration, temperature, pressure, electrical, or optical measurements).

[0095] The 3D reconstruction subsystem then fuses the multimodal inputs to estimate geometry and pose of the asset and / or its components and to produce a 3D model (e.g., a mesh or volumetric representation) that is continuously or repeatedly updated in response to new inputs.

[0096] The 3D model forms part of, or is associated with, a digital twin of the asset and provides a state representation usable for monitoring, simulation, or control, including application of constraint rules and generation of control actions. The 3D model may be exported in a standard format for visualization or simulation.

[0097] The subsystem employs a human-in-the-loop correction workflow in which operator inputs refine geometry, alignment, or semantic labels, with updates persisted to the digital twin.Machine Learning Architecture

[0098] The processor 112 and communication module 106 also pipeline performance and operational data of physical asset 200 feeding the existing digital twin. Over time, the digital twin learns (at both the physical and operational level) from the physical asset through embedded machine learning algorithms on the digital twin how to function such as to analyse samples and display results just like the physical assets. The digital twin may then be displayed graphically on a display 201 of the physical asset 200 itself or a connected computer monitor 210 or is being streamed remotely to connected systems, for example regulatory or auditors computers 110.

[0099] Various machine learning architectures are possible to be hosted locally on device 100 by processor 112 or in the cloud.

[0100] The machine learning components may comprise one or more machine-learning models and / or rule engines that together form a learning module. The learning module receives state vectors from the digital twin and computes control actions, predictions, or compliance assessments. The models may include supervised, unsupervised, or deep reinforcement learning algorithms, constraint solvers, or combinations of these, each configured to operate within the computational resources available on the edge hardware or cloud environment.

[0101] The machine learning components interact with the digital twin and virtual machine as follows:The digital twin produces a state vector representation indicative of sensor measurements, configuration parameters and / or derived metrics.The learning modules consume that state vector.The learning modules produce outputs such as a compliance score, control setpoints / commands, predicted future states and anomaly detection flags.The virtual machine receives these outputs and executes steps locally to simulate the outcomes on the physical asset 200 or on the device 100 itself if that device has local sensors / actuators.This process may be executed locally on device 100 (e.g. using edge hardware), performed in the cloud or performed in a hybrid environment of edge-cloud hardware. In some cases, a subset of the Al subsystem executes locally to maintain closed-loop control with bounded latency while heavier training tasks execute remotely.

[0102] In some embodiments, the digital twin generates authenticated execution rules for transmission to virtual machines hosted on two or more devices.System Overview

[0103] It will be appreciated that different operations may be performed on different versions of the digital twin that sit in different databases. For the digital twin model that is hosted within regulatory database 108A, the machine learning algorithms may only check operational and overall conditions against the master regulatory settings. However, in an industry environment 120 not restricted to regulatory constraints, the digital twin may be more dynamically updated.

[0104] The digital twin models may sit in different environments 110 and 120 (or 210 as per Figure 3 or in 300 as per Figure 4), and are accessible by healthcare regulators, patients, operators and manufactures via communications module 106 and has predefined operational standards as per 108A and which automatically extracted and embedded from the regulatory standards and auditing documentation corresponding to a given physical asset to be monitored and audited. Environments 110 and 120 are accessible to authorised users via the internet or within a private network such as an Ethernet environment. The data extraction process may comprise data / text / information / image extraction from various file formats from 108A (Figure 2) or 134 (Figure 3) into the environment, such as pdf, word, png, etc. which are uploaded and converted into digital signals for processing by machine learning algorithms. This can be done by a combination of python script, machine learning and Generative Al, and gesture recognition ML, creating a smart conversion layer 124 (Figure 2) or smart conversion layer 132 (Figure 3) and embeds the digital signals into the twin environment 114 (Figure 2) or 130 (Figure 3) and puts them as a regulatory red flags or windows for real time monitoring / auditing of the physical asset 200 through the twinning. The smart conversion layer 124 comprises hybrid machine learning models working together in a cluster, performing multitasking and rotating tasks while progressively improving through each rotation.

[0105] The operational standards can also be updated in real-time over the internet by lab managers or personnel using the physical asset 200 or authorized people associated with regulatory bodies.

[0106] Referring to Figures 1 and 2, the digital twin environment hosted on device 100 works as a local environment while a digital twin environment hosted in regulatory supervised environment 110, under which also database 108A is hosted, works as a universal Master (supervised and set) environment 114, accessible by the regulators only. Supervised environment 110 represents the physical server infrastructure managed by the regulatory authority (FDA / TGA / etc.). Environment 114 represents the logical digital twin environment operating within environment 110 for compliance checking, with controlled updates, machine-readable standards, and audit-oriented displays. Environment 114 displays the realtime DT corresponding to the physical asset 200, through device 100 and communication module 106, remotely receives real-time data from the corresponding physical asset 200 for auditing.

[0107] In some embodiments, device 100 is capable of operating offline (as in a zero trust environment) without external or internal network connectivity and synchronizes the digital twin state when connectivity resumes. This is useful in high security applications, in underground mining and in orbital space operations where connectivity is difficult or absent.

[0108] Environment 114 holds regulators key parameters, like FDA, TGA or specific ISO standards as performance criteria window and are created as described above by layer 124 (Figure 2). The smart conversion layer 124 ingests regulatory documents such as PDFs, SOPs, or structured rules, uses ML and text-extraction methods to identify key operational parameters, and compiles them into machine-readable constraint rules for the digital twin. A machine learning environment here is supervised / controlled and DT / ML do not learn from incoming data and its role is to monitor DT and 200 performance compliance with the set criteria. This environment 114 is dynamic with a permission only to those who can setup the supervised conditions, receives updated documents and parameters from the regulators, embeds and works as a master plan for auditors. It creates twins of regulatory requirements and documents that work with the environment. A Master version of the digital twin may sit with the regulatory and can be updated by them.

[0109] Referring to Figure 3, in some embodiments, the digital twin is hosted in an industry environment 120 and has two functional layers:

[0110] Layer 1- Master or supervised layer / environment 130 hosted in the industry environment 120 (or210 as per Figure 3) that has regulatory database 134 that holds the digital twin device related information, the environment 130 checks ongoing status of the connected physical asset in real time and cross checks its compliance level through machine learning or Python script with embedded flags (standards). If the digital twin is out of conformity, then a flag, and moves it to the next layer referred to as a dynamic layer / environment 116. Feedback may be provided to external organizations such as regulatory bodies and companies. The machine learning process in this environment is supervised / controlled and is not changing based on the received real time data.

[0111] Within the industry environment, Layer 1 monitors compliance of the digital twin model in real time with one or more operational standards from a database 134 (described below) used in layer 132, for the corresponding physical asset 200 and, upon detection of a lack of compliance, instructs or permits a second layer 116 (Layer 2 described below) to update the digital twin model and therefore the physical asset to comply with the one or more operational standards.

[0112] Layer 2- A dynamic layer / environment 116 that performs learning, saving, performing (simulation) and backup.

[0113] When the digital twin in 130 (Figure 3) is receiving real time data (events like input actions, operational signals, results, methods, SOP information etc.) from the connected remote physical asset 200 via the WebSocket APIs or MQTT (real time), which then are communicated to 116, there are preferably embedded Al agents in the model and / or in the 116 environment that are smart bots or clusters of machine learning algorithms. An agent is a software program that can collect data, and use the data to perform self-determined tasks to meet predetermined goals. These agents are capable of learning, mirroring and replicating and are capable to learn due to given API functionality and therefore autonomously simulating same events while keeping the memory. The memory can be updated dynamically with new events coming from connected corresponding physical assets 200. The agents can also store the events and can perform (simulate) same events when not connected real time, or to internet; offline. Layer 2 if detecting anomalies, calculates prescriptive corrective actions and sends backto device 100, which communicates with the connected physical asset 200 operating boards via ports 102 and 104 and smart sensors.

[0114] Some agents are implemented as smart algorithms that sit as an “eye” continually watching for incoming events. When an incoming event is detected in a real time API, it is immediately recognised by an agent and passed to a ‘brain’ that initiates chain reactions for auto-constructing the model based on the mirroring of the events-display.

[0115] Although not illustrated, device 100 may comprise a display screen and / or a user interface for displaying device information and allowing a user to control functions of the device. A mouse cursor or other user input device is used to control or operate the digital twin via the screen (e.g., open / close, tray in / out, mixing speed, magnetic rod position, etc.).

[0116] As mentioned above, in some embodiments, a version of the digital twin model is stored in a cloud database via communications module 106. By way of example, the digital twin may be stored in the master environment (layer 1) 114 or in another storage dedicated layer in 110 instead of or in addition to being stored locally in memory on device 100. In case of the industrial environment 120 (210 in Figure 3), the DT models are stored in the master environment (layer) 130 or in another layer dedicated for storage. All environments have dedicated GPU for processing and storing the twins.

[0117] Once a digital twin model is generated, communications module 106 may be configured to upload the digital twin model to a processor 302 embedded in one or more host devices 300. Alternatively, a digital twin model that is stored in the master environment 114 which is under regulatory network 110 may be downloaded to the host device 300. The host devices 300 may represent any device operable by a user or clinician and which can be operated in accordance with the physical assets 200. However, preferably the host devices 300 comprise personal medical devices to be operated by a user. In some embodiments, the personal medical devices comprise wearable devices such as biosensors, DNA extractors, thyroid monitors, blood analysis devices, glucose monitors or many others. Host devices 300 comprise hardware such as processor 302 and software that are embeddable with bio and digital sensors, biomarkers, standards.

[0118] This transfer of a digital twin to a host device 300 allows the digital twin models to sit on a portable or wearable or kit or attachable forms and utilize that device as a universal biosensing board. The digital twins are embeddable, updatable and interchangeable to suitchanging operation system or regulatory requirements of a device. They can be multidirectionally connected to the corresponding physical assets 200 or to doctors, scientists, and humans. They can also be a standalone digital diagnostics device themselves, see below. By way of example, the transfer of information about the digital twin to the host device 300 and the corresponding physical assets may be via communication protocols such as MQTT, FAST APIs etc.

[0119] The result is having a digitalised local device (e.g. wearable device) that operates in a similar or identical and twinning manner to a corresponding physical asset (e.g. large scale laboratory device). As such, a large scale device can be miniaturised onto a wearable or portable device.

[0120] In some embodiments, the processor 302 of a personal medical device is adapted to receive a request from a medical practitioner to operate the personal medical device to start a test, extract data about a patient and report that data to the medical practitioner.

[0121] In operation, a doctor may send a digital prescription directly to the host device 300 and which reads, initiates, operates, regulates the host device 300 and reports the data to the doctor first and the patients with multilevel permission communication.

[0122] Referring to Figure 2, there is illustrated schematically exemplary data flow between device 100 described above and master environment 114 hosted within a regulatory environment 110. The regulatory environment 110 represents an internal server network hosted by a regulatory body such as the FDA or TGA. Master environment 114 hosts a version of the digital twin and operates as a centralised communication between regulatory environment 110 and device 100. Master environment 114 also works to receive operational signals from the host devices (e.g. personal medical devices like wearables) on their performance and send data back to the regulators. Master environment 114 may also act to display the digital twin in real time on a display device 122 associated with regulatory environment 110.

[0123] Master environment 114 communicates with a smart layer 124, which reviews regulatory documents and information received or stored in regulatory database 108A and feeds relevant information to environment 114. By way of example, this information may comprise digitized company and regulatory documents such as pdf files that contain information relevant to one or more physical assets 200. Master environment 114 may output KPIs, update APIs and other information relevant to the digital twin. Some or all of this information may bereceived from a database 126 of extensions, smart / digital sensors, APIs and other information hosted within regulatory environment 110.

[0124] Although described as being hosted within regulatory environment 110, it will be appreciated that some or all of the functionality of elements 114, 124 and 108A may be hosted locally within device 100.

[0125] Referring now to Figure 3, there is illustrated schematically exemplary data flow between device 100 described above and dynamic environment 116 hosted within an industry environment 120. A central master environment 130 operates in a similar way to that of master environment 114 described above by hosting a version of the digital twin and operating as a centralised communication between industry environment 120 and device 100. This master environment 130 communicates with a dynamic layer / environment 116 and a smart layer 132. Dynamic environment 116 learns from master environment 130 and sends information back to master environment 130, and also to the physical asset 200 via the device 100.

[0126] Smart layer 132 operates in a similar manner to smart layer 124 described above. In particular, smart layer 132 ingests regulatory documents such as PDFs, SOPs, or structured rules received or stored in an industry database 134, uses ML and text-extraction methods to identify key operational parameters, and compiles them into machine-readable constraint rules for the digital twin. The machine-readable constraint rules are then fed to master environment 130.

[0127] Master environment 130 may output KPIs, update APIs and other information relevant to the digital twin. Some or all of this information may be received from a database 136 of extensions, smart / digital sensors, APIs and other information hosted within industry environment 120. Master environment 130 may also act to display the digital twin in real time on a display device 138 associated with regulatory environment 110.

[0128] The host device 300 may be configured to interface with device 100 as described above either directly via a physical connection or indirectly via the internet (as shown in Figure 1). Referring to Figure 4, the host device 300 may comprise one or more digital, bio, smart sensors / actuators / miniature cameras 304A, 304B and 304C for continual, periodic or sporadic interfacing with a patient 400 to obtain patient data. Processor 302 acts as controller for operating the one or more sensors 304A, 304B and 304C according to a digital twin model of a corresponding physical asset 200. Host device 300 comprises memory 306 for storing thedigital twin model and its OS on device 300. The digital twin model may have embedded standards, and biomarkers which then communicate with the readings of the sensors 304A, 304B and 304C. The embedded machine learning of the digital twin model may receive the data and analyze it in federated manner. The analysis may comprise suggesting diagnosis of one or more conditions of patient 400.

[0129] Host device 300 also comprises a communications module 308 for receiving data to generate or update the digital twin model such that the host device 300 mimics the behaviour and / or characteristics of the physical asset 200 and complies with relevant regulatory requirements of the physical asset 200. Communications module 308 may be configured to store and / or download a version of the digital twin on / from a cloud database such as from regulatory database 108A. It is also connected to 306 where DT is stored.

[0130] The host device 300 may be in the form of a wearable device, attachable device or a kit with disposable slips. Device 300 may comprise an interface that has a smart sensor layer (where sits the digital device), digital camera (miniature spectrometer). Communications module 308 may connect wirelessly to associated devices such as computers 310 and tablet computers 312 to visually display data associated with device 300 and / or the digital twin model.

[0131] Referring to Figure 5, host devices 300 may comprise a number of functional layers, as described below.

[0132] Layer 1- 400 - Represents the physical format of device 300. This includes the physical structure, housing, patient or sample interface and attachment elements in the case of a wearable or attachable device. Layer 1 400 may comprise elements such as a transdermal, microneedles, camera on a porous capillary system with pre-concentration nano capillaries to aggregate the physical fluid, blood drop, and pushing towards the Layer 2.

[0133] Layer 2- (402, 304A, 304B, 304C) is a multi-modal system on a chip (SoC) combining digital biochemical, chemical, environmental smart and quantum sensors, nanoparticles that are ML / AI enabled (embedded). This layer works in between the DT, biomarker standards and the physical sample like a brain to cross check the actual sample composition against the standards. Sensors sense the physical composition, while on the SoC, the composition is converted to digital data or into a programmable language. Biomarker standards from Layer 3 also flow into Layer 2, and Layer 2 cross checks the chemical identifiers from Layer 1 by checking with the standards. SoC also checks the camera data. The output isdigital data that are communicated to DT. Layer 2 activates the DT (Layer 4 described below). Digital data from Layer 2 goes to the cloud for diagnostic processing or stays on the edge to be processed in Layer 4 on the DT.

[0134] Layer 3- 404- Has embedded biomarkers known for diagnostics. Same kits can be embedded with dynamic chemical, microbiological and other compounds that will work as standards and will be used for ML, sensor, OS assisted analysis and diagnostics. Kits as dynamically embedded, and the components can be selected during the manufacturing phase. Specific standards get activated from the DT Layer 406, which then move towards the SoC.

[0135] Layer 4- DT Layer- 406 gets activated from Layer 2402 and, in turn, activates Layer 3 to release sample corresponding standards. DT can be downloaded from the cloud and can be linked with the corresponding physical asset 200 or without. DT is enabled (embedded) with ML, which can be uploaded / updated remotely over a wireless network connection. Both DT and ML are dynamic. DT is calculating the diagnostics and the results are communicated through communications module 308 to 312 and 310 or to the cloud / DT layer either embedded during manufacturing phase or downloadable from the cloud.

[0136] Layer 406 may comprise a camera that can check, cell and measure the cells. Images may be captured and sent to the cloud for processing. This data also goes to Layer 2 for ML / DT processing for diagnostics.

[0137] Additional layers (not illustrated) may be included in device 300 as follows.

[0138] Layer5- Smart digital sensing wires or sensors. These sensors can get activated based on the DT.

[0139] Layer 6- Porous capillary system for finger or skin prick for micro amount drop of blood which then enters the DT and triggers the analysis of for example TSH, blood count, etc. For the continues monitoring wires with the sensors are in contact with inner skin layers that can take occasionally sense the blood and send the information to the DT / ML layers for analysis and the results to cloud or doctors / etc. Some sensors can be transistor sensors, like Organic electrochemical transistor that can convert the biological signals (like blood reading) into electrical signals to be analysed by the ML and non-invasive real-time detection.

[0140] In case of lab DT- the samples in miniature amount can be used instead of human samples.

[0141] Layer 7- A middle layer or interoperability layer (described above) that will normalise data from different sources. It will also send raw data (all readings seen in the blood sample) to physical machines and DT in the cloud for reference and standard checking and analysis.

[0142] Layer 8- Is a firmware layer that extracts information continuously from blood and check with the smart sensors and DT that has mirroring OS of the physical asset.Physical Al with the agentic orchestration

[0143] In some embodiments, device 100 comprises physical Al, which refers to a distributed, embedded control architecture in which Al-powered software agents are embedded directly into the device 100 firmware or microcontrollers. The agents may be deployed directly on or inside physical components of the device (e.g., chambers, actuators, sensors). This enables local autonomy, local inference, and local execution of actions.

[0144] The multi-modal data received by device 100 from the physical asset(s) and from the cloud, are received by the physical Al, filtered by Deep Learning (DL) Models and pipelined to the digital twin. The digital twin, in turn, performs deep reinforcement learning to validate the best operation / action / standard. The recommendation as a command is then fed back to the physical components, where the local Al agents execute the actions on the physical asset. The local Al agents also learns from the actions and feeds outcomes back to improve the digital twin. The result is that both the digital twin and the physical asset become cognitive and autonomously self-regulating. As mentioned above, the digital twin may run on the device 100 itself and / or in the cloud with reinforcement learning.

[0145] In device 100, where local sensors and actuators are present, physical Al agents reside on some or all of the physical compartments, such as chambers, motors, tubes, actuators, etc. These sensor-level agent modules function like “eye neurons”, continuously absorbing, processing, multimodal information, including virtual machines, object and event detections, environmental sensors, gestures, audios, chat, actuators etc. They crosscommunicate with one another and exchange data bidirectionally with the system “brain”; the Digital Twin (DT) of the device 100 more generally.

[0146] The agents are constantly ON but fired up when signalled by the orchestrator. They can be more active or less active given the circumstances and are therefore adaptive tothe environments. The physical Al agents form part of a closed-loop feedback cycle with the digital twin. This bidirectional loop means:Physical Al agents continuously feed raw or preprocessed data to the DT. The DT evaluates those states using RL or rule-based constraints.The DT returns validated actions or recommended control adjustments.Physical Al agents execute those actions on the hardware and learns from those actions.

[0147] On the physical asset 200, agents operate in clusters, where similar functions work together, for example, object-detection clusters, environmental sensing clusters, motioncontrol clusters, gestures clusters, etc. They continuously or routinely exchange information between the physical asset and digital (DT) in bidirectional loops, creating a hybrid physical to digital and digital to physical live feedback system.

[0148] The middle layer between the physical Al clusters and the DT is a deep learning perception layer which includes task-specific models, e.g., vision, audio, and sensor models, as well as foundation models such as Vision-Language-Action (VLA) and Vision Foundation Models (VFMs). This layer performs high-level feature extraction, transforming large, unstructured raw inputs into filtered, compressed, and normalized latent representations. By filtering raw sensor data into actionable vectors, this layer provides the DT and the RL system with a high-signal, low-noise environment, enabling rapid convergence and accurate decisionmaking for physical tasks.

[0149] For example, when a cluster receives large volumes of data about environmental conditions and increased cell counts, these raw inputs are filtered by VFMs into structured forms, which are then interpreted by the VLA to generate action tokens to coordinate reagent pumps. These actions are then evaluated within the DT by the RL to learn and validate an optimal policy, such as adjusting the reagent volume to 1 pL. This is then mapped and applied to the physical chambers, where the physical Al adapts the chambers to the new policy for continuous self-correction. The physical system continuously / routinely and autonomously selfcorrects until a new policy arrives.

[0150] The data flow is preferably continuous but may be intermittent or periodic. Physical Al agents constantly observe the environment and stream data to the DT. The DTevaluates the state using deep reinforcement learning, and the validated actions are continuously deployed back to the physical system. The physical system becomes selfregulating, autonomous and self-correcting at all times. As a result, the DT and the physical asset become cognitive entities capable of reasoning and decision-making through a hybrid digital to physical and physical to digital interconnected loop.

[0151] The agents of the physical Al are a hybrid of 4 capabilities:1. The agents directly physically control the hardware and execute its movements following validated reinforcement learning recommendations received from the DT.2. The agents are capable of learning from the physical environment, processes and from the reinforcement learning recommendations and therefore staying accountable to reinforcement learning policies operates in a standardised manner, and self-correcting and autonomous.3. The agents are capable of continuously receiving and transferring real time cluster readings to the DT continuously, just like when the eyes are open continually see and process to the brain (DT).4. The agents communicate with other physical Al clusters to coordinate systemlevel behaviour. They are adaptive.Digital Passport

[0152] In some embodiments, the digital twin is able to operate as a living digital passport of a corresponding physical asset. The digital passport may take the form of a structured data object associated with a physical asset. In general, the digital passport contains essential information that uniquely identifies a physical asset. The digital passport contains persistent digital identities of physical assets that combine immutable (static) and evolving (dynamic) sections. Digital passports provide three main functions: identity, execution trust, and data secrecy across data at rest, in motion, and in use.

[0153] The digital passport has a static section of passport data that guarantees identity, continuity and origin / history, while a dynamic section of passport data captures the evolving operational, regulatory and verifiable lifecycle traceability of a physical asset overtime.

[0154] The dynamic section stores time-varying operational and lifecycle data of the physical asset, including at least records of performance, maintenance, calibration, orcompliance states. By way of example, the dynamic section of the digital passport may include signed, encrypted, and versioned records such as ownership and custody changes, calibration and maintenance events, regulatory and compliance status, diagnostics, performance metrics, location, and operational state. These records are modular to allow secure extension and evolution throughout the asset’s lifetime.

[0155] The static section stores persistent identity and configuration data of the physical asset, including at least a unique asset identifier and metadata defining the asset’s origin, model, or characteristics. By way of example, the static section of the digital passport may contain the immutable identity established at creation or commissioning, including a unique identifier of a physical asset, digital twin or passport ID, manufacturer and model information, country of origin, production batch, and foundational metadata. This section serves as the cryptographic anchor for trust, verification, and long-term traceability.

[0156] Each device 100 has a hardware-rooted identity embedded during manufacturing, with a device key pair generated and stored inside the hardware. This key is long-lived, rotatable, and never exported, forming the root of trust for secure key execution and management.

[0157] Digital twins I passports are cryptographically bound to this hardware identity. They are multi-signature, self-verifying objects and are executed only within trusted execution environments (secure enclaves) bound to a specific device 100 and execution context. Twin logic, passport updates, and Al-driven decisions are processed exclusively inside secure enclaves or confidential computing runtimes.

[0158] In some embodiments, each digital passport is issued with:• A stable, non-secret identifier stored in the static section (e.g., digital twin ID or passport ID) that preserves identity continuity and traceability overtime. This is described below.• A secret, short-lived, twin-specific temporary cryptographic key scoped to a specific twin and execution session and generated inside the device 100 powering the Al hosted locally on device 100.

[0159] This temporary key is generated by the hardware root of trust. The key never leaves the secure enclave in plaintext, and is usable only within a trusted execution boundary. It may be time-bound or one-time, automatically expires, and / or is securely destroyed. Data isdecrypted only inside the enclave, processed, and re-encrypted, ensuring that no sensitive twin state or logic is exposed outside trusted execution environments.

[0160] The temporary key is used only for current signing and verification and is periodically replaced by the hardware generating a fresh symmetric key. Each key replacement is cryptographically attested by the previous key and, when required, by a trusted authority (manufacturer, operator, or regulator).

[0161] As a result, the digital twin can cryptographically prove which physical asset it represents, which device 100 it is bound to, and whether it has been tampered with. This zerotrust model protects against memory scraping, compromised operating systems, and insider attacks while securing digital twin state in use, passport updates, reasoning engine outputs, control intents, and RL commands, recommendations and decisions.

[0162] The device 100 never exposes long-term secrets or historical keys; continuity is demonstrated exclusively through the latest valid key and its attested transition. As cryptographic standards evolve, including the adoption of post-quantum algorithms, new keys and schemes may be introduced without breaking the digital twin’s identity or passport history, ensuring long-term verifiability, compliance, and trust.

[0163] Federated (or decentralised) machine learning and twin evolution may be performed with encrypted model deltas, secure aggregation, and device-signed updates. Digital twin updates may be versioned, hash-chained, and signed, ensuring full visibility into which twin version was trained how and deployed where. This transforms the digital passport into a verifiable lineage and evolution record.Distributed Standardisation and Orchestration (Propagation / Multiplication)

[0164] In some embodiments, upon completion of a step on a first device — such as a laboratory instrument or a device-on-a-chip (DoC) — the DT normalises the step result into a device-agnostic result package comprising at least: (i) measured values and derived metrics, (ii) associated confidence / quality indicators, and (iii) provenance data including the device identity, protocol step index, and constraint-rule versions applied. The normalised result package is written to the digital passport of the asset and versioned for audit and replay. The DT then compiles a downstream execution ruleset by applying the machine-readable constraint rules to the normalised result package, thereby producing parameterised setpoints, interlocks, and step schedules suitable for a next device in a pipeline. The downstream execution rulesetis digitally signed and distributed to one or more edge devices hosting virtual machines (VMs) associated with respective physical assets.

[0165] Each receiving VM instantiates the downstream execution ruleset by mapping parameterised instructions to local actuation adapters (e.g., RS-485 / Modbus, OPC-UA, MQTT, or on-chip pump / valve interfaces) and begins synchronised execution either (a) upon explicit dependency events emitted by the prior device’s DT (e.g., “Step k completed, parameters {...}”), or (b) at a time-synchronised boundary. During execution, the receiving device operates under closed-loop control with its own DT, which re-standardises local measurements against the applicable constraints, updates its digital passport, and, where the process definition specifies, emits a further normalised result package and subsequent downstream execution recipe to the next device in the chain. This mechanism enables orchestration and multiplication of standardised outcomes across distributed devices, ensuring that each hop operates within tolerance bands while replicating process conditions across heterogeneous assets.Device-on-a-Chip

[0166] Referring now to Figure 6, there is illustrated schematically a device-on-a-chip (DoC) 600. Device 600 operates in a similar manner to device 100 described above but also comprises a number of additional components and functions. In particular, device 600 comprises a number of sensors and actuators mounted to a common integrated circuit 101 so as to be able to perform measurements and sense data. In this regard, device 600 may be referred to as a lab-on-a-chip. Corresponding features of device 100 are given the same reference numerals in device 600.

[0167] Processor 112 of device 600 not only hosts a local digital twin 610 of one or more physical assets, but it also hosts one or more virtual machines 612 to operate the various local components on device 600. Multiple virtual machines may operate on the same device. Processor 112 also operates as one or more microcontrollers for controlling the various components of device 600. In other embodiments, device 600 comprises a plurality of distributed microcontrollers for controlling individual components or subsets of components.

[0168] Device 600 comprises one or more microfluidic chambers 602. Chambers 602 may comprise a sample chamber, a mixing chamber, and a detection chamber. Each chamber may comprise a local microcontroller executing a firmware module (“agent”), which reads chamber sensors, applies policy parameters received from the digital twin 610, adjustsactuators, and sends updated state back to the digital twin 610, which is hosted locally on processor 112. Processor 112 also hosts virtual machines 612, enabling autonomous execution of physical processes (e.g., wet-lab protocols) under standardised conditions.

[0169] Device 600 comprises a plurality of sensors 604 configured to generate measurements of fluid or sample conditions within the microfluidic chambers 602. The sensors 604 may comprise at least one of temperature, pressure, optical absorbance / fluorescence, electrical impedance sensing, or camera-based imaging.

[0170] Integrated cameras such as smart camera 105 monitor the process, perform cell counting, visually recognise features and patterns, and provide data to generate or update the digital twin 610, train a local Al model, perform regulatory monitoring and further analysis into processor 112.

[0171] One or more actuators 606 are housed on integrated circuit 101. These actuators 606 comprise at least one of micropumps or microvalves for controlling the flow of fluid within the microfluidic chambers 602. Virtual machines 612 interpret one or more protocols to generate actuator control signals for actuators 606.

[0172] Digital twin 610 is configured to compare the measurements with a stored standard profile and to adjust the protocol. This enables device 600 to autonomously execute and standardises a wet-lab process on-chip using the sensors and actuators. Processor 112 hosts on-device physical Al (through local microcontrollers) that communicates with and follows the digital twin to control chambers, gates, motors, mixers, and other component operations based on the digital twin’s trained recommendations. Therefore, device 600 is self-correcting, self-driving and self-regulating through persistent updating of the digital twin.

[0173] Agents can reside per chamber to execute digital twin-validated actions (e.g., dosing, flow adjustments, incubation timing) and coordinate across chambers. Modular “cartridge” chambers allow process reconfiguration. Hydrogel matrices may stabilize cells; pathways can direct cells to mixing or detection regions.

[0174] Device 600 may be housed within a protective housing 608. Housing 608 may comprise multiple layers that may comprise a radiation-tolerant layer, a thermal insulation layer and an outer protective layer. In some embodiments, housing 608 comprises a coolant loop for processor heat removal or facilitating microgravity operation.

[0175] The device may have amplifiers for amplifying concentration for quantitative and qualitative analysis.

[0176] In some embodiments, device 600 and its peripherals are provided as a modular cartridge system in which functional modules (e.g., chambers, sensor pods, actuator blocks) are detachably couplable to a common base manifold or backplane. Each module is dimensioned to a standardized mechanical footprint and includes indexed connectors that allow tool-less assembly, reconfiguration, and replacement without recalibrating the entire device.

[0177] In operation, a doctor may send a digital prescription directly to twin (and possibly also the physical asset). The DT then reads, initiates, operates, regulates and reports data to the physical asset for checking and the doctor interprets the patient’s results. This is a multilevel permission communication.

[0178] The above described invention enables physical asset auto-generated digital twins to stream data to auditors. Physical devices that operate based on the digital twin can be auto-audited during and after device operation. The present invention also allows personal digital twin device generation for diagnostics, that can be carried by humans while being monitored by med experts, physical assets and the regulatory.

[0179] The present invention provides a shift toward smarter compliance and greater accessibility will not only address existing inefficiencies but also set the foundation for a more equitable and reliable healthcare system worldwide.INTERPRETATION

[0180] Throughout this specification, the terms “digital twin” (DT) refer to a dynamic, digital representation of a physical asset, system, process, or environment that continuously or repeatedly synchronizes with its physical counterpart in real time or near real time. A digital twin comprises data, models, and logic that emulate the operational behaviour, characteristics, and context of the physical entity throughout its lifecycle. In the context of the present invention, a digital twin may comprise:• Identity and lifecycle data of the physical entity (e.g., specifications, configuration, operational history, maintenance records).• Live or past operational signals obtained from sensors, controllers, or other sources associated with the physical entity.• Machine learning and / or Al components that enable autonomous monitoring, decisionmaking, compliance enforcement, and orchestration of workflows.• Interoperability features for communicating with other digital twins, virtual machines, or external systems via APIs or other protocols.

[0181] A digital twin may function as a digital passport for the physical entity, providing identity assurance, compliance tracking, and lifecycle management. It may reside on edge hardware, in the cloud, or on a device-on-a-chip (DoC), and may operate independently or in coordination with other digital twins to enable distributed, autonomous, and standardised operations.

[0182] Throughout this specification, the terms “Virtual Machine” (VM) refer to a software-based emulation of the operational behaviour, logic, and functional characteristics of a physical asset, instrument, or system. In the context of the present invention, a VM replicates the processes, workflows, and control logic of the corresponding physical entity, enabling the execution of tasks, simulations, and operations in a virtualized environment. A VM may:• Operate as an autonomous software layer that mirrors the physical asset’s operating system, control parameters, and functional states.• Be embedded on edge hardware, such as a device-on-a-chip (DoC), or hosted in a cloud or on-premises environment.• Interface with digital twins (DTs) to provide synchronized, real-time or near real-time orchestration of physical and virtual processes.• Support offline operation, enabling the physical asset or DoC to execute predefined or adaptive tasks without network connectivity.• Include machine learning and Al components for enforcing compliance, optimizing performance, and coordinating workflows across distributed systems.

[0183] In some embodiments, the VM acts as a programmable operating framework for modular hardware (e.g., DoC chambers), interpreting experimental protocols or operational instructions and autonomously enforcing execution conditions.

[0184] Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as"processing," "computing," "calculating," “determining”, analyzing” or the like, refer to the action and / or processes of a computer or computing system, or similar electronic computing device, that manipulate and / or transform data represented as physical, such as electronic, quantities into other data similarly represented as physical quantities.

[0185] In a similar manner, the term “controller” or "processor" may refer to any device, portion of a device or plurality of devices that processes electronic data, e.g., from registers and / or memory to transform that electronic data into other electronic data that, e.g., may be stored in registers and / or memory. A “computer” or a “computing machine” or a "computing platform" may include one or more co-located or distributed processors.

[0186] Reference throughout this specification to “one embodiment”, “some embodiments” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, appearances of the phrases “in one embodiment”, “in some embodiments” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure, in one or more embodiments.

[0187] As used herein, unless otherwise specified the use of the ordinal adjectives "first", "second", "third", etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

[0188] In the claims below and the description herein, any of the terms “comprising”, “comprised of’, “which comprises” or similar are open terms that mean including at least the elements / features that follow, but not excluding others. Thus, the term “comprising” and its variations, when used in the claims or description, should not be interpreted as being limitative to the means or elements or steps listed thereafter. For example, the scope of the expression a device comprising A and B should not be limited to devices consisting only of elements A and B. Similarly, any of the terms “including”, “which includes”, “that includes” or similar as used herein are also open terms that also mean including at least the elements / features that follow the term, but not excluding others. Thus, “including” is synonymous with and means “comprising”.

[0189] It should be appreciated that in the above description of exemplary embodiments of the disclosure, various features of the disclosure are sometimes grouped together in a single embodiment, Fig., or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claims require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this disclosure.

[0190] Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the disclosure, and form different embodiments, as would be understood by those skilled in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0191] In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the disclosure may be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

[0192] Similarly, it is to be noticed that the term coupled, when used in the claims, should not be interpreted as being limited to direct connections only. The terms "coupled" and "connected", along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Thus, the scope of the expression a device A coupled to a device B should not be limited to devices or systems wherein an output of device A is directly connected to an input of device B. It means that there exists a path between an output of A and an input of B which may be a path including other devices or means. "Coupled" may mean that two or more elements are either in direct physical, electrical or optical contact, or that two or more elements are not in direct contact with each other but yet still co-operate or interact with each other.

[0193] Embodiments described herein are intended to cover any adaptations or variations of the present invention. Although the present invention has been described and explained in terms of particular exemplary embodiments, one skilled in the art will realize thatadditional embodiments can be readily envisioned that are within the scope of the present invention.

Claims

What is claimed is:

1. A device for generating a digital twin of a physical asset, the device comprising:an input interface configured to receive operational signals from sensors associated with a connected physical asset;a standards module configured to store machine readable constraints derived from regulatory data about the physical asset, the regulatory data comprising at least one regulatory or operational standard applicable to the physical asset; a processor configured to:generate or update a digital twin model of the physical asset that mimics the behaviour and / or characteristics of the physical asset and complies with relevant regulatory requirements of the physical asset; compute control actions by applying the machine readable constraints to the digital twin model; andan actuation interface configured to transmit the control actions to an input of the physical asset;wherein execution of the control actions constrains at least one operating parameter of the physical asset to remain within a tolerance band specified by the machine-readable constraints.

2. The device according to claim 1 wherein the processor generates or updates the digital twin model through training a machine learning model to learn the behaviour and characteristics of the physical asset based on the operational signals and regulatory data.

3. The device according to claim 1 or claim 2 comprising a communications module configured to communicate with a cloud database and / or other external device / network.

4. The device according to claim 3 wherein the communications module is configured to upload the digital twin model to a processor embedded in the physical asset.

5. The apparatus of any one of the preceding claims wherein the processor is further configured to detect non-compliance of a regulatory or operational standard and totrigger prescriptive corrective control actions comprising at least one of: a halt instruction for the physical asset, a change in state of the physical asset or operator notification.

6. The apparatus of any one of the preceding claims wherein the control actions comprise one or more of motor torque or speed setpoints, temperature setpoints, valve duty cycles, pump flow rates, or electrical drive parameters.

7. The apparatus of any one of the preceding claims wherein the operational signals comprise at least one of vibration signals, acoustic emission, temperature, pressure, current draw, optical intensity, or image frames from a camera.

8. The apparatus of any one of the preceding claims wherein the processor is configured to generate, update or host a virtual machine configured to emulate operational logic of the physical asset.

9. The device according to any one of the preceding claims wherein the digital twin model comprises Al clusters.

10. The device according to any one of the preceding claims wherein the standards module stores ISO, I EC FDA orTGA standards compiled into machine readable constraints.

11. The device according to claim 2 wherein the machine learning model receives the operational signals from the physical asset via one or more websocket APIs associated with the physical asset.

12. The device according to any one of the preceding claims wherein the input interface and / or actuation interface comprises one or more of a USB, HDMI, Ethernet, serial RS232 or RS485 port.

13. The device according to any one of the preceding claims wherein the input interface and / or actuation interface comprises wireless communications comprising one or more of Wi-Fi, Bluetooth, Zigbee, LoRaWAN, LTE, or 5G.

14. The device according to claim 2 wherein the machine learning model comprises one or more agents that are adapted to update the model based on events detected in the operational signals received from the physical asset.

15. The device according to claim 2 wherein the machine learning model comprises a first layer that monitors compliance of the digital twin model with one or more operational standards for the physical asset and, upon detection of a lack of compliance, instructsor permits a second layer to update the digital twin model to comply with the one or more operational standards.

16. The device according to claim 3 wherein the communications module stores a version of the digital twin model in a cloud database or in a wearable or standalone device.

17. The device according to any one of the preceding claims wherein the digital twin comprises a digital passport including:a static section storing persistent identity and configuration data of the physical asset; anda dynamic section storing time-varying operational or lifecycle data including at least performance, maintenance, calibration or compliance state records.

18. The device of claim 17 wherein the digital passport is continuously or intermittently updated in response to operational signals from the physical asset.

19. The device of any one of the preceding claims, further comprising a 3D reconstruction subsystem configured to ingest multimodal inputs comprising image data from one or more cameras and non-image sensor signals indicative of the asset’s operating state.

20. The device of claim 19, wherein the 3D reconstruction subsystem is configured to fuse the multimodal inputs to estimate geometry or pose of the physical asset and to generate a three-dimensional model associated with the digital twin.

21. The device of claim 20, wherein the three-dimensional model is continuously or repeatedly updated based on new sensor or image inputs.

22. The device of any one of the preceding claims, wherein the processor comprises a smart conversion layer configured to ingest regulatory or operational documents and convert them into machine-readable constraints.

23. The device of claim 22, wherein the smart conversion layer applies one or more of text extraction, machine learning or natural-language processing techniques to identify regulatory parameters for the physical asset.

24. The device of any one of the preceding claims, wherein the processor comprises an interoperability layer configured to automatically detect a communication protocol of a newly connected physical asset and retrieve metadata associated with the asset.

25. The device of claim 24, wherein the interoperability layer applies an unsupervised machine-learning model to identify unknown data streams and group them for subsequent classification.

26. The device of any one of the preceding claims, wherein the input interface is configured to receive image or audio data representing gestures or spoken commands, and the processor updates the digital twin based on recognized gestures or events.

27. The device of claim 26, wherein the processor employs one or more convolutional neural networks (CNNs) or temporal models to detect asset-related events or human interactions from image or audio data.

28. The device according to any one of the preceding claims wherein the digital twin generates authenticated execution rules for transmission to virtual machines hosted on two or more edge devices.

29. The device according to any one of the preceding claims wherein the physical asset comprises a personal medical device to be operated by a user.

30. The device according to claim 29 wherein the one or more personal medical devices are wearable devices.

31. The device according to claim 29 wherein the one or more personal medical devices comprise biosensors.

32. The device according to claim 29 wherein the one or more personal medical devices comprise a DNA extractor.

33. The system according to claim 29 wherein the one or more personal devices comprise blood analysis devices.

34. The device according to claim 29 wherein the personal medical devices comprise a processor that is adapted to receive a request from a medical practitioner to operate the personal medical device to extract data about a patient and report that data to the medical practitioner.

35. The device according to any one of the preceding claims in the form of a device-on-a- chip.

36. The device according to any one of claims 1 to 35 in the form of a lab-on-a-chip.

37. The device according to claim 36 wherein the lab-on-a-chip comprises one or more embedded sensors or actuators.

38. The device according to claim 36 wherein the lab-on-a-chip comprises a microfluidic device.

39. The device according to any one of the preceding claims wherein the input interface is configured to receive image data from one or more connected image sensors.

40. A patient device configured to interface with the device according to any one of the preceding claims, the patient device comprising:one or more sensors / actuators for interfacing with a patient or sample to obtain patient or sample data;a controller for operating the one or more sensors for diagnostics according to a digital twin model of a corresponding physical asset;memory for storing the digital twin model; anda communications module for receiving data to generate or update the digital twin model such that the patient device mimics the behaviour and / or characteristics of the physical asset and complies with relevant regulatory requirements of the physical asset.

41. A patient device configured to obtain patient data, the patient device comprising:one or more sensors / actuators for interfacing with a patient to obtain patient data; a controller for operating the one or more sensors according to a digital twin model of a corresponding physical asset;memory for storing the digital twin model; anda communications module for receiving data to generate or update the digital twin model such that the patient device mimics the behaviour and / or characteristics of the physical asset and complies with relevant regulatory requirements of the physical asset.

42. The patient device according to claim 41 wherein the communications module is configured to store and / or download a version of the digital twin on / from a cloud database or into the wearable device.

43. A device-on-a-chip (DoC) comprising:one or more microfluidic chambers;sensors configured to generate measurements of fluid or sample conditions; actuators comprising at least one of micropumps or microvalves;an embedded processor hosting a virtual machine that interprets a protocol to generate actuator control signals; anda digital twin interface configured to compare the measurements with a stored standard profile and to adjust the protocol;wherein the DoC autonomously executes and standardises a wet-lab process on-chip using the sensors and actuators.

44. The DoC of claims 43 wherein the sensors comprise at least one of temperature, pressure, optical absorbance / fluorescence, electrical impedance, or camera-based imaging.

45. The DoC of claim 43 or claim 44 wherein the one or more microfluidic chambers comprise at least a sample chamber, a mixing chamber, and a detection chamber 46. The DoC of any one of claims 43 to 45 comprising a 3D reconstruction subsystem configured to ingest multimodal inputs comprising image data from one or more cameras and non-image sensor signals indicative of the asset’s operating state.

47. The DoC of any one of claims 43 to 46 wherein the 3D reconstruction subsystem reconstructs geometry of the microfluidic chambers or components using multimodal sensor and camera inputs.

48. The DoC of any one of claims 43 to 47 wherein the microfluidic chambers are modular and replaceable as cartridge units for reconfiguration of experimental processes.

49. A method of enforcing compliant operation of a physical asset, the method comprising:receiving sensor signals from the physical asset;forming or updating a digital twin state representing an operating condition of the physical asset;compiling a regulatory or operational standard into machine-executable constraints;computing one or more control setpoints by applying the machine-executable constraints to the digital twin state; andapplying the control setpoints to the physical asset via an actuation interface, thereby maintaining at least one operating parameter of the physical asset within a specified tolerance range.

50. The method of claim 49 wherein compiling an operational standard comprises using a machine learning model trained from historical operational data of the physical asset.

51. A device configured to perform the method of claim 49 or claim 50.

52. The device of claim 51 in the form of a device-on-a-chip having edge computing functionality.

53. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause performance of the method of claim 49 or claim 50.

Images