CO/NO₂ Gas Detection System Design for Parking Garages

Developing a closed parking garage CO/NO₂ gas detection system requires evaluating interconnected design parameters together — from gas detector hardware to the control panel, from firmware architecture to EN 50545-1 (the European standard for toxic and flammable gas detection devices in car parks and tunnels) certification. In this article, drawing on our gas detection device design experience, we cover the process from detector and control unit design through to the test body process.

An important note: since EN 50545-1 certification is granted to the system consisting of the detector and control unit (panel) — not to the detector alone — panel design, communication architecture, and system-level alarm management must be planned together from the start of the project.

1. Which Gases Must Be Monitored in a Parking Garage?

The EN 50545-1 standard requires monitoring of carbon monoxide (CO), nitrogen dioxide (NO₂), and nitric oxide (NO) — toxic gases from vehicle exhaust — in closed parking garages. CO is colorless and odorless, making its accumulation undetectable in enclosed spaces; for this reason, the standard uses time-weighted average (TWA)-based evaluation rather than a fixed threshold value. NO₂ is a gas emitted particularly from diesel and GDI gasoline vehicles that irritates the respiratory tract and poses a serious health risk at low concentrations. Although NO is defined in the standard, it is generally not measured in market applications; the vast majority of existing systems are built around CO and NO₂, and user demand follows the same direction.

Alarm Levels and TWA Requirements

EN 50545-1 defines a three-tier alarm structure for parking garage gas detection systems: Alarm 1, Alarm 2, and Alarm 3. The threshold values and evaluation method for each tier are given below.

CO alarm values:

• Alarm 1 (30 ppm): 15-minute TWA (Time-Weighted Average) window
• Alarm 2 (60 ppm): 15-minute TWA window
• Alarm 3 (150 ppm): 1-minute continuous monitoring

NO₂ alarm values:

• Alarm 1 (3 ppm): 15-minute TWA window
• Alarm 2 (6 ppm): 15-minute TWA window
• Alarm 3 (15 ppm): 1-minute continuous monitoring

This structure creates a critical difference from a firmware perspective. For Alarm 1 and Alarm 2, TWA calculation is performed at the software layer, monitoring the average gas concentration over a 15-minute sliding window. This filters out short-duration spikes and evaluates the actual exposure level. Alarm 3 works differently: it checks whether the threshold value has been continuously exceeded for 1 minute.

On the firmware side, this requires a significantly more complex architecture than a simple threshold comparison. A timestamped sample buffer, a sliding average update loop, and independent management of alarm state based on both TWA and continuous monitoring values are mandatory. The alarm algorithm must be considered at the beginning of the software development process.

The much lower NO₂ thresholds compared to CO create a separate design constraint. The measurement resolution and stability of the NO₂ sensor impose far stricter requirements than the CO sensor; noise and drift in the analog front-end circuit directly affect alarm reliability at low ppm levels.

2. Sensor Selection for Parking Garage CO/NO₂ Gas Detection

Sensor selection is one of the most critical design parameters in parking garage gas detection system development. The wrong technology choice cannot be corrected in the field through calibration.

Three sensor technologies can be evaluated for CO and NO₂ measurement:

NDIR sensors are effective for CO₂ measurement; however, they are not suitable for CO and NO₂ in commercial parking applications. The low selectivity and high cross-sensitivity of MOS sensors make them unsuitable for gas detection in closed parking garages. Electrochemical sensors are the industry standard for parking applications.

The decision does not end with sensor technology selection. There are significant differences in measurement range, T90 response time, resolution, and cross-sensitivity among sensors offered by different manufacturers such as Alphasense, Membrapor, SGX Sensortech, and Winsen for the same gas. These comparison criteria are covered in detail in our gas sensor selection guide.

Cross-Sensitivity

Cross-sensitivity is a gas sensor's response to gases other than the target gas. This criterion becomes even more important in multi-gas environments like parking garages for low-concentration gas monitoring applications. Cross-sensitivity tables in sensor datasheets must be carefully evaluated according to the application environment. We cover this topic in detail in our electrochemical gas sensor guide and gas sensor selection guide.

Sensor Lifespan and Service Planning

Electrochemical sensor lifespan is approximately 2 years, depending on manufacturer warranty and field conditions. In our field applications, we observe that electrochemical sensor lifespan can fall below the manufacturer warranty; this period is significantly shorter in sensors continuously exposed to high concentrations. Additionally, sensor calibration must also be part of the maintenance plan. The calibration period for electrochemical sensors is approximately 3 months.

In parking device design, the sensor's mounting position, connector type, and post-replacement and periodic calibration procedures on the firmware side directly affect service costs and are design decisions that must be planned from the outset.

3. Analog Front-End Circuit Design for Electrochemical Gas Sensors

The output of electrochemical CO and NO₂ sensors is a current signal in the nanoampere range. A potentiostat circuit must be designed to correctly convert this signal to voltage. CO and NO₂ sensors are activated by applying a 0 mV bias voltage between the reference and working electrodes. Accurate and stable measurement can be achieved with a low-offset, low-leakage current (picoampere) transimpedance amplifier (TIA) circuit, a power supply design with low ripple voltage, and an ADC with appropriate resolution and sampling frequency.

4. Control Unit (Panel) Design

EN 50545-1 certification is granted to the system consisting of the detector and control unit. The panel collects measurement data from detectors, manages zone-based alarm decisions, and drives relay outputs. It notifies the operator of fault conditions via LED indicators or a display. The panel can also relay fault status to external systems (such as BMS) via relay output. No matter how well the detector is designed, the requirements that the panel must meet at the system level must also be fulfilled separately.

Communication Architecture: 4–20 mA vs Modbus RTU

The choice of communication protocol between the panel and detectors directly determines the scalability of the system.

In 4–20 mA analog communication, a separate analog input channel to the panel is required for each detector. This approach is simple and reliable; however, since it requires 1 ADC channel per communication port, it limits the number of detectors that can be connected per panel. In parking systems with 16 or 32 detectors, analog input capacity is quickly exhausted, requiring additional expansion cards or multiple panels.

With RS485/Modbus RTU digital communication, up to 247 addressable devices (provided they are 1/8 unit load) can be connected on a single line. Each detector has a unique Modbus address; the panel acts as master and performs sequential polling. In this architecture, the panel ADC channel limit is eliminated, wiring is simplified, and additional data such as fault status, alarm status, and calibration information can be transferred from each detector alongside the concentration value.

The disadvantage of Modbus RTU is protocol complexity: CRC calculation, timeout management, communication error detection, and retry mechanisms must be provided in both detector and panel firmware. 4–20 mA requires no protocol layer; however, it falls behind digital communication in terms of scalability.

Panel Hardware Requirements

The control unit must execute tasks in parallel such as simultaneous monitoring of multiple detectors, independent zone-based alarm management, user notification via display/indicator, and communication protocol. These requirements cannot be met with a simple 8-bit microcontroller. The STM32F4 series or Nuvoton M4 series, with sufficient SRAM and Flash capacity, multiple UART/SPI/I2C peripherals, hardware CRC unit, and real-time processing capacity, are suitable options for this application. Parameters to consider in MCU selection include UART channel count (RS485 master + display communication if applicable), GPIO capacity (relay drivers, LED indicators), ADC channel count (battery and power input monitoring etc.), Flash and SRAM size (if alarm history recording and configuration parameters are to be implemented), and hardware watchdog timer.

Display vs. Non-Display Panel Design

The panel can be designed with a display (LCD/TFT) or without one. In a panel with a display, zone-based concentration values, alarm statuses, error codes, and system configuration can be viewed directly.

In a non-display panel design, LED indicators become mandatory. LEDs such as alarm status LEDs for zone detectors (Alarm 1, Alarm 2, and Alarm 3), fault LEDs for detectors or zones, and power status LEDs (backup battery and power supply) must be present.

Whichever approach is chosen, clearly notifying the operator of any fault condition (sensor failure, communication loss, power supply issue) is one of the fundamental requirements of EN 50545-1.

Panel Power Supply and Battery Backup

Parking garage gas monitoring panels typically operate on 230 V AC mains supply, and an internal power supply unit provides DC output. If a backup battery is present on the panel, the firmware layer of the panel must also include a low battery scenario.

5. Detector Firmware Architecture

Detector firmware assumes three core functions: sensor measurement and filtering, alarm management, and RS485 panel communication.

Measurement and Signal Filtering

Raw sensor data read from the ADC cannot be fed directly into alarm evaluation. Since the output of CO and NO₂ electrochemical sensors is in the nanoampere range, they are susceptible to electrical noise; when used unfiltered, they cause false alarms.

In filter design, the sensor's T90 response time is the determining parameter. T90 is the time for the sensor to reach 90% of the target gas concentration, typically around 30 seconds for CO and NO₂ sensors. The filter time constant must be kept significantly shorter than T90; otherwise the filter adds additional delay on top of the sensor's own response, and the total system response time may exceed the ≤60 second limit required by EN 50545-1.

In practice, a moving average, exponential weighted average (EMA), or low-pass IIR filter can be used. The selection must be made considering the advantages and disadvantages of the filter type to be used. Moving average implementation is straightforward but requires a fixed-length buffer, and delay is directly proportional to window size. EMA or IIR filter can be tuned with a single coefficient, uses less memory, and the delay-noise suppression balance is controlled by coefficient selection.

RS485 Communication

The detector communicates with the panel via RS485 (Modbus RTU). The detector operates as a slave and, when polled by the panel, can return registers such as instantaneous concentration value, alarm status, and fault information depending on the communication software layer. CRC verification, address filtering, and timeout management must be provided in the communication firmware.

6. Panel Firmware: EN 50271 Compliance Requirements

Panel firmware must meet EN 50271 (general standard for gas detection control units) requirements. This standard requires that control unit software comply with certain rules in terms of reliability and functional safety.

Watchdog and Fail-Safe Architecture

Hardware must automatically restart the system in the event of unexpected firmware hang. The watchdog timeout period must be chosen to suit the normal operating cycle; too short a period causes unnecessary resets, while too long a period results in delayed intervention in actual fault conditions.

In accordance with the fail-safe architecture principle, the system must default to the safe side in any fault condition. In the event of a communication loss, the relevant zone should enter alarm state or the fault relay should be activated. If the fault is at the software layer, the system must not remain in an unknown state; after the watchdog reset, the self-test routine must run and the system state must be verified.

RAM and ROM Integrity Testing

EN 50271 requires that RAM and ROM integrity be periodically verified at runtime. In the scope of RAM testing, the write/read accuracy of memory cells is checked. Checkerboard or walking-bit pattern can be used as the test method. ROM/Flash testing compares the CRC or checksum value of the firmware image with the stored reference value, switching the system to a fault state when corruption is detected.

The tests to be performed must be done incrementally in the background without disrupting the main operating loop. For example, testing the entire RAM at once can cause timeouts in the panel RS485 communication protocol monitoring multiple detectors simultaneously.

Fault Relay and Alarm Management

The panel must contain at least one fault relay and zone-based alarm relays. The fault relay activates when there is a system-wide failure (power supply issue, communication error, sensor failure, self-test failure, MCU lockup, RAM test failure, etc.) and signals the external monitoring system or BMS.

In zone-based alarm management, Alarm 1, Alarm 2, and Alarm 3 states for each zone must be evaluated independently. Gas accumulation in one zone should only trigger ventilation for that zone.

Firmware Coding Standards

EN 50271 expects certain software engineering practices during firmware development. These include structured programming, variable boundary checks, redundant storage of critical data, and software versioning. MISRA C rules offer a suitable framework for meeting these requirements; they provide systematic discipline on topics such as preventing constructs that can lead to undefined behavior, pointer safety, and type conversion control.

Certification is granted to a specific firmware version. A change to alarm thresholds or algorithm may require renewal of type testing; bug fixes and interface updates are subject to risk assessment. The firmware versioning strategy must be planned at the start of the project with certification requirements in mind.

Key Considerations in the Certification Process

The most common mistake in the certification process is attempting to achieve compliance with standard requirements after design is complete. In our projects, we make design decisions in line with EN 50545-1 and EN 50271 requirements from the start of the project; this approach minimizes the need for revisions at the certification stage. Firmware version, hardware revision, and calibration procedure are recorded in the certification document; subsequent changes may require retesting depending on scope.

R&D Partnership for Parking Garage Gas Detection System Development

Developing a parking garage gas detection system requires multiple disciplines working together: sensor engineering, hardware design, embedded software development, panel design, and certification management. Running all these disciplines under one roof may not be efficient for every company.

In our gas detection device development service, the process proceeds as follows: in the concept and requirements analysis phase, the gases to be detected, alarm scenarios, panel capacity, certification targets, and timeline are determined together. In the design and prototype phase, detector and panel hardware schematics, PCB design, and firmware architecture are developed. In the testing phase, functional tests and pre-certification evaluation are performed on the prototype. In the certification phase, technical support is provided during the application process to an accredited body such as Kiwa. In the final phase, production files (Gerber, BOM, firmware binary, test procedures) are prepared and the infrastructure for transition to serial production is established.

If you are looking to develop an EN 50545-1 compliant parking garage gas detection system, we can evaluate your project together. Contact us →

References

1. BS EN 50545-1, Electrical apparatus for the detection and measurement of toxic and combustible gases in car parks and tunnels.
2. BS EN 50271, Electrical apparatus for the detection and measurement of combustible gases, toxic gases or oxygen — Requirements and tests for apparatus using software and/or digital technologies.
3. SGX Sensortech. Electrochemical Sensors Application Note 2: Design of Electronics for Electrochemical Gas Sensors.
4. Membrapor. Basics of Electrochemical Gas Sensors.