slashwhy entwickelt zeitkritische Embedded Software für Sensorik, Steuerungssysteme und Aktorik.
slashwhy entwickelt zeitkritische Embedded Software für Steuerungssysteme, Sensorik und Aktorik – bare-metal auf Mikrocontrollern und RTOS-basiert. Wir übernehmen die Entwicklung ab dem Punkt, an dem Hardware-Plattform und HAL feststehen, und bringen die eigentliche Funktionalität zum Laufen.
Echtzeit bedeutet nicht, dass es besonders schnell passieren muss. Echtzeit bedeutet, dass etwas garantiert innerhalb einer definierten Zeitspanne passiert; unabhängig von Systemlast oder parallelen Tasks. Wie eng diese Zeitspanne sein muss, hängt direkt am möglichen Schaden: Systeme, die Personen schützen, haben härtere Anforderungen als Systeme, bei denen nur die Produktqualität leidet.
Ob ein Projekt ein Echtzeit-Betriebssystem (RTOS) wie FreeRTOS oder Zephyr braucht oder ob bare-metal die richtige Wahl ist, entscheiden wir gemeinsam mit dir früh im Projekt, auf Basis der Timing-Anforderungen, der Hardware-Ressourcen und der erwarteten Systemkomplexität. Ein späterer RTOS-Wechsel würde Refactoring bedeuten.
Die Entwicklung von Echtzeitanwendungen sind Teil des Embedded-Software-Portfolios von slashwhy. Je nach Projekt ziehen wir zusätzlich unsere Expert:innen für Embedded Linux, IoT & Cloud Integration, Firmware Entwicklung und grafische Benutzeroberflächen heran, wenn ein System neben zeitkritischen Funktionen auch Konnektivität oder ein Display braucht.
Interesse geweckt? Dann findest du auf dieser Seite alle Informationen über slashwhy als Dienstleister für die Entwicklung von Echtzeitanwendungen.
Deine Ausgangslage
Echtzeit ist eine Anforderung an eine Anwendung und keine Eigenschaft einer Technologie. Ein System hat sogenannte Echtzeitanforderungen, wenn eine verpasste Deadline zu einem definierten Schaden führt und nicht weil es besonders schnell sein soll. Wie hart diese Anforderung ist, hängt direkt am möglichen Schaden: Ein Sicherheitsschalter, der einen laufenden Motor nicht rechtzeitig stoppt, kann Menschen gefährden. Ein Steuerungszyklus, der zu spät ausgeführt wird, kann ein Werkstück zerstören. Eine Audioausgabe, die um wenige Millisekunden versetzt ist, stört das Nutzererlebnis. Alle drei sind Echtzeitanwendungen mit sehr unterschiedlichen Konsequenzen für Architektur, Technologiewahl und Testtiefe.
Unternehmen entwickeln Echtzeitanwendungen mit slashwhy, wenn ihr Produkt innerhalb einer definierten Zeitspanne und unter realen Betriebsbedingungen auf bestimmte Ereignisse reagieren muss. Die Ausgangssituationen sind unterschiedlich, aber die Grundfrage ist immer dieselbe: Was passiert, wenn das System zu spät reagiert?
Am Anfang jedes Echtzeitprojekts steht die Frage: Was passiert, wenn eine Deadline nicht eingehalten wird? Wir klären gemeinsam mit dem Kunden die konkreten Timing-Anforderungen, unterscheiden zwischen Hard und Soft Real-Time und leiten daraus die passende Systemarchitektur ab. Auf dieser Basis entscheiden wir, ob bare-metal oder ein Echtzeit-Betriebssystem (RTOS) die richtige Wahl ist; und wenn RTOS, welches. Die Entscheidung fällt früh, weil ein späterer Wechsel ein vollständiges Refactoring bedeutet. Lizenzmodell, Community-Support und die konkrete Hardware-Plattform fließen dabei genauso in die Entscheidung ein wie die funktionalen Anforderungen.
Wir legen die Task-Struktur des Systems fest: Welche Aufgaben laufen nebenläufig, welche Prioritäten bekommen sie, wie verdrängen höherpriorisierte Tasks niedrigere? Schlecht geplantes Scheduling ist eine der häufigsten Ursachen für Timing-Verletzungen in wachsenden Systemen. Wir entwerfen die Prioritätshierarchie so, dass das verfügbare Zeitfenster für die Task-Ausführung, das sogenannte Timing-Budget, auch bei steigendem Funktionsumfang eingehalten wird.
Nebenläufige Tasks müssen Daten austauschen und Ressourcen koordinieren, ohne sich gegenseitig zu blockieren. Wir implementieren die passenden Synchronisationsmechanismen (z. B. Semaphore, Mutexes oder Message Queues) je nachdem, was das Kommunikationsmuster des Systems erfordert. Deadlocks und Race Conditions entstehen durch schlechtes Design, nicht durch Pech. Wir verhindern sie durch eine saubere Ressourcenarchitektur von Anfang an.
Echtzeitanwendungen reagieren auf Ereignisse wie Signale von Sensoren, Schaltern oder externen Systemen. Wir implementieren das Interrupt Handling so, dass Interrupt Service Routines (ISR) kurz und deterministisch bleiben und rechenintensive Verarbeitungsschritte in Tasks ausgelagert werden. Auf der Aktorseite steuern wir Relais, Motoren und andere Ausgabegeräte so an, dass die Reaktionskette vom Eingang bis zum Ausgang innerhalb des verfügbaren Zeitfensters abläuft.
Wir analysieren das Zeitverhalten des Systems unter realen Betriebsbedingungen. Dazu gehört die Betrachtung der Worst-Case Execution Time (WCET) kritischer Tasks sowie das Messen von Interrupt-Latenzen und Jitter. Wenn das Timing-Budget knapp wird, identifizieren wir die Engpässe und optimieren gezielt: durch Anpassung der Task-Prioritäten, Reduktion von Context-Switch-Overhead oder Verlagerung von Berechnungen. Systeme, die unter Last anders reagieren als im Test, sind ein häufiges Problem in gewachsenen Projekten. Wir machen das Zeitverhalten messbar und nachvollziehbar.
Debugging in Echtzeitsystemen ist grundsätzlich anders als in normaler Embedded-Software. Ein angehängter Debugger verändert das Zeitverhalten des Systems: Fehler, die im normalen Betrieb auftreten, lassen sich unter Debugging-Bedingungen manchmal nicht reproduzieren. Dasselbe gilt für Logging-Ausgaben. Wir setzen auf Methoden, die das Systemverhalten möglichst wenig beeinflussen: Hardware-Tracing, minimalinvasives Logging und gezielte Timing-Messungen über dedizierte Debug-Pins. Deadlocks und Race Conditions lokalisieren wir systematisch.
Manchmal ist das RTOS eines bestehenden Systems nicht mehr die richtige Wahl, weil z. B. Lizenzkosten steigen, der Hersteller-Support ausläuft oder die Plattform gewechselt wird. Wir übernehmen die Migration von proprietären oder veralteten RTOS-Lösungen auf moderne Open-Source-Systeme wie FreeRTOS oder Zephyr. Das umfasst die Analyse des bestehenden Systems, die Neudefinition der Task-Struktur auf der Zielplattform und die schrittweise Portierung der Funktionalität.
RTOS: FreeRTOS, Zephyr – proprietäre Systeme auf Kundenvorgabe
Bare-Metal: ARM Cortex-M (STM32, NXP, Nordic)
Sprachen: C, C++, Rust
Debugging & Tracing: SEGGER J-Link, JTAG, SWD, Hardware-Tracing, Percepio Tracealyzer, Debug-Pin-Messungen
IDEs & Toolchains: STM32CubeIDE, IAR Embedded Workbench, Keil MDK, GCC
HAL-Integration: plattformabhängig, herstellerunabhängige Entwicklung
Individuelle Echtzeitanwendungen sind hochspezielle Systeme. Gerne ermitteln wir gemeinsam mit unseren Kunden die tatsächlichen Anforderungen. Als Technologie- und Entwicklungspartner beraten wir hier zuverlässig und individuell.
Dr. Joachim Wilharm
Managing Director bei slashwhy
Unsere Grundsatzfragen
Bevor slashwhy eine Zeile zeitkritischen Code schreibt, stellen wir drei Fragen. Die Antworten bestimmen die Architektur, die Technologiewahl und den Testaufwand des gesamten Projekts. Diese Entscheidungen fallen früh und sind schwer rückgängig zu machen. Wir treffen diese Entscheidungen gemeinsam mit dem Kunden und auf Basis der konkreten Produkt- und Projekt-Anforderungen.
Die erste Frage bestimmt alles andere. Bei Hard Real-Time ist eine verpasste Deadline ein Systemfehler mit potenziell sicherheitskritischen Folgen für Personen oder Maschinen. Bei Soft Real-Time führt eine Verzögerung zu messbaren Qualitätseinbußen, aber nicht zum Ausfall. Wir klären diese Einstufung gemeinsam mit dem Kunden anhand einer konkreten Frage: Was passiert, wenn das System zu spät reagiert? Die Antwort bestimmt die Architekturtiefe, die Testanforderungen und wie eng die Timing-Spezifikation sein muss.
Bei einem System mit wenigen, klar abgegrenzten Aufgaben und begrenzten Hardware-Ressourcen ist bare-metal oft die bessere Wahl. Sobald das System komplexer wird und mehrere nebenläufige Tasks koordinieren muss, wird ein RTOS sinnvoller. Wir treffen diese Entscheidung auf Basis der Systemkomplexität, der verfügbaren Hardware-Ressourcen und der Frage, wie das Produkt in Zukunft wachsen soll.
Wenn die Entscheidung für ein RTOS gefallen ist, folgt die nächste Frage: FreeRTOS, Zephyr oder ein proprietäres System? FreeRTOS ist ausgereift, weit verbreitet und hat eine große Community – bei Problemen muss man aber selbst im Quellcode nachschauen. Zephyr bietet modernere Architektur und breite Hardware-Unterstützung, ist aber jünger. Proprietäre Systeme wie VxWorks oder QNX liefern kommerziellen Support, binden den Kunden aber an Lizenzkosten und Hersteller-Abhängigkeit. Bringt der Kunde bereits ein RTOS mit, evaluieren wir gemeinsam, ob es die Anforderungen erfüllt.
Wir steigen ein, wenn Hardware-Plattform und Hardware Abstraction Layer (HAL) feststehen. Board Bring-Up und Hardware-Entwicklung übernehmen wir nicht – das ist beim Hersteller oder einem spezialisierten Hardware-Dienstleister besser aufgehoben. Ab dem Punkt, wo die Hardware läuft und es um die eigentliche Funktionalität geht, übernehmen wir: Scheduling, Interrupt Handling, Task-Design und die Integration von Sensorik und Aktorik.
Beides ist möglich. Wenn der Kunde bereits ein RTOS einsetzt, arbeiten wir auf dieser Basis; vorausgesetzt, es erfüllt die Anforderungen des Projekts. Wenn wir gemeinsam ein RTOS auswählen, fließen Lizenzmodell, Community-Support, Hardware-Unterstützung und die konkrete Systemkomplexität in die Entscheidung ein.
Das ist eine der zentralen Herausforderungen bei Echtzeitsystemen. Ein angehängter Debugger verändert das Zeitverhalten des Systems und Fehler, die im Betrieb auftreten, verschwinden manchmal unter Debugging-Bedingungen. Wir arbeiten deshalb mit minimalinvasiven Methoden: Hardware-Tracing, gezielte Timing-Messungen über Debug-Pins und Stresstests unter realer Last. Timing-Probleme machen wir messbar, bevor wir sie beheben.
Das ist ein bekanntes Problem in gewachsenen Echtzeitsystemen. Mehr Features, mehr Tasks, derselbe Mikrocontroller. Irgendwann könnten Deadlines aufgrund gestiegener Anforderungen gerissen werden. Wir dokumentieren bei der Übergabe die Task-Struktur, das Scheduling und die Timing-Messungen so, dass das interne Team oder ein zukünftiger Dienstleister weiß, wo das verfügbare Zeitfenster eng werden könnte. Wenn das System nach der Übergabe Unterstützung braucht, stehen wir als Ansprechpartner zur Verfügung.
Bei harten Echtzeitanforderungen ist eine verpasste Deadline ein Systemfehler mit potenziell schwerwiegenden Folgen. Bei weichen Echtzeitanforderungen führt eine Verzögerung zu Qualitätseinbußen, wie z. B. Ruckeln in der Audio- oder Videoverarbeitung, aber nicht zum Ausfall. Beide Szenarien erfordern unterschiedliche Architekturen und Entscheidungslogiken.
Nice to know
Mit PREEMPT_RT lässt sich der Linux-Kernel so konfigurieren, dass er weiche und bedingt harte Echtzeitanforderungen erfüllt. Das ist relevant für Systeme, die neben zeitkritischen Funktionen auch Netzwerkstack, Dateisystem oder eine grafische Oberfläche benötigen und auf leistungsfähigerer Hardware laufen. Für rein weiche Echtzeitanforderungen reicht dabei oft schon ein normaler Linux-Kernel. PREEMPT_RT Linux ist kein Ersatz für ein dediziertes RTOS bei harten Sicherheitsanforderungen, aber für viele industrielle Anwendungen eine pragmatische Alternative. Die Entscheidung hängt an den konkreten Latenzanforderungen und der Zielplattform.
Unser Vorgehen
Kein Echtzeitprojekt ist identisch. Die Hardware-Plattform, die Kritikalität der Anforderungen und der Reifegrad des bestehenden Systems bestimmen, wie ein Projekt bei slashwhy konkret aussieht. Der folgende Ablauf beschreibt den grundlegenden Ansatz.
1 | Anforderungen klären und Architektur festlegen
Wir starten mit den Timing-Anforderungen und nicht mit der Technologie. Was passiert, wenn eine Deadline nicht eingehalten wird? Wie oft tritt ein Ereignis auf, wie lang darf die Reaktion dauern? Dabei betrachten wir immer das Gesamtsystem – bei Steuerungsaufgaben gehört auch die Trägheit der Aktoren mit in diese Betrachtung. Auf Basis dieser Antworten unterscheiden wir zwischen Hard und Soft Real-Time und entscheiden, ob bare-metal oder ein RTOS die passende Architektur ist. Diese Entscheidung fällt ganz am Anfang des Projektes, weil sie alle weiteren Schritte bestimmt. Ein späterer Wechsel bedeutet Refactoring.
2 | Task-Struktur und Scheduling entwerfen
Wir legen fest, welche Aufgaben das System nebenläufig ausführt, welche Prioritäten sie bekommen und wie sie miteinander kommunizieren. Dazu gehört die Definition von Interrupt Service Routines, die Festlegung von Synchronisationsmechanismen und die erste Abschätzung der Worst-Case Execution Time kritischer Tasks. Weil schlechtes Scheduling schwer zu korrigieren ist, planen wir es sorgfältig, bevor wir implementieren.
3 | Implementierung und Integration
Wir implementieren die Steuerungslogik, binden Sensorik und Aktorik an und integrieren die Software auf der Zielplattform. Wenn der Kunde ein bestehendes RTOS mitbringt, arbeiten wir auf dieser Basis. Wenn wir gemeinsam ein RTOS ausgewählt haben, übernehmen wir die Konfiguration und Integration des Kernels. Die Implementierung folgt der in Schritt 2 definierten Task-Struktur. Abweichungen davon dokumentieren wir und bewerten ihre Auswirkungen auf das Timing.
4 | Timing-Analyse und Debugging
Wir messen das Zeitverhalten des Systems unter realen Betriebsbedingungen. Interrupt-Latenzen, Jitter und Context-Switch-Overhead werden unter Peak Load geprüft. Timing-Probleme, die unter normalen Bedingungen nicht auftreten, zeigen sich oft erst unter Last. Da ein angehängter Debugger das Zeitverhalten verändert, setzen wir auf minimalinvasive Methoden: Hardware-Tracing und gezielte Messungen über Debug-Pins.
5 | Übergabe, Dokumentation und nächste Schritte
Wir übergeben lauffähige, getestete Software mit vollständiger Dokumentation der Task-Struktur, des Schedulings und der Timing-Messungen. Der Kunde erhält damit eine Grundlage, auf der sein eigenes Team, ein anderer Dienstleister oder das slashwhy Team aufbauen kann. Wenn das Produkt z. B. zusätzlich eine App, eine Cloud-Anbindung oder eine grafische Benutzeroberfläche braucht, können wir das nahtlos übernehmen – ganz ohne Schnittstellenverlust zwischen verschiedenen Dienstleistern.
Wenn zeitkritische Software im Nominalfall funktioniert, ist das längst noch keine Garantie für den echten Einsatz im Feld. Echtzeitsysteme versagen typischerweise unter Bedingungen, die im normalen Testbetrieb nicht auftreten, z. B. unter Peak Load, bei aperiodischen Ereignissen oder nach langer Laufzeit. Wir testen deshalb nicht nur, ob das System korrekte Ergebnisse liefert, sondern ob es das innerhalb der definierten Zeitfenster, konsistent und unter realen Betriebsbedingungen tut.
Intuitive Bedienung mittels einer modernen UI ist uns sehr wichtig. Unsere Kunden sollen sich nicht mit der Technik herumärgern, sondern Spaß mit den Produkten und der Anwendung haben.
Oliver Kortekamp
Team Leader & PO bei Oase
Wir haben immer das Gefühl, dass slashwhy Ownership für das Produkt übernimmt. Alle Beteiligten identifizieren sich voll mit dem Produkt. Das ist bei anderen Dienstleistern anders.
Dr. Melanie Schuh
Product Management bei W&H
Wir haben mit slashwhy einen Partner, der nicht einfach nur Code abliefert, sondern von der Konzeption bis zur Umsetzung den gesamten Prozess begleitet, der sich mit dem Produkt identifiziert und es aktiv verbessert.
Friedrich Laube
Director Digital Products & Services Smart Home bei Miele
Das agile Mindset aller slashwhy-Projektmitglieder ist beeindruckend und im positiven Sinne ansteckend. Wir arbeiten mit slashwhy auf Augenhöhe in agilen Projektteams und erreichen gemeinsam schneller unsere Ziele.
Markus Rose
Director CHARX control Division Charging Infrastructure bei Phoenix Contact
Der große Benefit der mit slashwhy entwickelten Lösung ist, dass wir die Weiterentwicklung der Serienprodukte parallel zu den neuen Entwicklungsprojekten betreiben können.
Axel Schröder
Director Advanced Engineering bei CLAAS E-Systems
Wir können uns eine durchgeführte Inbetriebnahme in der App abspeichern und gerade bei großen Bauvorhaben diese Vorlage immer wieder nutzen und gleiche Tore damit einstellen. Das ist ein klarer Vorteil und ein großer Nutzen der App.
Tobias Lange
Projektmanager bei Hörmann
Unsere Zusammenarbeit
Wir entwickeln Software von Menschen für Menschen. Und alle diese Menschen haben ganz unterschiedliche Ansprüche. Die Nutzer:innen wollen ihre Aufgaben effizient lösen, unsere Kunden einen Mehrwert schaffen. Und wir? Wir wollen Software gestalten, die echte Herausforderungen löst, den Alltag vereinfacht und die Spaß in der Anwendung macht.
Global Players und Hidden Champions
Echtzeitanforderungen entstehen überall dort, wo Software auf physische Prozesse trifft und wo eine verzögerte Reaktion Konsequenzen hat. In der Industrieautomation sind das Steuerungssysteme, die Sensoren zyklisch auslesen und Aktoren zu definierten Zeitpunkten ansteuern. In der Landtechnik sind es Steuergeräte, die unter rauen Feldbedingungen zuverlässig und deterministisch reagieren müssen. In der Medizintechnik gelten harte Anforderungen, weil eine verpasste Deadline Personenschäden bedeuten kann. In Consumer Electronics und Gebäudetechnik sind die Anforderungen weicher, aber Latenz und Jitter beeinflussen direkt die Produktqualität und das Nutzererlebnis. slashwhy arbeitet branchenübergreifend mit verschiedenen Marktführern zusammen. Was immer bleibt, ist die Grundfrage jedes Projekts. Was passiert, wenn das System zu spät reagiert?
Ein normales Betriebssystem wie Windows oder Standard-Linux ist für Durchsatz und Benutzerfreundlichkeit optimiert. Es versucht Ressourcen möglichst effizient zu verteilen, gibt aber keine Garantien über Reaktionszeiten. Ein Echtzeit-Betriebssystem (RTOS) garantiert, dass eine definierte Aktion bis zu einem vorgegebenen Zeitpunkt abgeschlossen sein wird. Der Unterschied liegt nicht in der Geschwindigkeit, sondern in der Vorhersagbarkeit. Ein RTOS kann langsamer sein als ein General Purpose OS, aber es ist deterministisch.
Bare-metal bedeutet, dass Software direkt auf der Hardware läuft, ohne Betriebssystem. Der Entwickler hat maximale Kontrolle über das Zeitverhalten und es gibt keinen Betriebssystem-Overhead. Das ist sinnvoll für einfache Systeme mit wenigen, klar abgegrenzten Aufgaben. Ein RTOS bringt einen Scheduler, Task-Management und Synchronisationsmechanismen mit. Das bringt gerade bei komplexen Systemen Vorteile in Sachen Wartbarkeit und Struktur mit sich, fügt aber Overhead hinzu. Die Wahl hängt an der Systemkomplexität, den Hardware-Ressourcen und der Frage, wie das System in Zukunft wachsen soll.
FreeRTOS ist eines der am weitesten verbreiteten Open-Source-Echtzeit-Betriebssysteme für Mikrocontroller. Es ist schlank, gut dokumentiert und unterstützt eine große Anzahl von Hardware-Plattformen. Die MIT-Lizenz erlaubt kommerzielle Nutzung ohne Lizenzkosten. FreeRTOS eignet sich für Systeme mit moderater Komplexität, mehreren nebenläufigen Tasks und begrenzten Hardware-Ressourcen. Für Systeme mit IoT-Konnektivität und breiter Hardware-Unterstützung ist Zephyr eine zunehmend relevante Alternative.
Determinismus bedeutet in diesem Kontext, dass das Zeitverhalten eines Systems vorhersagbar ist. Ein deterministisches System liefert unter denselben Bedingungen immer dieselbe Reaktionszeit. In der Praxis heißt das: Interrupt-Latenzen sind nach oben begrenzt, Context-Switch-Zeiten sind bekannt, und die Worst-Case Execution Time kritischer Tasks lässt sich berechnen. Kein reales System ist absolut deterministisch.
Ein gut entworfenes Echtzeitsystem ist aber deterministisch genug, um Deadlines unter allen definierten Betriebsbedingungen einzuhalten. Dazu gehört auch die Speicherverwaltung: Im zeitkritischen Laufzeitpfad vermeiden Echtzeitsysteme dynamische Speicherallokation mit Standardverhalten, weil sie unvorhersagbare Verzögerungen verursachen kann. Speicher wird deshalb meist während der Initialisierungsphase reserviert oder von vornherein statisch zugewiesen. Wo dynamische Allokation zur Laufzeit trotzdem nötig ist, kommen deterministische Allokatoren mit garantierter Worst-Case-Zeit zum Einsatz.
Du hast bereits eine konkrete Projekt-Idee und möchtest herausfinden, ob slashwhy der richtige Embedded-Dienstleister im Bereich Echtzeitanwendungen für dich ist? Oder stehst du noch am Anfang deiner Reise und suchst den idealen Startpunkt? In jedem Fall freut sich unser Expert:innen-Team über deine Kontaktaufnahme und steht dir für einen unverbindlichen Beratungstermin zur Seite.
slashwhy entwickelt zeitkritische Embedded-Software für Steuerungssysteme, Sensorik und Aktorik, bare-metal auf Mikrocontrollern und RTOS-basiert. Als Dienstleister für Echtzeitanwendungen übernehmen wir die Entwicklung ab dem Punkt, an dem Hardware-Plattform und HAL feststehen. Wir bringen die eigentliche Funktionalität zum Laufen: Scheduling, Interrupt Handling, Task-Design und die Integration zeitkritischer Steuerungslogik.
Echtzeitsysteme stellen andere Anforderungen als normale Embedded-Software. Die Unterscheidung zwischen Hard Real-Time und Soft Real-Time bestimmt Architektur, Testtiefe und Technologiewahl. Ob ein Projekt ein Echtzeit-Betriebssystem wie FreeRTOS oder Zephyr braucht oder ob bare-metal die richtige Entscheidung ist, klären wir früh im Projekt, auf Basis der konkreten Timing-Anforderungen und der erwarteten Systemkomplexität.
Zeitkritische Softwareentwicklung ist schwerer zu debuggen als normale Embedded-Entwicklung. Wir arbeiten mit minimalinvasiven Methoden wie Hardware-Tracing, Timing-Analyse unter realer Last und gezielten Messungen über Debug-Pins. Das Zeitverhalten von Echtzeitsystemen machen wir messbar und nachvollziehbar.
Echtzeitanwendungen sind Teil des Embedded-Software-Portfolios von slashwhy. Wenn ein zeitkritisches System neben Steuerungslogik auch Konnektivität oder Cloud-Anbindung braucht, decken wir das mit eigenen Teams für Embedded Linux und IoT & Cloud Integration ab. Braucht das Produkt zusätzlich eine grafische Benutzeroberfläche oder eine App, arbeiten unsere Embedded-Teams direkt mit den Kolleg:innen aus UX & UI Design und Applikationsentwicklung zusammen. Für Unternehmen, die digitale Produkte ganzheitlich entwickeln wollen, ist slashwhy damit ein Ansprechpartner über den gesamten Stack.
Unsere Kunden kommen aus Branchen, in denen zeitkritische Steuerungslogik zum Kern des Produkts gehört: Industrieautomation, AgriTech, HealthTech, CleanTech und Consumer Electronics. Gemeinsam ist ihnen die Grundfrage jedes Echtzeitprojekts: Was passiert, wenn das System zu spät reagiert? slashwhy entwickelt an vier Standorten in Deutschland als direkter Ansprechpartner für komplexe Echtzeitsysteme, ohne Nearshore-Risiken und ohne Koordinationsaufwand über Ländergrenzen.
