As noted earlier, a simple example of a TT architecture which is in widespread use involves creation of a collection of periodic tasks which operate co-operatively (or “non-pre-emptively”). Such a time-triggered co-operative (TTC) architecture has sometimes been described as a cyclic executive.
Other (more advanced) TT architectures support task pre-emption. For example, “rate monotonic” (TTRM) nd “deadline monotonic” (TTDM) are phrases which are often used to describe a fully pre-emptive, time-triggered scheduling algorithm which can — if implemented in an appropriate manner (with suitable mechanisms for dealing with shared resources) — result in the creation of systems with highly predictable behaviour and low resource requirements.
Support for TTRM and TTDM architectures will be provided in our RapidiTTy™ Professional product.
No system architecture is perfect. However, a key advantage with TT architectures is that problems (caused by coding errors or hardware failure) can be detected very quickly.
For example, in a TT design we know when tasks should run and how long they should take to complete. In such designs a “task guardian” (TG) can be very useful. You can think of a TG as a form of “intelligent watchdog timer” which can be used to identify (and shut down) tasks which are running incorrectly.
[Figure by Zemian Hughes. Click to enlarge.]
Full (and automatic) support for the creation of task guardians will be provided in RapidiTTy™ Professional.
To reiterate: when we say that a computer system has a time-triggered architecture we mean that we can determine in advance — before the system begins executing — exactly what it will do at every moment of time in which it is running.
This key feature is unique to TT systems. It has very significant implications for system developers.
For example, because we know exactly what the system should do, we can tell if it is working correctly. More specifically, we can use tools like RapidiTTy™ Professional to create a “scheduler agent” which matches a particular design precisely. Usually, the scheduler agent will run on a separate processor (to ensure that it is as independent as possible). In many cases, the agent will operate by measuring the power consumption (only) from the main processor: this helps to maximise the separation between the monitored system and the monitoring system.

[Graphic by Kam L. Chan.]
Not all systems require a scheduler agent (or a task guardian). However, where reliability is an important concern, use of task guardians and / or scheduler agents can help to add “safety nets” to your system design. Support for both task guardians and scheduler agents will be provided in RapidiTTy™ Professional.