Module-4

1. Explain the operational and non-operational quality attributes of embedded systems. Discuss each attribute
with their significance in product development.
Ans:
Operational quality attributes (online mode)
These attributes apply when the embedded system is in operation or online.
1. Response
• Response measures how quickly the system tracks changes in input variables and produces the
corresponding output.
• Many embedded systems, especially mission-critical ones like flight control or automotive brake
control, demand almost real-time response so that no critical deadlines are missed.
• Significance: Poor response can lead to safety hazards or unacceptable user experience, so designers
must consider worst-case scenarios and choose suitable processors, scheduling policies, and interrupt
mechanisms.
2. Throughput
• Throughput represents the efficiency of the system, defined as the rate of production or operation over
a period of time, such as transactions per minute in a card reader.
• It is usually evaluated using benchmarks, which act as reference performance criteria or standard
products for comparison.
• Significance: High throughput is crucial in applications like payment terminals or communication
gateways where a large number of operations must be served within limited time, directly affecting
system sizing and hardware selection.
3. Reliability
• Reliability indicates how much we can rely on the proper functioning of the system and reflects its
susceptibility to failures.
• It is expressed using Mean Time Between Failures (MTBF) and Mean Time To Repair (MTTR),
where MTBF shows failure frequency and MTTR shows allowed repair time.
• Significance: For critical embedded systems, MTTR must be very small (order of minutes), and high
MTBF ensures fewer breakdowns, influencing component quality, redundancy, and fault-tolerant
design.
4. Maintainability
• Maintainability deals with the ease of supporting and repairing the product, through both scheduled
(preventive) and corrective maintenance.
• Significance: Maintainability is closely linked to system availability; as reliability improves,
corrective maintenance reduces, so designers must plan diagnostics, modular design, and service
strategies.
MTBF
• Ideal availability is given by Ai = , showing how design decisions on reliability and repair
MTBF+MTTR
time affect usable uptime.
5. Security
• Security in embedded systems is often described using Confidentiality, Integrity and Availability for
data and applications.
• Significance: Security prevents unauthorised access, modification, or misuse of embedded devices,
which is vital in shared devices, industrial controllers, and network-connected embedded products.
6. Safety
• Safety focuses on the potential damages to operators, the public and the environment due to system
breakdown or hazardous emissions from the product.
• Significance: Safety analysis is mandatory in product engineering to evaluate possible damages and
define measures (protective circuits, shutdown mechanisms, standards compliance) to reduce risk to
an acceptable level.

Non-operational quality attributes (offline mode)

These attributes are considered when the product is not in normal operation, but in development, testing, evolution or
business planning contexts.
1. Testability and Debug-ability
• Testability indicates how easily the designer can test the hardware and firmware of the embedded
product.
• Debug-ability refers to the ability to debug hardware and firmware to locate sources of unexpected
behaviour, with separate mechanisms for hardware-level and firmware-level debugging.
 • Significance: Good test and debug support (test points, self-test firmware, JTAG, in-circuit emulators)
shortens development time, reduces field issues and improves product quality.
2. Evolvability
• Evolvability indicates how easily the embedded product, including hardware and firmware, can be
modified to exploit new technologies.
• Significance: High evolvability allows product families and upgrades (e.g., adding new features using
the same platform), reducing long-term cost and increasing product life span.
3. Portability
• Portability measures system independence, i.e., the ease of running the same embedded product on
different processors, environments or operating systems.
• Firmware written in a high-level language like C with minimal processor-specific code is easy to port
by replacing only target-specific parts and recompiling, whereas assembly-only designs are difficult to
port.
• Significance: High portability reduces rework when migrating from one microcontroller family to
another or from one RTOS to another, which is common in cost reduction or performance upgrades.
4. Time-to-prototype and time-to-market
• Time-to-market is the time between product conceptualisation and the moment the product is ready
for sale or use.
• In competitive and fast-changing embedded markets (e.g., mobile phones, portable media players),
long development time can cause loss of market share or technological obsolescence.
• Prototyping is a rapid, informal development of key features to check feasibility and reduce overall
development time, often using off-the-shelf components and reusable assets.
• Significance: Shorter time-to-prototype and time-to-market improve commercial success and help
keep up with rapid technology changes.
5. Per-unit cost and revenue (product life cycle view)
• Cost is a sensitive factor for both users and manufacturers; incorrect pricing can cause product failure
in the market.
• The Product Life Cycle (PLC) curve shows how revenue, unit cost, product sales and profit evolve
over time: revenue rises to a peak at maturity then declines, initial unit cost is high, and profit is
negative in early development and becomes positive after returns exceed investment and operating
cost.

• Significance: Understanding PLC helps plan investments, pricing strategy, and timing of new
versions; for example, new model phones launch at high price and drop significantly after a few
months.

2. Explain the fundamental issues in hardware-software co-design. Discuss the key decisions involved in
selecting the system model, architecture (RISC/CISC), programming language, and partitioning system
requirements.
Ans:
In hardware–software co-design, the same embedded system requirements must be realised partly in hardware and
partly in software, so several fundamental design decisions become critical: model, architecture, language and
partitioning.
Fundamental issues in HW–SW co-design
The co-design process starts from system-level processing requirements, expressed as functional needs rather than
separate hardware and software demands. These requirements are first modelled and simulated to check functionality
and performance, and only in the architecture phase are they mapped to specific hardware and software blocks based
on various trade-offs. The main fundamental issues are: selecting a suitable system model, selecting an appropriate
architecture (e.g., controller, datapath, RISC, CISC, VLIW, SIMD, MIMD), choosing a programming language that
matches the model and architecture, and finally partitioning system requirements into hardware and firmware.
1. Selecting the system model
• A model is a formal system with objects and composition rules used to capture system characteristics.
• In practice, no single model suffices; designers often switch between models as the design moves from
specification (functionality-oriented) to implementation (structure-oriented).
Common computational models in this chapter include Data Flow Graph (DFG), Control Data Flow Graph (CDFG),
State Machine Model, Sequential Program Model, Concurrent/Communicating Process Model and Object-Oriented
Model.
• At the requirements/specification stage, data-driven or behavioural models (e.g., DFG, CDFG, FSM) are
preferred to express what the system should do without implementation details.
• At the architectural/implementation stage, models must reveal structure (controllers, datapaths, tasks, objects,
communication), so designers use FSMD, concurrent processes, or OO models that map more directly to
hardware blocks and software tasks.
• Issue: Choosing models that both capture behaviour accurately and are amenable to automatic or manual
mapping to hardware and software; a poor choice complicates verification and partitioning.

2. Selecting the architecture (RISC/CISC, controller/datapath, parallel)

The architecture describes how the system will actually be implemented: number and types of components and
interconnections.
Key architectural styles:
• Controller architecture
• Implements a finite state machine using a state register and two combinational circuits (next-state and
output logic).
• Suitable for control-dominated, event-driven behaviour.
• Datapath architecture
• Suited for DFG-style data-flow computations, where outputs are obtained by predefined computations
on inputs.
• Contains registers, register files, memories, ports, and high-speed arithmetic units, often with
pipelining; ports connect to multiple buses.
• FSMD (Finite State Machine with Datapath)
• Combines controller and datapath; controller generates control signals, while datapath does the data
processing via its control and data ports.
• CISC architecture
• Uses complex instructions that can perform multi-step operations with a single instruction (e.g., 8051
CJNE read, compare, and jump).
• Reduces program memory accesses and program size but needs extra silicon for a microcode decoder
and a more complex datapath.
• RISC architecture
• Uses simple instructions; many instructions may be needed for a complex operation.
• Datapath has a large register file and instructions mainly operate on registers; supports extensive
pipelining.
• VLIW and parallel architectures (SIMD/MIMD)
• VLIW packs one operation per functional unit (ALU, multiplier, etc.) into a very long instruction
word.
• SIMD executes the same instruction on multiple processing elements under one controller; MIMD
allows different instructions to run on different processing elements and is the basis of multiprocessor
systems using shared memory or message passing.
Issue: The architect must choose between control-centric vs data-centric, simple vs complex instruction sets, and serial
vs parallel architectures to meet performance, area, power and cost goals of the co-designed system.

3. Selecting the programming language

• A programming language is used to capture the computational model and to map it onto the chosen
architecture.
• There is no strict rule that a given model must use a specific language: the same model can be captured in
different languages (C, C++, Java) for software, or VHDL, Verilog, SystemC for hardware.
• Conversely, a single language can express multiple models, but some languages are better suited to particular
models (e.g., C++ is a good candidate for object-oriented models).
Issue: The only essential requirement is that the language should capture the chosen model easily and efficiently so
that it can be implemented on the selected architecture.
 • For hardware-oriented parts (controllers, datapaths), HDLs like VHDL/Verilog/SystemC are preferred, while
firmware and higher-level behaviour use C/C++/Java depending on the need for OO, concurrency or low-level
control.

4. Partitioning system requirements into hardware and software

• After modelling and choosing architecture, the remaining key issue is where to implement each processing
requirement: in hardware or in software (firmware).
• Many processing requirements can be realised either as a dedicated hardware block or as a software routine on
a processor, so the designer must decide using hardware–software trade-offs (performance, cost, flexibility,
power, etc.).
Issue: Partitioning is a tough decision-making task because it directly affects system performance, time-to-market,
upgradability and cost.
• Performance-critical, highly parallel or computationally intensive operations often go to hardware (e.g.,
specialised datapaths or accelerators).
• Control-oriented, frequently changing or feature-rich logic is usually placed in software for flexibility and
easier updates.
• The architectural design phase produces detailed behavioural descriptions for hardware and formal definitions
of software that will run on that hardware, so incorrect partitioning at this stage can require costly redesign.

3. With functional block diagrams, explain the operation of the following application-specific embedded
systems:
(i) Washing Machine Control System
(ii) Automatic Tea/Coffee Vending Machine
(iii) Automatic Seat Belt Warning System
Ans:
(i) Washing Machine Control System

Operation in brief
1. User inputs and modes
• The user selects wash parameters via keypad: type of cloth (Light / Medium / Heavy duty), wash
stage (Wash, Spin, Rinse) and washing time.
• These inputs go to the control unit, which runs the control algorithm.
2. Filling and sensing
• The controller opens the inlet valve to let water in through the inlet pipe into the outer tub.
• The water level sensor and temperature sensor continuously provide feedback about water level and
temperature.
 • Based on feedback and selected program, the controller closes the inlet valve when required level and
temperature are reached.
3. Washing/agitation phase
• For top-loading machines, the agitator twists back and forth pulling clothes down and up; for
front-loading machines, clothes are tumbled and plunged into water repeatedly.
• The controller drives the motorised agitator/tumble tub with appropriate speed and direction
according to the selected cloth type and wash time.
4. Draining and spin phase
• After washing, the pump removes water from the tub and drains it through the outlet pipe.
• The inner tub spins at several hundred RPM, using centrifugal force to remove water through holes
into the stationary outer tub.
• This is the Spin phase (controlled via Spin button).
5. Rinse and completion
• The controller may repeat fill–agitate–drain cycles for rinsing based on the selected program.
• Status indications (e.g., stage, remaining time) are shown on LED/LCD display and status LEDs.
Thus, the washing machine is an application-specific embedded system where the controller orchestrates sensors and
actuators to implement different wash programs based on user input.

(ii) Automatic Tea/Coffee Vending Machine

FSM-based operation
Vending starts by inserting a 5-rupee coin; user can then select Tea or Coffee or press Cancel to get the coin back.
1. State A – Wait for coin
• Initial state with no coin inserted.
• Event: Insert Coin → Action: accept coin → Next state: Wait for user input (State B).
2. State B – Wait for user input
• Machine waits for one of: Cancel, Tea button, Coffee button.
• Event: Cancel button press → Action: return coin → Next state: Wait for coin (State A).
• Event: Tea button press → Action: Dispense Tea → Next state: Dispense tea (State C).
• Event: Coffee button press → Action: Dispense Coffee → Next state: Dispense coffee (State D).
3. State C – Dispense tea
• Controller activates valves/pumps for tea mix and hot water to fill the cup.
• Event: Tea Dispensed → Action: Done → Next state: Wait for coin (State A).
4. State D – Dispense coffee
• Controller activates coffee mix and hot water valves/pumps.
• Event: Coffee Dispensed → Action: Done → Next state: Wait for coin (State A).
Possible enhancements include adding timeouts if no user input is given after coin insertion, and error states for
“Water not available” or “Tea/Coffee mix not available”
(iii) Automatic Seat Belt Warning System
Two main diagrams:
• FSM model for Seat Belt Warning System.

• FSM model for Timer.

System requirement
1. When vehicle ignition is turned ON and the seat belt is not fastened within 10 seconds, the system generates
an alarm signal for 5 seconds.
2. The alarm turns OFF when any one of the following occurs first: 5-second alarm time expires, seat belt is
fastened, or ignition switch is turned OFF.

FSM-based functional
Operation:
1. State: Alarm Off
• Default state; alarm is not active.
• Event: Ignition Key ON → Action: start 10 s wait timer → Next state: Waiting.
2. State: Waiting
• System waits for 10 s to allow driver/passenger to fasten the seat belt.
• If Seat Belt ON occurs during Waiting, or Ignition Key OFF occurs, the system transitions back to
Alarm Off (no alarm).
• When the 10 s timer expires, it generates event Timer Expire → Next state: Alarm On (if ignition still
ON and seat belt OFF).
3. State: Alarm On
• Alarm output is activated and 5 s alarm timer is started.
• Alarm continues until any of these events occur first:
• Seat Belt ON, or
• Ignition Key OFF, or
• Alarm Time Expire (5 s over).
• On any of these events, system transitions to Alarm Off and alarm output is deactivated.

Timer FSM
• States: IDLE, READY, RUNNING.
• IDLE → READY on Load Timer (timer count loaded).
• READY → RUNNING on Start Timer (count begins decrementing).
 • RUNNING → IDLE on Stop Timer or Timer Expire; on Timer Expire, Timeout flag/interrupt is set.
Together, the seat belt warning controller FSM, ignition and seat belt sensors, timers, and alarm actuator form an
application-specific embedded system that improves safety by reminding users to fasten seat belts promptly after
ignition is turned on.

4. Explain the Finite State Machine (FSM) model with the following examples:
(i) FSM model for an Automatic Tea/Coffee Vending Machine
(ii) FSM model for a Coin-Operated Telephone System
Ans:
Finite State Machine (FSM) is a model in which the system behaviour is described using a finite set of states, with
transitions triggered by events, and optional actions associated with transitions or states. The basic elements are: States
(current situation), Events (inputs/stimuli), Transitions (movement from one state to another), and Actions (activities
performed).

(i) FSM model for an Automatic Tea/Coffee Vending Machine (10 marks)

I. States, events and actions

From the textbook requirement: vending is initiated by inserting a 5-rupee coin, after which user can select Tea,
Coffee, or Cancel.
• States
• State A: Wait for coin
• State B: Wait for user input
• State C: Dispense tea
• State D: Dispense coffee.
• Events
• Insert Coin (5 rupee coin insertion)
• Tea Button Press
• Coffee Button Press
• Cancel Button Press
• Tea Dispensed
• Coffee Dispensed.
• Actions
• Accept coin
• Return coin
• Dispense Tea
• Dispense Coffee
• Done (end of vending, go back to initial state).
II. FSM operation
1. State A – Wait for coin
• Initial idle state; machine is ready but no coin is inserted.
• Event: Insert Coin
• Action: “ok” (accept coin).
 • Next state: State B (Wait for user input).
2. State B – Wait for user input
• Machine waits for user to either choose a drink or cancel.
• Event: Cancel Button Press
• Action: Coin Out (return coin to user).
• Next state: State A (Wait for coin).
• Event: Tea Button Press
• Action: Dispense Tea.
• Next state: State C (Dispense tea).
• Event: Coffee Button Press
• Action: Dispense Coffee.
• Next state: State D (Dispense coffee).
3. State C – Dispense tea
• Vending mechanism dispenses tea into the cup.
• Event: Tea Dispensed
• Action: Done (finish transaction).
• Next state: State A (Wait for coin).
4. State D – Dispense coffee
• Vending mechanism dispenses coffee.
• Event: Coffee Dispensed
• Action: Done.
• Next state: State A (Wait for coin).
The FSM in Fig, thus captures the complete control behaviour using a finite number of states and event-driven
transitions. Enhancements like timeout on waiting state or error states (e.g., “Water not available”, “Tea/Coffee mix
not available”) can be added as extra states and transitions.

(ii) FSM model for a Coin-Operated Telephone System (10 marks)

Show states A–I with transitions labelled as given (Line OK, Lift Receiver, Coin Insert, Line Busy, etc.).
Requirements captured by the FSM
• Call starts when receiver is lifted (off-hook) and a 1-rupee coin is inserted.
• User dials a number; if invalid, coin is returned when receiver is placed back.
• If line is busy or there is a line fault, coin is returned when receiver is placed back.
 • If line is through, user can talk for 60 seconds; at 45 seconds, user is asked to insert another coin to continue
the call.
• If additional coin is not inserted, call terminates at 60 seconds.
• System goes to “Out of order” state when line fault occurs.

Main states in the FSM are:

• A: Ready
• B: Wait for coin
• C: Wait for number
• D: Dialling
• E: Call in progress
• F: Call terminated
• G: Unable to make call
• H: Invalid number input
• I: Out of order.

Key events and actions

• Events: Line OK, Line Fault, Lift Receiver, Coin Insert, Valid Number, Invalid Number, Line Available, Line
Busy, Time Out, Place Receiver.
• Actions: Display OK, Display Error, Return Coin, Dial, monitor duration, Disconnect Line.
FSM operation
1. State A – Ready
• Line is OK, phone is on-hook and ready.
• Event: Line Fault → Action: Display Error → Next state: I (Out of order).
• Event: Line OK from I → Action: Display OK → Next: A.
• Event: Lift Receiver → Action: ok → Next state: B (Wait for coin).
2. State B – Wait for coin
• Receiver is off-hook; system waits for 1-rupee coin.
• Event: Coin Insert → Action: ok → Next state: C (Wait for number).
3. State C – Wait for number
• User dials the phone number.
• Event: Valid Number → Action: Dial → Next: D (Dialling).
• Event: Invalid Number → Action: Display Error → Next: H (Invalid number input).
4. State H – Invalid number input
• Event: Place Receiver → Action: Return Coin → Next: A (Ready).
5. State D – Dialling
• System is dialling and awaits network response.
• Event: Line Busy / Line Fault → Action: Display Error → Next: G (Unable to make call).
• Event: Line Available → Action: Monitor duration → Next: E (Call in progress).
6. State G – Unable to make call
• Call could not be established.
• Event: Place Receiver → Action: Return Coin → Next: A (Ready).
7. State E – Call in progress
• User is talking; controller monitors call time.
• At around 45 seconds, the system gives warning to insert another coin (implemented as part of
Monitor duration action).
• If extra coin is not inserted, at 60 seconds a Time Out event occurs → Action: Disconnect Line →
Next: F (Call terminated).
• At any time, user can Place Receiver → Action: Disconnect Line → Next: A (Ready).
8. State F – Call terminated
• Call already disconnected.
• Event: Place Receiver (if not already placed) → Action: Done → Next: A (Ready).
9. State I – Out of order
• Entered when there is a line fault.
• Event: Line OK → Action: Display OK → Next: A (Ready).
This FSM uses a finite set of states and clearly labelled transitions to capture all the behaviour specified for the
coin-operated telephone system, including error handling, coin return, monitoring of call duration and out-of-order
conditions.
5. Explain the following embedded firmware programming models with examples:
(i) Sequential Program Model
(ii) Concurrent/Communicating Process Model
(iii) Object-Oriented Model
Ans:
These three are standard computational models used to structure embedded firmware during hardware–software
co-design. Each model gives a different way to think about behaviour and concurrency.

(i) Sequential Program Model

In the sequential program model, all functions or processing requirements are executed one after another in a single
thread of control, just like normal procedural C code. Instructions execute in sequence, with loops and conditionals
controlling the flow, and the same CPU executes all steps in a fixed order.
• Characteristics:
• Single flow of control (no true parallel tasks).
• Program state advances step-by-step according to the control flow.
• Easy to understand and implement, but may under-utilise CPU when there is I/O waiting or delays.
• Modelling tools:
• Flowcharts to show control flow.
• FSMs for state-driven logic.
Example – Seat Belt Warning System (sequential version)

1. Wait for Ignition Key ON.

2. Once ignition is ON, wait 10 seconds.
3. If seat belt is still OFF after 10 s and ignition is ON, start alarm and 5-second timer.
4. While alarm is active, repeatedly check:
• If ignition becomes OFF → stop alarm and end.
• If seat belt becomes ON → stop alarm and end.
• If 5-second timer expires → stop alarm and end.
This is implemented as one sequential function with if, while, and timer checks, executing steps strictly in sequence.
(ii) Concurrent / Communicating Process Model
The concurrent (communicating) process model represents the system as multiple tasks or processes executing
concurrently and interacting via communication and synchronization mechanisms. It is useful for real-time systems
where independent activities should run “in parallel” (logically), such as monitoring inputs while controlling outputs.
• Characteristics:
• Several tasks run concurrently (preemptively or cooperatively).
• Tasks communicate via events, shared memory, message passing, etc.
• Requires task scheduling, synchronisation and inter-task communication overhead.
•
Example – Seat Belt Warning System (concurrent version)

The same seat belt warning requirement is remodeled using multiple tasks:
• Tasks defined:
1. Wait Timer Task (10-second wait after ignition ON).
2. Ignition Key Status Monitor Task.
3. Seat Belt Status Monitor Task.
4. Alarm Control Task.
5. Alarm Timer Task (5-second alarm duration).
• Events used for communication:
• waittimerexpire – set by Wait Timer Task after 10 seconds.
• ignitionon / ignitionoff – set/reset by Ignition Monitor Task.
• seatbelton / seatbeltoff – set/reset by Seat Belt Monitor Task.
• alarmtimerstart, alarmtimerexpire – used by Alarm Control and Alarm Timer tasks.
• Behaviour:
• Wait Timer Task: sleeps 10 s, then sets waittimerexpire.
• Ignition Monitor Task: continuously updates ignitionon/ignitionoff events.
• Seat Belt Monitor Task: continuously updates seatbelton/seatbeltoff.
• Alarm Control Task:
• Waits for waittimerexpire.
• If ignitionon and seatbeltoff are set → starts alarm and sets alarmtimerstart.
• Then waits until one of alarmtimerexpire / ignitionoff / seatbelton occurs, then stops alarm.
• Alarm Timer Task: waits for alarmtimerstart, then sleeps 5 s and sets alarmtimerexpire.
(iii) Object-Oriented Model
The object-oriented (OO) model decomposes the system into interacting objects, each encapsulating state (data) and
behaviour (methods), with classes as blueprints for objects. It emphasises abstraction, encapsulation, reuse and
maintainability.
• Key OO concepts in embedded modelling:
• Object: Entity representing part of the system with its own state and behaviour.
• Class: Abstract description (blueprint) of a set of objects, containing member variables (state) and
member functions (behaviour).
• Access control: private, public, protected members to control visibility and protection.
• Inheritance: Derived classes inheriting behaviour and state from base classes.
OO modelling is often combined with UML class diagrams, sequence diagrams and state diagrams for embedded
systems.

Example – Object-oriented model for Seat Belt Warning System

Class Event for events like waittimerexpire, ignitionon, etc.
• Class Task with derived
classes: WaitTimerTask, IgnitionMonitorTask, SeatBeltMonitorTask, AlarmControlTask, AlarmTimerTask,
each implementing a run() method.
Each task object encapsulates its own behavior and uses event objects for communication, providing better modularity
and reuse compared to a monolithic procedural program. This is the essence of the object-oriented model in embedded
firmware design.

6. With a neat block diagram, explain how a high-level source file is translated to an object file during
firmware development. Describe each stage of the translation process.
Ans:

Stages of translation
1. Preprocessor
• Input: High-level source file (.c) plus header files.
• Functions:
• Expands macros defined using #define.
• Processes conditional compilation directives (#if, #ifdef, #ifndef, #else, #endif).
• Includes header files using #include by literally copying their contents.
• Output: A pure high-level language file with all macros expanded and headers included, sometimes called
“preprocessed source”.
The preprocessor operates on source file directives and generates an expanded source file without preprocessor
directives.
2. Compiler (front end, optimization, code generation)
• Input: Pre-processed high-level source.
• Front end:
• Performs lexical analysis (tokenizing), syntax analysis (parsing), and semantic analysis (type checking,
scope resolution).
 • Builds an intermediate representation (IR) of the program.
• Optimizer:
• Applies high-level and machine-independent optimizations like constant folding, dead-code
elimination, common subexpression elimination, loop optimizations.
• Code generator:
• Translates the IR into target-specific assembly language for the chosen microcontroller/processor.
• Output: Assembly source file (.asm or .s) containing symbolic instructions and labels.
Compiler converts the high-level program into target assembly code, with optional optimization.

3. Assembler
• Input: Assembly file generated by the compiler.
• Functions:
• Translates symbolic assembly instructions into actual machine opcodes for the target processor.
• Resolves symbolic labels into addresses (within that module).
• Builds relocation information, symbol table entries, and sections (code, data, bss).
• Output: Object file (.obj or .o), which is in a relocatable binary format (e.g., ELF, COFF) understood by the
linker.
Assembler converts assembly language into relocatable machine code and produces the object file.

4. Object file
• The object file contains:
• Machine code for the compiled module (text section).
• Initialised data, uninitialised data info.
• Symbol table (exported and undefined symbols).
• Relocation records so the linker can later adjust addresses.
In the final build, the linker combines multiple object files and libraries, resolves external symbols and relocates code
to generate the final executable or firmware image (e.g., HEX/BIN for ROM/Flash).

7. Explain the concepts of Time-to-Market and Time-to-Prototype. Discuss their significance in embedded
product development and strategies to minimize them.
Ans:
Time-to-Market and Time-to-Prototype are both time-based quality attributes that strongly influence the commercial
success of an embedded product.

Time-to-Market
Definition:
Time-to-Market is the elapsed time between the conceptualisation of a product and the point at which the product is
ready for selling or deployment.
• It covers idea generation, feasibility, design, development, testing, certification, and ramp-up to a shippable
product.
• In embedded products (mobiles, automotive ECUs, consumer gadgets), the market is highly competitive and
technology changes fast, so delay can make the product obsolete even before launch.
Significance in embedded development:
• If your time-to-market is long, competitors may launch similar or better products earlier and capture market
share.
• Since technology evolves rapidly, a design based on a “new” technology may become outdated by the time
you ship if development takes too long.
• Revenue and profit curves in the product life-cycle show that maximum profit is realised when you enter the
growth and maturity phases early; late entry can drop you straight into a saturated or declining market.
Strategies to minimise Time-to-Market:
• Use rapid prototyping to validate feasibility early and reduce re-design cycles.
• Reuse existing IP blocks, reference designs, and proven software components instead of reinventing them.
• Choose off-the-shelf components and development platforms (evaluation boards, RTOS, middleware) to avoid
long custom hardware cycles.
• Parallelise hardware and firmware development where possible, based on early stable interfaces.
• Maintain good requirements management to prevent late scope changes that cause slips.
Time-to-Prototype
Definition:
Time-to-Prototype is the time taken to build an initial working prototype that demonstrates the important features of
the product concept.
• A prototype is an informal, early version used to check feasibility, validate requirements, and uncover design
issues; it need not be fully optimised or production-ready.
• Fast prototyping helps you explore design alternatives and assess technical risk early in the project.
Significance in embedded development:
• A quick prototype helps detect hardware/firmware integration problems before committing to costly final
hardware.
• It reduces uncertainty: once feasibility is proven, detailed design estimates and schedules become more
realistic, which indirectly shortens time-to-market.
• Early feedback from customers or internal stakeholders (using the prototype) can refine requirements and
avoid expensive late changes.
Strategies to minimise Time-to-Prototype:
• Use evaluation boards, development kits and generic platforms instead of designing custom hardware for the
first iteration.
• Employ high-level tools and reusable firmware components (libraries, middleware, RTOS drivers) to get basic
functionality running quickly.
• Focus the prototype only on critical features and high-risk parts, not on full product polish, mechanicals, or
cost optimisation.
• Leverage re-usable assets from previous projects (code, schematics, test setups).

Relationship between the two

Time-to-Prototype is a major contributor to Time-to-Market: a shorter, effective prototyping phase usually translates
to a shorter overall development cycle. Good use of off-the-shelf components, reuse, and rapid prototyping techniques
simultaneously reduces both metrics, improving the chances of commercial success for embedded products.

1. Write short notes on the following embedded design tools and methods:
(i) Data Flow Diagram (DFD)
(ii) Control Data Flow Diagram (CDFD)
(iii) State Machine Model
Ans:
All three are modelling tools used during embedded hardware–software co-design to capture behaviour and structure
before coding.

(i) Data Flow Diagram (DFD) / Data Flow Graph (DFG)

Concept:
DFD/DFG is a data-driven model where program execution is determined by the flow of data, not by explicit control
flow. It focuses on how input data is transformed into output data through a series of operations.
• Representation:
• Processing/operation: circle or block (process node).
• Data items: arrows entering or leaving a node (data edges).
• Used for: computationally intensive, data-dominated applications (e.g., DSP algorithms).
Example:
For the computation x = a + b and y = x − c, the DFG shows two operation nodes: one “+” node taking a, b and
producing x, and one “−” node taking x, c and producing y, with arrows for data flow between them. A DFG without
feedback is called an acyclic DFG (ADFG).
(ii) Control Data Flow Diagram (CDFD / CDFG)
Concept:
Control Data Flow Diagram combines data flow (as in DFG) with control flow (decisions, conditionals). It is used
when behaviour depends on both data operations and conditional branching.
• Representation:
• Data flow nodes: same as DFG (circles/blocks for operations, arrows for data).
• Control/decision nodes: diamond-shaped blocks representing conditions (like an if in a flowchart).
• CDFG includes both data flow nodes and decision nodes; decision nodes select which data path executes.
Example:
Requirement:
“If flag = 1, x = a + b else y = a − b.”
The CDFG has:
• A decision (diamond) node testing flag.
• One data path (DFG subgraph) computing x = a + b for flag = 1.
• Another data path computing y = a − b for flag ≠ 1.
Thus the control node determines which data flow is active.
A practical example mentioned is image capture and storage in a digital still camera where data flows through AFE,
ADC, processing, and the control part decides the output format (JPEG, BMP, etc.) based on user settings.

(iii) State Machine Model

Concept:
The State Machine model (usually a Finite State Machine, FSM) describes a reactive embedded system using states,
events, transitions and actions. It is suited for event-driven control applications whose behaviour depends on current
state and external events.
• Elements:
• State: representation of current situation.
• Event: input stimulus that may cause a transition.
• Transition: movement from one state to another, labelled with event (and optional condition/action).
• Action: activity performed when a transition occurs or while in a state.
Example – Seat Belt Warning System:
Requirements: if ignition is ON and seat belt not fastened within 10 s, alarm sounds for 5 s, and stops if belt is
fastened, ignition goes OFF, or alarm time expires.
• States: Alarm Off, Waiting, Alarm On.
• Events: Ignition Key ON/OFF, Timer Expire (10 s), Alarm Time Expire (5 s), Seat Belt ON.
• Behaviour:
• Alarm Off → (Ignition ON) → Waiting.
• Waiting → (Timer Expire & seatbelt still OFF) → Alarm On.
• Alarm On → (Seat Belt ON or Ignition OFF or Alarm Time Expire) → Alarm Off.
State machines can be extended to Hierarchical/Concurrent FSMs (HCFSM) using statecharts (e.g., Harel statecharts,
UML state diagrams) to better support concurrency and hierarchy in complex embedded systems.

2. Explain the basic approaches for designing embedded firmware. Discuss the trade-offs between assembly
language and high-level language firmware development.
Ans:
Basic approaches to firmware design
In embedded design, once HW–SW partitioning is done, the functions mapped to software are implemented as
firmware using a suitable programming language.
• Assembly-only approach: Entire firmware is written in the target processor’s assembly language and
assembled to machine code.
• High-level language (HLL) approach: Firmware is written mainly in a high-level language such as C or
C++, compiled to assembly/machine code by a compiler.
• Mixed approach: Most of the code in C, with small performance-critical or device-specific parts in assembly
(e.g., context switch, ISRs, start-up code).
The choice is governed by trade-offs involving performance, memory, cost, development time, portability, and
maintainability.

Assembly language firmware – pros and cons

Advantages
• Maximum control and efficiency:
• Direct access to CPU registers, flags, special instructions; you can hand-optimize cycles and memory
usage.
• Useful when strict real-time deadlines or very tight RAM/ROM constraints exist (e.g., tiny 8-bit
controllers).
• Fine-grained hardware control:
• Precise timing loops, bit-banging protocols, and custom instruction sequences are easier to tune.
Disadvantages
• Poor portability:
• Assembly is specific to an instruction set; moving from e.g. 8051 to ARM requires a complete
rewrite.
• Longer development and debug time:
• Code is verbose, error-prone, and harder to read and review, which increases Time-to-Prototype and
Time-to-Market.
• Lower maintainability and scalability:
• Large systems in pure assembly become difficult to modify, extend, or hand over to new engineers.

High-level language firmware – pros and cons

Advantages
• Faster development and easier maintenance:
• C/C++ support structured programming, functions, modules, and abstraction; this shortens coding,
debugging, and enhances readability.
• Easier to manage large code bases, reuse modules, and enforce coding standards.
 • Better portability and evolvability:
• Same C code can often be recompiled for a different MCU/CPU by changing only low-level,
processor-specific parts.
• This improves the product’s portability and evolvability quality attributes.
• Tool support and optimization:
• Modern embedded compilers generate highly optimized machine code and integrate with IDEs,
debuggers, and static analysis tools.
Disadvantages
• Less direct control over hardware and timing:
• Compiler may introduce overhead (e.g., function prologues/epilogues, stack frames), making exact
cycle counting harder.
• Potentially higher memory footprint:
• If not carefully written or configured, compiled code may be larger than a hand-coded assembly
equivalent.

Aspect Assembly firmware High-level language firmware

Potentially highest, Generally high; depends on compiler

Execution speed
instruction-level control optimizations

Code size Often larger, but tunable via optimization

Can be minimized by hand-tuning
(ROM/RAM) options

Long; coding and debugging are

Development time Short; structured, easier to write and debug
tedious

Maintainability Poor for large projects Good; modular and readable

High; retarget by recompiling and

Portability Very low; tied to one CPU
changing HAL parts

Hardware
Excellent, cycle-accurate Good, but less predictable without care
control/timing

Tiny, ultra-critical, cost-driven Most modern 16/32-bit, complex

Suitability
8-bit systems embedded applications

3. Explain the automotive communication buses (CAN, LIN, FlexRay) and discuss the key players in the
automotive embedded market. Highlight the significance of these buses in modern automotive design.
Ans:
Automotive communication buses
1. CAN – Controller Area Network
• Proposed by Bosch, CAN is a multi-master, message-oriented serial bus widely used in automotive safety and
powertrain systems.
• It supports medium-speed ISO11519 Class B (up to 125 kbps) and high-speed ISO11898 Class C (up to 1
Mbps).
• CAN is event-driven and includes robust error detection and handling, so it is used in critical applications
such as airbag control, engine control, ABS, and navigation systems.
2. LIN – Local Interconnect Network
• LIN is a low-speed, low-cost serial bus aimed at simple sensor/actuator networks and body electronics.
• It uses a single master and up to 16 slave nodes, with a single-wire physical layer and data rates up to 20 kbps.
• The master triggers all communication, eliminating arbitration issues and making LIN suitable for non-critical
functions like mirror control, fan control, seat position, window control, and similar comfort features.
3. FlexRay (and note on MOST)
• FlexRay is referenced in the context of automotive networking products alongside CAN and LIN, supplied by
vendors like Atmel.
 • It is a high-speed, deterministic bus designed for x-by-wire and advanced safety systems where
time-triggered, fault-tolerant communication is required (e.g., steer-by-wire, brake-by-wire).
• The book also discusses MOST (Media-Oriented Systems Transport), a fibre-optic multimedia bus for
audio/video distribution, but your focus is CAN/LIN/FlexRay as control and body networks.

Significance of these buses in modern automotive design

• Reduced wiring and weight:
• Using serial buses instead of dedicated point-to-point wiring drastically reduces cable harness
complexity, weight, and cost in vehicles.
• Functional partitioning:
• High-speed critical ECUs (engine, ABS, airbags) typically sit on CAN or FlexRay, while low-speed
comfort and body functions (windows, seats, mirrors) use LIN.
• Scalability and modularity:
• New ECUs can be added to existing networks with minimal wiring changes, enabling feature
upgrades and platform reuse across vehicle models.
• Support for safety and regulations:
• Government regulations on fuel economy, emissions, and safety, plus customer demand for comfort
and infotainment, have pushed manufacturers to adopt sophisticated ECU networks interconnected by
these buses.

Key players in the automotive embedded market

The ecosystem is typically described in three verticals: silicon providers, tools/platform providers, and solution
providers.
1. Silicon providers
These supply microcontrollers, DSPs, ASICs, and interface chips supporting CAN, LIN, FlexRay and related
functions.
• Analog Devices – DSPs, precision analog MCUs, accelerometers, LED drivers for driver assistance, audio,
navigation.
• Xilinx – FPGAs, CPLDs, automotive IP cores for GPS, driver information, collision avoidance, entertainment,
etc.
• Atmel – ARM/AVR/8051 MCUs, flash controllers, ASSPs for chassis, body, security, infotainment, and
CAN/LIN/FlexRay networking products.
• Maxim/Dallas – Analog, digital, and mixed-signal ICs (MCUs, ADC/DAC, regulators, RF parts) for
automotive solutions.
• NXP, Renesas, TI, Fujitsu, Infineon, NEC – Families of automotive-grade MCUs, DSPs, and communication
controllers for CAN/LIN/FlexRay and other vehicle networks.

2. Tools and platform providers

They offer RTOSs, modelling tools, and development/debug tools for automotive ECUs.
• ENEA – OSE real-time OS for CPU and DSP, with multi-core and fault-tolerant support.
• MathWorks – MATLAB, Simulink, Stateflow, Real-Time Workshop for modelling, simulation, code
generation for control and DSP applications.
• Keil – Microcontroller IDEs (µVision) and toolchains, especially for 8051 and C166.
• Lauterbach – High-end debug and trace tools supporting many automotive processors.
• Artisan – Collaborative modelling tools for requirements and design of complex systems.
• Microsoft – Windows CE–based embedded platforms tailored for automotive infotainment and related
applications.
3. Solution providers (OEM/Tier-1)
These integrate silicon and tools into complete automotive systems.
• Bosch – Complete solutions in body electronics, engine control (gasoline/diesel), powertrain, safety systems,
navigation and infotainment.
• Denso – OEM for engine management, climate control, body electronics, safety, hybrid systems, infotainment
and communications.
• Infosys – Engineering services and embedded hardware/software solutions for automotive.
• Delphi – Systems and components for engine control, safety, infotainment, plus mechanical parts like spark
plugs and bearings.

Why these buses matter for these players

• Silicon vendors build MCUs and transceivers with integrated CAN/LIN/FlexRay controllers to plug into
vehicle networks.
 • Tool vendors support protocol stacks, timing analysis and debugging over these buses, which is essential for
safety-critical validation.
• Solution providers design complete ECU networks over these buses to meet requirements in safety, comfort,
emissions and infotainment, leveraging their robustness and scalability.

4. Explain the characteristics of Embedded Systems

Ans:
Embedded systems differ from general-purpose computers through a set of specific characteristics that influence how
they are designed and implemented.

1. Application and domain specific

• An embedded system is designed to perform a fixed, well-defined set of functions for a particular
application/domain (consumer electronics, automotive, telecom, industrial control, etc.).
• You cannot normally replace the controller of one product with that of another; for example, a microwave
oven’s control unit cannot simply be used in an air-conditioner or a telecom controller in a consumer
appliance.

2. Reactive and real time

• Embedded systems continuously interact with the physical world via sensors and user inputs, reacting
to events as they occur.
• Many are real-time, meaning they must respond within known deadlines; missing a deadline in applications
like flight control or ABS can cause unsafe behavior, though not all embedded systems are strict real-time
(e.g., toys).
3. Operates in harsh environments
• Embedded products are often deployed in non-controlled environments: dust, high temperature, vibration,
shock, power fluctuations, corrosion, and component ageing must be tolerated.
• Design must therefore consider temperature grade of components, mechanical protection, shock absorption,
and robustness of the power supply.
4. Distributed nature
• Many embedded systems are part of a larger distributed system, made up of multiple cooperating embedded
units.
• Examples include vending machines and ATMs, where separate embedded units (card reader, transaction unit,
printer, etc.) work together to achieve the overall function, and SCADA systems with distributed field
controllers linked to a supervisory node.
5. Small size and weight
• Product aesthetics and ease of handling demand compact and lightweight embedded devices.
• Customers prefer small, sleek products (for example, mobile phones), so embedded designs typically
emphasize minimal PCB area, packaging volume, and weight.
6. Power concerns
• Embedded systems must often minimize power consumption to reduce heat dissipation and allow small,
fanless, battery-operated designs.
• Designers use low-power components (e.g., low-dropout regulators, MCUs/DSPs with power-saving modes)
and optimize both hardware and firmware for energy efficiency, especially in portable and battery-based
products.