Characteris cs and Quality A ributes of Embedded Systems 73

Characteristics and
3 Quality Attributes of
Embedded Systems

LEARNING OBJECTIVES

LO 1 Understand the characteris cs describing an embedded system

LO 2 Explain the non-func onal requirements that needs to be addressed in the design of
an embedded system
Learn the important quality a ributes of the embedded system that needs to be
addressed for the opera onal mode (online mode) of the system. This includes
Response, Throughput, Reliability, Maintainability, Security, Safety, etc.
Know the important quality a ributes of the embedded system that needs to
be addressed for the non-opera onal mode (offline mode) of the system. This
includes Testability, Debug-ability, Evolvability, Portability, Time to prototype
and market, Per unit cost and revenue, etc.
Understand the Product Life Cycle (PLC)

No matter whether it is an embedded or a non-embedded system, there will be a set of characteristics

describing the system. The non-functional aspects that need to be addressed in embedded system design are
commonly referred as quality attributes. Whenever you design an embedded system, the design should take
into consideration of both the functional and non-functional aspects. The following topics give an overview
of the characteristics and quality attributes of an embedded system.

3.1 CHARACTERISTICS OF AN EMBEDDED SYSTEM

Unlike general purpose computing systems, embedded systems possess certain
specific characteristics and these characteristics are unique to each embedded LO 1 Understand
system. Some of the important characteristics of an embedded system are as the characteristics
follows: describing an
(1) Application and domain specific embedded system
(2) Reactive and Real Time
(3) Operates in harsh environments
74 Introduc on to Embedded Systems

(4) Distributed
(5) Small size and weight
(6) Power concerns

3.1.1 Application and Domain Specific

If you closely observe any embedded system, you will find that each embedded system is designed to perform
a set of defined functions and they are developed in such a manner to do the intended functions only. They
cannot be used for any other purpose. It is the major criterion which distinguishes an embedded system from
a general purpose computing system. For example, you cannot replace the embedded control unit of your
microwave oven with your air conditioner’s embedded control unit, because the embedded control units of
microwave oven and airconditioner are specifically designed to perform certain specific tasks. Also, you
cannot replace an embedded control unit developed for a particular domain say telecom with another control
unit designed to serve another domain like consumer electronics.

3.1.2 Reactive and Real Time

As mentioned earlier, embedded systems are in constant interaction with the Real world through sensors and
user-defined input devices which are connected to the input port of the system. Any changes happening in
the Real world (which is called an Event) are captured by the sensors or input devices in Real Time and the
control algorithm running inside the unit reacts in a designed manner to bring the controlled output variables
to the desired level. The event may be a periodic one or an unpredicted one. If the event is an unpredicted one
then such systems should be designed in such a way that it should be scheduled to capture the events without
missing them. Embedded systems produce changes in output in response to the changes in the input. So they
are generally referred as Reactive Systems.
Real Time System operation means the timing behaviour of the system should be deterministic; meaning
the system should respond to requests or tasks in a known amount of time. A Real Time system should not
miss any deadlines for tasks or operations. It is not necessary that all embedded systems should be Real
Time in operations. Embedded applications or systems which are mission critical, like flight control systems,
Antilock Brake Systems (ABS), etc. are examples of Real Time systems. The design of an embedded Real
time system should take the worst case scenario into consideration.

3.1.3 Operates in Harsh Environment

It is not necessary that all embedded systems should be deployed in controlled environments. The environment
in which the embedded system deployed may be a dusty one or a high temperature zone or an area subject
to vibrations and shock. Systems placed in such areas should be capable to withstand all these adverse
operating conditions. The design should take care of the operating conditions of the area where the system is
going to implement. For example, if the system needs to be deployed in a high temperature zone, then all the
components used in the system should be of high temperature grade. Here we cannot go for a compromise
in cost. Also proper shock absorption techniques should be provided to systems which are going to be
commissioned in places subject to high shock. Power supply fluctuations, corrosion and component aging,
etc. are the other factors that need to be taken into consideration for embedded systems to work in harsh
environments.

3.1.4 Distributed
The term distributed means that embedded systems may be a part of larger systems. Many numbers of such
distributed embedded systems form a single large embedded control unit. An automatic vending machine
 Characteris cs and Quality A ributes of Embedded Systems 75

is a typical example for this. The vending machine contains a card reader (for pre-paid vending systems), a
vending unit, etc. Each of them are independent embedded units but they work together to perform the overall
vending function. Another example is the Automatic Teller Machine (ATM). An ATM contains a card reader
embedded unit, responsible for reading and validating the user’s ATM card, transaction unit for performing
transactions, a currency counter for dispatching/vending currency to the authorised person and a printer unit
for printing the transaction details. We can visualise these as independent embedded systems. But they work
together to achieve a common goal.
Another typical example of a distributed embedded system is the Supervisory Control And Data Acquisition
(SCADA) system used in Control & Instrumentation applications, which contains physically distributed
individual embedded control units connected to a supervisory module.

3.1.5 Small Size and Weight

Product aesthetics is an important factor in choosing a product. For example, when you plan to buy a new
mobile phone, you may make a comparative study on the pros and cons of the products available in the
market. Definitely the product aesthetics (size, weight, shape, style, etc.) will be one of the deciding factors
to choose a product. People believe in the phrase “Small is beautiful”. Moreover it is convenient to handle a
compact device than a bulky product. In embedded domain also compactness is a significant deciding factor.
Most of the application demands small sized and low weight products.

3.1.6 Power Concerns

Power management is another important factor that needs to be considered in designing embedded systems.
Embedded systems should be designed in such a way as to minimise the heat dissipation by the system. The
production of high amount of heat demands cooling requirements like cooling fans which in turn occupies
additional space and make the system bulky. Nowadays ultra low power components are available in the
market. Select the design according to the low power components like low dropout regulators, and controllers/
processors with power saving modes. Also power management is a critical constraint in battery operated
application. The more the power consumption the less is the battery life.

3.2 QUALITY ATTRIBUTES OF EMBEDDED SYSTEMS

Quality attributes are the non-functional requirements that need to be
documented properly in any system design. If the quality attributes are LO 2 Explain the non-
more concrete and measurable it will give a positive impact on the system functional requirements
development process and the end product. The various quality attributes that needs to be
that needs to be addressed in any Embedded System development are addressed in the design
broadly classified into two, namely ‘Operational Quality Attributes’ and of an embedded system
‘Non-Operational Quality Attributes’.

3.2.1 Operational Quality Attributes

The operational quality attributes represent the relevant quality attributes related to the Embedded System
when it is in the operational mode or ‘online’ mode. The important quality attributes coming under this
category are listed below:
(1) Response
(2) Throughput
(3) Reliability
(4) Maintainability
76 Introduc on to Embedded Systems

(5) Security
(6) Safety
[Link] Response Response is a measure of quickness of the system. It gives you an idea about how fast
your system is tracking the changes in input variables. Most of the embedded systems demand fast response
which should be almost Real Time. For example, an embedded system deployed in flight control application
should respond in a Real Time manner. Any response delay in the system will create potential impact to the
safety of the flight as well as the passengers. It is not necessary that all embedded systems should be Real
Time in response. For example, the response time requirement for an electronic toy is not at all time-critical.
There is no specific deadline that this system should respond within this particular timeline.
[Link] Throughput Throughput deals with the efficiency of a system. In general it can be defined as the
rate of production or operation of a defined process over a stated period of time. The rates can be expressed
in terms of units of products, batches produced, or any other meaningful measurements. In the case of a Card
Reader, throughput means how many transactions the Reader can perform in a minute or in an hour or in
a day. Throughput is generally measured in terms of ‘Benchmark’. A ‘Benchmark’ is a reference point by
which something can be measured. Benchmark can be a set of performance criteria that a product is expected
to meet or a standard product that can be used for comparing other products of the same product line.
[Link] Reliability Reliability is a measure of how much % you can rely upon the proper functioning of
the system or what is the % susceptibility of the system to failures.
Mean Time Between Failures (MTBF) and Mean Time To Repair (MTTR) are the terms used in defining
system reliability. MTBF gives the frequency of failures in hours/weeks/months. MTTR specifies how long
the system is allowed to be out of order following a failure. For an embedded system with critical application
need, it should be of the order of minutes.
[Link] Maintainability Maintainability deals with support and maintenance to the end user or client
in case of technical issues and product failures or on the basis of a routine system checkup. Reliability and
maintainability are considered as two complementary disciplines. A more reliable system means a system
with less corrective maintainability requirements and vice versa. As the reliability of the system increases,
the chances of failure and non-functioning also reduces, thereby the need for maintainability is also reduced.
Maintainability is closely related to the system availability. Maintainability can be broadly classified into
two categories, namely, ‘Scheduled or Periodic Maintenance (preventive maintenance)’ and ‘Maintenance to
unexpected failures (corrective maintenance)’. Some embedded products may use consumable components
or may contain components which are subject to wear and tear and they should be replaced on a periodic
basis. The period may be based on the total hours of the system usage or the total output the system delivered.
A printer is a typical example for illustrating the two types of maintainability. An inkjet printer uses ink
cartridges, which are consumable components and as per the printer manufacturer the end user should replace
the cartridge after each ‘n’ number of printouts to get quality prints. This is an example for ‘Scheduled or
Periodic maintenance’. If the paper feeding part of the printer fails the printer fails to print and it requires
immediate repairs to rectify this problem. This is an example of ‘Maintenance to unexpected failure’.
In both of the maintenances (scheduled and repair), the printer needs to be brought offline and during this
time it will not be available for the user. Hence it is obvious that maintainability is simply an indication of
the availability of the product for use. In any embedded system design, the ideal value for availability is
expressed as
Ai = MTBF/(MTBF + MTTR)
 Characteris cs and Quality A ributes of Embedded Systems 77

where Ai = Availability in the ideal condition, MTBF = Mean Time Between Failures, and MTTR =
Mean Time To Repair
[Link] Security ‘Confidentiality’, ‘Integrity’, and ‘Availability’ (The term ‘Availability’ mentioned
here is not related to the term ‘Availability’ mentioned under the ‘Maintainability’ section) are the three
major measures of information security. Confidentiality deals with the protection of data and application
from unauthorised disclosure. Integrity deals with the protection of data and application from unauthorised
modification. Availability deals with protection of data and application from unauthorised users. A very good
example of the ‘Security’ aspect in an embedded product is a Personal Digital Assistant (PDA). The PDA
can be either a shared resource (e.g. PDAs used in LAB setups) or an individual one. If it is a shared one
there should be some mechanism in the form of a user name and password to access into a particular person’s
profile–This is an example of ‘Availability’. Also all data and applications present in the PDA need not be
accessible to all users. Some of them are specifically accessible to administrators only. For achieving this,
Administrator and user levels of security should be implemented –An example of Confidentiality. Some data
present in the PDA may be visible to all users but there may not be necessary permissions to alter the data by
the users. That is Read Only access is allocated to all users–An example of Integrity.
[Link] Safety ‘Safety’ and ‘Security’ are two confusing terms. Sometimes you may feel both of them as
a single attribute. But they represent two unique aspects in quality attributes. Safety deals with the possible
damages that can happen to the operators, public and the environment due to the breakdown of an embedded
system or due to the emission of radioactive or hazardous materials from the embedded products. The
breakdown of an embedded system may occur due to a hardware failure or a firmware failure. Safety analysis
is a must in product engineering to evaluate the anticipated damages and determine the best course of action
to bring down the consequences of the damages to an acceptable level. As stated before, some of the safety
threats are sudden (like product breakdown) and some of them are gradual (like hazardous emissions from
the product).

3.2.2 Non-Operational Quality Attributes

The quality attributes that needs to be addressed for the product ‘not’ on the basis of operational aspects are
grouped under this category. The important quality attributes coming under this category are listed below.
(1) Testability & Debug-ability
(2) Evolvability
(3) Portability
(4) Time to prototype and market
(5) Per unit and total cost.
[Link] Testability & Debug-ability Testability deals with how easily one can test the design,
application and by which means he/she can test it. For an embedded product, testability is applicable to both
the embedded hardware and firmware. Embedded hardware testing ensures that the peripherals and the total
hardware functions in the desired manner, whereas firmware testing ensures that the firmware is functioning
in the expected way. Debug-ability is a means of debugging the product as such for figuring out the probable
sources that create unexpected behaviour in the total system. Debug-ability has two aspects in the embedded
system development context, namely, hardware level debugging and firmware level debugging. Hardware
debugging is used for figuring out the issues created by hardware problems whereas firmware debugging is
employed to figure out the probable errors that appear as a result of flaws in the firmware.
78 Introduc on to Embedded Systems

[Link] Evolvability Evolvability is a term which is closely related to Biology. Evolvability is referred
as the non-heritable variation. For an embedded system, the quality attribute ‘Evolvability’ refers to the ease
with which the embedded product (including firmware and hardware) can be modified to take advantage of
new firmware or hardware technologies.
[Link] Portability Portability is a measure of ‘system independence’. An embedded product is said to
be portable if the product is capable of functioning ‘as such’ in various environments, target processors/
controllers and embedded operating systems. The ease with which an embedded product can be ported on
to a new platform is a direct measure of the re-work required. A standard embedded product should always
be flexible and portable. In embedded products, the term ‘porting’ represents the migration of the embedded
firmware written for one target processor (e.g. Intel x86) to a different target processor (say an ARM Cortex
M3 processor from Freescale). If the firmware is written in a high level language like ‘C’ with little target
processor-specific functions (operating system extensions or compiler specific utilities), it is very easy to
port the firmware for the new processor by replacing those ‘target processor-specific functions’ with the ones
for the new target processor and re-compiling the program for the new target processor-specific settings.
Re-compiling the program for the new target processor generates the new target processor-specific machine
codes. If the firmware is written in Assembly Language for a particular family of processor (say x86 family),
it will be very difficult to translate the assembly language instructions to the new target processor specific
language and so the portability is poor.
If you look into various programming languages for application development for desktop applications,
you will see that certain applications developed on certain languages run only on specific operating systems
and some of them run independent of the desktop operating systems. For example, applications developed
using Microsoft technologies (e.g. Microsoft Visual C++ using Visual studio) is capable of running only on
Microsoft platforms and may not function on other operating systems; whereas applications developed using
‘Java’ from Sun Microsystems works on any operating system that supports Java standards.
[Link] Time-to-Prototype and Market Time-to-market is the time elapsed between the
conceptualisation of a product and the time at which the product is ready for selling (for commercial
product) or use (for non-commercial products). The commercial embedded product market is highly
competitive and time to market the product is a critical factor in the success of a commercial embedded
product. There may be multiple players in the embedded industry who develop products of the same
category (like mobile phone, portable media players, etc.). If you come up with a new design and
if it takes long time to develop and market it, the competitor product may take advantage of it with
their product. Also, embedded technology is one where rapid technology change is happening. If you
start your design by making use of a new technology and if it takes long time to develop and market
the product, by the time you market the product, the technology might have superseded with a new
technology. Product prototyping helps a lot in reducing time-to-market. Whenever you have a product
idea, you may not be certain about the feasibility of the idea. Prototyping is an informal kind of rapid
product development in which the important features of the product under consideration are developed.
The time to prototype is also another critical factor. If the prototype is developed faster, the actual
estimated development time can be brought down significantly. In order to shorten the time to prototype,
make use of all possible options like the use of off-the-shelf components, re-usable assets, etc.
[Link] Per Unit Cost and Revenue Cost is a factor which is closely monitored by both end user (those
who buy the product) and product manufacturer (those who build the product). Cost is a highly sensitive
factor for commercial products. Any failure to position the cost of a commercial product at a nominal rate,
 Characteris cs and Quality A ributes of Embedded Systems 79

may lead to the failure of the product in the market. Proper market study and cost benefit analysis should be
carried out before taking a decision on the per-unit cost of the embedded product. From a designer/product
development company perspective the ultimate aim of a product is to generate marginal profit. So the budget
and total system cost should be properly balanced to provide a marginal profit.
The Product Life Cycle (PLC) Every embedded product has a product life cycle which starts with the design
and development phase. The product idea generation, prototyping, Roadmap definition, actual product design
and development are the activities carried out during this phase. During the design and development phase
there is only investment and no returns. Once the product is ready to sell, it is introduced to the market. This
stage is known as the Product Introduction stage. During the initial period the sales and revenue will be low.
There won’t be much competition and the product sales and revenue increases with time. In the growth phase,
the product grabs high market share. During the maturity phase, the growth and sales will be steady and
the revenue reaches at its peak. The Product Retirement/Decline phase starts with the drop in sales volume,
market share and revenue. The decline happens due to various reasons like competition from similar product
with enhanced features or technology changes, etc. At some point of the decline stage, the manufacturer
announces discontinuing of the product. The different stages of the embedded products life cycle–revenue,
unit cost and profit in each stage–are represented in the following Product Life-cycle graph (Fig. 3.1).

Product Product Product Product

Growth
development introduction maturity retirement
Revenue

es
al
ts
uc
od
Pr

Unit cost

t
Profi
0
Time

Fig. 3.1 Product life cycle (PLC) curve

From the graph, it is clear that the total revenue increases from the product introduction stage to the
product maturity stage. The revenue peaks at the maturity stage and starts falling in the decline/retirement
stage. The unit cost is very high during the introductory stage (a typical example is cell phone; if you buy a
new model of cell phone during its launch time, the price will be high and you will get the same model with
a very reduced price after three or four months of its launching). The profit increases with increase in sales
and attains a steady value and then falls with a dip in sales. You can see a negative value for profit during the
initial period. It is because during the product development phase there is only investment and no returns.
Profit occurs only when the total returns exceed the investment and operating cost.
84 Introduc on to Embedded Systems

Embedded Systems—
4 Application-
and Domain-Specific

LEARNING OBJECTIVES

LO 1 Illustrate the applica on specific aspect of embedded systems with examples

LO 2 Know the domain specific aspect of embedded systems in automo ve industry
Learn about HECUs and LECUs employed in automo ve applica ons
Learn about the CAN, LIN and MOST communica on buses used in automo ve
applica ons
Know the semiconductor chip providers, tools and pla orm providers, and
solu on providers for automo ve embedded applica ons

As mentioned in the previous chapter on the characteristics of embedded systems, embedded systems are
application and domain specific, meaning; they are specifically built for certain applications in certain domains
like consumer electronics, telecom, automotive, industrial control, etc. In general purpose computing, it is
possible to replace a system with another system which is closely matching with the existing system, whereas
it is not the case with embedded systems. Embedded systems are highly specialised in functioning and are
dedicated for a specific application. Hence, it is not possible to replace an embedded system developed for a
specific application in a specific domain with another embedded system designed for some other application
in some other domain. The following sections are intended to give the readers some idea on the application
and domain specific characteristics of embedded systems.

4.1 WASHING MACHINE—APPLICATION-SPECIFIC EMBEDDED SYSTEM

People experience the power of embedded systems and enjoy the features
LO 1 Illustrate
and comfort provided by them, but they are totally unaware or ignorant of the
the application
intelligent embedded players working behind the products providing enhanced
specific aspect of
features and comfort. Washing machine is a typical example of an embedded
embedded systems
system providing extensive support in home automation applications (Fig. 4.1).
with examples
 Embedded Systems—Applica on- and Domain-Specific 85

As mentioned in an earlier chapter, an embedded system

contains sensors, actuators, control unit and application-specific
user interfaces like keyboards, display units, etc. You can see
all these components in a washing machine if you have a closer
look at it. Some of them are visible and some of them may be
invisible to you.
The actuator part of the washing machine consists of a
motorised agitator, tumble tub, water drawing pump and inlet
valve to control the flow of water into the unit. The sensor
part consists of the water temperature sensor, level sensor,
etc. The control part contains a microprocessor/controller
based board with interfaces to the sensors and actuators. The
sensor data is fed back to the control unit and the control unit
generates the necessary actuator outputs. The control unit also
provides connectivity to user interfaces like keypad for setting
the washing time, selecting the type of material to be washed
Fig. 4.1 Washing Machine – Typical example of like light, medium, heavy duty, etc. User feedback is reflected
an embedded system through the display unit and LEDs connected to the control
(Photo courtesy of Electrolux Corpora on board. The functional block diagram of a washing machine is
([Link]/au))
shown in Fig. 4.2.

Fig. 4.2 Washing machine – Functional block diagram

Washing machine comes in different designs, like top loading and front loading machines. In top loading
models the agitator of the machine twists back and forth and pulls the cloth down to the bottom of the tub.
86 Introduc on to Embedded Systems

On reaching the bottom of the tub the clothes work their way back up to the top of the tub where the agitator
grabs them again and repeats the mechanism. In the front loading machines, the clothes are tumbled and
plunged into the water over and over again. This is the first phase of washing.
In the second phase of washing, water is pumped out from the tub and the inner tub uses centrifugal force
to wring out more water from the clothes by spinning at several hundred Rotations Per Minute (RPM). This is
called a ‘Spin Phase’. If you look into the keyboard panel of your washing machine you can see three buttons
namely* Wash, Spin and Rinse. You can use these buttons to configure the washing stages. As you can see
from the picture, the inner tub of the machine contains a number of holes and during the spin cycle the inner
tub spins, and forces the water out through these holes to the stationary outer tub from which it is drained off
through the outlet pipe.
It is to be noted that the design of washing machines may vary from manufacturer to manufacturer, but
the general principle underlying in the working of the washing machine remains the same. The basic controls
consist of a timer, cycle selector mechanism, water temperature selector, load size selector and start button.
The mechanism includes the motor, transmission, clutch, pump, agitator, inner tub, outer tub and water inlet
valve. Water inlet valve connects to the water supply line using at home and regulates the flow of water into
the tub.
The integrated control panel consists of a microprocessor/controller based board with I/O interfaces and
a control algorithm running in it. Input interface includes the keyboard which consists of wash type selector
namely* Wash, Spin and Rinse, cloth type selector namely* Light, Medium, Heavy duty, and washing time
setting, etc. The output interface consists of LED/LCD displays, status indication LEDs, etc. connected to the
I/O bus of the controller. It is to be noted that this interface may vary from manufacturer to manufacturer and
model to model. The other types of I/O interfaces which are invisible to the end user are different kinds of
sensor interfaces, namely, water temperature sensor, water level sensor, etc. and actuator interface including
motor control for agitator and tub movement control, inlet water flow control, etc.

4.2 AUTOMOTIVE–DOMAIN SPECIFIC EXAMPLES OF EMBEDDED SYSTEM

The major application domains of embedded systems are consumer, industrial,
LO 2 Know the
automotive, telecom, etc., of which telecom and automotive industry holds a
domain specific
big market share.
aspect of embedded
Figure 4.3 gives an overview of the various types of electronic control units
systems in
employed in automotive applications.
automotive industry

4.2.1 Inner Workings of Automotive Embedded Systems

Automotive embedded systems are the one where electronics take control over the mechanical and electrical
systems. The presence of automotive embedded system in a vehicle varies from simple mirror and wiper
controls to complex air bag controller and Anti-lock Brake Systems (ABS). Automotive embedded systems
are normally built around microcontrollers or DSPs or a hybrid of the two and are generally known as
Electronic Control Units (ECUs). The number of embedded controllers in an ordinary vehicle varies from
20 to 40 whereas a luxury vehicle like Mercedes S and BMW 7 may contain over 100 embedded controllers.
Government regulations on fuel economy, environmental factors and emission standards and increasing
customer demands on safety, comfort and infotainment forces the automotive manufactures to opt for
sophisticated embedded control units within the vehicle. The first embedded system used in automotive
application was the microprocessor based fuel injection system introduced by Volkswagen 1600 in 1968.

* Name may vary depending on the manufacturer.

 Embedded Systems—Applica on- and Domain-Specific 87

Fig. 4.3 Embedded system in the automotive domain

(Photo courtesy of Honda Siel Car India ([Link]))

The various types of electronic control units (ECUs) used in the automotive embedded industry can be
broadly classified into two–High-speed embedded control units and Low-speed embedded control units.
[Link] High-speed Electronic Control Units (HECUs) High-speed electronic control units (HECUs)
are deployed in critical control units requiring fast response. They include fuel injection systems, antilock brake
systems, engine control, electronic throttle, steering controls, transmission control unit and central control unit.
[Link] Low-speed Electronic Control Units (LECUs) Low-Speed Electronic Control Units (LECUs)
are deployed in applications where response time is not so critical. They generally are built around low cost
microprocessors/microcontrollers and digital signal processors. Audio controllers, passenger and driver door
locks, door glass controls (power windows), wiper control, mirror control, seat control systems, head lamp
and tail lamp controls, sun roof control unit, etc. are examples of LECUs.

4.2.2 Automotive Communication Buses

Automotive applications make use of serial buses for communication, which greatly reduces the amount of
wiring required inside a vehicle. The following section will give you an overview of the different types of
serial interface buses deployed in automotive embedded applications.
[Link] Controller Area Network (CAN) The CAN bus was originally proposed by Robert Bosch,
pioneer in the Automotive embedded solution providers. It supports medium speed (ISO11519-class B with
data rates up to 125 Kbps) and high speed (ISO11898 class C with data rates up to 1Mbps) data transfer.
CAN is an event-driven protocol interface with support for error handling in data transmission. It is generally
employed in safety system like airbag control; power train systems like engine control and Antilock Brake
System (ABS); and navigation systems like GPS. The protocol format and interface application development
for CAN bus will be explained in detail in another volume of this book series.
88 Introduc on to Embedded Systems

[Link] Local Interconnect Network (LIN) LIN bus is a single master multiple slave (up to 16
independent slave nodes) communication interface. LIN is a low speed, single wire communication interface
with support for data rates up to 20 Kbps and is used for sensor/actuator interfacing. LIN bus follows the
master communication triggering technique to eliminate the possible bus arbitration problem that can occur
by the simultaneous talking of different slave nodes connected to a single interface bus. LIN bus is employed
in applications like mirror controls, fan controls, seat positioning controls, window controls, and position
controls where response time is not a critical issue.
[Link] Media Oriented System Transport (MOST) Bus The Media Oriented System Transport
(MOST) is targeted for high-bandwidth automotive multimedia networking (e.g. audio/video, infotainment
system interfacing), used primarily in European cars. A MOST bus is a multimedia fibre-optic point-to-point
network implemented in a star, ring or daisy-chained topology over optical fibre cables. The MOST bus
specifications define the physical (electrical and optical parameters) layer as well as the application layer,
network layer, and media access control. MOST bus is an optical fibre cable connected between the Electrical
Optical Converter (EOC) and Optical Electrical Converter (OEC), which would translate into the optical
cable MOST bus.

4.2.3 Key Players of the Automotive Embedded Market

The key players of the automotive embedded market can be visualised in three verticals namely, silicon
providers, solution providers and tools and platform providers.
[Link] Silicon Providers Silicon providers are responsible for providing the necessary chips which are
used in the control application development. The chip may be a standard product like microcontroller or DSP
or ADC/DAC chips. Some applications may require specific chips and they are manufactured as Application
Specific Integrated Chip (ASIC). The leading silicon providers in the automotive industry are:
Analog Devices ([Link]) Provider of world class digital signal processing chips, precision
analog microcontrollers, programmable inclinometer/accelerometer, LED drivers, etc. for automotive signal
processing applications, driver assistance systems, infotainment, powertrain body and chassis, etc.
Xilinx ([Link]) Supplier of high performance FPGAs, CPLDs, and automotive specific IP cores
for GPS navigation systems, driver information systems, distance control, collision avoidance, rear seat
entertainment, adaptive cruise control, voice recognition, etc.
Atmel ([Link]) Supplier of cost-effective high-density Flash controllers and memories. Atmel
provides a series of high performance microcontrollers, namely, ARM®†, AVR®‡, and 80C51. A wide range
of Application Specific Standard Products (ASSPs) for chassis, body electronics, security, safety and car
infotainment and automotive networking products for CAN, LIN, and FlexRay are also supplied by Atmel.
Maxim/Dallas ([Link]) Supplier of world class analog, digital and mixed signal
products (Microcontrollers, ADC/DAC, amplifiers, comparators, regulators, etc), RF components, etc. for all
kinds of automotive solutions.
NXP Semiconductor ([Link]) Supplier of 8/16/32 Flash microcontrollers, CAN/LIN/FlexRay
transceivers, LED controllers, LCD drivers, Audio amplifiers, Angular/Rotational/Temperature sensors,
automotive lighting control and discrete components etc.
Renesas ([Link]) Provider of high speed microcontrollers, battery control systems, powertrain
solutions, chassis and safety solutions, body control solutions, instrument cluster solutions, etc.
† ARM® is the registered trademark of ARM Holdings.
‡ AVR® is the registered trademark of Atmel Corporation.
 Embedded Systems—Applica on- and Domain-Specific 89

Texas Instruments (www. .com) Supplier of microcontrollers, digital signal processors, and automotive
communication control chips for Local Inter Connect (LIN) bus products, Advanced Driver Assistance
Systems, Body Electronics and Lighting Solutions, Hybrid, Electric and Power train systems, Infotainment,
Meter cluster and safety solutions, etc.
Fujitsu ([Link]) Fujitsu is the global leader in graphics display controllers (GDCs), including
instrument clusters, in-dash navigation, heads-up displays and rear-seat entertainment. Fujitsu also offers the
world’s first automotive controller for HD video in vehicle networks and delivers CAN microcontrollers that
are used widely for critical automotive functions.
Infineon ([Link]fi[Link]) Supplier of high performance microcontrollers and customised application
specific chips for body and convenience, safety, powertrain, security systems.
Freescale Semiconductor ([Link]) Solution provider for Advanced Driver Assistance Systems
(ADAS), Body Electronics, Chassis and Safety, Infotainment, Instrument Cluster, Powertrain and Hybrid systems
Microchip ([Link]) Supplier of robust automotive grade microcontroller, analog and memory
products, CAN/LIN transceivers, etc.
There are lots of other silicon manufactures which provides various automotive support systems like
power supply, sensors/actuators, optoelectronics, etc. Describing all of them is out of the scope of this book.
Readers are requested to use the Internet for finding more information on them.
[Link] Tools and Pla orm Providers Tools and platform providers are manufacturers and suppliers
of various kinds of development tools and Real Time Embedded Operating Systems for developing and
debugging different control unit related applications. Tools fall into two categories, namely embedded software
application development tools and embedded hardware development tools. Sometimes the silicon suppliers
provide the development suite for application development using their chip. Some third party suppliers
may also provide development kits and libraries. Some of the leading suppliers of tools and platforms in
automotive embedded applications are listed below.
ENEA ([Link]) Enea Embedded Technology is the developer of the OSE Real-Time operating
system. The OSE RTOS supports both CPU and DSP and has also been specially developed to support multi-
core and fault-tolerant system development.
The MathWorks ([Link]) It is the world’s leading developer and supplier of technical
software. It offers a wide range of tools, consultancy and training for numeric computation, visualisation,
modelling and simulation across many different industries. MathWork’s breakthrough product is MATLAB–a
high-level programming language and environment for technical computation and numerical analysis.
Together MATLAB, SIMULINK, Stateflow, and Real-Time Workshop provide top quality tools for data
analysis, test & measurement, application development and deployment, image processing and development
of dynamic and reactive systems for DSP and control applications.
Keil So ware ([Link]) The Integrated Development Environment Keil Microvision from Keil
software is a powerful embedded software design tool for ARM, 8051 & C166 family of microcontrollers.
Lauterbach (h p://[Link]/) It is the world’s number one supplier of debug tools, providing
support for processors from multiple silicon vendors in the automotive market.
Atego Modeling Tools (h p://[Link]) Is the leading supplier of collaborative modeling tools for
requirements analysis, specification, design and development of complex applications.
Microso ([Link] .com) Is a platform provider for automotive embedded applications. Microsoft’s
Windows Embedded Automotive is an extensible technology platform for automakers and suppliers to deliver
in-car experiences that keep drivers connected and informed. Leveraging a range of devices, services and
technology, the platform extends work and home into the vehicle through connected car scenarios.
90 Introduc on to Embedded Systems

[Link] Solu on Providers Solution providers supply OEM and complete solution for automotive
applications making use of the chips, platforms, and different development tools. The major players of this
domain are listed below.
Bosch Automo ve ([Link]) Bosch is providing complete automotive solution ranging
from body electronics, diesel engine control, gasoline engine control, powertrain systems, safety systems,
in-car navigation systems, and infotainment systems.
DENSO Automo ve ([Link]) Denso is an Original Equipment Manufacturer (OEM) and
solution provider for engine management, climate control, body electronics, driving control & safety, hybrid
vehicles, embedded infotainment, and communications.
Infosys Technologies ([Link]) Infosys is a solution provider for automotive embedded hardware
and software. Infosys provides the competitive edge in integrating technology change through cost-
effective solutions.
Delphi ([Link]) Delphi is the complete solution provider for engine control, safety, infotainment,
etc., and OEM for spark plugs, bearings, etc.
……and many more. The list is incomplete. Describing all providers is out of the scope of this book.

Summary
Embedded systems designed for a particular application for a specific domain cannot be replaced
with another embedded system designed for another application for a different domain LO1
Consumer, industrial, automotive, telecom, etc. are the major application domains of
embedded systems. Telecom and automotive industry are the two segments holding a big LO2
market share of embedded systems
Automotive embedded systems are normally built around microcontrollers or DSPs or a hybrid of
the two and are generally known as Electronic Control Units (ECUs) LO2
High speed Electronic Control Units (HECUs) are deployed in critical control units
requiring fast response, like fuel injection systems, antilock brake system, etc. LO2
Low speed Electronic Control Units (LECUs) are deployed in applications where response
time is not so critical. They are generally built around low cost microprocessors/
microcontrollers and digital signal processors. Audio controllers, passenger and driver LO2
door locks, door glass controls, etc., are examples for LECUs.
Automotive applications use serial buses for communication. Controller Area Network (CAN),
Local Interconnect Network (LIN), Media Oriented System Transport (MOST) bus, etc. LO2
are the important automotive communication buses.
CAN is an event driven serial protocol interface with support for error handling in data transmission.
It is generally employed in safety system like airbag control, powertrain systems like LO2
engine control and Antilock Brake Systems (ABS).
LIN bus is a single master multiple slave (up to 16 independent slave nodes) communication
interface. LIN is a low speed, single wire communication interface with support for data LO2
rates up to 20Kbps and is used for sensor/actuator interfacing.
The Media Oriented System Transport (MOST) bus is targeted for automotive audio video
equipment interfacing. MOST bus is a multimedia fibre-optic point-to-point network
LO2
implemented in a star, ring or daisy-chained topology over optical fibres cables
The key players of the automotive embedded market can be classified into ‘Silicon Providers’,
‘Tools and Platform Providers’ and ‘Solution Providers’ LO2