Towards 0-bug software in the automotive industry

Towards 0-bug software in the
automotive industry
Amin Amini

www.certx.com
Autonomous
systems
Functional safety
of electronic controls
OT / IT Cyber
security
CertX – Our Expertise
CertX ensures your innovation with unique know
Machinery,
Robotics,
Automation
Automotive
Autonomous mobility
Drones,
UAS
Railway,
Signalling,
Train Control
2
EN ISO 13849
IEC EN 61508
IEC EN 61496
ISO 26262
ISO 21448 (SOTIF)
ASPICE
EC 2019/945 & 947
EN 50126 / 50128 / 50129
EC 2009/402 (CSM)
EC 2006/42
(CE)
ISA/IEC 62443
ISO 21434
ISO 27001/2
GDPR
CertX webinar © 2021 by CertX AG , all rights reserved

www.certx.com
Product Certifications
Concept Development Prototyping / Test Manufacturing
Accelerate your development – we support you from the start of it
3
Assessment
On-Site Audit
Application Certificate
• Product description
• Scope of certification
• Definition of certification
requirements
• Milestones and timeline
• Audit FS* / CS** management manual/system
• Production audit (incl. suppliers w/o certificate)
• Audit report
Kick-Off
• Product changes
• Accidents and incidents
Annual
Surveillance
*FS: Functional Safety
**CS: Cyber Security
• Assessment of design and process documents
• Assessment Report
• Tests as required along the development

www.certx.com
CertX Services
CertX provides comprehensive safety and security services
4
TRAINING & CERTIFICATION of ENGINEERS and MANAGERS
ASSESSMENTS of products and processes
ISA (Independent Safety Assessment) or AsBo (Assessment Body) as
a pre-requisite for the approval by the railway authority.
CERTIFICATION of PRODUCTS
CERTIFY CORPORATE PROCESSES and ORGANIZATIONS

www.certx.com
Dilemma of Fail Safe, Fail Secure and Fail Operational
3-dimensions dilemma
• Fail Safe: In case of failure, systems can achieve the
safe state. Most systems are Fail-safe.
• Fail operational: in case of failure, systems remain
operational.
• Fail Secure: In case of failure, system remain in its
secure state.
Challenges:
 Normally fail-safe and fail operational goals are in
contradiction
 Classical Safety Mechanism does not cover the fail
operational aspects
 Fail operational architectures shall guarantee almost
the full functionality in the case of a fault.
Fail Operational
Fail Safe
Fail secure

www.certx.com
7
 ISO 26262:2018 Road vehicles Functional Safety — Applied to safety-related
systems that include one or more electrical and/or electronic (E/E) systems and
that are installed in series production road vehicles, excluding mopeds
 ISO 21448:2021 Safety Of The Intended Functionality- An acceptable level of
safety for road vehicles requires the avoidance of unreasonable risk caused by
every hazard associated with the intended functionality and its implementation,
especially those not due to failures, e.g. due to performance limitations or
insufficiencies of specification.
 ISO 21434:2020 Road vehicles Cybersecurity engineering - This document
addresses the cybersecurity perspective in engineering of electrical and
electronic (E/E) systems within road vehicles. By ensuring appropriate
consideration of cybersecurity, this document aims to enable the engineering of
E/E systems to keep up with changing technology and attack methods.
Automotive industry Safety & security standards

Most Seen Challenges for Safe &
Secure codes

www.certx.com
Challenge 1 – Software Requirement Specification
9
A Software Requirement specification within the following characteristic:
Unambiguous and comprehensible:
Must be unambiguous and understandable
Atomic:
Cannot be divided into more than one safety
requirement
Internally consistent:
Each individual safety requirement contains no
contradictions within itself
Feasible:
safety requirement can be implemented within the
constraints of system development
Verifiable:
Safety requirement can be tested and verified for its correct
specification and implementation
Necessary:
an essential capability, characteristic, constraint,
and/or quality factor
Implementation free:
avoids placing unnecessary constraints on the
architectural design
Complete:
requirement is clear without further amplification
Conforming.:
requirement conforms to applicable government,
automotive industry and product standards

www.certx.com
Freedom from interference
absence of cascading failures between two or more elements that could lead to the violation of a safety
requirement
EXAMPLE 1 Element 1 is free of interference from element 2 if no of element 2 can cause element 1 to fail.
EXAMPLE 2 Element 3 interferes with element 4 if there exists a failure of element 3 that causes element 4
to fail.
Application: if the embedded software consists of software components with different ASIL ratings. 2
option are proposed:
- The entire software must be developed according to the highest ASIL
- freedom from interference shall be ensured for software components with a higher ASIL rating from
elements with a lower ASIL rating.
10
Challenge 2 - Freedom from Interference (FFI)
SW Module ASIL
QM
SW Module ASIL
QM
Software Element ASIL C

www.certx.com
The faults are grouped as follows:
• Memory : Software Components which are developed according to a low ASIL
rating may interfere by wrongfully accessing memory regions of software
components with a higher ASIL rating.
• Timing: Safe behavior requires that the systems actions and reactions are
performed within the right time without monopolizing the CPU.
• Execution : An incorrect control flow occurs if one or more program
instructions are processed either in the incorrect sequence or are not even
processed at all.
• Exchange of Information : In a distributed system, the exchange of data
between a sender and the receiver(s) can affect functional safety, if its safe
behavior safety depends on the integrity of such data
11
Challenge 2- Freedom From Interference (FFI) – elements

www.certx.com
12
Verification methods of SW architectural design:
a) data-flow analysis: is a technique for gathering information about the possible set of values calculated at
various locations in a computer program
b) control-flow analysis: is a technique for determining the order of operations in a computer program.
Challenge 3 – SW Design Verification
Src: Ldra

www.certx.com
13
Challege 4 - SW Unit Verification
To enable the specification of appropriate test cases for the software unit testing, test
cases shall be derived using the methods as listed in Table 8.
To evaluate the completeness of test cases and to demonstrate that there is no unintended
functionality, the coverage of requirements at the software unit level shall be determined and
the structural coverage shall be measured in accordance with the metrics listed in Table 9.

www.certx.com
Workshop - Slide 14
 Objectives:
1. To provide criteria to determine the required level of confidence in a software tool when applicable.
2. To provide means that the user can rely on the correct functioning of a software tool for those activities or
tasks required by ISO 26262
 Tool Confidence Level (TCL):
 Tool Impact (TI)
 Tool Error Detection (TD)
 TI1 is chosen when there is an argument that there is no possibility that the malfunctioning software tool
can violate a safety requirement. For all other cases, TI2 is chosen.
 TD1 is chosen if there is a high degree of confidence in the tool's ability to detect an error.
 TD3 is chosen for a very low degree of confidence, often when it is determined that the error can only be
detected randomly.
Challenge 5- Confidence in Use of Software Tools
14
Tool Error Detection
TD1 TD2 TD3
Tool
Impact
TI1 TCL1 TCL1 TCL1
TI2 TCL1 TCL2 TCL3

www.certx.com
Workshop - Slide 15
No particular requirements for SW parts in
ISO/SAE 21434 excepting:
 Management activities
• Tool management (trusted SW env.)
• Information sharing ()
• Management systems (incl. SW config.)
 Development activities
• Use of suitable coding guideline (MISRA-C or
CERT-C)
• Use of trusted secure design and
implementation principles (e.g. use of NIST
SP-800-160, Appendix F.1…)
• Security V&V (review, analysis, simulation,
prototyping and specific activities such as
vuln. scanning, fuzzing, pentest…)
ISO/SAE 21434 – Cyber Security
15

www.certx.com
Workshop - Slide 16
No particular requirements for SW parts in
ISO/SAE 21434 excepting:
 Continual activities
• Cybersecurity monitoring: collect as much
information as possible about your products,
your environments and threat landscape (e.g.
threat intelligence platform)
• Vulnerability management: evaluate your
vulnerabilities to react accordingly (e.g.
Incident-Response triggering, development of
patches/updates…)
 Post-development activities
• SW handling during production (Security
controls of servers holding SW parts, post-
development requirements)
• End of cybersecurity support &
decommissioning: communicate a consistent
period
16

www.certx.com
Workshop - Slide 17
Cyber security approach described by ISO/SAE 21434 is totally aligned with FuSa standard (ISO 26262), but
proposing a more generic description of security-related activities applicable for either system, SW or HW parts
Reminder:
“In the European Union, the new regulation on cyber security (UNECE WP.29/R155) will be mandatory for all new
vehicle types from July 2022 and will become mandatory for all new vehicles produced from July 2024.“
Be prepared for demonstrating your compliance in a near future !
17

The information contained in this presentation is the property of CertX AG.
This presentation and extracts thereof may only be duplicated or forwarded tthird parties following
explicit written approval by CertX AG.
All product names used in this documentation are trademarks or otherwise protected by law, even if
not specifically indicated.
© 2020 by CertX AG.
Route Ancienne Papeterie 106
1723 Marly, Switzerland
www.certx.com
All rights reserved.
18

1
Conﬁdential . EasyMile© . 2021
AUTONOMOUS FUTURE,
TODAY
EasyMile brings driverless vehicle solutions
for people and goods to life with leading technology,
providing a real service.

2
Autonomous solutions ready today
—
EasyMile provides software and
complete solutions for driverless
mobility and goods transportation.
We partner with blue-chip
manufacturers to automate their
vehicles. Our technology is built on
safety-by-design and ready for
deployment today with clear
client benefits.

3
EasyMile at a glance
—
5
locations
22
nationalities
Shareholders and partners
Since
2014
240+
30+ PhDs
IS0 9001
certiﬁed
Denver, USA
Berlin, Germany
Singapore
Adelaide, Australia
Headquarters
Toulouse, France
Recognition

4
Focused on Level 4 of autonomous driving
—
DRIVERLESS
FULLY AUTONOMOUS
In a known area
4
DRIVER
Zero autonomy
0
FEET-OFF
Assisted
1
HANDS-OFF
Low
automated
2
EYES-OFF
Medium
automated
3
FULLY AUTONOMOUS
Everywhere
5
HUMAN
TODAY

5
Driverless technology’s promise
—
Safe
Reduce the 1.35
million deaths per year
in human driven
accidents.
Make workplaces
safer where fatal
accidents are most
commonly caused by
machines, tools or
handling equipment.
Productive
Meet unsatisﬁed
mobility needs.
Savings on industrial
ﬂows.
Green
Lower
congestion, better
use of public and
private space,
decrease
emissions.
Flexible
Adapt to changes
in demand.
Integrate with
existing systems with
no additional
infrastructure.
Level 4 vehicles
can be deployed
immediately as
demand arises.

6
But there are challenges
—
System
availability
Component
cost
Regulations
Cybersecurity
Safety
Public
acceptance

7
Two offers
—
Vehicle solutions
EZ10: Cities, transit agencies, airports,
colleges/universities, resorts, sports stadiums,
communities, business parks etc.
TractEasy: Factories, warehouses, airports etc.
CLIENTS:
Software
OEMs: Buses, trucks, trams, vans, farm or
warehouse equipment etc.
WE SELL:
1
2

8
Using all the
available data from
the different sensors
in a fusion
algorithm, the
vehicle knows its
position and the
accuracy of it at all
times. Any potential
deviation will safely
slow down or stop
the vehicle.
The vehicle can be
programmed to a
site map, even with
a network of
potential
trajectories, with all
elements triggering
speciﬁc behavior
(e.g speed areas,
pedestrian crossings
etc.). The
vehicle follows
the path smoothly
with pre-deﬁned
behavior.
If an obstacle
appears, the
vehicle’s sensors
detect it and trigger
appropriate
behavior, slowing
down, overtaking or
stopping. When the
obstacle is avoided,
the vehicle
proceeds.
Navigation
—
Perception
—
Localization
—
Vehicles that know how to behave
—

9
Safety Critical System V&V
—
Emergency Collision Avoidance

10
Test Means - VHC in the Loop
Test on Vehicle
Site : Francazal Airport
10
—

11
Test Means - Hardware in the Loop
VHC Simulation Test Bench
11
—

12
Test Means - Hardware in the Loop
SCES T32 Test Bench
12
—

13
Static Veriﬁcation tools (CI)
13
—
Test Means - Software in the Loop

14
Thank you
—
Connect with us:
#EasyMile

March 29th, 2021
Ma t h e m a t ica lly
Gu a ra n t e e d
C a n d C++ Co d e
Fabrice Derepas
Co-founder
CEO TrustInSoft
@fderepas
Formal methods for human beings

Let’s consider that I want to assess
(a+b)2=a2+b2+2ab

I am going to compute this formula
for, let’s say, 10,000 values for (a,b).
I think that I will have a good idea if
the formula holds or not!
Would that still work with larger
numbers? Did I miss any corner cases
(INT_MAX or INT_MIN)

Now let’s consider another approach :
(a+b)2=a2+b2+2ab

(a+b)2=(a+b)x(a+b)
= a2+ab + b2+ba
=a2+b2+2ab
The right approach is to do the
following computations:
Now I know that the equation
holds for any (a,b) couple.

deployment on an
airplane code
Testing or Formal Verification: DO-178C Alternatives and Industrial Experience
IEEE Software (Volume: 30 , Issue: 3 , May-June 2013)
https://ieeexplore.ieee.org/document/6471965

NIST report
to the white
house
NIST underlines in a report to the White House a re s u lt
u n iq u e in t h e w o rld p e rfo rm e d b y
Tru s t In So ft : a mathematical assessment of absence of
buffer overflow or memory error in a stack at the core of
ARM’s mbed environment.
https://trust-in-soft.com/polarssl-verification-kit/

Journey to maximum quality with TIS
Boost the coverage of your tests
with generalized inputs / static
analysis
Check functional implementation
Customer test activities
with TIS
Stage 3
Stage 2
Stage 1
Customer Benefits
• Ensure implemented SW architecture and
functions behave in line with spec
• Full mathematical guarantee for safety
and security
• Mathematical guarantee that all
Undefined Behaviours are detected
• 0 false negatives
• Achieve up to 100% coverage on unit
tests
• Instant productivity: find more bugs
quicker
• Mathematical guarantee that Undefined
Behaviors resulting from discrete tested
values are detected
• 0 false positives & 0 false negatives
Existing tests with discrete
values are replayed
“dynamically” in TIS
Max quality

• Signed Overflow (24)
• Uninitialized Variable (2)
• Uninitialized memory (1)
• Link Error (1)
• Invalid Pointer Arithmetic (1)
• Uninitialized Variable (3335 times)
• Incompatible Function Pointer (735)
-Rules of the game: Find UBs by replaying-existing test suits & Use a fuzzer (AFL)
-Results: After generating 10,000 test with AFL from the 44 existing ones, we found 13 UBs
Removing vulnerabilities is key when used as a live intrusion detector
2019: 13 UBs identified on Wireshark Packet Analyser
Found new bugs not caught by other tools for years

Compute 2^4 in a virtual machine
#define ARRAY_SIZE 10000
unsigned char mem[ARRAY_SIZE] =
{80, 7, 5, 5, 3, 5, 3, 5, 4 , 11, 2};
#define NEXT
if (pos<ARRAY_SIZE-1) ++pos; break
int main() {
unsigned int A=0, B=0, pos=0;
while (1) {
switch (mem[pos] & 7) {
// add
case 0: A+=mem[pos]>>3; NEXT;
// substract
case 1: A-=mem[pos]>>3; NEXT;
// load
case 2: A=mem[B]; NEXT;
// store
case 3: if (B<ARRAY_SIZE) mem[B]=A; NEXT;
// exit
case 4: return A;
// load and add
case 5: if (B<ARRAY_SIZE) A=A+mem[B]; NEXT;
// goto A
case 6: if (A<ARRAY_SIZE) pos=A; break;
// swap A and B
case 7: {int tmp=B; B=A; A=tmp;} NEXT;
}}}

Let’s run this code
$ clang vm.c && ./a.out
$ echo $?
16

25610,000
tests
25610,000 is a number with 24,000 digits

solution
#include <tis_builtin.h>
{80, 7, 5, 5, 3, 5, 3, 5, 4 , 11, 2};
#define NEXT
int main() {
tis_make_unkown(mem, ARRAY_SIZE);
while (1) {
// add
// substract
// load
case 2: A=mem[B]; NEXT;
// store
// exit
case 4: return A;
// load and add
// goto A
// swap A and B
}}}

solution
#include <tis_builtin.h>
{80, 7, 5, 5, 3, 5, 3, 5, 4 , 11, 2};
#define NEXT
int main() {
tis_make_unkown(mem, ARRAY_SIZE);
while (1) {
// add
// substract
// load
case 2: if (B<ARRAY_SIZE) A=mem[B]; NEXT;
// store
// exit
case 4: return A;
// load and add
// goto A
// swap A and B
}}}

SSL/TLS Without
Undefined behavior
• Using TrustInSoft Analyzer we have a report which tells how to compile, configure
and deploy mbedTLS in a given perimeter in order to be immune from all attacks
caused by CWE 119 to 127, 369, 415, 416, 457, 476, 562, 690. All bugs of those
kind were found and removed.
• Download the full report: http://trust-in-soft.com/polarssl-verification-kit
2016: NIST underlines in a report to the White House a result
unique in the world performed by TrustInSoft: a mathematical
assessment of absence of buffer overflow or memory error in a
stack at the core of ARM’s mbed environment.

AIS2DW12 Driver - TIS CI Analysis
• The AIS2DW12 3-axis accelerometer was selected as it had the most recent
contributions on github
• TIS Analyzer determined, simulated and cascaded the superset of all possible
inputs, code values and behaviors
• Buffer overflow identified and fixed in less than 1,5 hour (incl. the time to
get familiar with ST datasheet and driver)
• With the proposed fix and the analysis run again, TIS confirms that for all
existing tests, whatever the registers the HW contains, the driver has no
undefined behavior
• Link to this issue and new commit from ST
https://github.com/STMicroelectronics/STMems_Standard_C_drivers/issues/
75

ACSL:
ANSI/ISO C Specification Language
•Code is annotated using comments
•It’s based on the concept of contract
•Allows to specify functional properties
•ACSL enables to combine multiple analysis
techniques within TrustInSoft Analyzer

/*@requires n>=0 &&
valid(t+(0 .. n−1));
assigns nothing;
ensures result!=0 <==>
(forall integer j ;0<=j<n ==> t[j]==0) ;
*/
int check_all_zeros (int t[],int n){
int k;
/*@ loop invariant 0<=k<=n;
loop invariant (forall integer j ; 0<=j<k ==> t[j]==0);
loop assigns k ;
loop variant n−k ; */
for(k=0; k<n; k++)
if(t[k]!=0)
return 0;
return 1;
}
Checking values
in an array
9 red lines
6 black lines
From https://nikolai-kosmatov.eu/publications/talk_2015_11_24_SASEFOR_slides.pdf, thanks Nikolaï!

What if the math is too hard?
WHY 3
http://why3.lri.fr/
Automatic provers
Alt-Ergo, Beagle, CVC3, CVC4, E
Prover, Gappa, Metis, Metitarski,
Princess, Psyche, Simplify, SPASS,
Vampire, veriT, Yices, Z3.
Proof Assistants
Coq, PVS, Isabelle/HOL
you knew you could do the job
yourself!
C/C++

32
Our customers’ primary drivers
ENSURE CODE QUALITY
AND OPERATIONAL
EFFICIENCY
Where do your team’s priorities fall?
ENSURE
CODE SECURITY
ENSURE
CODE SAFETY
 Boost software coverage
 Reduce software verification efforts/costs
 Reduce updates & critical issues handling costs
 Avoid multiple certification iterations
 Improve Time to Market
 Perform tests on host as if they were on target
 Ensure source code
vulnerabilities are detected and
removed
 Ensure software does not crash
 Ensure code deterministic behaviour
 Ensure code does what it is supposed to
 Ensure functional implementation in line
with spec

Not your usual
static analyzer
• Analysis starts from an entry point (like a test)
• Exhaustive coverage of inputs
• Supports full C and C++ language up to C++17
• Platform specific analysis without compiling
• Universal forward/backward debugger for
efficient bug fix

Towards 0-bug software in the automotive industry

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Towards 0-bug software in the automotive industry

Similar to Towards 0-bug software in the automotive industry (20)

Recently uploaded

Recently uploaded (20)

Towards 0-bug software in the automotive industry