This paper proposes a Mobility Digital Twin (MDT) framework to improve mobility services by creating a digital replica of the transportation ecosystem. This framework includes digital representations of humans, vehicles, and traffic, interacting in real-time with their physical counterparts through a cloud-edge-device architecture. Using Amazon Web Services (AWS), the framework supports real-time monitoring, modeling, and prediction to improve existing and future mobility services. A personalized adaptive cruise control (P-ACC) system demonstrates the MDT's practical application. The framework's potential to improve services by incorporating personalized data and real-time feedback is significant, and the paper also addresses future challenges like standardization and AI integration.
Description: Figure 2 depicts the four-layered architecture of the MDT framework, showcasing the cloud, edge, device, and API layers. It visually represents the data flow and interaction between these layers, highlighting the use of AWS services and other technologies.
Relevance: This figure is crucial for understanding the system's architecture and how it supports the MDT framework's functionality.
Description: Table I presents the P-ACC case study results, comparing takeover percentages between traditional ACC and the personalized P-ACC. It quantitatively demonstrates the significant reduction in takeover events achieved by the P-ACC system.
Relevance: This table provides strong evidence supporting the effectiveness of the MDT framework and the P-ACC system in improving driver comfort and potentially safety.
This paper presents a novel Mobility Digital Twin (MDT) framework for connected vehicles using a cloud-edge computing architecture built on AWS. The framework integrates digital twins of humans, vehicles, and traffic, enabling real-time data exchange and personalized services. The P-ACC case study demonstrates the framework's practical effectiveness by significantly reducing driver takeover events compared to traditional ACC. While the architecture and case study showcase the MDT's potential, future research should address security and privacy concerns, further investigate the role of edge computing, and explore the framework's generalizability to diverse traffic scenarios and vehicle types. Continued development in these areas will pave the way for broader adoption and unlock the full potential of MDT technology to revolutionize transportation systems.
This paper proposes a Mobility Digital Twin (MDT) framework, an AI-driven system for enhancing mobility services. It replicates human, vehicle, and traffic elements in a digital space, using cloud-edge-device interactions. The framework allows for real-time monitoring, modeling, and prediction to improve services like personalized adaptive cruise control (P-ACC). A cloud-edge architecture using Amazon Web Services (AWS) supports the framework, and a P-ACC case study demonstrates its effectiveness compared to traditional systems. The paper also discusses future challenges like standardization and the role of AI.
The abstract clearly defines the MDT framework and its purpose, making it easy for readers to understand the core concept.
The abstract effectively summarizes the main contributions of the paper, including the MDT framework, AWS architecture, and P-ACC case study.
The abstract acknowledges future challenges, demonstrating a forward-looking perspective and suggesting areas for further research.
While the abstract mentions improved P-ACC performance, it would be stronger with specific quantitative results to showcase the impact of the MDT framework.
Rationale: Providing concrete numbers would make the benefits of the MDT framework more compelling and attract readers' attention.
Implementation: Include a brief statement quantifying the improvement in P-ACC performance, such as percentage reduction in takeover events or improvement in fuel efficiency.
The abstract briefly mentions AI but could elaborate on its specific applications within the MDT framework.
Rationale: Highlighting the specific AI techniques used would strengthen the paper's contribution in this area.
Implementation: Mention specific AI methods used, such as machine learning for driver classification or reinforcement learning for traffic optimization.
The introduction sets the stage for the Mobility Digital Twin (MDT) framework by highlighting the growing importance of the Internet of Things (IoT) in various sectors, including transportation. It emphasizes the increasing attention and market value of Digital Twin technology, particularly in the automotive industry. The paper points out the lack of a holistic framework connecting different mobility entities (human, vehicle, and traffic) and positions the proposed MDT framework as a solution. The introduction also outlines the contributions of the MDT framework, such as its power, shareability, manageability, and extendibility, and provides a roadmap for the rest of the paper.
The introduction effectively establishes the context by discussing the relevance of IoT and the growth of Digital Twin technology in the transportation sector.
The introduction clearly identifies the lack of a holistic framework connecting mobility entities as a key problem that the proposed MDT framework aims to address.
The introduction explicitly states the contributions of the MDT framework, highlighting its advantages and setting clear expectations for the reader.
While the introduction mentions general applications of IoT and Digital Twins, providing more specific examples related to mobility would enhance reader engagement.
Rationale: Concrete examples would make the potential benefits of the MDT framework more tangible and relatable for the reader.
Implementation: Include examples like real-time traffic optimization, personalized route planning, or predictive vehicle maintenance.
The introduction could briefly touch upon the challenges associated with developing and implementing the MDT framework.
Rationale: Acknowledging challenges early on would provide a more balanced perspective and prepare the reader for the discussion in later sections.
Implementation: Add a sentence or two mentioning potential challenges like data security, communication reliability, or computational complexity.
The introduction could benefit from a stronger opening hook to immediately capture the reader's attention and emphasize the significance of the research.
Rationale: A compelling hook would make the introduction more engaging and encourage the reader to continue reading.
Implementation: Start with a striking statistic about the growth of connected vehicles or the potential impact of Digital Twins on the transportation industry.
This section reviews existing research on cloud computing and Digital Twins in the context of connected vehicles. It discusses transportation applications using cloud computing, highlighting the limitations of traditional systems that rely on onboard resources. The review also covers the use of Digital Twins for connected vehicles, noting the confusion surrounding its definition and its connection to other technologies like model-based design. The section emphasizes the need for a holistic framework that connects various mobility entities (human, vehicle, and traffic), which is the focus of the current paper. It also mentions related work on parallel driving and recent studies by the authors on Digital Twins for connected vehicles, highlighting the limitations of these studies in terms of cloud architecture, data structures, and workflows.
The literature review provides a comprehensive overview of relevant research on cloud computing and Digital Twins in transportation, covering various applications and highlighting the limitations of existing approaches.
The review clearly identifies the gaps in existing research, particularly the lack of a holistic framework connecting mobility entities, which justifies the need for the proposed MDT framework.
The literature review is directly relevant to the proposed MDT framework, providing a solid foundation for the subsequent sections and highlighting the novelty of the current research.
While the review covers a range of studies, it could benefit from a stronger focus on the most recent advances in Digital Twin technology and cloud-edge computing for connected vehicles.
Rationale: Highlighting the latest developments would strengthen the paper's timeliness and relevance.
Implementation: Include more recent publications and discuss emerging trends in the field, such as the use of 5G and edge AI for Digital Twins.
The review could provide a deeper analysis of a few key studies, comparing and contrasting their approaches and highlighting their strengths and weaknesses in more detail.
Rationale: A more in-depth analysis would provide a more nuanced understanding of the existing research landscape.
Implementation: Select 2-3 influential studies and dedicate a paragraph to each, discussing their methodologies, findings, and limitations in relation to the proposed MDT framework.
The review could more explicitly connect the discussed literature to the specific components of the proposed MDT framework (human, vehicle, and traffic).
Rationale: This would strengthen the link between the literature review and the subsequent sections of the paper.
Implementation: When discussing each study, mention which component(s) of the MDT framework it relates to and how it informs the design of the proposed framework.
This section introduces the Mobility Digital Twin (MDT) framework, which consists of three interconnected planes: the physical space (human, vehicle, traffic), the digital space (digital replicas), and the communication plane facilitating data exchange between them. The MDT leverages IoT technologies to connect these entities, enabling real-time data flow and synchronization. The section details the functions of each plane and their building blocks, emphasizing the importance of the communication plane in maintaining synchronization between the physical and digital worlds.
The section clearly describes the MDT framework and its three planes, providing a good understanding of the overall concept and the interactions between the physical and digital worlds.
The section provides a detailed explanation of the building blocks within each plane, including their functions and how they contribute to the overall framework.
The section emphasizes the importance of the communication plane in maintaining synchronization between the physical and digital spaces, which is a crucial aspect of the Digital Twin concept.
While the section mentions various potential microservices, providing more concrete examples with specific inputs and outputs would enhance clarity and demonstrate the practical applications of the MDT.
Rationale: Concrete examples would make the potential of the MDT framework more tangible and easier to grasp.
Implementation: For instance, describe a microservice that uses real-time traffic data to optimize traffic light timings or a microservice that predicts vehicle maintenance needs based on sensor data.
The section mentions the data lake as a key component but could provide more details on its implementation, such as the type of database used and how data consistency is maintained.
Rationale: More details on the data lake implementation would strengthen the technical credibility of the framework.
Implementation: Specify the database technology used (e.g., NoSQL, distributed database) and discuss how data consistency and integrity are ensured across the different Digital Twins.
The section could address security and privacy considerations related to the data exchange and storage within the MDT framework.
Rationale: Given the sensitive nature of some mobility data, discussing security and privacy aspects is crucial for building trust and ensuring responsible development of the MDT.
Implementation: Add a paragraph discussing potential security threats and outlining measures to protect data privacy, such as encryption, access control, and data anonymization.
This figure illustrates the Mobility Digital Twin (MDT) framework. It shows the interaction between the physical space (human, vehicle, and traffic), the digital space (Human Digital Twin, Vehicle Digital Twin, and Traffic Digital Twin), and the communication plane connecting them. Each digital twin has an associated data lake. The communication plane facilitates data flow between the physical and digital spaces, enabling real-time updates and synchronization.
Text: "The MDT framework proposed in this study, as shown in Fig. 1, consists of three planes"
Context: This section introduces the core concept of the Mobility Digital Twin (MDT) framework, explaining its three main components: the physical space, the digital space, and the communication plane connecting them. It emphasizes the role of the communication plane in enabling real-time data exchange and synchronization between the physical and digital worlds.
Relevance: This figure is crucial for understanding the core concept of the MDT framework and how it connects the physical and digital worlds to enable real-time monitoring, modeling, and prediction for improved mobility services.
This section details an example architecture implementing the MDT framework using cloud and edge computing. It leverages AWS for cloud services and incorporates an edge layer for low-latency processing. The architecture is divided into four layers: cloud, edge, device, and API. The cloud layer handles data storage, analytics, and microservices. The edge layer manages communication, computing, and temporary data caching. The device layer represents real-world entities like vehicles and simulators. The API layer connects the system to external data sources. This architecture enables real-time and batch data processing, supporting the MDT's functionalities.
The architecture covers all necessary components for a Digital Twin implementation, including data ingestion, processing, storage, and communication, across both cloud and edge layers.
The architecture leverages established technologies like AWS, Kafka, and Spark, ensuring reliability and scalability.
The four-layer architecture (cloud, edge, device, API) provides a clear separation of concerns and facilitates understanding of the system's structure and data flow.
While the edge layer is mentioned, more details on the specific hardware and software used for edge computing would be beneficial.
Rationale: This would provide a more concrete understanding of the edge layer's capabilities and limitations.
Implementation: Specify the type of edge devices used, their processing power, and the software platform employed for edge computing tasks.
The section lacks discussion on security aspects of the architecture, which is crucial for a system handling potentially sensitive data.
Rationale: Security is a critical concern in any cloud-edge architecture, and addressing it would strengthen the proposal.
Implementation: Include a paragraph discussing security measures implemented at each layer, such as data encryption, access control, and intrusion detection.
The architecture should address scalability and fault tolerance, especially given the dynamic nature of mobility data and the distributed nature of the system.
Rationale: Ensuring scalability and fault tolerance is crucial for real-world deployment of the MDT framework.
Implementation: Discuss how the architecture can handle increasing data volumes and device connections, and how it ensures system resilience in case of component failures.
This figure presents a four-layered architecture designed to implement the Mobility Digital Twin (MDT) concept using cloud and edge computing. The layers are: 1) Cloud Layer (built on AWS and its Virtual Private Cloud), containing data lakes, microservices, model training, and real-time processing components; 2) Edge Layer, responsible for storage, computing, and communication between the cloud and devices; 3) Device Layer, comprising mobile apps, simulators, real vehicles, and RC vehicles, which generate data and receive instructions; and 4) API Layer, connecting the cloud to external APIs for additional data sources like traffic, map, and weather information. Arrows indicate the flow of data and interactions between the layers.
Text: "As shown in Fig. 2, the architecture can be divided into four layers"
Context: This section details the architecture of the proposed MDT framework, which leverages cloud and edge computing. It describes the four layers of the architecture (cloud, edge, device, and API) and how they interact to enable real-time and bulk data processing for various mobility applications.
Relevance: This figure is essential for understanding how the MDT framework can be implemented in a real-world setting using cloud and edge computing. It provides a visual representation of the system's architecture and the flow of data between different components.
This figure illustrates the architecture of the proposed Mobility Digital Twin (MDT) system, which comprises four layers: Cloud Layer, Edge Layer, Device Layer, and API Layer. The Cloud Layer, within an Amazon VPC, includes Data Lakes, Analytics Workbench, Data Stores, Distributed Real-time Processing, Rule Engine, AI/ML Framework & Digital Twin Microservices, Bulk Data Ingestion, and OpenID Connect for authentication. The Edge Layer handles Edge Computing and Communication. The Device Layer consists of Mobile Apps, Real & RC Vehicles, and Simulators. The API Layer connects to external data sources like Traffic, Map, and Weather Data via an API Gateway, Customized Event Query API, and a Customized Web Portal.
Text: "As shown in Fig. 2, the architecture can be divided into four layers"
Context: This section presents a detailed architecture for the proposed MDT concept, leveraging cloud and edge computing. It describes the four layers of the architecture (cloud, edge, device, and API) and their respective components, explaining how they interact to enable real-time and bulk data processing for various mobility applications.
Relevance: This figure is crucial for understanding the detailed architecture of the MDT system and how different components interact to support the framework's functionalities. It shows the specific technologies and services used in each layer, providing a concrete implementation of the MDT concept.
This section details example microservices within each Digital Twin (Human, Vehicle, Traffic) and presents a case study of a Personalized Adaptive Cruise Control (P-ACC) system. The Human Digital Twin demonstrates user management and driver classification. The Vehicle Digital Twin showcases cloud-based ADAS features. The Traffic Digital Twin covers traffic flow monitoring and variable speed limits. The P-ACC case study integrates these microservices, demonstrating improved performance over traditional ACC by incorporating personalized driver behavior, vehicle type, and environmental factors.
The section provides clear examples of microservices for each Digital Twin, illustrating their functionalities and potential applications.
The P-ACC case study effectively integrates the microservices and demonstrates the benefits of the MDT framework in a real-world application.
The inclusion of quantitative results, such as the takeover percentage and latency measurements, strengthens the case for the P-ACC system's effectiveness.
While the section mentions Max-Ent IRL, more details on the training process, including data collection and model validation, would be beneficial.
Rationale: A more detailed explanation of the model training process would enhance the technical rigor of the case study.
Implementation: Provide information on the size and characteristics of the training dataset, the training procedure, and the metrics used for model evaluation.
The section focuses on the benefits of P-ACC but could also discuss its limitations and potential challenges for real-world deployment.
Rationale: Acknowledging limitations would provide a more balanced perspective and open avenues for future research.
Implementation: Discuss potential challenges like handling unexpected events, ensuring safety in diverse traffic conditions, and addressing ethical considerations related to personalized driving models.
The section could discuss the generalizability of the P-ACC system to different vehicle types, driver demographics, and traffic environments.
Rationale: Addressing generalizability would strengthen the case for the broader applicability of the MDT framework and the P-ACC system.
Implementation: Discuss how the system can be adapted to different contexts and what further research is needed to ensure its robustness and effectiveness in diverse scenarios.
This figure shows a real-world demonstration of the cloud-based driver scoring system in Mountain View, CA. The system is used for user management and driver type classification. The image depicts a dashboard display inside a vehicle, showing scores for Safety (75), Comfort (83), Eco (97), and an Overall score (85). It also displays the current speed (16 mph) and indicators for 'Trip' and 'Cloud'. The 'CONNECTED CAR CLOUD DOWNLINK' banner suggests real-time data transfer from the cloud to the vehicle.
Text: "One example is shown as Fig. 3, where different driving scores of a driver (i.e., overall score, eco score, safe score, and comfort score) are calculated by the opensource MOVESTAR model [83] running on the cloud in real time."
Context: This subsection discusses example microservices of the Human Digital Twin, including user management and driver type classification. It describes a web portal for data management and visualization, and how driver scores are calculated and used for classification.
Relevance: This figure demonstrates a practical application of the Human Digital Twin, showing how real-time driver scoring and feedback can be implemented using the MDT framework. It highlights the connection between data collected in the physical space and its use for user management and driver classification in the digital space.
This figure shows the user management page on the web portal of the MDT. It displays the user's driver risk class (reckless, intermediate, or competent) using a circular gauge chart. In this specific instance, the driver is classified as 'Intermediate'. The page also lists past trips with details like start and end times, vehicle name, total distance, and completion status. Clickable links (in light blue) provide access to more details about each trip.
Text: "An example classification result is visualized on the Web portal (currently shown as “Competent” in Fig. 4)"
Context: This subsection describes how driver scores are calculated in real-time and used for driver type classification. It explains how the classification result is visualized on the web portal and how historical data can be accessed.
Relevance: This figure illustrates the user management and driver classification aspects of the Human Digital Twin. It shows how the MDT framework stores and presents driver data, including risk assessment and trip history, enabling personalized services and user management functionalities.
This figure shows a human-in-the-loop simulation of a cloud-based Advanced Driver-Assistance System (ADAS). The simulation uses AWS for cloud computing, the Unity game engine for creating the virtual driving environment, and a Logitech G29 Driving Force steering wheel and pedals for human input. The image displays the in-car view of the simulation, along with two panels showing the data exchange between Unity and AWS. A smaller inset shows a person using the steering wheel, highlighting the 'human-in-the-loop' aspect. The 'Unity-AWS Uplink Message' panel likely shows the data being sent from the simulation to the cloud, while the 'AWS-Unity Downlink Message' panel shows the information being sent back from the cloud to the simulation, such as control commands or guidance information.
Text: "As shown in Fig. 5, a human-in-the-loop simulation (built with AWS, the Unity game engine, and the Logitech G29 Driving Force) is conducted to emulate the data sampling process from a connected vehicle in the physical space [39]."
Context: This subsection describes how a cloud-based ADAS works within the Vehicle Digital Twin. It explains how data is collected from a simulated vehicle in Unity, sent to the cloud (AWS) for processing, and then returned to the simulation as guidance information. The figure illustrates this process and the human driver's interaction with the simulation.
Relevance: This figure is important because it visually demonstrates how the Vehicle Digital Twin can be used to develop and test cloud-based ADAS functionalities. It shows the interaction between the simulation (representing the physical vehicle), the cloud platform (AWS), and the human driver, highlighting the real-time data exchange and control loop.
This figure consists of two parts illustrating the real-world data collection process for the Personalized Adaptive Cruise Control (P-ACC) case study. Part (a) shows a Lexus LS, a mass-produced vehicle used in the study to collect real-world driving data. This emphasizes that the proposed framework is tested on a real car, not just in simulation. Part (b) shows a person driving the Lexus LS on Highway 237 in California. This image represents the 10-minute driving sessions used to gather Controller Area Network (CAN BUS) data, which is the vehicle's internal communication network. This data is then used to train and evaluate the P-ACC system.
Text: "A real-world end-to-end test is conducted, which utilizes the CAN BUS data generated from a Lexus LS test vehicle shown as Fig. 9(a), including 15 data fields, such as position, speed, acceleration, and so on."
Context: This subsection describes the real-world testing of the P-ACC system. It explains that data was collected from a Lexus LS vehicle during 10-minute drives on Highway 237 in California. The figure shows the vehicle and a driver inside, illustrating the data collection process.
Relevance: This figure is important because it grounds the P-ACC case study in real-world data. It shows the actual vehicle and driving scenario used to collect the CAN BUS data, which is crucial for training and validating the personalized driving models used in the P-ACC system.
Table I presents a comparison of takeover percentages between the proposed Personalized Adaptive Cruise Control (P-ACC) and traditional ACC. Takeover percentage represents the proportion of time during a trip when the driver intervenes by using the accelerator or brake pedals because they feel uncomfortable with the system's performance. Lower takeover percentages indicate better system performance and greater driver comfort.
Text: "The results are presented in Table I."
Context: This subsection discusses the results of a real-world end-to-end test comparing the proposed P-ACC with traditional ACC. The key metric is the 'takeover percentage,' which measures how often drivers feel the need to intervene and take control of the vehicle. The results demonstrate a significant reduction in takeover events with the P-ACC system.
Relevance: This table provides quantitative evidence of the P-ACC system's effectiveness compared to traditional ACC. It directly supports the claim that the MDT framework improves driver comfort and reduces the need for interventions.
Table II shows the latency results for processing 10 minutes of CAN bus data and querying the data lakes. It breaks down the latency into three components: Uplink Latency (time to upload data to the cloud), Cloud Computing + Downlink Latency (time for processing in the cloud and downloading results), and Overall Latency (total time from data sampling to receiving results). The table presents these latencies for different data frequencies (0.5 Hz, 1 Hz, 5 Hz, and 10 Hz), showing how the increasing data volume affects the uplink latency while the cloud processing time remains relatively constant.
Text: "The end-to-end latency results are shown in Table II"
Context: This subsection discusses the end-to-end latency of the P-ACC system, which is the time it takes for data to be sampled from the vehicle, processed in the cloud, and for the results to be sent back to the vehicle. The latency is broken down into uplink, cloud processing, and downlink components, and the results are presented for different data sampling frequencies.
Relevance: This table provides insights into the system's responsiveness and the time required for different stages of data processing. It's important for understanding the feasibility of real-time applications and identifying potential bottlenecks.
This section discusses the future challenges in developing and implementing Digital Twin technology for connected vehicles, focusing on standardization, AI integration, cloud platform choices, and heterogeneous communication environments. It highlights the need for specific standards for the transportation domain, the importance of robust AI techniques for cloud-edge computing, the trade-offs between public and private cloud platforms, and the complexities of managing diverse communication technologies for connected vehicles.
The section effectively identifies key challenges related to Digital Twin development for connected vehicles, covering important aspects like standardization, AI integration, cloud platforms, and communication.
The section raises important open questions for future research, stimulating further investigation and discussion in the field.
The section provides a balanced discussion of the advantages and disadvantages of public and private cloud platforms, offering a nuanced perspective on this important decision.
While the section discusses the challenges in general terms, providing more concrete examples would enhance clarity and impact.
Rationale: Concrete examples would make the challenges more relatable and easier to understand.
Implementation: For example, in the standardization section, describe a specific scenario where the lack of standards creates interoperability issues between different Digital Twin implementations. In the AI section, provide an example of how poor data quality can affect the performance of an AI-based Digital Twin system.
The section could prioritize the challenges based on their potential impact and urgency, providing a clearer roadmap for future research and development.
Rationale: Prioritization would help focus efforts on the most critical challenges and guide resource allocation.
Implementation: Rank the challenges based on their importance and provide a brief justification for the chosen ranking. This could be done in a separate paragraph or by using visual cues like numbered lists or bullet points.
While the section identifies the challenges, it could also suggest potential solutions or research directions to address them.
Rationale: Suggesting potential solutions would make the section more constructive and contribute to the advancement of the field.
Implementation: For each challenge, briefly discuss potential solutions or research directions. For example, in the standardization section, suggest specific organizations or initiatives that could lead the development of Digital Twin standards for transportation. In the AI section, mention specific research areas, such as robust machine learning or explainable AI, that could address the challenges of AI integration.
This conclusion summarizes the key contributions of the paper, reiterating the development of the Mobility Digital Twin (MDT) framework for connected vehicles using cloud and edge computing. It emphasizes the novelty of the framework, particularly its integration of cloud-edge computing with detailed microservices for connected vehicles. The paper highlights the use of AWS for the cloud-edge architecture and the successful implementation of a Personalized Adaptive Cruise Control (P-ACC) case study demonstrating the framework's effectiveness. Finally, it concludes by mentioning key considerations for Digital Twin framework design (scalability, reliability, security, cost, latency, and fidelity) and anticipates further research in the mobility domain.
The conclusion provides a concise and clear summary of the paper's key contributions and findings.
The conclusion effectively highlights the novelty of the MDT framework and its integration of cloud-edge computing with microservices.
The conclusion offers a forward-looking perspective by anticipating future research in the mobility domain, suggesting continued relevance and potential for growth.
While the conclusion mentions the P-ACC case study, quantifying its impact with specific metrics would strengthen the overall message.
Rationale: Providing concrete numbers would make the benefits of the MDT framework more compelling and memorable.
Implementation: Include a brief statement quantifying the improvement achieved by the P-ACC system, such as the percentage reduction in takeover events or improvement in fuel efficiency.
The conclusion could discuss the broader implications of the MDT framework beyond the specific case study, highlighting its potential impact on the transportation industry as a whole.
Rationale: Discussing broader implications would enhance the significance of the research and its potential for real-world impact.
Implementation: Add a sentence or two discussing the potential of the MDT framework to improve traffic flow, enhance road safety, or enable new mobility services.
The conclusion could include a call to action, encouraging further research and collaboration in the development and implementation of Digital Twin technology for connected vehicles.
Rationale: A call to action would engage the reader and promote continued progress in the field.
Implementation: Add a sentence encouraging researchers and industry professionals to explore the potential of the MDT framework and contribute to its further development and application.