Digital twin system

Abstract

A method and a graphical programming environment (120) for creating and testing a digital twin of a graphical program module (414). Generating the graphical program module (414) in the graphical programming environment (120) such as an integrated development environment, where the graphical program module (414) includes a first executable portion of code (414a). Building the digital twin of the graphical program module (414) on one or more external host processor devices (170). The digital twin includes a second executable portion of code. Connecting the digital twin to the graphical programming environment (120) and testing the digital twin alongside the graphical program module (414) this may include the digital twin being configured to connect to and communicate with the one or more external host processor devices. The external host processor devices maybe a digital signal processor (DSP) chip.

Description

Technical Field of the Invention The present invention relates to a field of software development environments. More specifically, but without limitation, the present disclosure relates to a method and a graphical programming environment for creating and testing a digital twin of a graphical program module. Background to the Invention In traditional coding practices for external host processor devices like Digital Signal Processor (DSP) chips, the process of coding and the subsequent testing poses significant challenges and consumes a considerable amount of time. One major difficulty lies in the absence of direct feedback mechanisms or user interfaces on the chips themselves. Consequently, developers often resort to using on-chip debuggers to extract values from the chips during testing, a process that can introduce disruptions in timing and potentially influence the values being read. This lack of direct feedback and the need for external tools for monitoring and debugging not only complicates the testing process but also undermines the reliability and accuracy of the test results. As a result, developers face a daunting task of ensuring the proper functioning and performance of the coded functionalities on the external host processor devices, often leading to prolonged development cycles. Additionally, conventional programming Integrated Development Environments (IDEs) often lack the capability to efficiently develop and test graphical program modules that are ultimately executed on external host processor devices (such as DSP chips). The absence of real-time data routing and seamless integration between a graphical programming environment and the external host processor devices hampers the verification process and elongates debugging time. Summary of the Invention The presently disclosed method and graphical programming environment aim to address at least some of the above-mentioned limitations of conventional coding practices and IDEs by providing a seamless workflow for creating and testing digital twins of graphical program modules on external host processor devices. According to a first aspect of the invention, there is provided a method for creating and testing a digital twin of a graphical program module. The method may comprise generating the graphical program module in a graphical programming environment. The graphical program module may comprise a first executable portion of code. The method may comprise building the digital twin of the graphical program module on one or more external host processor devices. The digital twin may comprise a second executable portion of code. The method may comprise connecting the digital twin to the graphical programming environment. The method may comprise testing the digital twin alongside the graphical program module. It will be understood that the method disclosed herein may be used to test any portion of code within one or more external host processor devices alongside the graphical program module (i.e., the portion of code within one or more external host processor devices need not necessarily comprise a digital twin of a graphical program module). The digital twin of the graphical program module may be configured to replicate the behavior of the graphical program module. In other words, the digital twin of graphical program module may be configured to perform the same function as the graphical program module. As such, in some embodiments, the second executable portion of code may be identical to the first executable portion of code. Additionally, the output of the second executable portion of code may be identical to the output of the first executable portion of code. In some embodiments, the second executable portion of code may not be identical to the first executable portion of code, for example, due to an error in the second and / or the first executable portion of code. In this embodiment, the output of the second executable portion of code may not be identical to the output of the first executable portion of code. The error in the second and / or the first executable portion of code may be discoverable during the process of testing the digital twin alongside the graphical program module. In some embodiments, the second executable portion of code may not be identical to the first executable portion of code because the second executable portion of code and the first executable portion of code may be programmed using different languages in different programming environments. However, the second executable portion of code should produce the same output as the first executable portion of code. In some embodiments, the second executable portion of code may not produce the same output as the first executable portion of code, for example, due to an error in the second and / or the first executable portion of code. The error in the second and / or the first executable portion of code may be discoverable during the process of testing the digital twin alongside the graphical program module. The graphical programming environment may comprise a graphical programming Integrated Development Environment (IDE). The IDE may comprise a software tool that provides developers with a centralized platform for creating, testing, executing, and deploying software applications. Advantageously, within the graphical programming IDE, developers may be able to write, edit, interpret, debug, execute, and manage their code efficiently, within a single graphical interface. The disclosed graphical programming IDE may offer a visual environment for the creation of graphical program modules and code blocks. The code blocks may be constructed out of one or more graphical program modules. The code blocks may represent individual functional components and algorithms within the program. The provision of the visual environment within the disclosed graphical programming IDE offers several advantages over traditional text-based IDEs. For example, the visual representation of one or more graphical program modules and code blocks may provide the developers with a more intuitive and accessible means of designing and conceptualizing complex software architectures. By visually depicting program structures and data flows, developers may gain a clearer understanding of the system's logic and behavior, thereby facilitating a more effective problem-solving and debugging processes. Additionally, the utilization of the graphical programming IDE offers significant advantages, particularly in facilitating the incorporation and efficient utilization of external host processor devices. By integrating one or more external host processor devices within the IDE framework, developers gain the capability to execute specific code blocks on a per-module basis, thereby enhancing the modularity and scalability of the software architecture. Furthermore, the graphical programming IDE's functionality allows for routing real-time data through the external host processor devices, optimizing computational efficiency and enabling seamless integration of real-time processing tasks. This approach not only enhances the performance of the software system but also simplifies the development process by providing a unified platform for designing, testing, executing, and deploying software modules across diverse hardware environments. Ultimately, the graphical programming IDE allows developers to leverage the computational resources of external host processor devices effectively, leading to improved system performance, scalability, and flexibility. In addition, the graphical programming IDE facilitates the seamless verification of code integrity and comparison of outputs between the graphical module and its corresponding digital twin during the testing phase. This capability significantly streamlines the development process, allowing developers to ensure the accuracy and reliability of their code with ease. Through the IDE's graphical interface, developers can visually inspect and analyze the behavior of both the graphical module and the digital twin, enabling them to identify any discrepancies or deviations between the expected and actual outputs. Building the digital twin of the graphical program module on the one or more external host processor devices may comprise storing the second executable portion of code on the one or more external host processor devices. More specifically, building the digital twin of the graphical program module on the one or more external host processor devices may comprise storing the second executable portion of code within a memory of the one or more external host processor devices. The method may further comprise generating a second graphical program module in the graphical programming environment, the second graphical program module comprising a fourth executable portion of code. The method may further comprise building a second digital twin of the second graphical program module on one or more external host processor devices. The second digital twin may comprise a fifth executable portion of code. The method may further comprise connecting the second digital twin to the graphical programming environment. The method may further comprise testing the second digital twin alongside the second graphical program module. The second digital twin of the second graphical program module may be configured to replicate the behavior of the second graphical program module. As such, the fourth executable portion of code may be identical to the fifth executable portion of code. Additionally, the output of the fourth executable portion of code may be identical to the output of the fifth executable portion of code. In some embodiments, the fourth executable portion of code may not be identical to the fifth executable portion of code, for example, due to an error in the fourth and / or the fifth executable portion of code. In this embodiment, the output of the fourth executable portion of code may not be identical to the output of the fifth executable portion of code. The error in the fourth and / or the fifth executable portion of code may be discoverable during the process of testing the second digital twin alongside the second graphical program module. The fourth and fifth executable portions of code may be different than the first and second executable portions of code. The skilled person would recognise that the disclosed method may comprise generating any number of graphical program modules within the graphical programming environment. Additionally, the skilled person would recognise that the method may comprise building any number of digital twins of the respective graphical program modules on one or more external host processor devices and subsequently testing these digital twins alongside their respective graphical program modules. This modular approach to building and testing the graphical program modules offers several advantages that significantly enhance the development process. By breaking down the software functionality into discrete modules, developers can adopt a more structured and organized approach to software design, promoting code reusability, maintainability, and scalability. Additionally, this modular architecture enables developers to isolate individual graphical program modules, facilitating easier debugging and troubleshooting processes. If an error occurs within a specific graphical program module or its digital twin, developers can focus on modifying and verifying only the affected module, without needing to navigate through the entire codebase. This targeted approach minimizes the scope of modifications and reduces the risk of unintended side effects, thereby streamlining the development workflow and accelerating the resolution of issues. In some embodiments, a single external host processor device may comprise more than one digital twin. For example, a single external host processor device may comprise the digital twin of the graphical program module and the second digital twin of the second graphical program module. As such, in some embodiments, the method may comprise building the digital twin of the graphical program module and the second digital twin of the second graphical program module on a single external host processor device and subsequently testing both the digital twin alongside the graphical program module and the second digital twin alongside the second graphical program module. Connecting the digital twin to the graphical programming environment may comprise generating a digital twin module in the graphical programming environment. The digital twin module may be configured to connect to the one or more external host processor devices. The digital twin module may be configured to communicate with the one or more external host processor devices. More specifically, the digital twin module may be configured to relay data between the graphical programming environment and the one or more external host processor devices. Similarly, connecting the second digital twin to the graphical programming environment may comprise generating a second digital twin module in the graphical programming environment. The second digital twin module may be configured to connect to the one or more external host processor devices. The second digital twin module may be configured to communicate with the one or more external host processor devices. More specifically, the second digital twin module may be configured to relay data between the graphical programming environment and the one or more external host processor devices. The graphical program module, the second graphical program module, any code blocks, the digital twin module and / or the second digital twin module may each have a graphical representation within the graphical programming environment. The graphical programming environment may further comprise one or more links between the graphical representations of the graphical program module, the second graphical program module, any code blocks, the digital twin module and / or the second digital twin module. The one or more links may visually represent flow of data between the respective code blocks and / or modules. Advantageously, this visual representation of the various components and data flows between the respective components makes it easier for the developers to understand the program architecture. This in turn makes it easier for the developers to test the digital twin and / or the second digital twin alongside the graphical program module and / or the second graphical program module, respectively. The digital twin module and / or the second digital twin module may be configured to communicate with the one or more external host processor devices using a User Datagram Protocol (UDP). The UDP connection may facilitate data transfer between the digital twin module and / or the second digital twin module and the one or more external host processor devices. In other words, the UDP connection may facilitate data transfer between the graphical programming environment and the one or more external host processor devices. Unlike other transport protocols such as Transmission Control Protocol (TCP), UDP is connectionless and does not establish a direct communication channel between sender and receiver before data transmission. Instead, UDP simply encapsulates data into datagrams and sends them to the destination without prior negotiation or acknowledgment. This lightweight nature of UDP makes it well-suited for applications that prioritize speed and efficiency, as it minimizes overheads associated with establishing and maintaining connections. The use of the UDP connections between the digital twin modules and the one or more external host processor devices holds particular advantages in the context of the autonomous vehicle space, where real-time communication and rapid data transmission are paramount. The digital twin module may comprise one or more connection parameters. The one or more connection parameters may be configured to identify a specific external host processor device of the one or more external host processor devices within a network. The one or more connection parameters may comprise an IP address. The one or more connection parameters may comprise a port parameter. In some embodiments, the digital twin module may be configured to connect to, and communicate with, a first external host processor device. Similarly, the second digital twin module may be configured to connect to, and communicate with, a second external host processor device. In this embodiment, the digital twin module may comprise one or more first connection parameters. For example, the one or more first connection parameters may comprise a first IP address and a first port parameter. The one or more first connection parameters may be configured to identify the first external host processor device within the network. Additionally, the second digital twin module may comprise one or more second connection parameters. For example, the one or more second connection parameters may comprise a second IP address and a second port parameter. The one or more second connection parameters may be configured to identify the second external host processor device within the network. In some embodiments, the digital twin module may be configured to connect to, and communicate with, a plurality of external host processor devices. For example, the digital twin module may be configured to connect to, and communicate with, both the first external processor device and the second external processor device. In this embodiment, the digital twin module may comprise both one or more first connection parameters configured to identify the first external host processor device and one or more second connection parameters configured to identify the second external host processor device. In some embodiments, the first external processor device may comprise a master device and the second external processor device may comprise a subordinate or follower device. In this embodiment, only the master device may be configured to connect to and communicate with the digital twin module. The subordinate or follower device may be configured to communicate with the digital twin module via the master device. In other words, the subordinate or follower device may be configured to indirectly communicate with the digital twin module via the master device. Testing the digital twin alongside the graphical program module may comprise executing both the first executable portion of code and the second executable portion of code. Testing the digital twin alongside the graphical program module may comprise comparing the output of the first executable portion of code with the output of the second executable portion of code to verify parity between the digital twin and the graphical program module. More specifically, testing the digital twin alongside the graphical program module may comprise ensuring that the output of the first executable portion of code is identical to the output of the second executable portion of code. Testing the second digital twin alongside the second graphical program module may comprise executing both the fourth executable portion of code and the fifth executable portion of code. Testing the second digital twin alongside the second graphical program module may comprise comparing the output of the fourth executable portion of code with the output of the fifth executable portion of code to verify parity between the second digital twin and the second graphical program module. More specifically, testing the second digital twin alongside the second graphical program module may comprise ensuring that the output of the fourth executable portion of code is identical to the output of the fifth executable portion of code. The methods and the graphical programming environment described herein offer developers a comprehensive framework for testing the digital twin and / or the second digital twin alongside the graphical program module and / or the second graphical program module. This functionality enables the rapid identification and resolution of errors and discrepancies on a module-by-module basis, a crucial aspect of the debugging process. By isolating and addressing issues at the individual module level, developers may conduct focused analysis and modifications, thereby enhancing the precision and effectiveness of their debugging process. This targeted approach facilitates the systematic refinement of program components, ensuring optimal performance and functionality. Additionally, the seamless integration of digital twin and / or the second digital twin testing within the graphical programming environment enables developers to validate code modifications promptly, fostering continuous improvements throughout the software development lifecycle. By executing both the portions of code within the graphical program module and the digital twin simultaneously, the developers can quickly and readily see any discrepancies between their respective outputs. The digital twin module may comprise a first switch. The first switch may be configured to selectively connect or disconnect the digital twin from the graphical programming environment. The first switch may be configured to selectively connect or disconnect the one or more external host processor devices from the digital twin module within the graphical programming environment. More specifically, when the first switch is “on” a connection (e.g. a UDP connection) may be formed between the digital twin module and the one or more external host processor devices. In the “on” position the graphical programming environment may be configured to instruct the one or more external host processor devices to execute the second executable portion of code. Subsequently, in the “on” position the graphical programming environment may be configured to receive an output of the second executable portion of code from the one or more external host processor devices. When the switch is “off’ a connection (e.g., a UDP connection) may not be formed between the digital twin module and the one or more external host processor devices. Alternatively, when the switch is “off’ an existing connection (e.g., a UDP connection) between the digital twin module and the one or more external processing devices may be disbanded. In the “off’ position the graphical programming environment may not be configured to instruct the one or more external host processor devices to execute the second executable portion of code. The second digital twin module may comprise a third switch. The third switch may be configured to selectively connect or disconnect the second digital twin from the graphical programming environment. The third switch may be configured to selectively connect or disconnect the one or more external host processor devices from the second digital twin module within the graphical programming environment. More specifically, when the third switch is “on” a connection (e.g. a UDP connection) may be formed between the second digital twin module and the one or more external host processor devices. In the “on” position the graphical programming environment may be configured to instruct the one or more external host processor devices to execute the fifth executable portion of code. Subsequently, in the “on” position the graphical programming environment may be configured to receive an output of the fifth executable portion of code from the one or more external host processor devices. When the switch is “off’ a connection (e.g., a UDP connection) may not be formed between the second digital twin module and the one or more external host processor devices. Alternatively, when the switch is “off’ an existing connection (e.g., a UDP connection) between the second digital twin module and the one or more external processing devices may be disbanded. In the “off’ position the graphical programming environment may not be configured to instruct the one or more external host processor devices to execute the fifth executable portion of code. The graphical program module may comprise a second switch. The second switch may be configured to selectively enable or disable the execution of the first executable portion of code within the graphical programming environment. The second switch may be configured to connect or disconnect the graphical program module from the graphical programming environment. When the second switch is in the “on” position, the graphical programming environment may be configured to execute the first executable portion of code within the graphical program module. When the second switch is in the “off’ position, the graphical programming environment may be configured to not execute the first executable portion of code within the graphical program module. The second graphical program module may comprise a fourth switch. The fourth switch may be configured to selectively enable or disable the execution of the fourth executable portion of code within the graphical programming environment. The fourth switch may be configured to connect or disconnect the second graphical program module from the graphical programming environment. When the fourth switch is in the “on” position, the graphical programming environment may be configured to execute the fourth executable portion of code within the second graphical program module. When the fourth switch is in the “off” position, the graphical programming environment may be configured to not execute the fourth executable portion of code within the second graphical program module. Testing the digital twin alongside the graphical program module may comprise switching off the first switch to disconnect the digital twin from the graphical programming environment. Testing the digital twin alongside the graphical program module may further comprise executing the first executable portion of code within the graphical program module (i.e., only executing the portion of code within the graphical program module). In this testing scenario, the first switch may be in the “off” position and the second switch may be in the “on” position. Testing the second digital twin alongside the second graphical program module may comprise switching off the third switch to disconnect the second digital twin from the graphical programming environment. Testing the second digital twin alongside the graphical program module may further comprise executing the fourth executable portion of code within the second graphical program module (i.e., only executing the portion of code within the second graphical program module). In this testing scenario, the third switch may be in the “off” position and the fourth switch may be in the “on” position. In some embodiments, testing the digital twin alongside the graphical program module may comprise switching off the second switch to disable the execution of the first executable portion of code within the graphical programming environment. Testing the digital twin alongside the graphical program module may further comprise executing the second executable portion of code within the digital twin. In this testing scenario, the first switch is in the “on” position and the second switch is in the “off’ position. In some embodiments, testing the second digital twin alongside the second graphical program module may comprise switching off the fourth switch to disable the execution of the fourth executable portion of code within the graphical programming environment. Testing the second digital twin alongside the second graphical program module may further comprise executing the fifth executable portion of code within the second digital twin. In this testing scenario, the fifth switch is in the “on” position and the fourth switch is in the “off’ position. The disclosed method and graphical programming environment offer developers the capability to selectively transition between executing the code within the graphical program modules and their corresponding digital twins, represented as digital twin modules within the graphical programming environment. This functionality provides a significant advantage in software development, enabling developers to independently verify each module. By seamlessly transitioning between graphical modules and digital twins, developers can accurately test and debug individual components, thereby reducing the complexity and duration of the debugging process. Testing the digital twin alongside the graphical program module may comprise modifying the first executable portion of code into a third executable portion of code. Modifying the first executable portion of code into a third executable portion of code may comprise changing or altering the first executable portion of code into a third executable portion of code. Testing the digital twin alongside the graphical program module may further comprise comparing outputs of the third executable portion and the second executable portion of code. For example, the testing process may involve switching “on” the digital twin module and switching “off’ the modified graphical program module (which now comprises the third executable portion of code). Additionally, or alternatively, the testing process may involve switching “off’ the digital twin module and switching “on” the modified graphical program module (which now comprises the third executable portion of code). The third executable portion of code may be different than the first executable portion of code and the second executable portion of code. Advantageously, following the verification of the digital twin alongside the graphical program module, the graphical programming environment enables swift modifications to the graphical program module. This agility in code modification is facilitated by the ability to iterate and refine the code on a module-by-module basis. As a result, the modified version of the code (i.e., the third executable portion of code) can be tailored to be more efficient and effective than the original first executable portion of code. The graphical programming environment provides a platform for enhancing the code's performance and functionality incrementally, ensuring that improvements are made iteratively and systematically. Additionally, the environment allows developers to seamlessly switch between the modified graphical program module and the non-modified digital twin module, facilitating ease of reference and comparison during the development process. This iterative approach to code refinement, coupled with the flexibility to switch between code versions, fosters a dynamic and efficient development workflow, ultimately leading to the creation of optimized and robust software solutions. The method for creating and testing a digital twin of a graphical program module may further comprise building a third digital twin on one or more external host processor devices. The third digital twin may comprise the third executable portion of code. The method for creating and testing a digital twin of a graphical program module may further comprise connecting the third digital twin to the graphical programming environment. In some embodiments, the method for creating and testing a digital twin of a graphical program module may further comprise replacing the graphical program module with the digital twin after testing the digital twin alongside the graphical program module. In one embodiment, the method for creating and testing a digital twin of a graphical program module may further comprise replacing the second graphical program module with the second digital twin after testing the second digital twin alongside the second graphical program module. In one embodiment, the method for creating and testing a digital twin of a graphical program module may further comprise replacing the graphical program module with the third digital twin after testing the third digital twin alongside the graphical program module. The method for creating and testing a digital twin of a graphical program module presents a significant advantage by facilitating the replacement of the graphical program module with the digital twin after testing. This strategic transition effectively transfers processing tasks to independent hardware, such as one or more external host processor devices, thereby enhancing computational efficiency. By executing the digital twin on dedicated external hardware, the computational workload is offloaded from the primary system (i.e., the graphical programming environment), thereby alleviating processing bottlenecks and optimizing resource utilization. This distributed computing approach not only improves the overall performance and responsiveness of the system but also enhances scalability, allowing for the efficient allocation of computational resources based on workload demands. Consequently, by leveraging independent hardware for executing the digital twins, the method enhances computational efficiency, enabling the development of high-performance software solutions capable of meeting the demands of modem computing environments. The one or more external host processor devices may comprise one or more Digital Signal Processor (DSP) chips. The skilled person would recognise that other microprocessor chips may be used as the one or more external host processor devices. For example, the one or more external host processor devices may comprise one or more of: microcontrollers and / or field-programmable gate arrays (FPGAs). DSP chips are specifically designed to efficiently process digital signals in realtime, making them well-suited for applications requiring rapid computation and response times. In the context of autonomous vehicles, where split-second decisionmaking is crucial for ensuring safe and reliable operation, the high-speed processing capabilities of DSP chips are especially valuable. These chips excel at handling the complex algorithms and computations required for tasks such as sensor fusion, object detection, and trajectory planning, thereby enabling autonomous vehicles to navigate dynamic environments with precision and agility. FPGAs comprise similar advantages as DSP chips. The graphical programming environment may comprise an interpreter. The graphical programming environment may comprise a single interpreter. The single interpreter may be configured to execute all portions of code within the graphical programming environment. For example, the single interpreter may be configured to execute the first executable portion of code within the graphical program module and / or the fourth executable portion of code within the second graphical program module and / or the third executable portion of code within the graphical program module. The single interpreter may be configured to execute any portions of code within the digital twin module, the second digital twin module and / or the third digital twin module. For example, the single interpreter may be configured to cause the digital twin module, the second digital twin module and / or the third digital twin module to connect to and communicate with the one or more external host processor devices. The single interpreter may be configured to send instructions to (or cause the respective digital twin modules to send instructions to) the one or more external host processor devices (which store the digital twin, the second digital twin and / or the third digital twin) to execute their respective portions of code. The use of a plurality of distinct modules (e.g., the graphical program module and the digital twin module) and a single interpreter within the graphical programming environment has a synergistic effect of improving the programming scalability, computational efficiency, ease of debugging, programming flexibility as well as the software safety integrity. The single interpreter acts as a central hub that seamlessly integrates all of the distinct graphical program modules within the graphical programming environment. As a result, developers can combine various modules effortlessly, leading to the creation of a highly scalable and easily understandable object-oriented development environment. Additionally, any data, variables and definitions are shared between the distinct graphical program modules within the single graphical programming environment. In this manner, the developers do not need to continuously re-define or specify any data, variables and / or definitions between each individual graphical program module. This significantly improves the programming efficiency, leading to a more rapid code development. In order to share any data, variables and / or definitions, the distinct modules do not require any data flow between each other and may be placed anywhere within the graphical programming environment. The removal of the need to transfer data between the distinct modules substantially improves the computational efficiency of the program generated within the graphical programming environment. Additionally, the implementation of a single interpreter architecture in the graphical programming environment presents a crucial advantage for developers, particularly in the realm of real-time applications. For example, using the single code inteipreter in the autonomous vehicle space offers several significant advantages. Firstly, it enables real-time code modification processing, allowing developers to make on-the-fly adjustments to the vehicle's behaviour and algorithms without the need for the time-consuming recompilation. This capability is invaluable when dealing with dynamic environments, as it promotes quick adaptation to changing conditions. Additionally, the code interpreter simplifies the debugging process in the field, making it easier to identify and rectify issues during the testing and deployment phases. This streamlined debugging process not only saves time but also enhances safety and reliability of the autonomous vehicles. Ultimately, the use of a single code interpreter with a plurality of distinct graphical program modules facilitates seamless code modification and debugging which may be executed and directly tested in the field, ultimately reducing development time. The graphical programming environment may be configured to receive input data from an external hardware. The graphical programming environment may be configured to enter the input data into the graphical program module and / or the digital twin module. The graphical programming environment may be configured to execute the first executable portion of code and / or cause the execution of the second executable portion of code to generate output data. In some embodiments, the graphical programming environment may be configured to transmit the output data to the external hardware. The graphical programming environment may be configured to cause the execution of the second executable portion of code by instructing the digital twin module to connect to the one or more external host processor devices. The graphical programming environment may be configured to cause the execution of the second executable portion of code by instructing the digital twin module to send one or more signals to the one or more external host processor devices, the one or more signals instructing the one or more external host processor devices to execute the second executable portion of code. The execution of the second executable portion of code may yield output data. The digital twin, stored on the one or more external host processor devices, may be configured to transmit the output data to the digital twin module within the graphical programming environment. Subsequently, the graphical programming environment may be configured to transmit the output data to the external hardware. The external hardware may comprise a robot. The external hardware may comprise a vehicle. In some embodiments, the external hardware may comprise an autonomous vehicle. In some embodiments, the external hardware may comprise a semi-autonomous vehicle. In some embodiments, the external hardware may comprise an autonomous airport dolly. The autonomous airport dolly may comprise a groundhandling equipment configured to move baggage and cargo to and from aircraft. Autonomous airport dollies offer multiple advantages in modern aviation logistics. They significantly enhance efficiency by operating around the clock, optimizing routes, and reducing manual labour requirements. Additionally, safety is improved by incorporating advanced sensors which ensure that the airport dollies avoid any encountered obstacles. The input data may comprise sensor data from the external hardware. The input data may comprise sensor data from the robot or the autonomous vehicle. The input data may comprise sensor data from the autonomous airport dolly. The input data may comprise one or more of: Li DAR sensor data, RADAR data, GPS data, visual data from one or more cameras, vehicle acceleration data, vehicle orientation data, angular velocity data, ultrasonic sensor data, vehicle steering data, vehicle breaking data, odometry data, weather sensor data, infrared sensor data, barometric pressure sensor data, ground penetrating radar (GPR) sensor data and / or microphone or sound sensor data. The output data may comprise control signals for controlling the external hardware. The output data may comprise control signals for controlling the robot or the autonomous vehicle. The output data may comprise control signals for controlling the autonomous airport dolly. The output data may comprise one or more of: steering control signals, throttle control signals, brake control signals, gear, or transmission control signals, turn or indicator signals, horn signals, emergency brake signals, cruise control signals, parking or docking signals, adaptive driving mode signals and / or climate control signals. One or more of these control signals may be used to control the behaviour of the external hardware (e.g., the autonomous vehicle). While a limited number of examples have been provided in this disclosure for the input sensor data and the output control signals in the context of autonomous vehicles, it should be understood that numerous other sensor data inputs and control signals are conceivable and would be readily recognized by a person skilled in the art. Various sensors and control mechanisms may be adapted, integrated, or substituted as necessary to meet specific design requirements, functional objectives, or evolving technological advancements. The disclosed examples are intended to be illustrative rather than exhaustive. According to a further aspect of the invention, there is provided a graphical programming environment for creating and testing a digital twin of a graphical program module. The digital twin may be built on one or more separate host processor devices. The graphical programming environment may comprise at least one graphical program module. The graphical program module may comprise a first executable portion of code. The graphical programming environment may comprise means for connecting the digital twin to the graphical programming environment. The digital twin may comprise a second executable portion of code. The graphical programming environment may comprise means for testing the digital twin alongside the graphical program module. The means for connecting the digital twin to the graphical programming environment may comprise a digital twin module. The digital twin module may be configured to connect to the one or more external host processor devices. The digital twin module may be configured to communicate with the one or more external host processor devices. The means for testing the digital twin alongside the graphical program module may comprise a first switch on the digital twin module. The first switch may be configured to selectively connect or disconnect the digital twin from the graphical programming environment. The means for testing the digital twin alongside the graphical program module may comprise a second switch on the graphical program module. The second switch may be configured to selectively enable or disable the execution of the first executable portion of code within the graphical programming environment. According to a further aspect of the invention, there is provided a method of testing an external hardware. The external hardware may comprise one or more external host processor devices. The one or more external host processor devices may store at least one digital twin. The digital twin may comprise a second executable portion of code. The method of testing the external hardware may comprise sending input data from the external hardware to a graphical programming environment. The graphical programming environment may comprise a graphical program module. The graphical program module may comprise a first executable portion of code. The method of testing the external hardware may comprise receiving, by the external hardware, instructions from the graphical programming environment to execute the second executable portion of code. The method of testing the external hardware may comprise entering, by the external hardware, the input data into the digital twin. The method of testing the external hardware may comprise executing, by the external hardware, the second executable portion of code to generate a first testing output data. The method of testing the external hardware may comprise transmitting, by the external hardware, the first testing output data to the graphical programming environment. The method may further comprise the graphical programming environment executing the first executable portion of code to generate the second testing output data. The method may further comprise the graphical programming environment comparing the first testing output data to the second testing output data. The method may further comprise the graphical programming environment determining whether the first testing output data is identical to the second testing output data. In this manner, the graphical programming environment may ensure that the one or more external host processor devices (which store the digital twin) connected to the external hardware (e.g., connected to a computer of the external hardware) produce the same output as the graphical program module within the graphical programming environment. According to a further aspect of the invention, there is provided an external hardware. The external hardware may comprise a data processing apparatus comprising means for carrying out a method in accordance with the present disclosure. A further aspect of the disclosure provides a computer program comprising instructions which, when the program is executed by a computer, cause the computer to perform any of the methods disclosed herein. A further aspect of the disclosure provides a computer-readable medium comprising instructions that, when executed by one or more processors, cause an apparatus comprising the one or more processors to perform any of the methods disclosed herein. The skilled person will appreciate that except where mutually exclusive, a feature described in relation to any one of the aspects, methods, examples or embodiments described herein may be applied to any other method, aspect, example, embodiment or feature. Further, the description of any aspect, method, example or feature may form part of or the entirety of an embodiment of the invention as defined by the claims. Any of the examples described herein may be an example which embodies the invention defined by the claims and thus an embodiment of the invention. Detailed Description of the Invention In order that the invention may be more clearly understood one or more embodiments thereof will now be described, by way of example only, with reference to the accompanying drawings, of which: Figure 1 is a schematic diagram of a system for creating and testing a digital twin of a graphical program module. Figure 2 is a schematic diagram of the vehicle shown in Figure 1. Figure 3 is a schematic diagram of the computer shown in Figure 1. Figure 4a is a schematic diagram of the graphical programming environment shown in Figure 1. Figure 4b is an enlarged section of the graphical programming environment shown in Figure 4a. Figure 5 is a schematic diagram of a graphical program module and a digital twin module. Figure 6 is a schematic diagram of the digital twin module shown in Figure 5 communicating with the DSP chip shown in Figure 1. Figure 7 is a flow diagram of a method of creating and testing a digital twin of a graphical program module. Figure 8 is a flow diagram of a method of testing an external hardware, the external hardware comprising one or more DSP chips. Figure 1 is a schematic diagram of an example of a system 100 for creating and testing a digital twin of a graphical program module within a first code block 150. The system 100 includes an external hardware in the form of an autonomous vehicle 102, a computer 106 comprising a graphical programming environment 120 and an external host processor device 170 in a form of a DSP chip. In the subsequent description, the terms “external host processor device” and “DSP chip” will be used interchangeably. The autonomous vehicle 102 may be configured to communicate with the computer 106 using a first communication interface 105. The autonomous vehicle 102 may be configured to send input data to the computer 106 using a first input communication link 116. Additionally, the autonomous vehicle 102 may be configured to receive output data from the computer 106 using a first output communication link 118. In one embodiment, the first communication interface 105 may comprise a wireless communication interface. The first input communication link 116 and the first output communication link 118 may be managed by a network. The network may comprise any form of wireless communication network. For example, the network may comprise a wide-area network communication link. The wide-area network communication link may comprise a cellular telephone network, a Wi-Fi network or a combination thereof. The first input communication link 116 and the first output communication link 118 may form a wireless connection between autonomous vehicle 102 and the computer 106. Additionally or alternatively, the first communication interface 105 may comprise a wired connection. In this embodiment, the first input communication link 116 and first output communication link 118 may comprise a physical cable or wire. For example, this wired connection 105 may comprise coaxial cables or fiber-optic cables. The wired connection offers a reliable and secure data transfer connection. The computer 106 may be configured to communicate with the DSP chip 170 using a second communication interface 166. The computer 106 may be configured to send data to the DSP chip 170 using a second input communication link 164. Additionally, the computer 106 may be configured to receive data from the DSP chip 170 using a second output communication link 162. In one embodiment, the second communication interface 166 may comprise a wireless communication interface. The second input communication link 164 and the second output communication link 162 may be managed by a network. The network may comprise any form of wireless communication network. For example, the network may comprise a wide-area network communication link. The wide-area network communication link may comprise a cellular telephone network, a Wi-Fi network or a combination thereof. The second input communication link 164 and the second output communication link 162 may form a wireless connection between computer 106 and the DSP chip 170. Additionally or alternatively, the second communication interface 166 may comprise a wired connection. In this embodiment, the second input communication link 164 and second output communication link 162 may comprise a physical cable or wire. For example, this wired connection 166 may comprise coaxial cables or fiber-optic cables. The wired connection offers a reliable and secure data transfer connection. Although the vehicle 102 and the DSP chip 170 are portrayed as separate entities in Figure 1, it will be understood that in some embodiments the DSP chip 170 may be connected to, or incorporated into, the vehicle 102. This scenario will be described in more detail with reference to Figure 2. The autonomous vehicle 102 comprises a storage area 138 for receiving baggage or cargo, a steering control system 130, a wheel and suspension control system 132 and a plurality of sensors. The plurality of sensors may include a camera system 124, a LiDAR sensor 122, a RADAR sensor 128, a GPS receiver 126, an ultrasound sensor 134 and an infrared sensor 136. In some embodiments some of the above-mentioned sensors may be omitted or additional sensors may be added as needed. The input data transmitted from the vehicle 102 to the computer 106 may comprise sensor data. For example, the input data may comprise one or more of: LiDAR sensor data, RADAR data, GPS data, visual data from one or more cameras, vehicle acceleration data, vehicle orientation data, angular velocity data, ultrasonic sensor data, vehicle steering data, vehicle breaking data, odometry data, and / or infrared sensor data. Although certain aspects of the invention are particularly useful in connection with specific types of vehicles (i.e., an autonomous airport dolly vehicle), autonomous vehicle 102 may comprise any type of vehicle. Possible vehicles include, by way of example only, cars, trucks, motorcycles, busses, boats, airplanes, helicopters, lawnmowers, recreational vehicles, amusement park vehicles, trams, golf carts, trains and trolleys. In this specific embodiment, the autonomous vehicle 102 is visually represented as an autonomous airport dolly. Other forms of external hardware may be controlled and / or tested using the graphical programming environment 120 in accordance with the methods disclosed herein. For example, in some alternative embodiments, the system 100 may comprise a robot, a smart appliance and / or industrial machinery. The computer 106 comprises the graphical programming environment 120. The graphical programming environment 120 the first code block, a second code block 152 and a digital twin module 160. The first code block 150 comprises one or more graphical program modules, each having an executable portion of code. The second code block 152 comprises one or more graphical program modules, each having a different executable portion of code. The structure of the code blocks 150, 152 will be described in more detail with reference to Figures 4a, 4b and 5. The digital twin module 160 is configured to connect to the DSP chip 170. Additionally, the digital twin module 160 is configured to communicate with the DSP chip 170 using the second communication interface 166. More specifically, the digital twin module 160 is configured to relay data between the graphical programming environment 120 and the DSP chip 170. The digital twin module 160 is configured to communicate with the DSP chip 170 using a User Datagram Protocol (UDP) as will be described in more detail with reference to Figure 6. The graphical programming environment 120 further comprises a single interpreter 154. The single interpreter 154 is configured to execute each portion of code contained within the graphical programming environment 120. The single interpreter 154 may be configured to execute any portions of code within the digital twin module 160. For example, the single interpreter 154 may be configured to cause the digital twin module 160 to connect to, and communicate with, the DSP chip 170. The single interpreter 154 may be configured to cause the digital twin module 160 to send instructions to the DSP chip 170 to execute any code stored within the DSP chip and send back any outputs back to the digital twin module. This process will be described in more detail with reference to Figure 6. Advantageously, the single inteipreter 154 acts as a central hub that seamlessly integrates the code blocks 150 and 152 as well as the digital twin module 160 within the graphical programming environment 120. As a result, developers can combine various code blocks and modules effortlessly, leading to the creation of a highly scalable and easily understandable object-oriented development environment. Additionally, the implementation of interpreted code (within the code blocks 150 and 152 as well as the digital twin module 160) in the graphical programming environment 120 presents a crucial advantage for developers, particularly in the realm of real-time applications. Interpreted code allows for on-the-fly coding without the need for traditional compilation, leading to significant benefits during development, testing, and deployment phases. Executing some or each portion of code contained within the code blocks 150 and 152 as well as the digital twin module 160 generates output data. The output data may be transmitted from the computer 106 to the vehicle 102 using the first output communication link 118. The output data may comprise control signals for controlling the autonomous vehicle 102. For example, the output data may comprise one or more of: steering control signals, throttle control signals, brake control signals, gear or transmission control signals, turn or indicator signals, horn signals, emergency brake signals, cruise control signals, parking or docking signals, adaptive driving mode signals and / or climate control signals. As such, a developer may develop code within the graphical programming environment 120, which is configured to: receive input data from the autonomous vehicle 102, enter the input data into one or more of code blocks 150, 152 and / or the digital twin module 160, execute each portion of code contained within the code blocks 150, 152 and / or the digital twin module 160 to generate output data using the single interpreter 154 and transmit the output data to the autonomous vehicle 102. Although portrayed as a desktop computer in Figure 1 for the sake of simplicity, the computer 106 may be any suitable type of computing device, such as a smartphone, a tablet, laptop computer, or a wearable device (e.g., a VR headset). The computer 106 may be portable or stationary. In some embodiments, the computer 106 may be integrated into (e.g., form a part of) the autonomous vehicle 102. The DSP chip 170 comprises a digital twin of a graphical program module (shown in Figure 4b) of the first code block 150. The digital twin is built on the DSP chip 170 and comprises a second executable portion of code. The operation and functionality of the autonomous vehicle 102, the computer 106, the graphical programming environment 120, and the DSP chip 170 will be further described with reference to the following Figures. Figure 2 shows a schematic diagram of the vehicle 102 shown in Figure 1. More specifically, Figure 2 shows a schematic diagram of the various components within the vehicle 102. The autonomous vehicle 102 includes a vehicle computer system 200 that is in communication with sensors 214 and vehicle control systems 230. The vehicle computer system 200 may comprise a computer containing a processor 210, a memory 202, a communication system 212 and optionally the DSP chip 170. The vehicle computer system 200 may additionally comprise other components (not shown for the sake of simplicity) typically present in general purpose computers. In one embodiment, the DSP chip 170 may be connected to the vehicle computer 200 via a network cable or via a wireless network (e.g., Wi-Fi). The memory 202 may comprise an operating system (OS) 204, a sensor data memory module 206 and a database 208. The operating system (OS) 204 serves as the core software that manages and controls the computer's 200 hardware and software resources. It facilitates various tasks such as process management, memory allocation, file system operations, and device management. The sensor data memory module 206 may be configured to store information related to historical sensor data. The historical sensor data may be used for future vehicle training or for testing and evaluation purposes. The database 208 may comprise any other data which is stored in the memory 202 of the autonomous vehicle 102. The memory 202 stores information accessible by processor 210, including instructions and data that may be executed or otherwise used by the processor 210. The memory 202 includes processor-executable instructions that, when executed by the processor 210, cause the computer vehicle computer 200 to perform, or assist in performing, any of the methods described with reference to Figures 7 and 8. The memory 202 may be of any type capable of storing information accessible by the processor 210, including a computer-readable medium, or other medium that stores data that may be read with the aid of an electronic device, such as a hard-drive, memory card, ROM, RAM, DVD or other optical disks, as well as other write-capable and read-only memories. Systems and methods may include different combinations of the foregoing, whereby different portions of the instructions and data are stored on different types of media. The processor 210 may be any conventional processor, such as a microprocessor or a microcontroller. Alternatively, the processor may be a dedicated device such as an ASIC. Although Figure 2 functionally illustrates the processor, memory, the DSP chip 170 and the communication system 212 as being within the same block, it will be understood by the person skilled in the art that the processor and memory and / or DSP chip may actually comprise multiple processors, DSP chips and memories that may or may not be stored within the same physical housing. For example, rather than being stored in the same computer, processor 210, the DSP chip 170 and memory 202 may be stored in separate devices. Although there may be advantages to locating the processor 210, the DSP chip 170 and the memory 202 within the autonomous vehicle 201, various processes may be performed external to the autonomous vehicle 102 and various data may be stored outside of the autonomous vehicle 102. The communication system 212 may comprise one or more wireless transmitters and receivers, to communicate with the computer 106 over various types of communication interfaces 105, 166. For example, the communication system 212 may be configured to facilitate the communication between the digital twin module 160 within the graphical programming environment 120 and the digital twin on the DSP chip 170. As previously mentioned with reference to Figure 1, the autonomous vehicle 102 comprises a variety of internal and external sensors 214 that provide data to the autonomous vehicle computer 200. The sensors 214 comprise the previously mentioned camera system 124, LiDAR sensor 122, RADAR sensor 128, GPS receiver 126, ultrasound sensor 134 and the infrared sensor 136. The sensors allow the vehicle 102 to understand and respond to its environment in order navigate and to maximize safety. The GPS 126 may be used to determine the vehicle's 102 latitude, longitude and / or altitude. The camera system 124, the LiDAR sensor 122, the RADAR sensor 128, the ultrasound sensor 134 and the infrared sensor 136 may be used for detecting objects external to the vehicle 102 such as other vehicles, obstacles in the roadway, traffic signals, signs, trees, etc. The LiDAR sensor 122 may be 221 mounted on the roof of the vehicle 102 or other convenient location. In some embodiments, the LiDAR sensor 122 may measure the distance between the vehicle 102 and object surfaces facing the vehicle by spinning on its axis and changing its pitch. The LiDAR sensor 122 may also be used to identify changes in surface texture or reflectivity. The RADAR sensor 128 may be used to determine the relative location of external objects, speed of the vehicle 102 and / or condition of the road surface. The camera system 124 may include one or more cameras. If multiple cameras are used and the distances from each other are known, the parallax from the different images may be used to compute the distance to various objects which are captured by the cameras. One or more of the sensors 214 may be configured to determine environmental aspects that do not specifically relate to external object detection, such as surrounding air temperature, humidity etc. The vehicle control systems 230 comprises the steering control system 130, a brake control system 232, a throttle control system 234, a parking control system 236 and a climate control system 238. A skilled person would understand that additional control systems, which have not been explicitly mentioned, may also be present. The steering control system 130 is configured to change direction of the vehicle 102. The brake control system 232 is configured to cause the vehicle 102 to decelerate. The throttle control system 234 is configured to cause the vehicle 102 to accelerate. The parking control system 236 is configured to cause the vehicle 102 to park in a designated area. The climate control system 238 is configured to regulate the temperature and humidity within the vehicle. The vehicle computer 200 is configured to communicate with the vehicle control systems 230. More specifically, the vehicle computer 200 is configured to receive the output data comprising one or more control signals from the computer 106. The vehicle computer 200 may be subsequently configured to forward these one or more control signals to the vehicle control systems 230. During testing, the vehicle computer 200 comprising the DSP chip 170 may be configured to communicate with the graphical programming environment 120 to ensure the parity between the digital twin within the DSP chip 170 and the graphical program module (shown in Figure 4b). This process will be described in more detail with reference to Figure 8. Figure 3 shows a schematic diagram of the computer 106 shown in Figure I. The computer 106 comprises a communication interface 300, a display 302, a processor 304 and a memory 310. The processor 304 can be any suitable type of data processing device, such as a microprocessor, microcontroller or ASIC. The memory 310 comprises the graphical programming environment 120 and a computer operating system 308. The memory 310 can include a volatile memory, a non-volatile memory, or both volatile and non-volatile memories. The graphical programming environment 120 includes processor-executable instructions that, when executed by the processor 304, cause the computer 106 to perform, or assist in performing, any of the methods described with reference to Figure 7. The communication interface 300 can include any suitable type of interface that enables the computer 106 to communicate with the communication system 212 of the vehicle computer 200 and / or the DSP chip. For example, the communication interface may comprise the first communication interface 105 and / or the second communication interface 166. The display 302 can be any suitable type of output device. For example, the display 302 may include a liquid crystal display (LCD) screen or an organic lightemitting diode (OLED) screen. The display 302 may be a touchscreen to enable data input. The display 302 may be configured to display a graphical programming interface of the graphical programming environment 120 to a user. Figures 4a shows a schematic diagram of the graphical programming environment 120 depicted in Figure 1. The graphical programming environment 120 comprises a graphical programming interface which is presented to a user upon opening of the application. As previously mentioned, the graphical programming environment 120 comprises the first code block 150, the second code block 152 and the single interpreter 154. The graphical programming environment 120 further comprises the digital module 160, which is shown and described in more detail with reference to Figures 5 and 6. In this embodiment, the graphical programming environment 120 further comprises a third code block 408 as well as a data and definitions module 404. Additionally, the graphical programming environment 120 comprises a toolbar 410. The graphical programming interface provides a visual representation of all the elements 150, 152, 154, 408, 404, 410 within the graphical programming environment 120. Each code block 150, 152, 408 may comprise one or more code modules. Each of these code modules comprises an executable potion of code. For example, the first code block 150 comprises a first graphical program module 414 and a second graphical program module 412 (shown in Figure 4b). During operation, the portions of code within the code blocks 150, 152, 408 (as well as the digital twin module 160 shown in Figures 5 and 6) are executed by the single interpreter 154. In some embodiments, the single interpreter 154 is configured to execute the portions of code within each of the code blocks 150, 152, 408 concurrently. The graphical programming interface of the graphical programming environment 120 comprises a visual representation of data flow 400 between the first code block 150, the second code block 152 and the third code block 408. In this embodiment, output from the first code block 150 serves as input into the second code block 152. In turn, the output from the second code block 152 serves as input into both the third code block 408 and the first code block 150. In this manner, the first code block 150, the second code block 152 and the third code block 408 are linked together. As portions of code within the code blocks 150, 152, 408 are executed using the single interpreter 154 output data is generated. The output data may comprise control signals for controlling the vehicle 102. In this specific embodiment, the graphical programming environment 120 comprises the above-mentioned data flow 400 between the first code block 150, the second code block 152 and the third code block 408. However, a skilled person will recognise that the graphical programming environment 120 may comprise any number of distinct code blocks with any arrangement of data flow between these code blocks. The number of distinct code blocks and the associated data flow between them will largely depend on the specific requirements of the external hardware which is being controlled by the code created within the graphical programming environment 120. The toolbar 410 provides quick and convenient access to commonly used functions and tools, often represented by icons or buttons. These functions can include actions like saving, opening files, copying and pasting elements within the graphical programming environment 120, and running code. The toolbar can be used to create new distinct code blocks 150, 152, 408 and to edit or modify the content within the distinct code blocks 150, 152, 408. The data and definitions module 404 stores data, variables and definitions which are shared between the plurality of the distinct code blocks 150, 152, 408 within the single graphical programming environment 154. More specifically, the data and definitions module 404 essentially serves as a shared memory bank where all relevant data is kept. The distinct code blocks 150, 152, 408 within the graphical programming environment 120 can easily access and utilize these variables and definitions by referencing the data and definitions module 404. Figure 4b shows a more detailed view of section A of the graphical programming environment 120 shown in Figure 4a. More specifically, Figure 4b shows a more detailed view of the first code block 150. The first code block 150 comprises a first graphical program module 414 and a second graphical program module 412. Each graphical program module 412, 414 comprises an executable portion of code. More specifically, the first graphical program module 414 comprises a first executable portion of code 414a and the second graphical program module 412 comprises a fourth executable portion of code 412b. Section A shows the first code block 150 in a collapsed view. In the collapsed view the portions of code within the first graphical program module 414 and the second graphical program module 412 remain obscured from view. Section B shows an expanded view of the first graphical program module 414 and the second graphical program module 412. In the expanded view the portions of code 414a, 412b within the first graphical program module 414 and the second graphical program module 412 are visible. The user can transition between the collapsed view and the expanded view by clicking on the first code block 150. This feature is particularly useful for managing and navigating through large code files, improving readability and reducing clutter. Figure 5 shows a schematic diagram of the first graphical program module 414 and the second graphical program module 412 of the first code block 150, the digital twin module 160 and an output module 508. The digital twin module 160 is configured to connect to, and communicate with, the DSP chip 170. In this embodiment, the DSP chip 170 comprises a second executable portion of code (not shown). The second executable portion of code is configured to replicate the behaviour of the first executable portion of code 414a contained within the first graphical program module 414. In other words, the second executable portion of code is configured to produce the same output as the first executable portion of code 414a contained within the first graphical program module 414. In some embodiments, the second executable portion of code may not produce the same output as the first executable portion of code 414a, for example, due to an error in the second and / or the first executable portion of code 414a. The error in the second and / or the first executable portion of code 414a may be discoverable during the process of testing the digital twin alongside the first graphical program module 414. The second executable portion of code may not be identical to the first executable portion of code 414a because the second executable portion of code and the first executable portion of code may be programmed using different languages in different programming environments. However, the second executable portion of code should produce the same output as the first executable portion of code 414a. A method of testing the digital twin within the DSP chip 170 alongside the first graphical program module 414 will be described in more detail with reference to Figure 7. In some embodiments, after testing, the digital twin in the DSP chip 170 may be configured to replace the first graphical program module 414 within the graphical programming environment 120. This process will be described in more detail with reference to Figure 7. Although not explicitly shown, it will be understood that the graphical programming environment 120 may comprise any number of digital twin modules which are configured to connect to any number of digital twins, respectively. For example, the graphical programming environment 120 may comprise a second digital twin module (not shown), configured to connect to, and communicate with, a second DSP chip which stores a second digital twin. The second digital twin may, for example, comprise a fifth executable portion of code which is configured to replicate the second graphical program module 412. In this embodiment, the fifth executable portion of code may be configured to replicate the behaviour of the fourth executable portion of code 412b. As such, the fourth executable portion 412b of code may be configured to produce the same output as the fifth executable portion of code. The output module 508 may be configured to receive output data from the digital twin module 160 and / or first the graphical program module 414. The output module 508 may be configured to transmit the output data to the vehicle 102. As previously mentioned, the output data may comprise control signals for controlling the autonomous vehicle 102. In this view, the second graphical program module 412 is connected to the first graphical program module 414 via a first link 504. The first graphical program module 414 is connected to the output module 508 via a second link 506. The second graphical program module 412 is connected to the digital twin module 160 via a third link 502. The digital twin module is connected to the output module 508 via a fourth link 516. Data is configured to flow between the first graphical program module 414, the second graphical program module 412, the digital twin module 160 and the output module 508 via the first link 504, the second link 506, the third link 502 and the fourth link 516, respectively. The digital twin module 160 comprises two connection parameters. More specifically, the digital twin module comprises a first connection parameter in a form of an IP address 514 and a second connection parameter in a form of a port parameter 512. The first connection parameter 514 and the second connection parameter 512 are configured to identify the DSP chip 170. The first connection parameter 514 and the second connection parameter 512 are used to connect the digital twin module to the DSP chip 170. The digital twin module 160 further comprises a first switch 510. The first switch 510 is configured to selectively connect or disconnect the digital twin stored on the DSP chip 170 from the graphical programming environment 120. More specifically, the first switch 510 is configured to selectively connect or disconnect the DSP chip 170 from the digital twin module 160 within the graphical programming environment 120. When the first switch 510 is “on” a connection (e.g. a UDP connection) is formed between the digital twin module 160 and the DSP chip 170. In the “on” position the graphical programming environment 120 may be configured to instruct the DSP chip 170 to execute the second executable portion of code. Subsequently, in the “on” position the graphical programming environment 120 is configured to receive an output of the second executable portion of code from the DSP chip 170. When the switch is “off’ a connection (e.g., a UDP connection) is not formed between the digital twin module 160 and the DSP chip 170. Alternatively, when the switch is “off’ an existing connection (e.g., a UDP connection) between the digital twin module 160 and the DSP chip 170 may be disbanded. In the “off’ position the graphical programming environment 120 may not be configured to instruct the DSP chip 170 to execute the second executable portion of code. The first graphical program module 414 comprises a second switch 500. The second switch 500 is configured to selectively enable or disable the execution of the first executable portion of code 414a within the first graphical program module 414. The second switch 500 may be configured to connect or disconnect the first graphical program module 414 from the graphical programming environment 120. When the second switch 500 is in the “on” position, the graphical programming environment 120 is configured to execute the first executable portion of code 414a within the first graphical program module 414. When the second switch 500 is in the “off’ position, the graphical programming environment 120 is configured to not execute the first executable portion of code 414a within the first graphical program module 414. In one example, when the first switch 510 is in the “on” position, the third link 502 and the second link 506 may be present within the graphical programming environment 120. Additionally, when the first switch 510 is in the “off” position, the third link 502 and the second link 506 may be removed from (or not present in) the graphical programming environment 120. Similarly, when the second switch 500 is in the “on” position, the first link 504 and the fourth link 516 may be present within the graphical programming environment 120. Additionally, when the second switch 500 is in the “off’ position, the first link 504 and the fourth link 516 may be removed from (or not present in) the graphical programming environment 120. In some embodiments, the links 502, 504, 506, 516 will always remain in the graphical programming environment 120 and the switches 500, 510 simply control the data flow through the links 502, 504, 506, 516. In this embodiment, data will always flow through links 502 and 504. When the second switch 500 is in the “on” position, the first executable portion of code 414a will be executed and data will flow through link 516. When the second switch 500 is in the “off’ position data will not flow through link 516 and first executable portion of code 414a will not be executed. When the first switch 510 is in the “on” position, the second executable portion of code will be executed, and data will flow through link 506. When the first switch 510 is in the “off’ position, the second executable portion of code will not be executed, and data will not flow through link 506. The first link 504, the second link 506, the third link 502 and the fourth link 516 may be moved or removed manually during the testing of the digital twin alongside the first graphical program module 414. Figure 6 shows a schematic diagram of the digital twin module 160 shown in Figure 5 communicating with the DSP chip 170 shown in Figure 1. As previously mentioned, the digital twin module 160 is used to communicate with the DSP chip 170. The communication between the digital twin module 160 and the DSP chip 170 is executed using the UDP protocol. As the program is executed within the graphical programming environment 120, data may be sent to the digital twin module 160 along the third communication link 502. The digital twin module 160 is configured to convert the incoming data to a first portion of text. Subsequently, the resultant first portion of text is sent via the second input communication link 164 (using the UDP protocol) to the DSP chip 170. The first portion of text (or input data) is entered into the digital twin within the DSP chip 170. The second executable portion of code within the digital twin is executed by the DSP chip to generate a second portion of text. The second portion of text is returned from the DSP chip 170 to the digital twin module 160 via the second output communication link 162 (using the UDP protocol). The second portion of text is converted by the digital twin module into output data. The output data is sent to the output module 508 via the second link 506. Figure 7 shows a flow diagram of a method 700 for creating and testing a digital twin of the first graphical program module 414. In some embodiments, this method may be executed by the computer 106 and / or the vehicle computer 200. At step 702, the first graphical program module 414 is generated within the graphical programming environment 120. The first graphical program module 414 comprises the first executable portion of code 414a. In some embodiments, this step may be executed by the computer 106. At step 704, a digital twin of the first graphical program module 414 is built on the DSP chip. Building the digital twin of the first graphical program module 414 on the DSP chip 170 comprises storing the second executable portion of code on the DSP chip 170. In some embodiments, this step may be executed by the vehicle computer 200 which comprises the DSP chip 170. At step 706, the digital twin stored on the DSP chip 170 is connected to the graphical programming environment 120. Connecting the digital twin to the graphical programming environment 120 comprises generating the digital twin module 160 in the graphical programming environment 120. The digital twin module 160 is configured to connect to, and communicate with, the DSP chip 170. In some embodiments, this step may be executed by the computer 106. At step 708, the digital twin stored on the DSP chip 170 is tested alongside the first graphical program module 414. In some embodiments, this step may be executed by both the computer 106 and the vehicle computer 200. Testing the digital twin alongside the first graphical program module 414 may comprise executing both the first executable portion of code 414a and the second executable portion of code within the digital twin on the DSP chip 170. Subsequently, the testing process may comprise comparing the output of the first executable portion of code 414a with the output of the second executable portion of code to verify parity between the digital twin and the first graphical program module 414. Testing the digital twin alongside the first graphical program module 414 may comprise switching off the first switch 510 to disconnect the digital twin module 160 from the graphical programming environment 120. Testing the digital twin alongside the first graphical program module 414 may further comprise executing the first executable portion of code 414a within the first graphical program module 414. In this testing scenario, the first switch 510 may be in the “off’ position and the second switch 500 may be in the “on” position. In some embodiments, testing the digital twin alongside the first graphical program module 414 may comprise switching off the second switch 500 to disable the execution of the first executable portion of code 414a within the first graphical program module 414. Testing the digital twin alongside the first graphical program module 414 may further comprise executing the second executable portion of code within the digital twin. In this testing scenario, the first switch 510 is in the “on” position and the second switch 500 is in the “off’ position. The method and graphical programming environment described herein offer developers a comprehensive framework for testing the digital twin alongside the graphical program module. This functionality enables the rapid identification and resolution of errors and discrepancies on a module-by-module basis, a crucial aspect of the debugging process. Advantageously, the first switch 510 and the second switch 500 allow the developers to rapidly and easily switch between executing the second executable portion of code within the digital twin and the first executable portion of code 414a within the first graphical program module 414a. This easy switching between the respective executable portion of code allows the developers to quickly spot any errors or bugs within the first executable portion of code 414a and / or the second executable portion of code. At step 718, the first graphical program module 414 may be replaced by the digital twin stored on the DSP chip 170. By facilitating the replacement of the first graphical program module 414 with the digital twin after testing, processing tasks are transferred to independent hardware, such the DSP chip 170, thereby enhancing computational efficiency of the graphical programming environment 120. In some embodiments, testing the digital twin alongside the first graphical program module 414 may comprise modifying the first executable portion of code 414a into a third executable portion of code (not shown) in hopes of improving the first executable portion of code 414a. Modifying the first executable portion of code 414a into a third executable portion of code may comprise changing or altering the first executable portion of code 414a into a third executable portion of code. Testing the digital twin alongside the first graphical program module 414 may further comprise comparing outputs of the third executable portion and the second executable portion of code (which remains unaltered). At step 710, a third digital twin, comprising the third executable portion of code may be built on a third DSP chip (not shown). At step 712, the third digital twin may be connected to the graphical programming environment 120 in the same manner as described at step 706. At step 714, the third digital twin may be tested alongside the first graphical program module 414 in the same manner as described at step 708. At step 716, first graphical program module 414 may be replaced by the third digital twin in the same manner as described at step 718. Advantageously, following the verification of the digital twin alongside the first graphical program module 414, the graphical programming environment 120 enables swift modifications to the first graphical program module 414. This agility in code modification is facilitated by the ability to iterate and refine the code on a module-by-module basis. As a result, the modified version of the code (i.e., the third executable portion of code) can be tailored to be more efficient and effective than the original first executable portion of code 414a. Figure 8 shows a flow diagram of a method 800 of testing the vehicle 102, wherein the vehicle 102 comprises the DSP chip 170. The method 800 is executed by the vehicle computer 200. At step 802, the vehicle computer 200 sends input data to the graphical programming environment 120 via the first input communication link 116. The input data comprises sensor data from the one or more sensors 214 of the vehicle 102. At step 804, the vehicle computer 200 receives instructions from the graphical programming environment 120 via first output communication link 118. The instructions are configured to cause the vehicle computer 200 to execute the second executable portion of code stored within the digital twin in the DSP chip 170. At step 806, the vehicle computer 200 enters the input data into the digital twin stored on the DSP chip 170. At step 808, the vehicle computer 200 executes (or causes the execution of) the second executable portion of code on the DSP chip 170 to generate a first testing output data. At step 810, the vehicle computer 200 sends the first testing output data to the graphical programming environment 120 via the first input communication link 116. In some embodiments, the graphical programming environment 120 may be configured to execute the first executable portion of code 414a to generate the second testing output data. Additionally, the graphical programming environment 120 may be configured to compare the first testing output data to the second testing output data. The graphical programming environment 120 may determine whether the first testing output data is identical to the second testing output data. In this manner, the graphical programming environment 120 may ensure that the DSP chip 170 (which store the digital twin) and is connected to the vehicle computer 200 produces the same output as the first graphical program module 414 within the graphical programming environment 120. It will be understood that the invention has been described above purely by way of example, and that modifications of detail can be made within the scope of the claims. Although the graphical programming environment has been described with reference to specific applications in the autonomous vehicle industry, it should be appreciated that the graphical programming environment can be used in other contexts and industries. For example, the graphical programming environment disclosed herein can be used in the robotics industry. The methods shown in Figures 7 and 8 can be performed by instructions stored on a processor-readable medium. The processor-readable medium may be: a read-only memory (including a PROM, EPROM or EEPROM); random access memory; a flash memory; an electrical, electromagnetic or optical signal; a magnetic, optical or magneto-optical storage medium; one or more registers of a processor; or any other type of processor-readable medium. In alternative embodiments, the present disclosure can be implemented as control logic in hardware, firmware, software or any combination thereof. 5 Additionally, the sequence of operations shown in Figures 7 and 8 are merely exemplary. Any of the operations shown in the methods 700 and 800 may be performed in a different order that achieves substantially the same result.

Claims

1. A method for creating and testing a digital twin of a graphical program module,the method comprising:generating the graphical program module in a graphical programming environment, the graphical program module comprising a first executable portion of code;building the digital twin of the graphical program module on one or more external host processor devices, the digital twin comprising a second executable portion of code;connecting the digital twin to the graphical programming environment; andtesting the digital twin alongside the graphical program module.

2. A method according to claim 1, wherein connecting the digital twin to the graphical programming environment comprises:generating a digital twin module in the graphical programming environment, wherein the digital twin module is configured to connect to, and communicate with, the one or more external host processor devices.

3. A method according to claim 2, wherein the digital twin module is configured to communicate with the one or more external host processor devices using a User Datagram Protocol, UDP.

4. A method according to claim 2 or claim 3, wherein the digital twin module comprises one or more connection parameters, the one or more connectionparameters being configured to identify a specific external host processor device of the one or more external host processor devices within a network.

5. A method according to any one of the preceding claims, wherein testing the digital twin alongside the graphical program module comprises:executing both the first executable portion of code and the second executable portion of code; andcomparing the output of the first executable portion of code with the output of the second executable portion of code to verify parity between the digital twin and the graphical program module.

6. A method according to any one of claims 2 to 5, wherein the digital twin module comprises a first switch, the first switch being configured to selectively connect or disconnect the digital twin from the graphical programming environment.

7. A method according to any one of the preceding claims, wherein the graphicalprogram module comprises a second switch, the second switch being configured to selectively enable or disable the execution of the first executable portion of code within the graphical programming environment.

8. A method according to claim 6, wherein testing the digital twin alongside the graphical program module comprises:switching off the first switch to disconnect the digital twin from the graphical programming environment; andexecuting the first executable portion of code within the graphical program module.

9. A method according to claim 7, wherein testing the digital twin alongside the graphical program module comprises:switching off the second switch to disable the execution of the first executable portion of code within the graphical programming environment; andexecuting the second executable portion of code within the digital twin.

10. A method according to any one of the preceding claims, wherein testing the digital twin alongside the graphical program module comprises:modifying the first executable portion of code into a third executable portion of code; andcomparing outputs of the third executable portion and the second executable portion of code.

11. A method according to claim 10, the method further comprising:building a third digital twin on one or more external host processor devices, the third digital twin comprising the third executable portion of code; andconnecting the third digital twin to the graphical programming environment.

12. A method according to any one of the preceding claims, the method further comprising:after testing the digital twin alongside the graphical program module, replacing the graphical program module with the digital twin.

13. A method according to any one of the preceding claims, wherein the one or more external host processor devices comprise one or more Digital Signal Processor, DSP, chips.

14. A method according to any one of the preceding claims, wherein the graphical programming environment comprises a single interpreter.

15. A method according to any one of the preceding claims, wherein the graphical programming environment is configured to:receive input data from an external hardware;enter the input data into the graphical program module and / or the digital twin module;execute the first executable portion of code and / or cause the execution of the second executable portion of code to generate output data; and optionallytransmit the output data to the external hardware.

16. A method according to claim 15, wherein the external hardware comprises a robot or a vehicle.

17. A method according to claim 15 or claim 16, wherein the input data comprises sensor data from the external hardware.

18. A method according to any one of claims 15 to 17, wherein the output data comprises control signals for controlling the external hardware.

19. A graphical programming environment for creating and testing a digital twin of a graphical program module built on one or more separate host processor devices, the graphical programming environment comprising:at least one graphical program module, wherein the graphical program module comprises a first executable portion of code;means for connecting the digital twin to the graphical programming environment, the digital twin comprising a second executable portion of code; andmeans for testing the digital twin alongside the graphical program module.

20. A graphical programming environment according to claim 19, wherein the means for connecting the digital twin to the graphical programming environment comprises a digital twin module, wherein the digital twin module is configured to connect to, and communicate with, the one or more external host processor devices.

21. A graphical programming environment according to claim 20, wherein the means for testing the digital twin alongside the graphical program module comprises:a first switch on the digital twin module, the first switch being configured to selectively connect or disconnect the digital twin from the graphical programming environment; and / ora second switch on the graphical program module, the second switch being configured to selectively enable or disable the execution of the first executable portion of code within the graphical programming environment.

22. A method of testing an external hardware, the external hardware comprising one or more external host processor devices storing at least one digital twin, wherein the digital twin comprises a second executable portion of code, method comprising:sending input data from the external hardware to a graphical programming environment, the graphical programming environment comprising a graphical program module, wherein the graphical program module comprises a first executable portion of code;receiving instructions from the graphical programming environment to execute the second executable portion of code;entering the input data into the digital twin;executing the second executable portion of code to generate a first testing output data; andtransmitting the first testing output data to the graphical programming environment.

23. An external hardware, the external hardware comprising a data processing apparatus comprising means for carrying out a method in accordance with claim 22.

24. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to perform a method in accordance with any of claims 1 to 18 and / or a method in accordance with claim 22.

25. A computer-readable medium comprising instructions that, when executed by one or more processors, cause an apparatus comprising the one or more processors to perform a method in accordance with any of claims 1 to 18 and / or a method in accordance with claim 22.48

Images