João Esteves

🚗🔁 Which HiL Platform Do You Use in Automotive Testing – and Why? 🔍 In today’s fast-evolving automotive industry, Hardware-in-the-Loop (HiL) testing plays a vital role in validating ECUs, sensors, actuators, and software functionality before real-world deployment. But with a range of HiL platforms available, I’m curious 👇 Which platform do you use in your automotive projects – and what makes it your preferred choice? Here are a few widely-used platforms in the industry: ⚙️ dSPACE – known for powertrain, ADAS & complete ECU integration 🧩 Vector VT System – great for flexible signal manipulation and diagnostics 🛠️ NI (National Instruments) – modular, scalable, and ideal for custom setups 📏 ETAS – widely used with INCA integration, especially for calibration & measurement ⚡ Opal-RT – preferred for power electronics & real-time simulation 🔋 Typhoon HIL – perfect for electric drive and inverter systems 💻 Speedgoat + Simulink – tight MATLAB integration for rapid prototyping 🌐 Modelon, Siemens, AVL – for specialized or scalable plant modeling Each tool has its own niche – and the best fit often depends on your use case, whether it's ADAS, BMS, Powertrain, or complete vehicle systems. 🧠 Let’s exchange insights: ✅ Which HiL platform do you use? ✅ What domain do you apply it to? ✅ What advantages do you see? Let’s learn from each other and strengthen the automotive testing community 🔧🚘 👇 Share your experience in the comments! #HiLTesting #AutomotiveTesting #dSPACE #Vector #NI #ETAS #OpalRT #TyphoonHIL #Speedgoat #Simulink #ModelBasedDesign #RealTimeSimulation #AutomotiveTools #VehicleValidation #ADAS #Powertrain #BMS #ISO26262 #AutomotiveInnovation #MBD #AutomotiveEngineers #SoftwareDefinedVehicles #ECUTesting #SimulinkRealTime #HardwareInTheLoop #HiLPlatform

71

9 comentários

𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻 𝘃𝗶𝗿𝘁𝘂𝗮𝗹𝗶𝘇𝗮𝘁𝗶𝗼𝗻, 𝗵𝗼𝘄 𝗢𝗘𝗠𝘀 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗲 𝗮𝗻𝗱 𝗼𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗲 𝘃𝗲𝗵𝗶𝗰𝗹𝗲 𝗳𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝘀 𝗯𝗲𝗳𝗼𝗿𝗲 𝗵𝗮𝗿𝗱𝘄𝗮𝗿𝗲 𝗲𝘃𝗲𝗻 𝗲𝘅𝗶𝘀𝘁𝘀 Esteemed colleagues, In traditional automotive programs, 70–80% of integration happens after the hardware is built. 🛑 𝘉𝘺 𝘵𝘩𝘦𝘯: 𝘸𝘪𝘳𝘪𝘯𝘨 𝘪𝘴 𝘧𝘳𝘰𝘻𝘦𝘯, 𝘤𝘰𝘯𝘵𝘳𝘰𝘭𝘭𝘦𝘳𝘴 𝘢𝘳𝘦 𝘮𝘰𝘶𝘯𝘵𝘦𝘥, 𝘢𝘯𝘥 𝘣𝘶𝘨𝘴 𝘢𝘳𝘦 𝘦𝘹𝘱𝘦𝘯𝘴𝘪𝘷𝘦. That’s where Function Virtualization comes in ; enabling OEMs to simulate, validate, and deploy vehicle functions as software, before a single ECU is installed. 🔍 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗶𝘁? Function Virtualization means running a vehicle function : like lane keeping, thermal control, or door locking as a software-only unit, with full signal behavior, timing logic, and safety states. These vECUs (virtual ECUs) replicate the real ECU’s logic, allowing: ✅ Full integration in a virtual vehicle, ✅ Fault testing without hardware, ✅ Early validation long before SOP. 📈 𝗪𝗵𝘆 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀 Function Virtualization flips the old model: 🚫 Before: • Integration starts in Year 3 • ECUs are tested one by one • Bugs are found late, fixes are expensive • Hardware defines everything ✅ Now: • Integration starts in Year 1 • Dozens of ECUs simulated in parallel • Virtual road testing at scale • Software functions live independently from hardware In real numbers: 💻 Integration can start as early as Month 6, not Month 36 🧪 Regression testing costs drop by 90%+ using cloud-based SIL rigs 🔁 Code reuse jumps to 80%+ across vehicle platforms 🧯 Fault injection becomes automatic and repeatable 🛠️ Software freeze can happen months before hardware freeze 🧠 Real OEM Example One global OEM tested: • 4 zonal controllers + 1 central HPC • 600 km of simulated road for ADAS validation • 12 injected fault conditions (latency, redundancy, signal dropouts) • All executed with <8ms timing budgets across zones 💡 Result: Full validation before vehicle build, 💰 Multi-million savings in lab time, test benches, and ECU tooling. ⚙️ Key Enablers • AUTOSAR Adaptive on Linux/POSIX • Cloud-based orchestration (ETAS COSYM, dSPACE VEOS) • Digital Twins of power, sensors, and bus latency • Middleware + data virtualization (CAN, LIN, TSN Ethernet) 🚗 𝗪𝗵𝗮𝘁 𝘁𝗵𝗶𝘀 𝘂𝗻𝗹𝗼𝗰𝗸𝘀 🔄 Hardware-agnostic development 🚀 OTA features validated before rollout 🤝 Multi-supplier integration in common platforms 🧩 Failover paths validated in software, before vehicle SOP Function Virtualization isn’t a nice-to-have : 𝗶𝘁’𝘀 𝘁𝗵𝗲 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝗯𝗮𝗰𝗸𝗯𝗼𝗻𝗲 𝗼𝗳 𝗦𝗗𝗩𝘀. If you want software that scales, adapts, and survives beyond Job 1, you simulate it first. #FunctionVirtualization #vECU #ZonalArchitecture #SDV #SoftwareInTheLoop #AUTOSAR #DigitalTwin #SIL #Middleware #VehicleSoftware #EEArchitecture #MobilityEngineering

71

2 comentários

The Critical Role Of Safety Microcontrollers In ADAS And AD Applications. New Webinar: https://lnkd.in/d4bqBN-E Join us for an in-depth exploration of the critical role Safety Microcontrollers (MCUs) play in Advanced Driver Assistance Systems (ADAS) and Automated Driving (AD) applications. This webinar, presented by Infineon Technologies, aims to provide a comprehensive understanding of the functionalities and indispensability of Safety MCUs, particularly in contrast to the nascent Safety Islands within System on Chips (SoCs). Discover why OEMs continue to rely on external Safety MCUs, such as Infineon's AURIX™, despite the common availability of Safety Islands in modern automotive SoCs. Key takeaways: ✅ Essential Role of Safety MCUs: Safety MCUs are a cornerstone of a proper FUSA concept for ADAS/AD applications, such as domain controllers, smart cameras, LiDARs, and radars. ✅ Critical Functions of Safety MCUs: Safety MCUs supervise actuator commands, provide emergency response, monitor the health of all critical components, offer gateway functionality, and support an independent real-time software environment. ✅ Advantages of AURIX™ Safety MCUs: AURIX™ is the technically proven solution due to its best-in-class scalability, extensive AUTOSAR and safety software portfolio, and ability to handle fail-operational use cases. ✅ Limitations of Safety Islands: Safety Islands in SoCs lack the comprehensive feature set and hardware separation that dedicated Safety MCUs offer; hence, they cannot replace them.

166

2 comentários