55 / 82
for random hardware failures of ≤10-8
per hour.
These metrics are often seen as a
normative requirement, although
in practice they are a proposal, and
developers can justify their own target
metrics because the objective is to
enable safe products, not add bullet
points to a product datasheet.
A question I often ask myself in
respect of semi-autonomous driving
is whether it’s safer to meet the
standard’s proposed metrics for ASIL
D with 10,000 DMIPS of processing
or have 100,000 DMIPS with reduced
diagnostic coverage and enable
Get it delivered
When developing for functional safety,
an essential part of the product is
the supporting documentation which
needs to include a safety manual
to outline the product’s safety
case, covering aspects such as the
assumptions of use, explanation of its
fault detection and control capabilities
and the development process followed.
Safety cases are hierarchical in use,
the case for an IP is needed by chip
developers to form part of their safety
case which then enables their customer
and so forth. Most licensable silicon IP
will be developed as a Safety Element
out of Context (SEooC), where its
designers will have little no idea how
it will subsequently be utilised. Hence
the safety manual must also capture
insight from the IP developers about
their expectations in order to avoid
inappropriate use.
At ARM we support users of targeted
IP with safety documentation
packages, which always includes a
safety manual.
So in summary when planning for
functional safety think PDS:
Process
Development
Safety documentation package
‘smarter’ algorithms with better
judgement? The answer is application
specific, although in many cases a
more capable performant system could
save more lives than a more resilient
system with basic functionality, so
long as its failure modes are not wildly
non-deterministic.
Irrespective of the diagnostic coverage
achieved, it’s essential to follow
suitable processes when targeting
functionally safe applications – and
this is where the standards really help.
Even if you’re not targeting safety,
more rigorous processes can improve
overall quality.
Figure 2. Classes of fault
Table 1. ISO 26262 proposed metrics
New-Tech Magazine Europe l 55