Sérgio Silva

Electrical and mechanical engineers often work side by side—but not together. Design misalignment, late discoveries, and endless re-spins don’t come from lack of skill—they come from disconnected workflows. In our latest Wevolver article, Altium's Filipa de Melo Sofio explores how breaking down ECAD–MCAD silos helps teams design faster, reduce errors, and build confidence across disciplines. Read the full article to see how modern hardware teams are turning collaboration into true co-creation. Read the article here: https://bit.ly/4oj7hdp #altium #wevolver #ECAD #MCAD #cocreation

26

5 comentários

6 key guidelines for PCB engineers to design FPT test points 🔶 1. Select appropriate test point features and sizes 🔶 2. Adhere to maximum board dimensions 🔶 3. Include the component heights in your CAD data 🔶 4. Maintain optimum distances between test points and components 🔶 5. Place fiducials accurately for reliable alignment 🔶 6. Avoid interference of traces with test points 💡For more details, check the blog: https://lnkd.in/gZCXuVrK --Spread the word. #pcbdesigners #pcbassembly #circuitboardmanufacturing

37

Electronic Load for Parameter Characterization in Equivalent Circuit Models of Lithium-Ion Batteries Suelen Bampi 1,* , Gierri Waltrich 1 , Anderson Vaccari 2 1Federal University of Santa Catarina, Postgraduate Program in Electrical Engineering, Florianopolis - SC, Brasil. 2Vale S.A, Development and Innovation Sector, Vila Velha - ES, Brasil ABSTRACT -The applications and implemented volume of lithium-ion batteries have been gaining momentum each year. Aiming to contribute to the development of research in this area, this paper presents the design and implementation of an electronic load focused on characterizing parameters inherent to equivalent circuit models (ECM). ECMs are commonly applied for estimating the State of Charge (SoC), State of Health (SoH), and Remaining Useful Life (RUL) of lithium batteries. In this paper, an electrical design of an electronic load was implemented and validated through laboratory instrumentation to obtain characteristic data from a lithium titanate cell. The data from the tests performed on the cell were used as input for a SoC estimation algorithm based on the Extended Kalman Filter (EKF) to help corroborate the prototype's performance. The results comprise the performance of the electronic load, the results associated with the parameterization tests of the lithium cells, and the results obtained for the cell’s SoC estimation using the EKF. VIEW FULL PAPER: https://lnkd.in/dkgdPJNE

101

5 comentários

"We have to do ASPICE AND ISO 26262. Double the work." No. You're doing it wrong. Here's the thing most automotive engineers miss: ASPICE and ISO 26262 are complementary, not cumulative. ASPICE = Process capability framework. ISO 26262 = Functional safety standard. They're designed to work together. ISO 26262-compliant software development relies on the process capability that ASPICE provides. And ASPICE offers the perfect framework for integrating the safety activities that ISO 26262 requires. Combining them doesn't double your effort. Done right, it reduces it. How? 1. SHARED ARTIFACTS Requirements traceability? Both need it. Do it once. Configuration management? Both need it. Do it once. Change management? Both need it. Do it once. 2. ALIGNED REVIEWS ASPICE wants process reviews. ISO 26262 wants safety reviews. Combine them. One meeting, two checkboxes. 3. INTEGRATED WORKFLOWS Don't have separate "ASPICE activities" and "safety activities." Have "engineering activities" that satisfy both frameworks by design. The problem isn't the standards. The problem is treating them as separate compliance exercises instead of integrated engineering discipline. Here's the shift: OLD: "We need to be ASPICE Level 3 AND ISO 26262 ASIL D compliant." NEW: "We need to build safety-critical software with mature processes." The first framing creates bureaucracy. The second creates engineering excellence. What to do Monday: 1. Map your ASPICE artifacts to ISO 26262 work products 2. Identify overlaps (there are dozens) 3. Merge redundant documentation 4. Create integrated checklists You're probably doing 40% more work than necessary. Cut the duplication. Ship faster. Stay compliant. Where's your biggest overlap between ASPICE and 26262 activities? #automotive #aspice #iso26262

307

21 comentários

In embedded systems and electronics, component selection is crucial. Prior to creating your BOM, start with the function: ascertain the requirements of your project. To make development easier, use dependable, well-documented components like the SIM800L or ESP32.. For safety, always overrate: pick parts with ratings higher than what your design requires for voltage, current, and power. Availability is also important because a hard-to-find perfect part creates an issue to the project. Select production-ready components with consistent supply and long lifespans. Don't only rely on theory; test early and in real-world settings. Reliable, scalable architectures are the result of wise component selections. #ElectronicsDesign #IoT #ComponentSelection #EmbeddedSystems #HardwareEngineering #MadeInNigeria #TechInAfrica

22

2 comentários

What is OTA ? (Chapter 1 To understand OTA) OTA (Over-the-Air) updates allow automotive ECUs to receive firmware, software, or configuration updates remotely  via a wireless connection (Wi-Fi, Cellular, or V2X). This eliminates the need for physical service visits, making software deployment faster, safer, and cost-effective. MMU-Based A/B Swap Memory Remapping for OTA Updates There are two primary types of OTA updates in automotive: OTA Type     Description                                    Example SOTA (Software OTA) Updates software applications like infotainment, navigation, UI/UX.         Map updates, voice assistant improvements FOTA (Firmware OTA) Updates ECU firmware, including low-level software and microcontroller programming.  Powertrain, ADAS, or safety-critical updates. e.g Dual Bank (A/B Partitioning) HW Shall Support SWAP A/B Features for Partitioning. Two firmware images are maintained (Active & Backup). The new update is written to the inactive partition while the system continues running. On successful validation, the system switches to the new firmware The bootloader controls which firmware partition is active by modifying the MMU (Memory Management Unit) settings. To perform an OTA update, several AUTOSAR and non-AUTOSAR components are involved: Module Functionality OTA Client (ECU) Receives update package from cloud. OTA Server (Cloud Backend) Manages update distribution & security. Bootloader (FBL - Flash Bootloader) Handles firmware flashing & rollback. Download Manager Manages data download and storage. Secure Communication Module Ensures encrypted transmission (TLS, Secure Boot). Diagnostic Services (UDS - ISO 14229) Supports DoIP/CAN updates via UDS (0x34, 0x36, 0x37). Example: Infotainment ECU receives an OTA update. OTA Client verifies authenticity (RSA signature check). FBL stores new firmware in Flash and restarts the ECU. If the update fails, rollback to the previous version. Memory Layout e.g. +--------------------------+ 0x08000000 (Start of Flash) |    Bootloader     | (Immutable)   +--------------------------+   |    Active Firmware  | (Currently Running)   +--------------------------+   |    Backup Firmware  | (OTA Update Target)   +--------------------------+   |    OTA Metadata    | (Update Info, Version, Hash)   +--------------------------+   |    Swap Partition   | (Temporary Storage)   +--------------------------+ 0x080FFFFF (End of Flash)  API Sequence for UDS-Based OTA Step API Call Description 1️⃣ Request Update Dcm_TriggerDownload(0x34) ECU requests firmware update via UDS. 2️⃣ Validate Image Dcm_RequestTransferExit(0x37) Checks RSA signature and hash. 3️⃣ Store Firmware Fls_Write() Writes firmware to backup partition. 4️⃣ Flash ECU Fbl_TriggerReprogramming() Bootloader overwrites active firmware. 5️⃣ Restart System EcuM_TriggerReset() ECU reboots into new firmware. 6️⃣ Verify Update NvM_ReadBlock() Checks firmware integrity after reboot.  

155

5 comentários

- - -> V A R I S T OR <- - - Varistors are essential components for protecting circuits from transient voltage surges. Unlike a fuse, this component is connected in parallel at the input of the power circuit on electronic boards.

12

1 comentário

Kinematic Equations in ADAS Advanced Driver Assistance Systems (ADAS) rely on kinematic equations to predict motion, avoid collisions, and keep drivers safe. These equations help calculate: ✔ How fast a car is moving (velocity) ✔ How quickly it can stop (deceleration) ✔ How far it travels before reacting (stopping distance) v=v₀+at: Final velocity. d=v₀t+½at²: Displacement. v²=v₀²+2ad: Velocity-displacement relationship. d=1/2(v₀+v)t: Displacement with average velocity. Where: v = final velocity v₀ = initial velocity a = acceleration t = time d = displacement Automatic Emergency Braking (AEB): Scenario: Your car is traveling at 20 m/s (v₀). A pedestrian suddenly appears 25 meters ahead (d). The AEB system needs to determine the deceleration (a) required to stop in time. Calculation: We know the final velocity (v) must be 0 m/s to stop. Using v²=v₀²+2ad, we can rearrange to solve for a: a=(v2−​vo^2)/(2d) a=(0^2−20^2)/(2∗25) −400/50 =-8m/s² This means the AEB system needs to apply a deceleration of 8 m/s² to avoid a collision. Adaptive Cruise Control (ACC): Scenario: Your car is traveling at 30 m/s (v₀). The car ahead slows down, causing your radar to detect a relative acceleration of -2 m/s² (a). The system wants to calculate the distance (d) your car will travel in the next 3 seconds (t). Calculation: Using the equation d=Vo​t+1/2​at^2 d=(30∗3)+(0.5∗−2∗3^2) d=90+(−9) d=81 meters. The system calculates your car will travel 81 meters in that time frame. This information is used to adjust your car's speed to maintain a safe following distance. Time-to-Collision (TTC): Scenario: Your car is traveling at 15 m/s, and a car ahead is traveling at 10 m/s. The distance between them is 25 meters. Assuming the car ahead maintains its velocity. How much time until a collision? Calculation: Relative velocity = 15-10 = 5 m/s. TTC = distance / relative velocity. TTC = 25 / 5 = 5 seconds. Therefore, the time to collision is 5 seconds. If the car ahead were decelerating, then the "a" variable would be used to calculate a more accurate TTC. Key ADAS Points Sensors (radar, lidar, cameras) provide the initial data (position, velocity). ADAS algorithms use kinematic equations to: Predict future object positions. Calculate safe following distances. Determine necessary braking or steering actions. The accuracy of these calculations is critical for the reliable operation of ADAS. Disclaimer: This post is intended for educational purposes from a software development perspective. It does not cover complex non-linear vehicle dynamics.

561

12 comentários

🚗 Understanding Validation Stages in Automotive Embedded Systems Ensuring quality, safety, and reliability in modern vehicles requires a multi-layered validation approach at both the software and system levels. Here's a quick breakdown of how we validate at each stage: 🔍 Static Analysis Done early in development to catch errors before they surface. 🔹 Software Level: Checks code quality, compliance (e.g., MISRA). 🔹 System Level: Verifies model/architecture consistency and completeness. 🧪 Unit & Integration Testing Ensures internal logic and component interactions work as expected. 🔹 Software Level: Validates individual modules and their interfaces. 🔹 System Level: Confirms that components across ECUs function together. ⚙️ HIL (Hardware-in-the-Loop) Testing Bridges simulation and reality. 🔹 Software Level: Tests how the software responds to real-time stimuli. 🔹 System Level: Validates integration of ECUs with simulated physical environments. 🚘 Vehicle Testing The final and most realistic validation stage. 🔹 Real-world testing for safety, performance, and user experience under actual driving conditions. ✅ Each layer serves a distinct purpose, and together they build confidence in delivering safe and high-quality automotive systems. #Automotive #EmbeddedSystems #SystemValidation #SoftwareTesting #HILTesting #VehicleValidation #AUTOSAR #ADAS #SDV #ModelBasedDevelopment #FunctionalSafety Piyush Itankar Mahmad Bharmal Pyjama Brah! Janakiraman Vasudevan CreamCollar

99

2 comentários

🚗✨ What is XCP? A Quick Introduction for Automotive Engineers If you work in automotive ECU development, you’ve probably heard of XCP — but what exactly is it? Here’s a short explainer for anyone who wants to understand the basics! 📌 🔍 What is XCP? ✅ XCP = Universal Measurement and Calibration Protocol ✅ It’s an ASAM standard (Association for Standardization of Automation and Measuring Systems) ✅ Originally, it was mainly used for production-level calibration and measurement, but today it’s key for development, testing, and flashing ECUs 📌 How Does It Work? 👉 Master–Slave principle: Master = Calibration tool (e.g., PC) Slave = ECU 👉 Flexible protocol structure: Transport Layer (TL): Defines how data moves (CAN, CAN FD, FlexRay, Ethernet, USB, etc.) Protocol Layer (PL): Defines commands, memory access, measurement, calibration. 📌 Frames, PIDs & Message Types 🚦 XCP data is exchanged in frames, each with a PID (Packet Identifier): PID range: 0x00 – 0xFF There are 2 main message types: CTO (Command Transfer Object) → Small packets for commands or polling DTO (Data Transfer Object) → Larger packets for high-speed data streaming (DAQ) 📌 Measurement vs. Calibration Measurement: Read real-time ECU data (e.g., RPM, sensor values). Calibration: Adjust parameters on the fly without changing ECU code (e.g., maps, thresholds). ✅ Methods: CTO = Polling → On-demand read (simple, slower) DAQ (DTO) → Continuous, high-performance data streaming. 📌 What is the A2L File? A2L is a standardized description file that tells the tool: Which ECU variables exist Where they are in memory How to read or calibrate them No A2L, no measurement! 📌 Takeaway XCP is a powerful tool that helps engineers measure, calibrate, and test ECUs efficiently, no matter which transport layer is used. 🔧🚙 Whether you’re tuning engines, logging data on a dyno, or validating production vehicles — XCP is your bridge to what’s happening inside the ECU! #Automotive #XCP #ASAM #ECU #Measurement #Calibration #EmbeddedSystems #CAN #Ethernet #FlexRay #AutomotiveEngineering

101

5 comentários

I’ve seen it again and again in automotive projects. Unit tests pass. System tests fail. And no one knows what happened in between. There are no integration steps. No interface validation. No structured build-up from modules to behavior. But this isn’t just a tooling issue. It’s architectural. It’s cultural. It’s systemic. And still… – Automotive SPICE expects integration proof. – ISO 26262 requires composition validation. – Math shows it reduces risk. But too often, teams skip it. Why? Because all they see is overhead. Not the shrinking of the state space. Not the earlier detection of interaction faults. Not the clarity gained from staged behavior. ⸻ We don’t lack standards. We lack structural thinking. Testing is not a jump. It’s a build-up. From trusted parts to trusted connections to trusted systems. This requires: – staged integration – interface-focused testing – validation under real constraints – and a mindset that stops treating assembly as proof Otherwise, the system isn’t tested. It’s just stitched together. Welcome to the fix. #MrBrokenTesting #IntegrationBlindness #TestingStrategy #AutomotiveSPICE #ISO26262 #TestArchitecture

69

35 comentários

Last week, Bootlin engineer João Marcos Costa delivered our popular "Embedded Linux system development" training course on-site in Germany for Mobileye! Thanks to this training course, participants could learn about: 👉 Embedded Linux architecture 👉 Cross-compilation toolchains 👉 Booting embedded platforms: bootloaders, TF-A, OP-TEE 👉 Linux kernel configuration, build and booting 👉 Linux root filesystem architecture 👉 Accessing hardware in Linux: kernel drivers, Device Tree, etc. 👉 Filesystems for block and flash storage 👉 Cross-compilation and build systems such as Yocto or Buildroot 👉 Developing and debugging user-space applications

124

8 comentários

Every embedded system advice you find on the internet has context. You can't just apply as-is and expect to get the same result. ironically, this includes all of my advices here on LinkedIn. You need to get the context before applying my advices. For example, I encourage you to be a freelancer to boost your income (I even wrote a book on this exact topic to guide you). But the nuance is: you don't have to leave your main job. And you need to have spare time to use. My other advice: I push you to do 100 side projects to master embedded systems, but the nuance is: you shouldn't do tutorial projects, but you need to deliberate around what project to make. My other advice: I promote "good design first, performance last" mindset. The context is: that approach is extremely useful for startup company building firmware (performance is usually the last priority). But fails when you work on extreme low-latency project (which involves a lot of optimization wizardry). What else? Ah, the most controversial take: "you can debug 99% of bugs using printf, UART, and LED. No need to use advanced debuggers". The nuance: Most of my commercial projects doesn't have access to JTAG or SWD or GDB, so what's left is just UART and LEDs. So I was forced to train my brain to interpret data from limited tools. Sorry folks, social media makes people (including me) trim the context and publish quick advices, for the sake of punchier content. That's why I still love reading full books for something I really care, because it sets the context and nuance.

77

1 comentário