What is a ‘Time-Triggered’ system?
TT software architectures have been used for many years in industries such as aerospace and defence, because they have been found to provide the basis for reliable, robust and secure systems.
Until recently, use of TT architectures has been less common in organisations developing (for example) automotive, industrial, medical systems, or those developing household goods – but this situation is now changing rapidly, as developers in many different sectors experience the benefits of a TT solution.
We provide an introduction to TT architectures on this page.[This page was last updated: 2017-10-13]
TT vs. ET
There are two main architectures used to develop software for modern embedded systems: these can be labelled as “event triggered” and “time triggered”.
For many developers, event-triggered (or “ET”) architectures are more familiar. ET designs involve creating systems which handle multiple interrupts. For example, interrupts may arise from periodic timer overflows, the arrival of messages on a CAN bus, the pressing of a switch, the completion of an analogue-to-digital conversion and so on. To create such systems, the developer may write code to handle the various events directly: this will typically involve creating an “interrupt service routine” to deal with each event. The developer may employ a conventional real-time operating system (RTOS) to support the event handling. Whether an RTOS is used or not, the end result is the same: the system must be designed in such a way that events – which may occur at “random” points in time, and in various combinations – can always be handled correctly.
The alternative to an event-triggered architecture is a time-triggered (“TT”) architecture. When saying that an embedded system has a TT architecture we mean that it executes at least one set of tasks according to a predetermined schedule. The schedule determines the order of the task releases, the time at which each task is released, and whether one task can interrupt (pre-empt) another task. In most cases, the starting point for the implementation of a TT design is a “bare metal” software platform: that is, the system will not usually employ a conventional RTOS, Linux™ or Windows®. In the software platform, a single interrupt will be used, linked to the periodic overflow of a timer. A ‘polling’ process will then allow interaction with peripherals.
If you come from an “ET” background, then working with ‘just one interrupt’ may sound like a significant challenge, but (with a little experience) it’s far easier than you may imagine — and use of a TT architecture can have very significant benefits for organisations that need to produce reliable embedded systems.
We’ll consider some of these benefits in the sections below:
- Improved product reliability
- Ease of certification
- Reduced testing time
- Reduced maintenance / warranty / product recall costs
- Reduced unit costs
- Simpler and more deterministic run-time monitoring
Improved product reliability
The key advantage provided by TT designs is that they have extremely predictable behaviour. This can, in turn, lead directly to the creation of more reliable products.
One reason that TT designs are more reliable is that we always know what state the system (both hardware and software) will be in when an interrupt occurs: this means that we can — when required — provide timing guarantees for key activities at resolutions of microseconds (or even machine cycles, where this is needed). One consequence is that control and data sampling applications can provide extremely high levels of performance (with no “jitter”).
One important (and practical) implication of the use of TT designs is clear when we consider priority inversion (PI).
PI occurs in an ET system when a task of low priority can prevent a task of higher priority from running. In the worst case scenario, the result can be total deadlock (when the system “hangs” completely). Such problems can be reduced if we implement “priority ceiling” protocols correctly — but they can never be removed completely, and PI must be considered carefully during design reviews and when testing the system.
By contrast, TT designs can be rendered immune to priority inversion. This provides significant benefits in many applications, including improved system performance and reduce code complexity.[A YouTube video (Embedded C – Video 4) illustrates some of the challenges caused by priority inversion — and demonstrates why TT designs are not susceptible to this problem.]
Ease of certification
Many embedded systems need to be developed in compliance with one or more international safety standards, such as:
- IEC 61508 (Industrial / Generic)
- ISO 26262 (Automotive)
- IEC 62304 (Medical)
- ISO 13849 (Machinery)
- IEC 60335 / IEC 60730 (Household Goods)
- DO-178C (Civil Aerospace)
Because of the predictable nature of TT designs, certification authorities tend to look very favourably upon the use of this architecture in safety-critical and safety-related systems.
For example, according to the influential international standard IEC 61508 , the use of a TT architecture “Greatly reduces the effort required for testing and certifying the system.” [IEC 61508-3 (2010), Table C.1].
We provide further information about the links between TT architectures and international standards (such as IEC 61508, ISO 26262 and DO-178) on our Compliance page.
Even where your organisation may not be subject to specific certification requirements, there is always a concern that — in the event that one of your designs is alleged to have contributed to a situation in which people were injured or killed, or which has resulted in significant financial loss — you may be required to demonstrate that you followed “best practice” when developing your product.
An appropriate use of TT architectures can be a core part of a “best practice” solution in these unfortunate circumstances.
Reduced testing time
One of the first benefits that many organisations notice when they adopt a TT solution is that the time taken to test their systems is substantially reduced. This helps to ensure that organisations can get reliable products to market much more quickly.
TT systems are easy to test because we always know exactly what the system should be doing at every point in time, and we can (therefore) quickly tell if something is wrong.
If your company is still using a conventional RTOS and / or an ET system design involving large numbers of interrupts, ask yourself how many people in your team really understand how this system works, in detail? Will it ever be possible to work out exactly what will happen if (say) Interrupt 10 is triggered just after Interrupt 6, while Interrupts 2 and Interrupt 3 are being serviced? Just how many possible combinations are there to consider during testing — and will you have to repeat all of the tests again after every small change?
If your team members don’t fully understand how the system operates, how can they be sure that they have really finished testing it prior to release to customers — and how can you ever know exactly how your product will operate in the field?
Reduced maintenance / warranty / product recall costs
The predictable behaviour of TT systems — and the fact that you can be sure that your system has been fully tested before release — translates directly into lower warranty risk, and means that it is much less likely that you will ever need to recall products.
Where systems need to be maintained or upgraded in the field, a TT solution is — again — an excellent starting, point because the impact of changes to any part of the system can be predicted in advance.
Reduced unit costs
Many companies find that use of TT architectures helps to reduce unit costs, not least because it reduces system resource requirements.
There are two main reasons for this:
- Organisations which employ a TT solution find that they can determine maximum CPU loading levels with great accuracy (much more accurately than is possible with an ET solution). As a result, TT designs can run safely at very high levels of CPU loading and can make very effective use of lower-cost processors.
- TT designs don’t require a conventional RTOS: this further reduces resource requirements (and royalty costs).
Simpler and more deterministic run-time monitoring
When developing any reliable embedded design, getting the system to operate correctly on the test bench is only the first challenge: the system – of course – also needs to work ‘in the field’, often for many years.
It is perhaps not surprising that around 50% of the software in many safety-related embedded systems is devoted to run-time monitoring. Creating such software can be very challenging: however the deterministic nature of TT designs can greatly simplify the process of run-time monitoring process, if an appropriate approach is followed.
Further information about appropriate monitoring systems for TT designs is given in ‘ERES2‘.
Learn more about TT systems in ‘ERES2’
The Second Edition of ‘The Engineering of Reliable Embedded Systems’ (ERES2), documents an industry-proven approach to the development of software for reliable, real-time embedded systems, based on the use of ‘Time Triggered’ (TT) architectures.
What distinguishes TT approaches is that it is possible to model the expected system behaviour precisely. This means that: [i] during the development process, we can demonstrate that all of the requirements have been met; and [ii] at run time, we can detect problems very quickly.
The end result is that we can have a high level of confidence that a TT system will either: [i] operate precisely as required; or [ii] move into an appropriate state if a problem occurs.
The above characteristics mean that appropriately-implemented TT systems provide a particularly effective means of meeting the requirements of various international safety standards.