Simone Conso

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 commenti

🔐 UDS Service 0x27 vs. 0x29 – Old Guard vs. Modern Security in Automotive Diagnostics One of the most common questions I get in AUTOSAR & Diagnostics discussions is: 👉 “What’s the difference between Security Access (0x27) and Authentication (0x29)?” Both are about vehicle security, but their purpose and strength are worlds apart. Let’s break it down. ⸻ 🔑 Service 0x27 – Security Access (Seed & Key) This is the classic security method you’ll find in most vehicles today. • 🎯 Goal: Unlock an ECU for protected operations (e.g., flashing, WriteDataByIdentifier 0x2E, RoutineControl 0x31). • ⚙️ How it works: 1. Tester requests a seed. 2. ECU sends a random seed. 3. Tester applies a secret OEM algorithm → generates key. 4. ECU verifies → if correct, access granted. • 🔒 Crypto: Symmetric (shared secret algorithm). • ⚠️ Weakness: Once the algorithm leaks (firmware reverse-engineering), anyone can generate valid keys. Analogy: 🕺 A bouncer asking for a secret handshake before letting you in. ⸻ 🔒 Service 0x29 – Authentication (PKI-Based, Modern) Introduced in ISO 14229-1:2020, and now a key part of UNECE R155/R156 cybersecurity compliance. • 🎯 Goal: Verify the identity of the tester before granting access. • ⚙️ How it works: 1. Tester & ECU exchange supported methods (ACR – Authentication Configuration Record). 2. ECU sends a cryptographic challenge (nonce, APCE). 3. Tester signs the nonce with its private key and sends signature + certificate. 4. ECU verifies certificate chain, extracts public key, checks signature. • 🔐 Crypto: Asymmetric (RSA/ECDSA, PKI certificates). • ✅ Strength: Secure against replay/MITM. Breaking it requires cracking strong cryptography, not reverse-engineering. Analogy: 🛂 Showing your passport at border control, validated against trusted authorities. ⸻ 📊 Quick Comparison Feature 0x27 Security Access 0x29 Authentication Goal Unlock ECU security level Verify client’s identity Cryptography Symmetric (shared secret) Asymmetric (PKI: RSA/ECDSA) Data Exchanged Seed + Key Nonce, Signature, Certificates Security Strength Weak (algorithm leaks) Strong (private key protected) Common Use Flashing, legacy diagnostics Secure updates, R155/R156 compliance Analogy 🤝 Secret Handshake 🛂 Passport Verification ⸻ 🚘 Why This Matters • 0x27 → still dominant in legacy ECUs. • 0x29 → mandatory in new vehicle platforms to meet global cybersecurity regulations. • Future-proof ECUs will rely heavily on PKI-based authentication for software updates, diagnostics, and secure communication. 💡 Takeaway: • 0x27 = authorization to perform a function. • 0x29 = authentication of identity + trust establishment. Both will co-exist for a while, but 0x29 is the foundation of modern vehicle security.

123

5 commenti

ISO-TP: Multi-frame communication In embedded automotive systems, raw CAN frames aren’t enough when it comes to diagnostics, flashing, or infotainment communication. That’s where ISO 15765-2 (CAN TP) steps in—layering transport protocol logic over CAN to enable structured, multi-frame data exchange. 🔍 What is CAN TP? CAN TP (Transport Protocol) enables transmission of large payloads (up to 4 KB) over CAN’s 8-byte frame limit using segmentation and flow control. 🚍 Frame Types in CAN TP: Single Frame (SF): For payloads ≤ 7 bytes First Frame (FF): Starts multi-frame transmission Consecutive Frame (CF): Carries segmented data Flow Control (FC): Receiver’s response to manage pacing Key ISO-TP Frame Types: 1️⃣ Single Frame (SF) For messages ≤ 7 bytes. Entire message fits in one CAN frame. 2️⃣ First Frame (FF) Initiates messages > 7 bytes. Contains initial data + total message length. Notifies receiver to expect multiple frames. 3️⃣ Consecutive Frame (CF) Sends the remaining message sequentially. Includes a sequence number for correct reassembly. 4️⃣ Flow Control (FC) Sent by the receiver to control transmission rate, block size, and spacing between frames. Prevents buffer overflow and ensures smooth communication. ⚙️ Real-Time CAN TP in Action: 🧠 Dynamic segmentation and reassembly logic 🧹 Memory-safe buffer handling with debug logs ⏱️ Timing control for STmin and block size 📊 Real-time decoding of CAN TP frames for UDS services like ReadDataByIdentifier, RequestDownload, and TransferData Here’s a snapshot of a real CAN TP flow: Code [Tx] FF: 10 14 2F 01 00 00 ... [Rx] FC: 30 00 14 [Tx] CF: 21 00 00 00 ... [Tx] CF: 22 AA BB CC ... 🔐 Why It Matters: CAN TP is foundational for: 🔄 UDS Flashing and Diagnostics 📡 Enables reliable multi-frame communication in ECU diagnostics and flashing. Ensures data integrity for large messages. Mastering CAN TP means mastering the language of embedded diagnostics. #EmbeddedSystems #CANTP #ISO15765 #AutomotiveDiagnostics #UDS #CANProtocol #FirmwareUpdate #RealTimeSystems #Telematics #CProgramming #ProtocolDesign #CANBus #ISO_TP #AutomotiveEngineering #ECUFlashing #UDS

57

🚗🔁 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 commenti

If you’ve worked with AUTOSAR multicore distributions, you know this already: 2 cores ≠ 2x performance. Getting real performance gains depends on how application and base software are distributed across cores. Just throwing tasks onto another core doesn’t guarantee faster execution. In fact, in example below, shifting only 15% of runtime from one core to another led to a 4% increase in total runtime. Why? Some tasks still need to run sequentially, so you’ll never see a full 100% gain. And while adding more cores sounds like the obvious solution, it introduces concurrency challenges and new memory access bottlenecks. So how do you get maximum efficiency out of multicore distribution? 📄 Our latest white paper covers: • Why multicore architectures are essential in automotive ECU development • Key challenges in core distribution—and how to solve them • Real-life use cases with measurable benefits • Practical strategies using ETAS’ proven AUTOSAR stack • Emerging features shaping next-gen multicore systems 👉 Download the white paper to see how to get the most out of AUTOSAR multicore distributions. https://lnkd.in/eHSuH-Ye    #YourAmbitionIsOurMission #AUTOSARClassic

48

Mastering CAPL Interfaces in Automotive Embedded Systems In the world of automotive embedded systems, efficiency and accuracy in ECU communication are crucial. That’s where CAPL (Communication Access Programming Language) comes in. CAPL Interfaces, widely used in Vector CANoe, empower engineers to: ✅ Automate ECU testing and diagnostics (UDS, OBD-II) ✅ Simulate real-time CAN, LIN, FlexRay, and Ethernet networks ✅ Perform Hardware-in-the-Loop (HIL) testing with ease ✅ Accelerate debugging and validation cycles With the rapid growth of ADAS, EVs, and AUTOSAR-based systems, mastering CAPL is no longer optional—it’s an essential tool for engineers working on ECU validation and vehicle network testing. 🌟 Why it matters? CAPL bridges the gap between theory and practice, ensuring safer, smarter, and more reliable vehicles for the future. 👉 Download Now from Google Play 📱 https://lnkd.in/gaw5GaFq 👉 Visit for more: 🌍 https://lnkd.in/geWksCUX #Automotive #EmbeddedSystems #CAPL #VectorCANoe #CANProtocol #ECUTesting #AUTOSAR #ADAS #IoT #HILTesting #AutomotiveIndustry #EmbeddedEngineering #CANFD #CANXL #OBDII #Diagnostics #DoIP #FlexRay #LINProtocol #AutomotiveSoftware #ECUDevelopment #AUTOSAREngineer #VehicleNetworking #IoTApplications #EVTechnology #SmartVehicles #AutomotiveTesting #SoftwareValidation #HILSimulation #ModelBasedDesign #ControlSystems #FunctionalSafety #ISO26262 #ASIL #RealTimeSystems #Microcontrollers #FirmwareDevelopment #SoftwareEngineering #EngineeringInnovation #AutomotiveTechnology #AutomotiveEngineering #ElectronicsDesign

27

7 commenti

Automotive Cybersecurity This may be one of the hottest topics in the industry, primarily because the UN R155 regulation has become mandatory, and consequently, ISO 21434 is also becoming obligatory in order to comply with that regulation. There are many challenges in automotive cybersecurity, mainly, how to protect something that is widely accessible to the general public. On one hand, there's that broad exposure, and on the other hand, there's a global shortage of skilled professionals. Modern vehicles today are complex assets that combine both IT and OT. This means you need to consider cloud infrastructure, software, web, and networks on one side, and hardware, firmware, and sensors on the other. To cover all of this, a multidisciplinary team is needed, one that understands security by design, security throughout the software development lifecycle, penetration testing, and even safety aspects when working with the OT side. From a technical perspective, embedded engineers are often unaware of the problems that can be caused by using standard functions like memcpy. While some might claim it's obsolete, in reality, it's still widely used. Engineers often resort to shortcuts; not because they lack knowledge, but because they're under pressure. In addition to low-level programming errors, another critical issue is access to the CAN network, especially from infotainment systems. An attacker can override the CAN bus and send high-priority messages directly from the infotainment unit. Even more concerning are aftermarket systems, which are often poorly tested or not tested at all, and are installed simply to provide more features. Moreover, in 2023, the highest volume of attacks targeted telematics systems i.e., remote attacks, showing just how unprepared the industry is for what lies ahead. In the future, and already today, cars will become increasingly digitalized. Every new feature increases the attack surface. Therefore, this issue will need to be taken seriously, because with the popularization of any technology comes the popularization of its darker side as well.

22

11 commenti

💡Unified Diagnostic Services (UDS) is the backbone of vehicle fault detection and reporting in modern ECUs. It records issues as Diagnostic Trouble Codes that can be retrieved later by diagnostic tools. 🔎But where in the AUTOSAR architecture is UDS implemented? and Which module handles these codes and ensures they are stored and retrieved correctly? Our blog explores how the AUTOSAR Service Layer makes UDS-based diagnostics possible: https://lnkd.in/gGUY26m #UDS #VehicleDiagnostics #AUTOSAR #AutomotiveSoftware

39

🚗🔌 Understanding CAN .dbc Files & Simulation in Automotive Testing If you are working in the automotive embedded domain, chances are you’ve come across a .dbc file while dealing with CAN communication. Let’s break it down: 🔹 What is a .dbc file? A .dbc (Database CAN) file is a CAN database file used to describe the structure of CAN messages and signals. It defines which messages (frames) exist, their IDs, which signals they contain, scaling, units, byte order, etc. In short: It acts as a dictionary between raw CAN data (hex values) and meaningful engineering values (like speed in km/h, RPM, fuel level). 🔹 Why is it needed? Without a .dbc, CAN traffic is just raw hexadecimal data. With a .dbc, engineers can decode and analyze signals in human-readable format. It enables testing, validation, logging, and simulation in tools like Vector CANoe, CANalyzer, vTestStudio. 🔹 How to create a new .dbc file? 1. Identify the CAN communication matrix (from OEM or supplier). 2. Open tools like Vector CANdb++ Editor, CANoe, or other database editors. 3. Define: Message IDs (standard/extended). Message cycle time, DLC (data length code). Signals (start bit, length, scaling, offset, unit). Node information (ECUs transmitting/receiving). 4. Save as .dbc file and use it for analysis or simulation. 🔹 What is Simulation? Simulation in automotive testing means mimicking real ECUs or systems in a test environment. Example: Using CANoe, you can simulate an ECU (say ABS) to test another ECU (say ECU under test – BCM). Benefits: Reduces dependency on hardware availability. Helps in early validation, debugging, and automation. 🔹 What is Physical Value Extraction? When an ECU sends data on the CAN bus, the information is packed into raw binary/hexadecimal format inside a CAN frame. But engineers don’t directly work with these raw values. Instead, we need to extract and convert them into real-world engineering values (like temperature, speed, or RPM). This process is called Physical Value Extraction. --- 🔹 The Formula for Conversion Each signal in a CAN frame has parameters defined in the .dbc file: Start Bit, Length, Byte Order → tells where the signal is located. Factor (Scaling) and Offset → defines how raw values are converted. Minimum, Maximum, Unit → defines valid range and measurement unit. The conversion is done using this formula: 👉 Physical Value = (Raw Value × Factor) + Offset --- 🔹 Example Suppose you have a signal Vehicle_Speed defined as: Start bit: 0 Length: 16 bits Factor: 0.1 Offset: 0 Unit: km/h If the ECU sends raw data 0x03E8 (= 1000 decimal): Physical Value = (1000 × 0.1) + 0 = 100 km/h 🚗💨 --- 🔹 Why It Matters? Makes data human-readable. Allows proper monitoring, logging, and validation in tools like CANoe or CANalyzer. Ensures signals are interpreted consistently across teams (OEMs, suppliers, testers). #EmbeddedSystems #CAN #Testing #Simulation #DBC #Vector #SystemTesting #automotive

59