Lecture 02. The Engineering Team of an Embedded Project

Chronology: 2 September 2026 · second session. Primary source: the complete transcript. Connection: a continuation of Lecture 01—from defining embedded systems to people, components and physical delivery.

1. From the software stack to the physical product

In the previous session, embedded software was defined as software running on predetermined hardware. This idea is now expanded into a complete engineering chain.

Application
   ↓
Middleware / OS / services
   ↓
HAL / drivers
   ↓
MCU / SoC
   ↓
PHY / transceivers / power / protection
   ↓
PCB + mechanics + connectors
   ↓
physical environment

In a real product, selecting an MCU or SoC does not complete hardware design. The system still needs power rails, reset and clock circuitry, possibly memory, protection, physical interfaces, connectors, a PCB, thermal management, an enclosure, manufacturing and integration.

2. Hardware engineer: the target is only the beginning

The lecture decomposes the hardware workstream from selecting the target platform to designing the environment that makes it fit for real operation.

2.1. Minimum set of questions

• Which MCU, SoC, DSP or FPGA is appropriate in terms of computing performance, memory, peripherals and lifecycle?
• How is it powered?
• How does it start and reset?
• Which clock sources are required?
• Which external interfaces have to be implemented?
• What electrical protection is necessary?
• What EMC and ESD requirements arise from the operating environment?
• How is the board cooled and mechanically mounted?
• Are its components available at the intended production volume?

2.2. Logical and physical layers of an interface

An MCU may implement a digital peripheral function, but that does not mean its pins can be connected directly to a cable or network. Many interfaces require a transceiver or PHY to implement their physical layer.

Consider CAN as an example:

CAN controller in MCU
       ↓ TX/RX logic
CAN transceiver
       ↓ differential physical signal
CAN_H / CAN_L bus

Editorial clarification 01 — CAN and galvanic isolation

The spoken statement that “CAN is a galvanically isolated interface” is too broad. A CAN transceiver converts the controller's digital signals into the physical, usually differential, signalling used on the transmission medium. Galvanic isolation is a separate design choice added when the system needs it; CAN itself does not guarantee isolation.

Official terminology reference from CiA: https://www.can-cia.org/fileadmin/cia/documents/brochures/can_dictionary_v13_2026.pdf

3. ESD, EMC and shielding are not the same

The lecture correctly stresses that physical robustness cannot be postponed until “later”. However, the terms must be distinguished:

Metal shields, TVS diodes, common-mode chokes, galvanic isolation, filtering, grounding and PCB layout address different parts of the problem.

4. Three fundamental engineering workstreams

The lecture reduces a core embedded team to three interdependent workstreams:

             SYSTEM / PRODUCT
             /      |       \
      Firmware   Hardware   Mechanics
             \      |       /
               Integration

Firmware / Software

From application logic to low-level drivers, boot and updates, diagnostics, communication, timing and tests.

Hardware

Schematics, component selection, PCB layout, power, interfaces, protection, prototype bring-up and manufacturing support.

Mechanics

Enclosures, mounting, interfaces, thermal paths, accessibility, manufacturability and protection against the physical environment.

Critically, these workstreams cannot honestly function as three independent teams whose work is integrated “on the last day”. The mechanical envelope affects the PCB; the PCB affects connector placement and firmware bring-up; power and thermal limits constrain software modes; and testability requires decisions from all three groups.

5. Architect / systems engineer: connect decisions before integration

In the logic of this lecture, the architect is not the “boss of the engineers”, but the role that safeguards the coherence of the solution:

• translates product needs into a system structure;
• coordinates interfaces between engineering workstreams;
• identifies trade-offs;
• connects technical decisions to standards and constraints;
• helps define the team composition;
• prevents optimization within one discipline from breaking the system as a whole.

During early pre-sales, this role also helps determine which competencies should be demonstrated to the customer and whether the team can realistically carry out the proposed work.

6. Servant manager / servant leader

The lecture presents the management function as a service to the team, rather than top-down command.

In practice, that means:

• removing blockers between hardware and mechanics;
• communicating a technical issue to the customer;
• organizing legal matters, procurement or escalation;
• finding an external specialist;
• protecting engineering time from organizational noise;
• securing decisions for which an engineer lacks the authority or full context.

The manager and architect therefore work alongside one another but solve different problems: architecture maintains technical coherence; management maintains the organizational flow and enables the team to deliver.

7. Embedded engineering has a supply chain

Unlike purely software delivery, embedded projects are tied to the physical world. The lecture derives a separate chain from this fact:

Design
  ↓
component sourcing
  ↓
PCB / mechanical fabrication
  ↓
assembly
  ↓
shipping / customs
  ↓
bring-up
  ↓
rework / next iteration

The engineering plan consequently depends not only on developer velocity, but also on component availability, lead times, manufacturing slots, logistics and the ability to perform another iteration.

Editorial clarification 02 — vendor and country risks

The lecture includes strongly worded examples involving particular vendors and countries. The notes generalize these into supply-chain risks: component lifecycle, NRND/EOL status, long-term availability, second-source strategy, geopolitical or export-control restrictions, vendor lock-in, price volatility, quality of support and traceability of component origin. These are verifiable engineering criteria and are more useful than generalizations about brand nationality.

8. Cost optimization in mass production

In embedded products, a small difference in unit BOM cost can multiply across thousands or millions of units. Thus, the trade-off between an expensive integrated SoC and a simpler MCU with external PHY devices has no universally correct answer.

An informed choice must account for:

unit BOM
+ PCB area
+ assembly complexity
+ test cost
+ engineering effort
+ supply risk
+ certification impact
+ lifecycle cost

A component that is cheaper locally may increase manufacturing or support costs. Conversely, a more expensive IC may reduce total BOM, PCB area and assembly costs.

9. Practical organization of student teams

At the end of the session, the course moves from broad theory to group work. Students are to organize themselves into small teams. This is not merely an administrative assignment: each team will subsequently model a company, and members' roles will evolve from business and pre-sales into engineering and delivery.

The initial rule is that a team should be small enough to coordinate effectively, but complete enough to distribute meaningful responsibilities.

10. Review questions

1. Why is an MCU peripheral controller not yet a ready-to-use physical interface?
2. What is the purpose of a CAN transceiver?
3. Why must galvanic isolation not be equated with CAN?
4. How does ESD differ from EMC?
5. Which three engineering workstreams form the core embedded team in this course?
6. Where is the boundary between an architect and a manager?
7. Why can procurement and logistics become part of a project's critical path?
8. Why does the lowest BOM price not always yield the lowest system cost?

11. Diagram to remember

                  CLIENT / PRODUCT NEED
                           │
                    System Architect
                           │
       ┌───────────────────┼───────────────────┐
       │                   │                   │
   Firmware            Hardware            Mechanics
       │                   │                   │
       └────────────── Integration ────────────┘
                           │
                 Test / Manufacturing
                           │
             Procurement / Logistics
                           │
                        Delivery

         Servant Manager removes cross-cutting blockers

12. Transition to 8 September 2026

We now have a team potentially capable of developing something. The next question is: where will the work come from? The course therefore turns to service-business development—how an unknown company becomes visible, how trust is established and how a contact becomes a lead.

Verified references

• AUTOSAR Classic Platform — layered architecture: https://www.autosar.org/standards/classic-platform
• CAN in Automation, CAN Dictionary 2026: https://www.can-cia.org/fileadmin/cia/documents/brochures/can_dictionary_v13_2026.pdf