Design Article
Sensor architecture allows real-time auto emissions monitoring, Pt. 2
Ravindra Arora, Manmohan Rana, and Sunil Deep Maheshwari, Freescale Semiconductor
4/19/2012 3:00 AM EDT
As opposed to current periodic emission-control system testing—sensors, MCUs, and memory come together in an updated approach to real-time exhaust monitoring for improved pollution control.
Part 1 of this two-part series outlined the problem of auto emissions and the periodic "monitoring" of pollutants and vehicle systems for controlling them, via an annual inspection—as well as the proposed real-time monitoring system architecture.
Communication block
There might be many kinds of communication requirements, depending upon the final solution for the real-time emissions monitoring system. First is the interface between the information display MCU and the power train MCU. If one does not have single-chip support for display devices, as mentioned in Part 1, then one would also require a communication support between that display MCU and MCU under discussion.
The real-time solution also proposes to have a dynamic communication between the vehicle and any government pollution control and monitoring agency. To support this dynamic communication, one would also need to have a wireless communication support between the final solution and the central servers of an agency. This can be achieved using GPRS/CDMA/GSM mode of communication and therefore, support for this communication would also be required, either using the same chip by doing some architectural enhancements or using a separate chip interacting with the exhaust-monitoring MCU. All these requirements have to be kept in mind while designing the final product/solution to cater to the complete requirements.
Sensing emissions
An array of sensors detects the amount of various exhaust-components (such as carbon dioxide, carbon monoxide, etc) at the exhaust-pipe and sends it to the ADCs of the MCU. To maintain a constant flow of gases to the sensors, a pump and a flow-meter may also be used (as shown in below).
Multiplexers can also be used to mux-out one sensor-data at a time and then gathering the conversion data of all the sensors sequentially. This way, one can use very few pins to interface this sensor array with the MCU. Then, ADCs would digitize the data coming in from sensors and save it in the internal memories of the MCU so that it could be processed later.
Data regarding the power-train characteristics would also be saved in the internal memories for further exhaustive analysis. The software then would process the data and calculate whether the emissions are within the safe-limit or not. This information can be displayed to the driver using the auto-cluster display (above).
The driver can take appropriate action based on this information, which indicates over loading of the vehicle, poor-quality fuel, poor-health of vehicle, etc. In the event of persistent issue, the same information can be sent to the pollution control and monitoring agency, in the respective country/state so that appropriate action could be taken. To implement this, one would need to have communication support like on-chip GPRS communication support or interface-support IPs (such as I2C, SPI, SCI, etc.) to connect to another SoC which could handle this communication.
Part 1 of this two-part series outlined the problem of auto emissions and the periodic "monitoring" of pollutants and vehicle systems for controlling them, via an annual inspection—as well as the proposed real-time monitoring system architecture.
Communication block
There might be many kinds of communication requirements, depending upon the final solution for the real-time emissions monitoring system. First is the interface between the information display MCU and the power train MCU. If one does not have single-chip support for display devices, as mentioned in Part 1, then one would also require a communication support between that display MCU and MCU under discussion.
[Source: Ref. [5]]
The real-time solution also proposes to have a dynamic communication between the vehicle and any government pollution control and monitoring agency. To support this dynamic communication, one would also need to have a wireless communication support between the final solution and the central servers of an agency. This can be achieved using GPRS/CDMA/GSM mode of communication and therefore, support for this communication would also be required, either using the same chip by doing some architectural enhancements or using a separate chip interacting with the exhaust-monitoring MCU. All these requirements have to be kept in mind while designing the final product/solution to cater to the complete requirements.
Sensing emissions
An array of sensors detects the amount of various exhaust-components (such as carbon dioxide, carbon monoxide, etc) at the exhaust-pipe and sends it to the ADCs of the MCU. To maintain a constant flow of gases to the sensors, a pump and a flow-meter may also be used (as shown in below).
Multiplexers can also be used to mux-out one sensor-data at a time and then gathering the conversion data of all the sensors sequentially. This way, one can use very few pins to interface this sensor array with the MCU. Then, ADCs would digitize the data coming in from sensors and save it in the internal memories of the MCU so that it could be processed later.
Data regarding the power-train characteristics would also be saved in the internal memories for further exhaustive analysis. The software then would process the data and calculate whether the emissions are within the safe-limit or not. This information can be displayed to the driver using the auto-cluster display (above).
The driver can take appropriate action based on this information, which indicates over loading of the vehicle, poor-quality fuel, poor-health of vehicle, etc. In the event of persistent issue, the same information can be sent to the pollution control and monitoring agency, in the respective country/state so that appropriate action could be taken. To implement this, one would need to have communication support like on-chip GPRS communication support or interface-support IPs (such as I2C, SPI, SCI, etc.) to connect to another SoC which could handle this communication.
|
|
|
|
|
Navigate to related information