FAQ

Ja. Wir übernehmen einzelne Phasen genauso wie den kompletten Zyklus. Typische Zuschnitte sind reine Firmware-Entwicklung auf Ihrer bestehenden Hardware, reine Embedded-Hardware-Entwicklung mit Schaltungsentwurf und PCB-Layout, oder nur Test und Verifikation. Im kostenlosen Erstgespräch klären wir, welcher Schnitt technisch sinnvoll ist. Bei getrennter Vergabe achten wir besonders auf die Schnittstellendefinition, weil dort die meisten Projekte Zeit verlieren.

Schwerpunkt sind STM32, ESP32 und MSP430 sowie Embedded Linux und RTOS-Systeme. Dazu kommen Microchip PIC, NXP, Atmel, Motorola Coldfire, QNX und Raspberry Pi. Entwickelt wird in C, C++, Assembler, Python und Rust, im FPGA-Bereich in VHDL und Verilog. Für Schaltung und Layout arbeiten wir mit KiCad, Altium Designer, CadSoft Eagle und Fusion 360 Electronics. Andere Plattformen sind möglich, sofern eine kurze Einarbeitung im Projektrahmen vertretbar ist.

Ja, das ist einer unserer häufigsten Fälle. Wir starten mit einer kurzen Systemsichtung: vorhandene Schaltpläne, Firmware-Stand, Testdokumentation und der aktuelle Blocker. Daraus definieren wir einen konkreten Einstiegspunkt statt eines pauschalen Onboardings. In der Regel sind wir innerhalb von ein bis zwei Wochen produktiv. Voraussetzung ist Zugang zum Repository und zu einer lauffähigen Hardware, mindestens als Prototyp oder Eval-Board.

Für ein überschaubares Gerät mit Standard-Mikrocontroller und ohne Zulassungspflicht liegt der Rahmen einer Embedded-Entwicklung typischerweise bei sechs bis zwölf Monaten, von der Anforderungsanalyse bis zur produktionsreifen Übergabe. Sicherheitskritische Systeme mit Normnachweis nach IEC 61508, EN 50716 oder DO-178C dauern deutlich länger, weil Verifikation und Dokumentation dort einen erheblichen Teil des Aufwands ausmachen. Die drei größten Zeitfresser sind unklare Anforderungen, Bauteilverfügbarkeit und späte Änderungen an Gehäuse oder Mechanik.

Ihnen. Alle im Projekt entstandenen Ergebnisse gehen mit der Übergabe vollständig an Sie über: Firmware-Quellcode, Schaltpläne, Layout-Dateien, Stücklisten, Testberichte und Dokumentation. Wir behalten keine Nutzungsrechte an Ihrem Produkt zurück und binden Sie nicht an proprietäre Bausteine, die nur wir warten können. Werden Open-Source-Komponenten eingesetzt, dokumentieren wir Lizenz und Herkunft, damit Sie bei einer späteren Zulassung oder Due Diligence sauber dastehen.

Wenn Ihr Produkt digitale Elemente hat und in der EU auf den Markt kommt, sehr wahrscheinlich ja. Seit dem 11.09.2026 gelten Meldepflichten für aktiv ausgenutzte Schwachstellen, ab dem 11.12.2027 dürfen nur noch CRA-konforme Produkte mit CE-Kennzeichnung neu in Verkehr gebracht werden. Für die Entwicklung heißt das konkret: Security by Design, eine Software Bill of Materials, ein dokumentierter Update-Mechanismus und ein Schwachstellenmanagement über den gesamten Supportzeitraum. Wir berücksichtigen das ab der Architekturphase, weil Nachrüsten deutlich teurer ist.

Verifikation prüft, ob das System richtig gebaut wurde. Validierung prüft, ob das richtige System gebaut wurde. Bei der Verifikation wird also gegen die Spezifikation geprüft: erfüllt die Firmware die Anforderungen aus dem Pflichtenheft. Bei der Validierung wird gegen den tatsächlichen Bedarf im Einsatz geprüft: löst das Gerät das Problem des Anwenders. Im V-Modell steht die Verifikation auf jeder Ebene dem zugehörigen Entwurfsschritt gegenüber, die Validierung sitzt an der Spitze des rechten Astes.

Das V-Modell ordnet jeder Entwurfsebene eine passende Teststufe zu. Der Systemspezifikation entspricht der Systemtest, der Architektur der Integrationstest, dem Detailentwurf der Unit-Test. Praktisch heißt das: Testfälle werden aus den Anforderungen abgeleitet und nicht nachträglich aus dem Code, und jede Anforderung ist über eine Traceability-Kette bis zum Testergebnis nachverfolgbar. Genau diese Nachverfolgbarkeit wollen Prüfstellen in Zulassungsverfahren sehen.

Ja, das ist ein Schwerpunkt. Wir benötigen Zugang zu Schaltplänen und Quellcode sowie eine lauffähige Hardware. Auf dieser Basis erstellen wir Testplan und Testspezifikation eigenständig, auch wenn die vorhandene Dokumentation lückenhaft ist. Der unabhängige Blick ist dabei ein Vorteil: Wir testen gegen die Spezifikation und nicht gegen die Annahmen, die das ursprüngliche Entwicklungsteam im Kopf hatte.

Bei Hardware in the Loop läuft die echte Firmware auf der echten Hardware, während die Umgebung simuliert wird: Sensoren, Aktoren, Bussysteme und Fehlerfälle. Dadurch werden Tests reproduzierbar, die im realen Aufbau gar nicht oder nur mit hohem Risiko darstellbar sind, etwa Sensorausfälle oder Grenzwertüberschreitungen. Ein HIL-Test lohnt sich, sobald der reale Prüfaufbau teuer, gefährlich oder langsam ist, oder sobald Regressionstests regelmäßig wiederholt werden müssen.

Wir richten Testplanung und Dokumentation an V-Modell XT, Automotive SPICE, IEC 61508, DO-178C und EN 50716 aus. Zu EN 50716 ein Hinweis, der derzeit viele Projekte betrifft: Die Norm ersetzt EN 50128 und EN 50657, die zum 30.10.2026 zurückgezogen werden. Ab diesem Zeitpunkt darf für neue Begutachtungen und Weiterentwicklungen nur noch EN 50716 als Referenz herangezogen werden. Wenn Sie Bestandssoftware im Bahnumfeld weiterentwickeln, sollte die Einordnung jetzt passieren und nicht erst im Zulassungsverfahren.

Ja. Testpläne, Prüfprotokolle und Testberichte sind so strukturiert, dass sie als Nachweis in Zulassungsverfahren eingesetzt werden können, inklusive Rückverfolgbarkeit von der Anforderung über den Testfall bis zum Ergebnis. Wir sind selbst keine benannte Stelle und erteilen keine Zertifikate. Wir liefern die Nachweisdokumentation, die die zuständige Prüf- oder Zulassungsstelle von Ihnen verlangt.

Jedes Embedded-System, das über Jahre gewachsen ist und bei dem mindestens einer dieser Punkte zutrifft: die Dokumentation ist lückenhaft oder veraltet, die ursprünglichen Entwickler sind nicht mehr verfügbar, die Toolchain lässt sich auf aktuellen Rechnern nicht mehr aufsetzen, oder Bauteile sind abgekündigt. Entscheidend ist nicht das Alter des Legacy-Codes, sondern ob im Unternehmen noch jemand das System vollständig versteht. Ein System von 2019 kann bereits Legacy sein, eines von 2005 mit guter Dokumentation nicht.

Dann arbeiten wir am Binary. Über das Auslesen des Flash-Speichers, Disassemblierung und die Analyse des Laufzeitverhaltens rekonstruieren wir Funktionsblöcke, Schnittstellen und Datenflüsse, bei Bedarf ergänzt um PCB-Reverse-Engineering zur Rekonstruktion der Schaltpläne. Das Ergebnis ist keine 1:1-Wiederherstellung des Originalcodes, sondern eine belastbare funktionale Beschreibung, mit der eine Neuimplementierung oder Portierung möglich wird. Zwei Einschränkungen sind ehrlich zu nennen: Auslesesperren am Controller können den Zugriff verhindern, und der Aufwand liegt spürbar über dem einer Analyse mit vorhandenem Quellcode.

Bei eigenen Systemen in aller Regel ja. Wenn Sie rechtmäßiger Inhaber oder Nutzer des Systems sind, dürfen Sie es analysieren, um es zu verstehen, zu warten und Fehler zu beheben. Reverse Engineering ist also nicht pauschal verboten. Enger wird es bei fremder Software: § 69e UrhG erlaubt Dekompilierung nur, soweit sie zur Herstellung von Interoperabilität unerlässlich ist, und die gewonnenen Informationen dürfen nur dafür verwendet werden. Dazu kommen vertragliche Klauseln in Lizenzverträgen. Wir klären die Ausgangslage vor Projektstart und arbeiten nur an Systemen, an denen Sie die entsprechenden Rechte haben.

In drei Schritten. Erstens ein kostenloses Erstgespräch von 30 Minuten zur groben Einordnung. Zweitens eine kurze Systemsichtung, bei der wir uns Quellcode, Schaltpläne und vorhandene Dokumentation ansehen. Drittens nennen wir einen verbindlichen Festpreis für die Analyse- und Dokumentationsleistung mit klar definiertem Umfang und Liefergegenständen. Damit tragen wir das Aufwandsrisiko der Analyse und nicht Sie. Das ist bewusst so gebaut, weil sich bei Altsystemen kaum jemand auf ein offenes Stundenbudget einlässt.

Eine vollständige technische Dokumentation des Systems: Systemarchitektur, Beschreibung der Firmware-Module, Schnittstellen- und Datenflussbeschreibung, verifizierte oder rekonstruierte Schaltpläne, eine Risikoanalyse mit Bewertung der technischen Schulden sowie eine Einschätzung möglicher Modernisierungswege inklusive Aufwand. Dazu ein Review-Termin mit Ihrem Team, damit das Wissen ankommt und nicht nur als PDF abgelegt wird.

Die Faustregel: Solange die Funktionalität stimmt und nur Wartbarkeit, Bauteilverfügbarkeit oder Dokumentation das Problem sind, ist Modernisierung günstiger, oft schon durch gezieltes Refactoring von Legacy-Code und eine Portierung der betroffenen Baugruppe. Sobald sich die Anforderungen grundlegend geändert haben, die Hardwareplattform am Limit ist oder eine neue Zulassung ohnehin ansteht, wird die Neuentwicklung schnell wirtschaftlicher. Seriös entscheiden lässt sich das erst nach der Analyse, denn ohne Kenntnis des Ist-Zustands ist jede Aufwandsschätzung für einen Neubau geraten.

Das Lastenheft beschreibt, was der Auftraggeber will. Das Pflichtenheft beschreibt, wie der Auftragnehmer es umsetzt. Das Lastenheft entsteht zuerst und ist lösungsneutral formuliert: es nennt Funktionen, Randbedingungen und Abnahmekriterien, aber keine konkrete Technik. Das Pflichtenheft ist die technische Antwort darauf und wird vom Auftragnehmer erstellt, meist mit Systemarchitektur, Schnittstellenspezifikation und Aufwandsschätzung. In vielen Embedded-Projekten erstellen wir beide Dokumente, weil der Kunde für das Lastenheft die technische Vorarbeit braucht.

Immer dann, wenn unklar ist, was das System genau leisten soll, welche Normen greifen oder ob das Vorhaben überhaupt machbar ist. Der größte Kostenblock in Embedded-Projekten sind nicht Entwicklungsstunden, sondern Korrekturen an falsch verstandenen Anforderungen, die erst im Test auffallen. Eine Anforderungsanalyse macht Aufwand und Risiko vorher sichtbar und ist die Grundlage dafür, mehrere Angebote überhaupt vergleichen zu können.

Als Lastenheft-Inhalt mindestens: Zielsetzung und Einsatzkontext, funktionale Anforderungen, nicht-funktionale Anforderungen wie Timing, Leistungsaufnahme und Temperaturbereich, Schnittstellen zu Umsystemen, geltende Normen und Zulassungsanforderungen, Umgebungsbedingungen, geplante Stückzahlen und Lebensdauer sowie die Abnahmekriterien. Bei Embedded-Systemen kommen zwei Punkte dazu, die in generischen Vorlagen fehlen: die geforderte Langzeitverfügbarkeit der Bauteile und die Update-Strategie über die Produktlebensdauer.

Das ist der häufigste Ausgangspunkt und kein Hindernis. Wir starten mit strukturierten Interviews mit allen relevanten Beteiligten, also nicht nur mit der Entwicklung, sondern auch mit Service, Vertrieb und Produktion. Danach definieren wir den Systemkontext, arbeiten die Anforderungen aus und priorisieren sie. Erst im Review mit Ihnen entsteht das fertige Dokument. Sie müssen für dieses Requirements Engineering also keine Vorarbeit leisten. Eine grobe Produktidee und ein paar Stunden Zeit für Interviews reichen.

Ja, genau dafür sind sie gebaut. Lasten- und Pflichtenheft, Systemarchitektur und Aufwandsschätzung funktionieren als Briefing-Dokument für ein beliebiges internes oder externes Entwicklungsteam. Sie sind nicht auf EmTec zugeschnitten und enthalten keine Abhängigkeiten von unseren Werkzeugen. Viele Kunden nutzen die Analyse genau deshalb: um mit einem belastbaren Dokument mehrere Angebote einzuholen und vergleichen zu können.

Das ist möglich, aber ausdrücklich keine Voraussetzung. Die Analyse ist ein eigenständiges, in sich abgeschlossenes Ergebnis. Sie können damit intern weiterarbeiten, ein anderes Entwicklungshaus beauftragen oder uns. Wenn wir die Entwicklung übernehmen, sparen Sie die Einarbeitungsphase, weil wir das System und seine Randbedingungen bereits kennen. Die Entscheidung treffen Sie nach der Übergabe und nicht vorher.

Ja, das machen wir regelmäßig. Auch wenn Anforderungen unklar sind oder Dokumentation fehlt — wir analysieren den Stand und steigen gezielt ein.

Das hängt stark vom Scope ab. Nach einem kurzen Erstgespräch geben wir eine realistische Einschätzung — unverbindlich und kostenlos.

Ja. Test & Verifikation bieten wir als eigenständige Dienstleistung an — auch für Systeme die woanders entwickelt wurden.

30 Minuten. Sie schildern Ihr Vorhaben, wir stellen Fragen und geben eine erste technische Einschätzung. Kein Pitch, kein Verkaufsgespräch.

Ja. EmTec verfügt über eine Ermächtigung bis Sicherheitsstufe GEHEIM — Voraussetzung für Projekte im Bundeswehr-Umfeld.