Lecture 01. Embedded Systems and Two Models of IT Business

Chronology: 1 September 2026 · course opening. Primary source: the complete automatic transcript. Status: reconstructed from the original recording and frozen on 28 September 2026.

Why this course exists

This course is concerned less with programming-language syntax or algorithm theory than with the entire engineering and business lifecycle of an embedded project. The ambition stated in the lecture is to follow the journey from an idea to initial revenue, through routine delivery work and eventually to completion of the project or business.

The course's central framework:

idea
  ↓
definition of the need
  ↓
customer / market / funding
  ↓
team + processes + deliverables
  ↓
embedded-system development
  ↓
verification / validation / integration
  ↓
delivery / support / closure

Assessment is based on a team project and demonstrations, not merely on reproducing theory. Students organize into teams themselves; the roles and deliverables of those teams will evolve as the course progresses.

1. What “embedded” means in this course

The practical characteristic of embedded software is that it is designed for a particular hardware environment and forms part of a physical product or system. Beyond program functions, memory, computational resources, energy consumption, peripherals, interfaces, timing characteristics and the physical consequences of an error are all important.

The lecture contrasts two common topologies.

1.1. Compact system: application → HAL → hardware

For relatively small MCU designs, application logic may operate directly on top of the vendor's HAL or driver layer.

Application / business logic
            ↓
HAL + low-level drivers
            ↓
MCU / DSP / SoC / another target

Advantages include a smaller stack, controlled resource use and predictability. The trade-off is tighter coupling to the target and the need to implement more infrastructural functionality yourself.

1.2. Layered system: application → middleware/OS → HAL → hardware

In larger systems, reusing existing networking, filesystem, diagnostics and other services may be appropriate.

Application
    ↓
Middleware / services
    ↓
Operating system / runtime
    ↓
HAL / drivers
    ↓
Hardware

This does not automatically make the system “better”. It is another trade-off: greater reuse and flexibility, but also a more complex software stack, integration, update and security attack surfaces, and more interdependencies.

2. Why embedded engineering is not “just software”

The code ultimately affects the physical world: it generates electrical signals, controls actuators and exchanges data over physical interfaces. Consequently, a defect may manifest not merely as incorrect on-screen text but as:

• an incorrect command to an actuator;
• hardware damage;
• an unsafe equipment state;
• expensive rework of a manufactured production batch;
• non-compliance with safety or security requirements;
• loss of customer trust.

The lecture's central claim follows: high-quality embedded development is inseparable from testing, systems engineering and risk management.

3. Functional safety and cybersecurity are distinct risk dimensions

The lecture introduces two different sources of unwanted behavior:

These fields interact but cannot substitute for one another.

Editorial clarification 01 — ISO 26262

The spoken formulation in the lecture was broader than the standard's actual scope. ISO 26262 is a functional-safety standard for electrical/electronic systems in series-production road vehicles. Industrial, aerospace, railway, medical and other domains have their own applicable standards; ISO 26262 is not a universal baseline for every safety-critical industry.

Official source: https://www.iso.org/standard/68385.html

Editorial clarification 02 — QM and ASIL

Automotive ISO 26262 uses QM and ASIL A–D. The ASIL resulting from HARA is not calculated by simply multiplying “probability × consequence”. Classification involves the combination of Severity, Exposure and Controllability. The detailed method should be studied in ISO 26262-3 itself.

For cybersecurity engineering throughout the automotive E/E lifecycle, the domain-specific reference is ISO/SAE 21434: https://www.iso.org/standard/70918.html.

4. Idea + resources = an opportunity to build technology

The lecture presents a business in terms of two necessary ingredients:

IDEA  +  RESOURCES  →  TECHNOLOGY  →  VALUE FOR THE MARKET

An idea alone does not guarantee a product. People, time, money, equipment, manufacturing, marketing, legal/IP work, testing and market access are needed. Money is a convenient general representation of resources, but it is not the only resource.

5. Two business models used as the course's first major decision

5.1. Product company

A team develops its own product idea and assumes the associated market risk: what to build, for whom, how to protect IP, how to scale manufacturing and how to support the product.

5.2. Service company

A customer has a business or technical need but obtains external engineering capacity. A service company provides people, processes, infrastructure, domain expertise and sometimes hardware or manufacturing capability, receiving payment under an agreed engagement model.

The course deliberately starts with the service model because it offers access to real processes—lead generation, pre-sales, proposal, staffing and delivery—before moving to the product model.

6. IP and NDAs: what must be understood before work starts

The lecture stresses two practical constraints on service engagements: confidentiality and the rights to work products.

Editorial clarification 03 — NDA

The correct expansion is Non-Disclosure Agreement, not “Not Discussion Agreement”. An NDA defines obligations not to disclose confidential information; its actual limits depend on the agreement's wording and the applicable law.

Editorial clarification 04 — IP ownership

The claim that “IP in a service company always belongs to the customer” describes a common business arrangement, not a universal legal rule. Ownership, assignments, licences, background IP, foreground IP and rights of reuse depend on the contract and applicable law. These provisions must be read in MSA, SOW and IP clauses rather than inferred from the mere fact of outsourcing.

7. The lecturer's career perspective

The lecture offers a personal perspective: it is helpful first to acquire experience on real service projects, observe strong and weak processes, and learn to work with customers and risks. Then, once an idea and sufficient resources are available, one can move toward developing a proprietary product.

This is the lecturer's career advice, not a single universally required path.

8. Review questions

1. What distinguishes embedded software from an arbitrary desktop or web application?
2. When might bare-metal/HAL be preferable to an OS-based stack?
3. Why can a software defect in an embedded system become a hardware or safety problem?
4. How does functional safety differ from cybersecurity?
5. Why does an idea alone not constitute technology?
6. What does a product company sell, and what does a service company sell?
7. Why cannot IP ownership be established from the word “outsourcing” alone?
8. What obligations can an NDA actually impose on an engineer?

9. Short exercise

Describe one embedded-system idea in two arrangements:

• Product: you fund and sell the product yourself.
• Service: a customer brings the same need and you sell engineering services to meet it.

For each arrangement, identify the owner of the idea, who bears the risk, the funding source, the expected outcome and the principal IP/NDA questions.

10. Transition to 2 September 2026

Once an embedded system and two business models have been defined, the next logical question is: who turns the idea into a physical product? The next session moves from the abstract model to the engineering team—firmware, hardware, mechanics, architecture, management and the physical supply chain.

Verified references

• ISO 26262-3:2018, Concept phase / HARA: https://www.iso.org/standard/68385.html
• ISO/SAE 21434:2021, Road vehicles — Cybersecurity engineering: https://www.iso.org/standard/70918.html
• AUTOSAR Classic Platform: https://www.autosar.org/standards/classic-platform