Conferences and supporting programme
How Can You Sustain High Performance with Functional Safety Features?
Embedded systems markets are seeing relentless push for higher performance, while at the same time markets such as drones and robotics are introducing requirements for functional safety. Software developers concerned about developing for safe systems may be using coding standards such as MISRA, or use safety certified compilers and operating systems. The underlying hardware is also adding more features to support functionally safe systems, and it’s imperative that software engineers understand these features to get best performance from the design and meet their safety goals. This paper considers methods to achieve both high performance and high levels of functional safety, and will help software engineers understand features in both existing and new hardware platforms. We will discuss features including software test libraries, error correcting memories and detecting both software and hardware faults at runtime. We also consider at a higher level how hardware features such as additional privilege levels for virtualisation allow new software development methodologies. ---------further information------- Dual-core lockstep processors are used for the most demanding safety requirements, and these are entirely transparent to software developers. Looking to the future, demand for higher performance means that we will need to achieve this level of safety on application class processors. We will look at approaches to achieve this and what impact it will have on software. Error correcting codes are often used on memories – a common option can correct single bit faults and detect double bit errors. For the software developer this process is transparent, but it can have a performance impact – we will explain why and how to mitigate the effects. Memory protection units are offered by many common MCUs, but they need to be configured in software. In the simplest case they can be used for stack protection, making sure data is never executed and instructions are read only. With an RTOS you can start protecting tasks from each other, and making sure only the appropriate sections of code access peripherals. Newer embedded processors introduce a second level of memory protection, through which a hypervisor allows multiple OSes of different levels of criticality to be run on the same processor, isolated from each other in space and time. Software test libraries are carefully crafted sections of code, designed to be called at runtime to test parts of the processor for latent faults. Because they are just software code, they can save and restore processor state making them easy to use and much lower overhead than logic BIST. The software developer can then select the appropriate level of coverage, run time and code size trade-offs, and build them into the runtime or operating system.
--- Date: 28.02.2018 Time: 1:30 PM - 2:00 PM Location: Conference Counter NCC Ost