Mit der Einführung von verteilten Funktionen muss der OEM heute zunächst die Gesamtfunktion modularisieren und auf mehrere ECUs verteilen, bevor er Aufträge an ECU- und Software-Zulieferer vergibt. Eine zusätzliche technische Herausforderung besteht darin, dass das System während der Entwicklung nicht mehr „als Ganzes“ testbar ist, denn jeder Partner implementiert nur einen Teil des Systems. Das korrekte Zusammenspiel erst beim Integrationstest zu prüfen, ist offensichtlich zu spät, da Korrekturen hohe Kosten verursachen und ggf. sogar Entwicklungszeitpläne gefährden. Daraus ergibt sich eine Reihe neuer Fragen:
Die Beantwortung dieser (und weiterer) Fragen erfordert zunächst ein Verständnis des Zeitverhaltens verteilter Systeme und dann einen systematischen Umgang damit. Bild 3 zeigt den Signalfluss des Beispielsystems, diesmal unter Einbeziehung der Software-Architektur bei Verteilung auf drei ECUs.
Die Abbildung orientiert sich am AUTOSAR-Standard, die Effekte existieren jedoch in vergleichbarer Form auch heute schon in nahezu allen verteilten Systemen. Im Idealfall durchlaufen alle Signale von der Sensor-Hardware alle Komponenten immer in derselben zeitlichen Folge, analog einem Fließband. D.h., alle Stufen haben dieselbe Frequenz und sind perfekt synchronisiert, so dass die zweite Stufe genau dann beginnt, wenn die erste Stufe fertig mit der Berechnung ist usw.
In heutigen „zeitgesteuerten Systemen“ bedient man sich dazu gerne einer Taktung. In der Realität ist das Timing jedoch komplizierter, insbesondere durch die Einflüsse der Plattform bestehend aus Basis-Software, Bus-Kommunikation und Betriebssystem. Das hat mehrere Ursachen.