Airbag systems are critical safety systems and they save lives. They are also a mandatory feature on all vehicles sold in the developed countries making them a prime target for all automotive developers to have in their portfolio. However, the critical nature of these systems limits the companies which can develop them and even these limit to only a few semiconductor suppliers the sourcing of the electronic components used in the design. One of these important semiconductor suppliers capable of delivering ultra-reliable ICs is Freescale.

The Freescale electronic components dedicated to automotive airbag control units (ACUs) cover such a broad range of functionalities, that it is possible to design such a system using exclusively their components. And given the complexity of these systems, this means components with many functions and diverse functionalities. Although it is possible to regard the ACUs as black boxes, their functionality is far from simple. Just to enumerate a few of the complex tasks they have to achieve, we could mention:
- detect whether the car is suffering a crash (in a very short interval)
- deploy the airbags in case such an event occurred in given conditions (i.e. speed above a given threshold, passenger seatbelt fastened etc)
- differentiate between real crash and false crash (early ACUs were prone to errors when cars were being driven on bumpy roads)
- ensure the capability of deploying the airbags even in case the ACU connection to the car battery is severed.

All of these task are quite complex. For instance, detecting a potential crash is done by reading information from pressure and acceleration sensors spread around the car. Some of these sensors (the acceleration sensors) will supply data to the ECU even when there is a bump in the road, so this data has to be put through highly elaborated and well calibrated algorithms in order for the unit to determine whether this data represents real crash information or just a mere unimportant event.

Deploying the airbags is not, as one might expect, just a simple toggling of a logic line, but for this to happen a high current (>1A) is necessary for each explosive device that opens up as an airbag (these are known as squibs). Maybe in regular circumstances this would not prove itself so much of a threat, but in case you assume the ACU to be cut off from the car battery the task of triggering the squibs becomes a real challenge.

To make things even more complicated, due to the fact that airbags are a safety related system, car manufacturers require that any decision regarding the triggering of the airbags themselves should be taken not by one logic device (generally a microcontroller) but by two different ones. This is a “safing” concept that requires the existence of at least two microcontrollers in the ACU, one of each is called safing microcontroller and has the purpose of running parallel algorithms validating a real deployment. Even in the event of a crash, the squibs are not triggered unless some other specific conditions are fulfilled (like for instance if the seatbelt for the passenger is not fastened, its airbag will not deploy etc).

Along the time, two main architectures have emerged for the general ACU, both of them being fully supported by Freescale.

The first one is called Distributed System Interface (DSI); this protocol is the leading automotive safety bus. It was pioneered by Freescale and TRW. The DSI protocol supports point-to-point, parallel and daisy chain networks. To date, a dozen automotive OEMs have included DSI-based systems in their vehicles:

The second one is the well known Peripheral Sensor Interface 5 (PSI5), which is an interface for automotive sensor applications. PSI5 is an open standard based on existing sensor interfaces for peripheral airbag sensors:

As it may be seen from the diagrams above, you may find with Freescale electronic components suitable for every necessary block. We will go through all the blocks and explain the functionality of each one at a time.

The acceleration sensor (used in DSI) – it is a MEMS device that is capable of measuring acceleration along one or more axis. Freescale offers two families of devices (MMA12xxEG and MMA23xxEG). The MMA12xxEG family includes devices whose sensitive range spreads from 2.5g up to 250g reassuring the designer he can find a suitable device for vehicles with any weight. They feature extensive internal signal conditioning, integrated low-pass filters and temperature compensation. Unlike the acceleration sensor from Analog Devices, the Freescale ones have the appearance of regular SMD ICs:

Usually, the acceleration or pressure sensors are not used as standalone devices. They are neatly packed in separate housings together with some DSI or PSI5 interface ICs and the resulting devices are called either “satellites” or “integrated DSI/PSI acceleration/pressure sensor”. Although Freescale would supply such off-the-shelve satellites, information regarding these is somewhat restricted (available probably only to dedicated ACU design companies).

DSI Satellite sensor interface (used in DSI) – has the purpose of converting the analog output of sensors connected to it. The MC33784 for instance is a slave, Distributed System Interface Bus (DBUS), version 2.02 compatible device, optimized as a sensor interface. The device contains circuits to power sensors such as accelerometers, and to digitize the analog level from the sensor. The device is controlled by commands over the bus, and returns measured data and other information over the bus. However it is destined to operate with devices which are situated close to the main ACU. The MC33793, on the other hand, is destined to be used in combination with a sensor located far away (in relative terms) from the control unit. It provides both power and communication I/Os to the sensor over a DSI bus. It also performs the task of converting the analogue output of the sensor in digital format and sends this information further away via the DSI bus. Also, for ease of use in design it provides 4 GPIOs that can be remotely configured and controlled via the DSI bus. A simplified application diagram which also suggests how these GPIOs could be used would look like this:

Both the MC33784 and the MC33793 are slave devices on the DSI bus. The configuration of this bus, however requires also a master device to be located inside the ECU. These are typically devices which offer several DSI bus interfaces on a single chip, like the MC33781 (4 channels) and the MC33780 (two channels). If we analyze the MC3371 we notice is contains logic to transfer data to/from the DSI bus by means of an SPI link to a main microcontroller. Its internal circuits allow it to drive data and power on the bus, as well as receiving information from remote slave devices. Since it operates in a differential mode, the MC33781 generates quite low EMI which is critical in safety related applications.

This is where the differences between the DSI and PSI5 architectures are over. The rest of the ACU design contains the same components:
The power supply – this block would be required to generate quite a few voltage levels, as the numerous integrated circuit and discrete circuits in an ACU would most likely require more than just 5V or 3.3V
The main MCU – which is basically a microcontroller which centralizes the information from all remote and on-board sensors, and which runs the algorithms that decide whether the information from the sensors represent a valid crash. It also reads information from the seatbelts, and uses an SPI bus called “firing SPI bus” to enable the high current drivers which actually activate the squibs. Freescale MCUs that can be used in this role are the MC9S12XE and the MPC56xx families. Especially the MC9S12XE are well known and widely used automotive microcontrollers which found their way on the approved list of car manufacturers quite a while ago.

They are present not only in airbags but in many other vehicle subsystems and this is both because of their reliability and their ultra-rich subset of features:
* XGATE co-processor capable for build virtual peripherials and boost the overall performance
* Flexible programmable hardware emulated EEPROM
* System integrity support with the memory protection unit & supervisor/user modes
* S12X CPU @ 50Mhz bus speed
* Memory Protection Unit (MPU)
* Loop Control/Full-Swing Pierce Oscillator
* Enhanced Interrupt Module
* Non-Multiplexed External Bus Interface (EBI)
* Analog-to-Digital Converter (ATD) 12-bit resolution and 3us conversion time
* Enhance Capture Timer (ECT)
* Periodic Interrupt Timer (PIT)
* Real Time Interrupt (RTI)
* Asynchronous Periodic Interrupt (API)
* Pulse Width Modulator (PWM)
* MSCAN Module
* Serial Peripherial Interface (SPI)
* Serial Communication Interface (SCI)
* Background Debug (BDM)Debugger (xDBG)
* On-chip Voltage Regulator

The safing MCU – as mentioned before, a second logic unit in the ACU is required to confirm a valid crash, by running parallel algorithms apart from the main MCU. The safing MCU also generally reads information from the buckle-switches which indicate the seatbelt status. A lower performance microcontroller is needed in case of the safing MCU, as it has less tasks to perform than the main logic unit; it does not perform any communications with any device of the ACU neither via CAN, LIN, DSI nor PSI5 buses. Recommended microcontroller family from Freescale is the HCS08 which is actually an 8-bit microcontroller (compare this to the main MCU which can even go up to 32-bit core).

The rollover sensor – is actually based on an accelerometer sensor that we have discussed above and its purpose is to give the system a local information source about a potential crash event. In case of an accident, the physical wires connecting the external satellites to the ACU could be the first one severed, leaving the unit without relevant and important information about the event. The purpose of the rollover sensor (based, for instance, on the MMA1250EG acceleration sensor from Freescale) in combination with the other local acceleration sensors is to provide exactly this missing information.

The squib driver – represents yet another important block in the diagrams above. The dedicated MC33797 for channel squib driver IC from Freescale is a dedicated device for complete diagnostic of the squibs and also for their deployment. It incorporates diagnostic and system control features that provide fail-safe operation and it is controlled by the MCU via the “firing SPI bus”. The value of the current that will flow through the squibs at deployment is set by an external resistor.

Automotive airbag systems continue to enhance passenger safety through the incorporation of increasingly sophisticated features. Automotive suppliers face continuing pressure from the market to improve performance while at the same time reducing costs. Both of these trends are expected to continue in the future as the focus on safety stays in the forefront. Having the possibility of using a single supplier for most of the important position in the Bill of Materials can only reduce costs, while simplifying communication with the supplier. As we have seen, it is possible to design such an airbag control unit from scratch (don’t try this at home, though) using mainly Freescale components, including MCUs, sensors, bus interfaces, squib drivers etc, and offering all the advanced features the market requires from such safety sensitive devices.

Read the Italian version: I prodotti Freescale presenti nelle unità di controllo airbag

CONTACT REQUEST
If you want to know more about this Freescale product, please submit your request to Arrow Italy using this form.

NOTE: this form is valid ONLY for Companies or Customers based in Italy and working in the Italian area.