ReliabiliTTy® 2.0 technology – Benefits
At SafeTTy Systems, we help our customers to develop software for reliable space-based systems, automotive systems (including autonomous vehicles), industrial control systems, medical systems, railway systems, sports equipment …
We do this by developing and applying ReliabiliTTy® software frameworks that are designed to make it much easier to provide evidence that systems will meet ‘safety goals’ and comply with both local regulatory requirements and international safety standards.
For developers of high-reliability, safety-related and safety-critical embedded systems, we believe that ReliabiliTTy 2.0 provides a platform is ‘best in class’ (that is, best in any class).
On this page we outline some of the benefits that use of ReliabiliTTy 2.0 technology can provide to businesses involved in the development of safety-related systems.
We also provide links to information about some of our recent customer projects and an an overview of our SafeTTy Solutions packages and SafeTTy Outsource services.
[This page was last updated: 2024-01-04]
Evidence of compliance with safety requirements and international safety standards
As we discuss on our technology page, the main alternative to the use of a ReliabiliTTy platform in your next design is to use a conventional RTOS.
For many organisations, the key advantages of RTOS designs are that [i] the architecture is familiar to many developers; [ii] it is easy to build a prototype.
On the other hand, a key challenge with RTOS designs is that there may be a very large number of possible system states: this can make it very difficult to provide clear evidence that the resulting system will always operate correctly. This, in turn, means that long test cycles (sometimes very long) can be required in order to provide evidence of compliance with safety requirements and international safety standards.
As we discuss on our Technology page, ReliabiliTTy designs (whether they are based on a single processor or 100 processors) have highly-determinstic timing behaviour. Put simply this means that we know what the system should be doing at any given point in time; this, in turn, makes it easy to determine if something has changed (for example, because of a hardware failure).
The bottom line:
The deterministic behaviour of ReliabiliTTy designs means that – compared with an equivalent RTOS-based design – it is easy to provide evidence that the system will operate in compliance with its safety requirements (and international safety standards) at all times.
Reduced development times
The determinstic behaviour of designs based on ReliabiliTTy platforms can also help to reduce development times; this is primarily because (when compared with RTOS-based designs), test processes for ReliabiliTTy designs are much simpler.
This difference arises because, as we noted above, RTOS-based designs may have a very large number of possible system states: this can mean that long test cycles can be required in order to be sure that all possible system states have been considered. This means that changes to a single task (for example) may have a significant impact on the whole system (and require an extensive programme of re-testing).
By contrast, ReliabiliTTy designs usually run only one (co-operative) task at a time, in a pre-determined sequence. This greatly reduces the number of possible system states. This means that changes to a single task (for example) will have a limited impact on the behaviour of the rest of the system – and this impact can be modelled and assessed before the (limited) re-testing begins.
The bottom line:
With ReliabiliTTy designs, there is no need for the long ‘fix – test – fix – test …’ cycles that can be required when the software operates in a less deterministic manner – this helps to reduce development times significantly.
Reduced unit costs
Our lightweight ReliabiliTTy platforms have minimal processing and memory requirements, and are not tied to particular hardware: most of our customers base their products on off-the-shelf microcontrollers from a range of different semiconductor manufacturers.
When compared with a conventional RTOS, ReliabiliTTy platforms impose a minimal processor load. In addition, the maximum (and yes we really mean maximum – not average) processor load can be modelled precisely at design time: it is therefore not necessary for the development team to use a more powerful MCU ‘just in case’ the software load proves to be higher than expected.
The bottom line:
With ReliabiliTTy designs, processor load can be modelled precisely, allowing safe use of a low-cost processor (with a high processor load).
Reduced corporate risk
In our experience, use of ReliabiliTTy designs all organisations to:
- demonstrate compliance with safety requirements and international safety standards more easily than is possible with designs based on a conventional RTOS;
- develop products more quickly than is possible with designs based on a conventional RTOS;
- develop products with lower unit costs than is possible with a conventional RTOS.
The bottom line:
Organisations that use ReliabiliTTy platforms can reduce levels of corporate risk.
Benefits of ReliabiliTTy 2.0 vs. ReliabiliTTy 1.0
The technology behind ReliabiliTTy 2.0 has evolved over a period of around 25 years, building on project experience and research conducted by members of the SafeTTy team.
If you’d like to explore the original philosophy and code examples, the ‘Patterns for Time Triggered Embedded Systems’ book can still be downloaded – free of charge – from our PTTES page. You can also download sample chapters and various code examples from the more recent ‘Engineering of Reliable Embedded Systems’ book – also free of charge – from our ERES2 page.
With the benefit of hindsight, we now view the PTTES material as ‘ReliabiliTTy 0.0’ technology, and the ERES2 material as ‘ReliabiliTTy 1.0’ technology.
We have not (yet) published a book that documents ReliabiliTTy 2.0 technology in full but if you are familiar with the contents of the ERES2 book then our Technology page summarises some of the key recent developments (the changes may look small but the impact is significant, both in terms of diagnostic coverage and ease of use).
Please contact us if you are already using ReliabiliTTy 1.0 technology and wish to consider a switch to ReliabiliTTy 2.0.
Customer examples
You may like to consider some examples of our recent customer projects.
SafeTTy Solutions™ packages
We offer SafeTTy Solutions™ packages that are designed to help our customer’s development team produce TT embedded systems that are reliable, secure and safe, in compliance (where required) with one or more international safety standards: IEC 61508, ISO 26262, DO-178C, IEC 62304, IEC 60730 …
Learn more about our SafeTTy Solutions packages …
SafeTTy Outsource™ services
We offer a SafeTTy Outsource™ service, where we perform some or all of the software development activity for our customer (including organising qualification by a third-party assessor, where required).
Learn more about our SafeTTy Outsource services …