The project path page describes the five phases of a student-level mechatronics or IoT project, from the initial need to the final presentation. The path follows a V-model logic: the left-hand (descending) branch progressively defines the system (specification, concept, proof of concept), while the right-hand (ascending) branch builds and validates it (technical design file, integration and testing). This framework structures the whole tutorial and serves as the entry point for placing every concept, every tool and every deliverable in the flow of the project.
The five phases
- Technical specification — turn a need into measurable technical requirements
- Concept — choose an architecture and size it roughly
- Proof of concept — resolve the technical unknowns before detailed design
- Technical design file — produce every document needed for manufacturing
- Integration and testing — assemble, qualify, close the project
Each phase produces an identifiable deliverable and conditions the next one. No phase is validated until its deliverable has been accepted at a review.
The V-model
1. Technical specification
The key question
What must the system do, in what context, and for whom?
The team turns a need, often vague at the start of a project, into measurable technical requirements. This phase covers the analysis of the need, the study of the context of use, the state of the art of existing solutions, the eco-design constraints, and the formalisation of performance targets.
Main deliverable
The cahier des charges fonctionnel (CdCF, the French functional requirements specification), together with a technical specification file.
2. Concept
The key question
Which technical architecture meets the spec, and does it hold up under rough sizing?
The team picks one concept among several candidates, describes it through diagrams (in particular the functional block diagram, the kinematic diagram and the energy and information chains), and checks with quick rough sizing that the orders of magnitude hold (power, battery life, footprint).
Main deliverable
A concept file presenting the block diagram, the chain diagrams and the rough sizing calculations.
3. Proof of concept
The key question
Do the uncertain technical points of the concept actually work?
Before committing to the whole detailed design, the team identifies the unknowns in the concept (a control loop to achieve, a link to validate, a component to characterise) and tests them on a minimal setup. If a test fails, the spec or the concept has to change before the mistake gets expensive.
This phase is where an essential engineering skill is learned: resolving uncertainty early. Rather than designing everything and then testing, the things that could sink the project are tested first.
Main deliverable
One or more minimal prototypes, in other words the proof of concept itself. They show that the unknowns have been resolved, and come with an update of the spec and the concept where needed.
4. Technical design file
The key question
How is the system built, part by part and line of code by line of code?
The team produces every document needed to build the prototype: detail and assembly drawings, bill of materials (BOM), wiring diagrams, PCB layout, embedded algorithms, simulations, and the product qualification plan (how it will be shown that the system meets the spec).
Main deliverable
The complete technical design file, sufficient for an outside team to build and test the system.
5. Integration and testing
The key question
Does the assembled prototype satisfy the spec, and is the project properly closed?
The team manufactures, assembles and wires the prototype, then runs the qualification plan: every function described in the spec is tested, measured, and either validated or recorded as a deviation. The assembly must be safe and presentable. The phase ends with the final presentation, the final report and the lessons learned review.
Main deliverable
The outcome of integration and testing: a working prototype, a qualification file, the final presentation and the lessons learned.
Running alongside every phase
Three activities are not phases but continuous threads, present from the first week of the project to the last:
- Project planning and tracking: schedule, task tracking, risk management, team communication, interim reviews. A team that does not steer its project ends up being steered by it.
- Eco-design: life-cycle assessment, material choices, energy frugality. It is not decided at the end of the project. Every design choice commits the environmental footprint.
- Safety and quality: product and user risk analysis (AMDEC, the French acronym for FMEA), compliance with standards, quality of deliverables. To be considered from the spec onwards, not after the first accident.
These threads are assessed across the board: they appear in the deliverables of every phase, rather than in a phase of their own.
How to read this site
The tutorial has three kinds of page, which you can tell apart by the trame, tuto or notion tag shown under the title:
- Framework pages: describe a phase of the V-model. Dense and detailed, they guide the production of the expected deliverables. This page is a framework page.
- Tutorials: show how to put a tool or a method into practice (installing an IDE, understanding the GPIOs of a microcontroller, building a digital PID). Practical, action-oriented.
- Concept pages: short reminders (voltage, resistance, torque, force) that bridge to other courses. To be consulted whenever a basic notion is unclear.
Methods, organisation and framework
Beyond the phases, project management draws on organisational tools and a regulatory framework:
- Methods and organisation (MEO): client relationship, archiving and traceability, code review, SI units, cable management.
- Standards, safety and eco-design (ESE): product safety and compliance in safety and quality; environmental footprint in eco-design.
- Every project tool: see the PROJ index.