Design Life Cycle

Every embedded system product follows a systematic process from initial concept to final deployment. This structured process is called the embedded design life cycle. Understanding the life cycle is important not just for managing engineering projects, but also for ensuring that quality, safety, and correctness are systematically verified at each stage. Two widely adopted models for structuring this process are the Waterfall model and the V-model, both of which are commonly examined in GATE and university assessments.

Core Concept of Design Life Cycle

The design life cycle defines the sequence of activities required to take an embedded system from a problem statement to a verified, deployed product. It ensures that each phase is completed with documented outputs before the next phase begins, reducing the risk of discovering critical design errors late in development, when correction costs are high. The life cycle covers requirements capture, architecture design, detailed hardware and software design, implementation, verification, validation, and maintenance.

The Waterfall model is the oldest and most straightforward life cycle model. Phases flow strictly top to bottom: requirements, design, implementation, testing, and maintenance. Each phase must be completed and signed off before the next begins. The model is simple to manage and document, but its fundamental weakness is inflexibility. If a design error is discovered during testing, returning to the design phase is expensive because all intermediate work must be revisited.

The Waterfall model is suitable for projects where requirements are well-understood, stable, and unlikely to change during development, such as safety-critical embedded systems with clearly frozen specifications. It is not suitable for innovative product development where user requirements evolve as the product is built.

The V-Model

The V-model is an extension of the Waterfall model that explicitly links each development phase on the left arm of the V to a corresponding testing or verification phase on the right arm. The left arm descends from system requirements through system design, architectural design, and detailed design down to implementation at the bottom. The right arm ascends from unit testing through integration testing, system testing, and acceptance testing back up to the user-level validation.

The key insight of the V-model is that verification planning should begin as early as the corresponding design phase. For example, acceptance test plans are written during the requirements phase, not after implementation. This ensures that every requirement has a testable verification criterion defined from the start, preventing the common problem of requirements that are vague or untestable. This makes the V-model particularly well suited for safety-critical embedded systems such as automotive, medical, and avionics systems.

In the V-model, the distinction between verification and validation is important. Verification asks: are we building the product correctly according to the specification? Validation asks: are we building the correct product that satisfies the user need? Both activities are systematically addressed by the right arm of the V.

Practical Understanding

In practice, embedded systems are rarely developed using pure Waterfall or pure V-model due to evolving hardware availability, changing customer requirements, and iterative software development. Agile and iterative models are increasingly used for software-heavy embedded products. However, for the purpose of GATE and university exams, the Waterfall and V-model remain the standard reference models to understand and compare.

The design metrics discussed in the embedded systems overview — performance, power, cost, code size — are evaluated at the design phases of the life cycle. Architecture decisions at the system design phase lock in many of these metrics. Changing the processor architecture after implementation is very expensive, which is why the early design phases of the V-model must be treated with care and validated against all known requirements before proceeding.

Given:
Waterfall project: 12 months total
Error detected during Testing phase (month 10)
Rework required back to Design phase (month 4)

Why this formula applies:
Late error detection in Waterfall causes rework spanning multiple phases.

Cost of rework estimation (rule of thumb):
Cost of fixing an error in Testing ≈ 10× cost of fixing at Design phase

If fixing at Design phase costs: Rs. 5,000
Fixing at Testing phase costs: Rs. 5,000 × 10 = Rs. 50,000

V-model equivalent:
Same error caught at Unit Testing (month 7) instead of System Testing
Cost multiplier ≈ 3× (vs 10× at system test)
V-model cost: Rs. 5,000 × 3 = Rs. 15,000

Final Answer: V-model reduces error correction cost from Rs. 50,000 to Rs. 15,000 by detecting errors earlier through parallel verification planning.

Exam Tip: In GATE, the V-model is distinguished from Waterfall by its explicit mapping of each development phase to a verification phase. Key phrase: 'verification and validation activities are planned in parallel with development phases'. The bottom vertex of the V is always implementation or coding. Both arms of V must be memorized in order.

• Waterfall model: sequential phases, each phase output feeds next. Simple but inflexible for late changes.
• V-model: extends Waterfall by pairing each design phase with a corresponding verification phase.
• Verification: checking against specification (are we building it right). Validation: checking against user need (are we building the right thing).
• V-model forces test planning to start early, reducing cost of late defect detection by an order of magnitude.
• Bottom of the V is always implementation or coding. Left arm descends into design; right arm ascends into testing.

Quick Revision

• Waterfall model: Requirements → Design → Implementation → Testing → Maintenance. Strictly sequential, no backward flow.
• V-model: extends Waterfall with parallel test planning. Each left-arm phase pairs with a right-arm test phase.
• V-model pairing: Requirements ↔ Acceptance Test, System Design ↔ System Test, Detailed Design ↔ Unit Test.
• Early error detection saves cost: fixing at requirements phase is 10-100x cheaper than fixing at testing phase.
• Verification: specification conformance. Validation: user need conformance. Both addressed by V-model right arm.
• Exam trap: V-model is not iterative. It is a structured Waterfall variant, not an Agile or spiral model.
• Waterfall suits stable, well-defined requirements. V-model suits safety-critical systems needing formal verification traceability.