Publicité
Publicité

Contenu connexe

Publicité
Publicité

Virtual Twins: Modeling Trends and Challenges Ahead

  1. Laurent Maillet-Contoz, STMicroelectronics, France Virtual Twins: Modeling Trends and Challenges Ahead
  2. Outline • Flavours of Digital Twins • Evolution of the modeling trends over the last decade • Illustration on two examples • Upcoming challenges • Conclusion 2
  3. Flavours of Digital Twins 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 Design Flow: 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 Virtual Twins 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 Silicon Product = 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 for Complex 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: Complex SoC • 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: Proliferation of 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 • Anticipation of 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 Device Model
  13. STM32 Bluetooth Low Energy (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 Virtual Twin • 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 Node Model for Critical Water Management Infrastructure
  16. IoT Device Model Typical Architecture 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 Black Box 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 SystemC Architecture 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. Challenges Ahead
  20. Extending the Virtual Twin 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 TLM IP 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 of virtual 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
Publicité