Embedded Software Development Processes for KPI: a ContiMech engineering education note

Context

In 2025, cooperation with Igor Sikorsky Kyiv Polytechnic Institute (KPI) created a practical starting point for a new course at the Department of Software Engineering in Power Engineering (IPZE): Embedded Software Development Processes — 4 ECTS credits, third year, autumn semester.

The course addresses a gap repeatedly observed in both industry and academia: students learn languages, algorithms, and databases, but almost never see the full embedded development loop as one coherent process. From requirements to architecture, from build system to CI, from host tests to on-target checks, from the first commit to a release package with a CHANGELOG and checksums.

Why this course was necessary

The motivation came from several directions at once:

• The gap between industry and education. Based on more than 14 years of embedded work, the same pattern appears repeatedly: junior engineers know C, but do not understand the process. They do not know traceability. They have never looked at a map file. They do not understand why warning-as-error matters. This is a systemic problem and it needs a systemic solution through education.
• Academic background. The course design relied on experience with modeling and cyber-physical systems courses. Writing syllabi was not the hard part; the KPI format was stricter: template, formal details, mapping to the educational program, and a precise grading structure.
• A wish to transfer real experience. Not a theoretical “course about embedded,” but a discipline after which a student can enter a real firmware project and not get lost: create an issue, write a requirement with acceptance criteria, build the project, run tests, prepare a PR, go through code review, and assemble a release package.

Course structure

18 lectures (36 hours) + 9 practical sessions (18 hours) + 66 hours of self-study = 120 hours total (4 ECTS). Two sections:

• Section 1. Processes, requirements, and modeling — embedded context, system cooperation across SW/HW/Mech, requirements and traceability, target-behavior modeling, and project management with GitHub Projects and Jira.
• Section 2. Architecture, implementation, and quality — firmware architecture (BSP/HAL/drivers/services), RTOS and concurrency, toolchains and cross-compilation, Git workflow, verification and validation (host + on-target + HIL/SIL), code quality (MISRA/CERT, static analysis), CI for embedded, debugging (JTAG/SWD, crash analysis), and release/documentation.

What was difficult

• The KPI template format. A syllabus is not a free-form document. It requires a rigid structure: metadata, goals, learning outcomes linked to the official program, lecture topics, practical assignments, self-study hours, grading arithmetic, evaluation criteria, policies, and properly formatted references.
• Mapping to the educational program. The course design had to select concrete general competences, professional competences, and learning outcomes from the program and show how the course forms them. This is not decorative; those matrices matter during accreditation.
• Theory–practice balance. Eighteen lectures are too many for pure theory and too few for a deep specialization. The solution was to make every lecture a concrete engineering topic and every practical class hands-on with real tools such as Git, CMake, cppcheck, GitHub Actions, and Jira.
• SW/HW/Mech cooperation. This topic is rare in academic programs, even though it is one of the main sources of system errors in real embedded projects. A dedicated lecture was reserved for interface contracts, PCB revisions, and joint reviews.
• Project management. Two lectures on GitHub Projects and Jira were a deliberate choice. Embedded engineers too often try to work “in their heads” or in Excel. Students should get used to backlogs, boards, sprints, and automation from their first project experience.

What comes next

• Approval of the syllabus within the IPZE department and the methodological commission.
• Preparation of working materials: lecture slides, practical assignments, a mini-project repository template, and CI configuration examples.
• Pilot launch in the autumn semester of the 2026/2027 academic year.
• Longer-term growth toward AUTOSAR, Model-Based Design, and functional safety as separate modules or advanced courses.

Conclusion

A syllabus is a contract between lecturer and student: here is what will be learned, how it will be assessed, and which tools will be used. For ContiMech, it is also a way to systematize engineering experience and transfer it in a reproducible form.