Electronics Architecture for Automotive Fragrance Systems
Project in a Nutshell: Promwad designed the electronics architecture for a premium in-cabin fragrance system built around the NXP S32K automotive microcontroller. The scope covered requirements analysis, system architecture, component selection, and a preliminary BOM, including LIN vehicle integration and NFC-based cartridge identification. The client, a European Tier 1 supplier, received a validated architecture and a buildable component list ready for the PCB layout and implementation phase.
>
Client & Challenge
A European Tier 1 supplier was developing a fragrance system for a premium automotive OEM. The mechanical design was in place, but the electronics scope remained open: no architecture, no component selection, no BOM, and the specification was still evolving.
Without a structured electronics design process, the project risked arriving at implementation with unvalidated assumptions: components that don't meet automotive-grade requirements, an architecture misaligned with vehicle integration constraints, or a BOM that changes significantly at DVT. The client needed an engineering partner who could make sound design decisions and produce a defensible architecture while the spec was still in motion.
Solution
The unit sits in the center console. A fan controlled via PWM (Pulse Width Modulation) pushes air through a perfume bottle and into the cabin. Two stepper motors run in sync: one opens the air duct while the other locks the bottle. When the car turns off, the system closes the bottle cap to prevent evaporation.
The unit communicates with the vehicle over LIN (Local Interconnect Network). The driver adjusts intensity and scenting intervals from the HMI in the center console. The system identifies the installed fragrance via NFC and tracks remaining volume, reporting both to the vehicle in real time.
Promwad designed the electronics around this principle.
Control Board
The NXP S32K microcontroller (automotive-grade, with a guaranteed supply for over 10 years) was selected to control all subsystems. The LIN transceiver provides bidirectional communication with the vehicle’s HMI interface: command input and status output. Two stepper motor drivers operate synchronously and monitor mechanical resistance to protect the mechanism in case of jamming. A separate PWM driver regulates the fan speed. The protection circuit provides protection against reverse polarity, electrostatic discharge, and short circuits.
NFC subsystem
A reader on a dedicated board reads the tag built into the bottle cap and identifies which fragrance is installed. Antennas sit on separate boards because the metal housing blocks NFC signal. Both reader and tag chips were selected from NXP's automotive NFC family.
Firmware scope
The team defined what the firmware would handle: motor synchronization, fan control, NFC read cycles, capacitive fill-level polling, and LIN messaging to the vehicle (scent ID, fill level, lock state, error codes). The architecture reserved a firmware update path via the vehicle/service infrastructure, with the exact update mechanism to be defined during implementation.
The pattern is reusable: MCU plus NFC cartridge ID plus electromechanical lock plus a vehicle or industrial bus. Any product built around a swappable, identifiable, lockable module can use this stack.
- In-cabin air quality. Ionizers, purifiers, and multi-zone scent systems with swappable cartridges
- Smart dispensers. Fragrance, sanitizer, or cleaning fluid units with NFC cartridge ID and level monitoring
- HoReCa & offices. Automated scent management for hotels, restaurants, and commercial spaces
- Medical inhalers. Devices with NFC-based drug cartridge validation and dose level tracking
- Industrial dosing. Precision dispensing units with electromechanical locks and field bus communication
Results
The client has a validated electronics architecture and a component list ready for PCB layout.
Promwad defined the control board, NFC subsystem, LIN communication path, motor and fan control logic, protection circuits, and firmware responsibilities before schematic development began.
This gave the Tier 1 supplier a clear engineering baseline and reduced three specific late-stage risks: NFC antenna conflicts caused by the metal housing, BOM changes at DVT, and motor control issues that typically surface only during hardware testing.
More of What We Do for Automotive Electronics
- Automotive ECU Development: explore our engineering expertise in developing electronic control units for the automotive industry.
- Standalone Modular DAQ: see how we developed the LV-LOG for Klaric to enable time-synchronised measurements for EV and hybrid testing without the need for a PC.
- Automotive Ethernet: read our overview of Automotive Ethernet, where we explain how it helps simplify vehicle architecture.
FAQ
What communication protocols does Promwad use for vehicle integration in automotive electronics projects?
Promwad works with CAN, LIN, and automotive Ethernet. For cabin-level devices like climate control or interior systems, LIN is the standard choice: it's cost-effective, well-suited for low-speed control signals, and widely supported by automotive OEMs. The team selects the protocol based on bandwidth requirements, latency constraints, and what the vehicle architecture already supports.
Does Promwad handle both hardware and firmware development for automotive ECUs, or just one side?
Both. Promwad's ECU development covers the full scope: system architecture, hardware design, schematic and PCB development, embedded firmware, and integration testing. The team works across the stack so the hardware and software are designed together rather than handed off between separate vendors — which matters when timing, signal integrity, and power constraints all interact.
What microcontroller families does Promwad typically use for automotive embedded systems?
The team works with MCUs from NXP, Renesas, TI, Infineon, and Microchip. Vendor selection depends on the specific requirements: operating temperature range, available peripherals, automotive qualification grade, and long-term supply availability. For projects targeting 10+ year production lifetimes, supply continuity is often a deciding factor alongside technical fit.
What RTOS platforms does Promwad use for automotive firmware development?
The team works with FreeRTOS, A-FreeRTOS, Zephyr, TiRTOS, and Azure RTOS, as well as bare-metal implementations where the application doesn't require an OS. The choice depends on the MCU, the real-time requirements of the application, and whether the project needs to align with any platform constraints set by the client or the OEM.
What does Promwad's hardware design process include beyond schematic and PCB layout?
Beyond schematic and PCB layout, the process includes 3D modeling, thermal simulation, signal integrity analysis, electromagnetic compatibility analysis, and power integrity analysis. Once the design is complete, clients receive full documentation for PCB mass production in compliance with IPC standards — including everything a contract manufacturer needs to go to production.
