What is a ‘Time-Triggered’ system?
Time-triggered (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: 2016-12-04]
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.
What are the benefits of using TT architectures in embedded systems?
Use of TT architectures in your system may deliver some or all of the following benefits for your organisation:
- 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
We consider each of these issues in turn below.
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 systems for use in aerospace, medical, automotive and other sectors require certification.
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) in a later section of this web 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‘.
Recommended platforms for TT embedded systems
There are a large number of possible implementation options for TT systems: we find it useful to view these as a range of different “platforms”: the links between some of these platforms and some key international safety standards is summarised in the table below.
For example, the figure below gives an overview of a CorrelaTTor® platform.
As another example, the figure below summarises how a DuplicaTTor® platform might be used in an ISO 26262 design.
Further information about different TT platforms that we find to be particularly effective is available in the ‘ERES2’ book.
TT systems and IEC 61508 (2010)
IEC 61508 is concerned with functional safety, achieved by safety-related systems that are primarily implemented in electrical and/or electronic and/or programmable electronic (E/E/PE) technologies, i.e. E/E/PE safety related systems. The standard is generic in that it applies to these systems irrespective of their application.
The following are examples of E/E/PE safety-related systems:
- emergency shut-down system in a hazardous chemical process plant;
- crane safe load indicator;
- railway signalling system;
- guard interlocking and emergency stopping systems for machinery;
- variable speed motor drive used to restrict speed as a means of protection;
- system for interlocking and controlling the exposure dose of a medical radiotherapy machine;
- dynamic positioning (control of a ship’s movement when in proximity to an offshore installation);
- fly-by-wire operation of aircraft flight control surfaces;
- automobile indicator lights, anti-lock braking and engine-management systems;
- remote monitoring, operation or programming of a network-enabled process plant;
- an information-based decision support tool where erroneous results affect safety.
IEC 61508 and TT architectures
TT architectures are “Highly Recommended” for systems of Safety Integrity Level (SIL) 2 or above. [IEC 61508-3 (2010), Table A.2]
Use of a TT architecture “Greatly reduces the effort required for testing and certifying the system” [IEC 61508-3 (2010), Table C.1]
Static synchronisation of access to shared resources – a key characteristic of all TT designs — is “Recommended” (SIL3) / “Highly Recommended” (SIL4) [IEC 61508-3 (2010), Table A.2]
Limited use of interrupts – a defining characteristic of TT designs – is “Recommended” for SIL1 and SIL2 systems and “Highly Recommended” for SIL3 and SIL4 systems. [IEC 61508-3 (2010), Table B.1]
TT architectures also provide a highly-effective platform for designs that employ “SIL decomposition”: see IEC 61508-2, Clause 7.4.3. We provide a related example (showing ASIL decomposition) in ‘ERES2‘.
TT systems and IEC 62304 (2006) / Amendment 1 (2015)
IEC 62304 is concerned with the development of software for use in medical devices.
The standard notes that software is often an integral part of medical-device technology. It further notes that the effectiveness of a medical device that contains software requires: [i] knowledge of what the software is intended to do, and [ii] demonstration that the software will fulfill such intentions without causing unacceptable risks.
IEC 62304 requires that the manufacturer of the device assigns a safety class (Class A, Class B or Class C) to each software system.
The classes are assigned based on the impact that (failure of) the system may have:
- Class A: No injury or damage to health is possible
- Class B: Non-serious injury is possible
- Class C: Death or serious injury is possible
IEC 62304 and TT architectures
IEC 62304 is intended to be used together with other appropriate standards when developing a medical device. [IEC 62304 (2006), Section C.1]
In particular, readers of IEC 62304 are encouraged to use IEC 61508 as a source for good software methods, techniques and tools. [IEC 62304 (2006), Section C.7]
Many of the comments above about the use of TT architectures to achieve compliance with IEC 61508 also apply with IEC 62304 designs.
At a design level, IEC 62304 has a focus on the use of appropriate risk-control measures.
In our experience, the ‘TT Platforms’ presented in ‘ERES2‘ provide a very effective way of implementing such measures.
TT systems and ISO 26262 (2011-2012)
ISO 26262 is the adaptation of IEC 61508 to comply with needs specific to the application sector of electrical and/or electronic (E/E) systems within road vehicles. This adaptation applies to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic and software components.
Safety is one of the key issues of future automobile development. New functionalities not only in areas such as driver assistance, propulsion, in vehicle dynamics control and active and passive safety systems increasingly touch the domain of system safety engineering. Development and integration of these functionalities will strengthen the need for safe system development processes and the need to provide evidence that all reasonable system safety objectives are satisfied.
ISO 26262 and TT architectures
With respect to timing constraints, the effects of faults such as those listed below can be considered for the software elements executed in each software partition:
- blocking of execution;
- incorrect allocation of execution time;
- incorrect synchronization between software elements.
To deal with these problems] mechanisms such as … time-triggered scheduling, monitoring of processor execution time, program sequence monitoring … can be considered.[ISO 26262-6 (2011) – Annex D]
TT architectures also provide a highly-effective platform for designs that employ ‘ASIL decomposition’: see ISO 26262-9, Clause 5.
TT systems and ISO 13849-1 (2015)
As part of an overall risk-reduction strategy, a designer of machinery will often choose to achieve some measure of risk reduction through the application of safeguards employing what are known as “safety functions”.
ISO 13849-1 provides safety requirements and guidance on the principles for the design and integration of safety-related parts of control systems (SRP/CS), including the design of software. For these parts of SRP/CS, it specifies characteristics that include the performance level required for carrying out safety functions. It applies to SRP/CS, regardless of the type of technology and energy used (electrical, hydraulic, pneumatic, mechanical, etc.), for all kinds of machinery. ISO 13849-1 provides specific requirements for SRP/CS using programmable electronic system(s).
ISO 13849-1 and TT architectures
ISO 13849-1 does not make recommendations about the use of specific software or system architectures (it is up to the system developer to justify their chosen approach).
Our experience is that use of TT (as opposed to ET architectures) can greatly simplify the process of meeting ISO 13849-1 requirements.
For example, use of TT architectures can make it very easy to demonstrate that the system can meet “response-time requirements” [ISO 13849-1 (2015), Section 5.2.6]
More specifically, the ‘TT Platforms’ presented in ‘ERES2‘ provide an effective way of meeting the requirements for a “designated architecture” in ISO 13849-1, as summarised in the table below.
TT systems and IEC 60335 (2010) / IEC 60730 (2013)
[IEC 60335-1:2010+A1:2013] deals with the safety of electrical appliances for household and similar purposes, their rated voltage being not more than 250V for single-phase appliances and 480V for other appliances. … Appliances not intended for normal household use but which nevertheless may be a source of danger to the public, such as appliances intended to be used by laymen in shops, in light industry and on farms, are within the scope of this standard.
In general, [IEC 60730-1: 2013] applies to automatic electrical controls for use in, on, or in association with equipment for household and similar use. The equipment may use electricity, gas, oil, solid fuel, solar thermal energy, etc., or a combination thereof.
This International Standard is applicable to controls for building automation within the scope of ISO 16484.
This standard also applies to automatic electrical controls for equipm ent that may be used by the public, such as equipment intended to be used in shops, offices, hospitals, farms and commercial and industrial applications. …
This standard is also applicable to individual controls utilized as part of a control system or controls which are mechanically integral with multifunctional controls having non – electrical outputs.
IEC 60335, IEC 60730 and TT architectures
IEC 60730 and IEC 60335 are closely related (and compliance with both standards is usually required).
When developing embedded systems in compliance with IEC 60335-1, a key challenge is presented by Clause 19. This clause requires that electronic circuits must be designed and applied in such a way that a fault condition will not render the appliance unsafe with regard to electric shock, fire hazard, mechanical hazard or dangerous malfunction.
The effort required to demonstrate compliance with this core clause (and the standard as a whole) depends on the class of equipment being developed: the options are Class A, Class B or Class C. These are defined in IEC 60730:
- Class A control functions are not intended to be relied upon for the safety of the application (IEC 60730, H.2.22.1).
- Class B control functions are intended to prevent an appliance from entering an unsafe state; however, failure of the control function will not lead directly to a hazardous situation (IEC 60730, H.2.22.2).
- Class C control functions are intended to prevent special hazards such as explosion; failure of such functions could directly cause a hazard in the appliance (IEC 60730, H.2.22.3).
Class B designs are often implemented using small microcontroller-based systems. One of the permitted architectures for a Class B control system is a single-channel (that is, single MCU) design with periodic self-test (IEC 60730, H.2.16.6).
In addition, compliance with IEC 60335 requires limited use of interrupts (IEC 60335, R.22.214.171.124).
Class C designs will generally require more than one microcontroller.
Using a TT architecture can provide a highly-effective way of meeting Class B and Class C requirements.
TT systems and DO-178C (2012)
The rapid increase in the use of software in airborne systems and equipment used on aircraft and engines in the early 1980s resulted in a need for industry-accepted guidance for satisfying airworthiness requirements. DO-178 / ED-12, “Software Considerations in Airborne Systems and Equipment Certification”, was written to satisfy this need.
This document, now revised in the light of experience, provides the aviation community with guidance for determining, in a consistent manner and with an acceptable level of confidence, that the software aspects of airborne systems and equipment comply with airworthiness requirements. As software use increases, technology evolves, and experience is gained in the application of this document, this document will be reviewed and revised.
DO-178c and TT architectures
DO-178c does not make recommendations about the use of specific software or system architectures (it is up to the system developer to justify their chosen approach). Our experience is that use of TT (as opposed to “event triggered” architectures) can greatly simplify the process of meeting DO-178 requirements.
For example, DO-178c requires creation of a Design Description (DO-178c, Section 11.10).
Among other components, the Design Description should include the following:
- The description of the software architecture defining the software structure to implement the requirements.
- Resource limitations, the strategy for managing each resource and its limitations, the margins, and the method for measuring those margins, for example, timing and memory.
- Scheduling procedures and inter-processor/inter-task communication mechanisms, including time-rigid sequencing, preemptive scheduling, Ada rendezvous, and interrupts.
- Rationale for those design decisions that are traceable to safety-related system requirements.
In all of these cases, justifying design decisions is straightforward when a TT architecture is employed.
Want to learn more about TT systems?
Members of the team at SafeTTy Systems have been involved in the creation of successful TT designs for more than two decades.
Over this period, we’ve developed several highly-effective new TT solutions: these have allowed our customers to obtain the benefits of a time-triggered approach in products ranging from household goods to satellite systems.
- We offer Taster Days on your company site (anywhere in the world, on a date of your choosing)
- We offer various training courses (including a free online course) and a related staff certification programme
- We offer various books
Please do not hesitate to contact us if you require any further information.