Download to read offline
Uploaded byBrain IoT Project
Virtual Twins: Modeling Trends and Challenges Ahead
The document discusses the evolution and challenges of virtual twins in modeling, highlighting different types of digital twins, their applications in complex systems, and the advancements in design flow. It underlines the need for innovation in validation, security integration, and the handling of interconnected systems, particularly in automotive applications. Additionally, it emphasizes the importance of managing multiple levels of abstraction for effective integration and simulation in diverse technological domains.
More Related Content
Similar to Virtual Twins: Modeling Trends and Challenges Ahead
Virtual Twins: Modeling Trends and Challenges Ahead
- 1. Laurent Maillet-Contoz, STMicroelectronics,France Virtual Twins: Modeling Trends and Challenges Ahead
- 2. Outline • Flavours ofDigital Twins • Evolution of the modeling trends over the last decade • Illustration on two examples • Upcoming challenges • Conclusion 2
- 3. Flavours of DigitalTwins IP IP IPSOCSystem System of systems Digital Twin, model of: • Product • Production line • Manufacturing process Digital Twin, model of: • System architecture • Interaction between system components Virtual Twin, model of: • SoC architecture • Interactions between hardware and software 3
- 4. Evolution of DesignFlow: the Old Days Shift-left paradigm Architecture Implementation DebugArchitecture Implementation Debug Software design Architecture Design Verification Silicon Board Hardware design Specification Integration/Validation Functionality, safety, security Performance Virtual prototype / Twin Savings 2000’s 2010’s 1666-2011 1685-2014 4
- 5. Usage of VirtualTwins Nowadays • Before development of embedded software • Find ambiguities and contradictions in specifications • Prototype certain aspects of the specification (performance, low-power…) • Development of embedded software / Validation • Implement and test maximum number of aspects of the software and system • Mature software • Bringup • Tool to understand “final” software execution and remaining bugs • Customer own developments • Develop user parts of the embedded software • Integrate in bigger system Pre Si Post Si 5
- 6. Spec to SiliconProduct = Continuum of SoC Virtual Twins Project lifetime SOC SoC Black box model SoC SystemC architecture model 1666-2011 1685-2014 SoC systemC / HDL co-simulation SOC Specification HW & SW Specifications CPU IP IP IPSOC CPU IP IP IPSOC CPU IP (TLM) IPSOC IP (RTL) CPU IP (TLM) IPSOC IP (RTL) =Transactor SoC systemC / HDL Co-emulation / Co-protoyping = SystemC model = RTL = HW emulator = SW 6
- 7. Typical Profile forComplex SoC • Processing intensive • CPU, GPU, Neural PE, Image processing • Many I/Os • Sensors: LIDAR, Camera, GPS, etc. • Electronic Control Units • Safety and security constraints! • Unexpected behaviours • Hardware failures 7
- 8. Platform Case #1: ComplexSoC • Multi-core CPU • DDR 3 or 4 • Clusters • Processing (Video encode/decode, Image) • Security (dedicated processor) • I/O (SATA, USB, PCIe, Wifi, Ethernet, CAN, SPI, I2C, FlexRay, MiPHY …) • Actuation/Sampling (PWM, ADC, etc.) • “Raw” complexity • 20+M lines of code for software (Linux, proprietary RTOS, etc.) • 1 M lines of code for the models • Complex IPs (P10) (P11) IP (P4) Processor (P1) Processor (P2) IP (P3) memory Interconnect Eth Wifi CAN USB (P12) 8
- 9. Smart Objects &IoT • Many Applications domains • Consumer • Industrial • Medical • … • Connectivity • Ethernet, Industrial buses • Bluetooth, Wi-Fi, LoRa • Security • Distributed systems • Low-power 9
- 10. Platform Case #2: Proliferationof Small SoCs • MCU/MPU: Few embedded cores • SRAM • “Offloading” IPs (DMA, Graphics) • I/Os: GPIO (with some PWM), I2C, SPI... • Connectivity: USB, Bluetooth, Ethernet • Energy efficiency • Security • Complexity in the distributed system “Locally simple, Globally complex” Sensor 1 Sensor 2 Actuator M7 STM32 Sensor 1 Sensor 2 Actuator M7 STM32 Sensor 1 Sensor 2 Actuator M7 STM32 Sensor 1 Sensor 2 Actuator M7 STM32 Sensor 1 Sensor 2 Actuator M7 STM32 Sensor 1 Sensor 2 Actuator M7 STM32 Sensor 1 Sensor 2 Actuator M7 STM32 Sensor 1 Sensor 2 Actuator M7 STM32 10
- 11. Modeling Trends • Anticipationof functional embedded software development and validation • Introspection and diagnosis capabilities in virtual twins • Running « untestable » scenarios • Validation of dynamic power management strategies • Reset and clock controller, clock trees • Wake-up, low-power modes • Integration of security features • Validation of the (system-of-) system • Sensor inputs and environmental effects • From 10+ to 1000+ node instances • Physical/virtual device unification • Mixing actual devices and virtual twins in a single execution 11
- 12. Example: BLE DeviceModel
- 13. STM32 Bluetooth LowEnergy (BLE) Virtual Twins BLE USART I/O USART Window USART I/O Bluetooth RF channel BLE Node 0 GPIOs Cortex M4 STM32 subsystem Nucleo Panel Cortex M0 BlueTooth Node 1 GPIOs Cortex M4 STM32 subsystem Nucleo Panel Cortex M0 BlueTooth 13
- 14. STM32 BLE VirtualTwin • Abstract Hardware + Firmware: executable specification • BLE state machine & BLE I/F • STM32 subsystem • ARM Cortex M4 Instruction Set Simulator • GPIO, SPI, USART (core functionality needed) • RCC, EXTI, SYSCFG (partial) • Flash Interface, PWR (stub) • Benefits • Early availability of Virtual Twin: low effort thanks to high abstraction level • Scalable to tens of nodes • Corner case software bugs identified Ex: illegal values programmed in clock controller GPIO sNucleo Panel BLE I/FGATT Cortex M0 BlueTooth Cortex M4 STM32 subsystem 14
- 15. Example: Sensor NodeModel for Critical Water Management Infrastructure
- 16. IoT Device Model TypicalArchitecture MCU Connectivity Sensor Embedded software Open (%) Flow (m3/s) Satur. (%) m Benefits: 1. System validation without constraints of physical devices 2. Manage complexity 3. Increase flexibility and productivity 4. Increase the system reliability 16
- 17. Sensor Node BlackBox Model • A simple service-oriented model • Black-box • No detail on internal architecture • Embedded firmware is abstracted • Measures obtained from a file • Early availability • Fast execution • Generation of data communication to the gateway • Used as the functional contract of the sensor node specification Fecha;EMALCSA/00 PRESA CECEBRE/02 Válvulas/Compuerta 3/Apertura (%);EMALCSA/00 PRESA CECEBRE/02 Válvulas/Compuerta 3/Caudal (m3/s);EMALCSA/00 PRESA CECEBRE/02 Válvulas/Compuerta 3/Desague (%) 08/04/2019 00:25:21.871;10.11571;2.615295;9.07122 08/04/2019 00:35:21.879;10.11571;2.616884;9.061384 08/04/2019 00:45:21.887;10.11571;2.616821;9.061776 08/04/2019 00:55:21.911;10.11571;2.617014;9.060584 08/04/2019 01:05:21.920;10.11571;2.618574;9.050963 08/04/2019 01:15:21.928;10.11571;2.618614;9.050715 Post data towards gateway 17
- 18. Sensor Node SystemCArchitecture Model • Sensor node architectural model includes • Microcontroller Instruction Accurate model • Register accurate model of peripherals • Embedded software • Running on STM32 model • Using STM32 HAL • Collects data from sensor model through I2C bus • Programs connectivity IP model to issue communication • Generation of data communication to the gateway • Conform to the functional contract of the sensor node Fecha;EMALCSA/00 PRESA CECEBRE/02 Válvulas/Compuerta 3/Apertura (%);EMALCSA/00 PRESA CECEBRE/02 Válvulas/Compuerta 3/Caudal (m3/s);EMALCSA/00 PRESA CECEBRE/02 Válvulas/Compuerta 3/Desague (%) 08/04/2019 00:25:21.871;10.11571;2.615295;9.07122 08/04/2019 00:35:21.879;10.11571;2.616884;9.061384 08/04/2019 00:45:21.887;10.11571;2.616821;9.061776 08/04/2019 00:55:21.911;10.11571;2.617014;9.060584 08/04/2019 01:05:21.920;10.11571;2.618574;9.050963 08/04/2019 01:15:21.928;10.11571;2.618614;9.050715 Post data towards the gateway Cortex M4 STM32 Connectivity Flow Meter sensor i2c registers Payload (registers values) Embedded software STM32 F411 ARM CM4 I C N Flash RCC SPI GPIO EXTI Mem PWR I2C SCI SYS CFG 1666-2011 18
- 19.
- 20. Extending the VirtualTwin at the Next Level • Automotive domain: the whole system is a big network! • CAN, LIN, FlexRay, Ethernet AVB, MOST… • How to model inter-components protocols? • Which abstraction for the “blocks”? • Interoperability concern for virtual twins integration • Standardization effort still to be undertaken https://www.hyundai.news/eu/brand/hyundai-and-cisco-to-bring-vehicle-with-next-generation-network-technology-in-2019/ 20
- 21. Multi-system Integration Computing farm System address map TLMIP model Process or model AMS model TLM IP model Memor y model I/O Interconnect model • Models in different technical states • OS, Compiler, Simulation kernel • Heterogeneous domains • Digital, AMS, Multi-physics • Code sharing constraints vs flexibility required by customers • Replace IP X by Y • Add customer-specific IP • Idea: each domain in separate simulation • Challenges: performance, semantics • Opportunity: exploiting multi-cores? 21
- 22. Multi-level Twins Integration •Address simulation speed concern • Manage several levels of abstraction • Guaranty functional equivalence • Mitigate the modeling costs • Ensure seamless integration / substitution of twins • Interfaces interoperability • Heterogeneous modeling languages & frameworks 22
- 23. Takeaways • Usage ofvirtual twins for different categories of circuits • Complex SoCs • Smart objects • Trends and benefits • Early validation of embedded software & power management strategies • Testing “untestable“ scenarios • Integration of security features • Manage connectivity • Scalable validation of the (system-of-) system • Physical/virtual device unification • Upcoming challenges • Expand to the next level • Heterogeneous models integration • Management of multi-abstraction twins 23