SYSTEM ENGINEERING FOR

HIGHLY AUTOMATED
DRIVING - Safety Directed Design
Approach towards Architecture
Definition

April 6th, 2022

In Association with Automotive World 1

Whom are you listening to today?

Rohit Jain
INCOSE CSEP
Practice Director,
Autonomous Driving
Agenda

1. About KPIT

2. Autonomous Industry Trends and Challenges

3. Role of System Engineering in Autonomous Driving

4. Key Strategies – CONOPS, Requirements & Design Synthesis

5. How to improve the overall effectiveness of higher autonomy systems

6. Q&A

3
4
Software Autonomous eCockpit and
Electrification
solutions for Driving & ADAS Connectivity

new age
mobility Cloud & New age vehicle
Engineering & Predictive
Virtualization Diagnostics
Design

Common Middleware for new

E/E Architecture (AUTOSAR, Cybersecurity, OTA)

5
 25
Strategic clients in
Mobility ecosystem
7000+
KPITians passionate
Multi Domain about mobility &
Expertise technology
700+
Vehicle production
Global Scale program experience

World class
Quality systems
Dependability Worldwide footprint
Software centers of A-Spice L5 certified
excellence in
11 global locations
 10 Years
of ADAS/AD development

Software 19 OEMs & 8 Tier 1s

Integration partner partner with KPIT
for ADAS/AD
37 SOP
development programs

We Industrialize 56 Production
ADAS/AD software Projects

from Prototype
19 ECUs and Domain
technology to Controllers
Production ready as Integration Partner

solutions 3 Million Scenarios for Virtual

Simulation per ISO, NHTSA,
NCAP, SAE for Level 2 & L3+

7
Agenda
1. About KPIT

2. Autonomous Industry Trends and Challenges

3. Role of System Engineering in Autonomous Driving

4. Key Strategies – CONOPS, Requirements & Design Synthesis

5. How to improve the overall effectiveness of higher autonomy systems

6. Q&A

8
Global Trends
Autonomous Vehicle market expected
to reach $557 Billion by 2026

AD Cars to grow at 39% CAGR

▪ Large adoption of ADAS vehicles
▪ Autonomous Ride-Sharing
technology
▪ Regulation support (Germany, US,
Japan etc.)

AD Trucks to grow at 12.6% CAGR

▪ Keep trucks on the road all the time
▪ Digitization and Autonomous Driving
to Halve Logistics Costs by 2030
▪ Focus on safety and pollution
▪ Reduced Emission & Greater Fuel
Efficiency 9
Autonomous Driving
– Challenges
AVs can avoid 1/3rd of all accidents as they have more
accurate perception than humans But, for the other
2/3rd AVs must be programmed to prioritize safety
[as per study by IIHS]

As system complexity and safety needs are increasing

exponentially as we approach higher level of autonomy,
we see imperfection and unreadiness despite of plenty
of pilots :

▪ Performance Issues
▪ False Negatives – Missed Detections
▪ False Positives – Ghost Targets
▪ Error Prone, Not Resilient enough
▪ Unintended Behavior

10
Shortcomings - Gaps during HAD Development

Operational Design Domain Scalability & Robustness

System Use Cases Accuracy

Requirement Quality Reliability & Availability

The exponential jump in complexity from SAE L1/L2 to L3/L4 means that traditional development process
is no longer sufficient and needs to be completely rethought

What is needed – What can be done to overcome these Gaps ? 4/6/2022

11
Agenda

1. About KPIT

2. Autonomous Industry Trends and Challenges

3. Role of System Engineering in Autonomous Driving

4. Key Strategies – CONOPS, Requirements & Design Synthesis

5. How to improve the overall effectiveness of higher autonomy systems

6. Q&A

12
Key Pillars
The development of highly automated driving is a complex process and it is characterized by a wide
variety of interactions, some of which are unknown.

In order to build a robust product, understanding of multiple domains and Synchronizing

(interactions) it, is important & quiet challenging at the early phase of the product development. A
thoughtful approach is therefore needed in order to solve this

Solving early - saves

cost

Requirement
Analysis
(What to do)

Design Synthesis
(How to do)

13
 “System of Systems” Approach by bringing Design Flow
“life cycle Integration concept” into product

Customer Needs
CONCEPTS OF OPERATIONS

REQUIREMENT
ENGINEERING
DESIGN
SYNTHESIS

System Thinking Leading to Building robust solutions 14

Key Considerations During System Development

Use Cases
System Physical
for
Design Architecture
CONOPS
Agenda

1. About KPIT

2. Autonomous Industry Trends and Challenges

3. Role of System Engineering in Autonomous Driving

4. Key Strategies – CONOPS, Requirements & Design Synthesis

5. How to improve the overall effectiveness of higher autonomy systems

6. Q&A

16
CONOPS | REQUIREMENT |
DESIGN SYNTHESIS

1 Background context

Build CONOPS based on use

2 cases

Architecture Validation through

3 Simulation

4 Requirement Elicitation

5 Design Synthesis
Background Context → Customer Need ADS
Use
Safety of Automated Driving System (ADS) is a significant autonomy challenge Cases
within its own ODD. It is important to ensure that the released product does not
expose its users or other traffic participants to unreasonable risks

Human Driving - ODD

ADS Full ODD

ADS Ltd.
➢ ODD Perturbation ODD
Error
➢ Subjected to Fault ADS
➢ Driver Incapacitated rationally foreseeable
and preventable
*Ref: WP29: Framework document on automated vehicles

To improve the availability of the system, fault-tolerant architecture for the AD system is required to achieve the acceptable
safety level,
Overall Objective – Safe System
- Framework / Concept for ensuring AD Safety Case
1
4 6
Operational Design
Required Operating Regulations
Domain
Conditions for Use Cases
END USER AD NEED

(PAS 1883)

Endurance Run Data

Accident Database -
GIDAS, NHTSA, Pre-
Valid Within

Specific/Region

E/E Anomalies
History (Fault,
Crash, etc.…

Attack, …)
Country
Modelled 3
2 through Concepts of Operations
Use Case Operational Scenarios (MBSE Approach)
Realized By

Classification
Real Traffic Proving Ground Virtual Testing

Knowledge
Test Coverage
7

Expert
System Design ADS Perturbation
ADS Subjected in

5
Operational (Perception)
Safety Perception Disturbance
Validated
Against (Decision Making)
Traffic Disturbance
Functional Safety SOTIF Cyber Security Behavioural
(ISO 26262) (ISO/PAS 21448) (ISO 21434) Safety (Motion Control)
Vehicle Disturbance
(Interface)
Meets User Needs E/E Disturbance
8

19
Operational Design Domain- Categories

Impact
on
*Ref: As per NHTSA
Should be data driven → articulate data (measurable guidelines
parameter) from each of these attributes and not just
a scene

Sensing Planning & Decision Control

20
CONOPS | REQUIREMENT |
DESIGN SYNTHESIS

1 Background context

Build CONOPS based on use

2 cases

Architecture Validation through

3 Simulation

4 Requirement Elicitation

5 Design Synthesis
Use Cases [Life Cycle of Product]

Reg/Industry Norms
Regulations
Adherence to rules of the road
NCAP/NHTSA/FMVSS..

Human Factors &

Response to Anomalies User Trainings
Outside ODD Limits, Cyber Threats, Train the operator
Functional Safety, Faults/System Failure, Feature Awareness
Unknown Situations, ODD Variations Manuals/Guidebooks
.
Within
Intended Behavior operational Manufacturing/Factory
DDT, Object/ Event Detection, Occupant
envelope EOL Calibrations/Settings
Protection, HMI Data Logging /Recording
ODD Serviceability
Mission / Application Vehicle Class
Maintenance.
/Capability Handover/Takeover
.

22
To arrive at the “System and Safety Definition” for “Level 3 / Level 4 Autonomy”
Key Considerations for Use Cases
# Attributes
1 Intended Feature
2 Regulation & Standards
Description
Level 4 Autonomy – Autopilot, Point A to Point B Highway Driving, Chauffer Hub-to-Hub
Automated Driving, Highway Pilot
NHTSA, J3016, ISO 26262, European Standard (EN) 1525, ECE/TRANS/WP29/2019/34/Rev.1

3 Vehicle Specification Passenger car (M1 Category), Class 8 Trucks (N3 Category)……

Object Event Detection and Response LIDAR, stereo/mono Camera, Radar, GPS, V2X, HD Maps, 360 deg Cameras, In-Vehicle Sensors,
4
Capability DSRC, availability of V2X infrastructure to allow V2X communication
Typical interstate highways, Weather Condition, Road Configuration and conditions, Traffic
5 Operational Design Domain
Conditions, Lighting Conditions, Operating Speeds, geographic area
6 Vehicle Capability Braking Performance, Mass of Vehicle, Width and Length of Vehicle, Max Operating Speed
No driver intervention, ACC, Lane Keeping, Expressway merging, high speed cruising, low
7 System Dynamic Driving Task
speed Traffic jam, Adherence to rules of the road (Federal and local laws)
System Dynamic Driving Task Fall-back / Number of possible MRMs, Fail Operational Design, Adherence to rules of the road (Federal
8
Minimum Risk Manoeuvre and local laws)
9 Active & passive Safety System Collision Avoidance, Pre-Crash and Post Crash Behaviours
Driver availability and override possibility, Communication of Critical Messages, Signalling
10 Human Machine Interface
driving intentions to other road users
11 Protecting against Cyber Security Threats Risk Analysis & Mitigation Strategies (Cyberattack events), Incident Management
12 Data Recording Purpose of Data Recording and safe guarding the user privacy
13 Testing & Validation Methods Testing Methods (best practices, design principles, standards)
14 Serviceability / EOL / Factory EOL Settings / Factory Settings / Maintainability

23
 3

Operational Scenarios Ghost Object -

Spoofing Cyber
Threats
Dynamic Driving
Task

1. Via OBD
2. Via Telematics
3. Sensors
4. Communication
Bus
5. V2X

User
Awareness
Environmental
Noise Factor

Factory/EOL

24
Operational | Functional | Architectural Perspective (Sample View) 4

OPERATIONAL ANALYSIS FUNCTIONAL ANALYSIS ARCHITECTURAL ANALYSIS

System Boundary Activity Diagram Logical Architecture

Functional Flow Diagram Sequence Diagram

State Machine Diagram

Concept of Operations 25
CONOPS | REQUIREMENT |
DESIGN SYNTHESIS

1 Background context

Build CONOPS based on use

2 cases

Architecture Validation through

3 Simulation

4 Requirement Elicitation

5 Design Synthesis
Architecture Validation through Simulation
A 1
Operational Analysis - Analyze Use Case &
Requirements

2
Functional Analysis - System Behavioral
User Input
Modelling with IBM Rhapsody (Activity Diagram)

3
Architectural Analysis - Logical Architecture
Validation using IBM Rhapsody

4
Creating design Reference Model (for Simulink)
in Rhapsody

5
Building Detailed design model in Simulink as
per given scenario

Using Simulink & 6 7

Car Maker Review the results against the User
Scenario based validation
environment Requirements

27
Autopilot System Integration
Validating Logical behavior of system through scenarios

Autopilot
System Functions
(Rhapsody)
Rhapsody

Rhapsody Generated
Reference Model
(Simulink)
Simulink

Visualization + Plant Model

(CarMaker)

Carmaker

28
Logical Architecture Validation
Validating the logical Architecture through state
operations

Co-Simulation
Response to Anomalies - Scenarios
Cause/Event/Fault MRM1 MRC1
• Driver Non availability
• Actuator Fault - Steer
Fault
• Sensor Fault MRC2
MRM2
• Communication
failure
Closest destination in my
route

Continue Operation with

limited authority

System might have different MRMs to reach to a specific MRC,

→ either to make a safe stop
→ Limit the ODD and Continue the operation

30
Safety Driven MRM
Use Case Scenario-1: Steer actuation Failure

Scenario Considered:
Ego Vehicle (EV) on Justifications as per ISO
highway going in 26262 guidelines
Feature List: straight path. Distance
b/w EV & LV is less.
1. Highway EV & LV Speed is 60-
Autopilot 130 Kmph but suddenly
Severity – S3 (EV is on
LV applied the brake. highway, travelling with Fail Operational Secondary Function takes over and steers through
medium/high speed and
front/side collision with braking
another passenger car
with medium speed leads
to S3 severity) ASI Steer
Exposure – E3 (Ego LD Actuation
HAZOP Malfunction
vehicle approaching the Failure
Malfunctions Considered:
List: leading vehicle on
highway is most
Loss of Steering assist
occurring scenario)
1. Loss of
Resulting Scenario
Steering assist
leading to Hazard:
2. Unintended Loss of Steering Controllability – C3 (Less
Steering assist assist in Ego vehicle than 90 % of the average
lead to front end drivers are able to avoid
collision of EV with harm)
the leading vehicle.

31
 Safety Driven MRM
Use Case Scenario-2: Primary Autopilot ECU Failure

Scenario Considered:
Ego Vehicle (EV) on Justifications as per ISO
highway going in straight 26262 guidelines
path. Distance b/w EV & LV Secondary Function takes over with redundant camera and actuators
is less. and performs the Minimum Risk Maneuver for safe stop.
EV & LV Speed is 60-130 Severity – S3 (As the EV is
Kmph but suddenly LV on highway, it will be
HAZOP
applied the brake. travelling with
Malfunctions medium/high speed and LiDAR
List: front/side collision with LRR/MRR
another passenger car Side Radar
with medium speed leads
Primary
ASIL Camera
to S3 severity)
Channel Failure Exposure – E3 (Ego
D Rear Radar
Malfunction Considered: Map
- Loss of Loss of primary channel vehicle approaching the
control Resulting Scenario leading vehicle on highway
leading to Hazard: is most occurring scenario)
Loss of primary channel
in Ego vehicle leading to
degraded system Controllability – C3 (Less ECU
behavior and loss of than 90 % of the average
Failure
control lead to front end drivers are able to avoid
collision of EV with the harm)
leading vehicle.

32
ODD/Use Case Coverage
Critical ODD
Critical Operational
Parameter
Scenario Variations
Variation

Combinations
→
Vehicle Stability Limits

If critical situations are captured and

validated, then logical architecture is
robust enough for Requirement
Elicitation downstream

Driving on Busy Vs Driving on Empty

Roads Road
Speed Limit →

Identify the critical corner cases

(within and at the boundary) from
ODD considering variations of all
categories of ODD at each test points
33
CONOPS | REQUIREMENT |
DESIGN SYNTHESIS

1 Background context

Build CONOPS based on use

2 cases

Architecture Validation through

3 Simulation

4 Requirement Elicitation

5 Design Synthesis
Specification through Concept Model
Use Cases

Realize through Realize through

Modelling Realize through Modelling
Modelling

Requirement
Elicitation

35
Requirements Authoring ensuring complete coverage
+ Bi-Directional Traceability

Requirements are being

authored based on the CONOPS

• Covering all life cycle integration

components
• Regulatory Needs
• Performance Needs
• Safety Needs

36
Solution Accelerators

37
Quality Check through Requirement Analyzer/Guidelines
Ensuring INCOSE Guidelines for Writing Requirements

Requirement Leveraging
Attributes: Leverage In-House
SMART V Requirements Requirement
S – Specific | Management Analyzer Tool
Tool for to check the
M - Measurable achieving requirement
A – Achievable | Horizontal correctness
R - Relevant Traceability & based on
Vertical INCOSE 41
T – Traceable | Traceability ruleset
V - Verifiable guidelines

Benefits
▪ Reduction in review and update time on
requirements
▪ Increase the quality of documents
▪ Reduce the manual errors
▪ Quality check based on INCOSE-41 rulesets
Solution Accelerators
Solution Accelerators for ADAS/AD is “Model Based Re-Usable Elements (MBREs)” to perform Variant Management
across different levels of Autonomy

Reusable
Library
Autonomous Driving
“Model Based Re-Usable Elements” (MBREs)

Existing components used (with calibration) to build another product

Use Case Function Interface Component Scalable Requirement Scalable Test Case
Libraries Libraries Libraries Libraries Architecture s Libraries Design Libraries

Parameterization Modular Design Commonality Configurability

CONOPS | REQUIREMENT |
DESIGN SYNTHESIS

1 Background context

Build CONOPS based on use

2 cases

Architecture Validation through

3 Simulation

4 Requirement Elicitation

5 Design Synthesis
Bringing System Resilience as part of Architecture
Development

Trade Off

Integrity → Accuracy →

RAMS Trade Off

Ensuring design and architectural concepts at physical level is addressed thoroughly w.r.t critical aspects

41
Key Considerations during System Design Aspects Telematics
Cloud Server

Critical AV Data
Highly Automated Driving Data Recorder set
- To support
Driving Re-
construction in
1. Fault Response
not reaction
case of
1. ODD Limit
2. Diagnostics + Fault Monitoring Supervisory Control Determination
Incident
Prognostics
ENVIRONMENT

EGO VEHICLE
Signal Situation
Perception Planning Motion Control
Validation Analysis

Critical Considerations

1. Build Safety Envelope

1. Signal Accuracy 1. Env. Sensor 1. Risk Assessment
▪ Mobileye RSS*
2. Signal accuracy based on Motion Arbitration
▪ Nvidia SFF*
Availability 2. Veh. Sensor detection rather
2. Adhere to Traffic
3. To deduce from Accuracy (IMU) – than purely on
Laws
other sources dual sensor classification
3. Dynamics Constraints

OBSERVE ORIENT DECIDE ACT

*Ref: Safety assurance of automated driving systems. Raising the level of ambition, European Commission
Fault Monitoring & Response Strategy

Monitoring Strategy

End Goal
❑ Faster Fault Detection
❑ Fault Isolation
Reliability
❑ Small MTTR
❑ Minimize False Alarm Rate

Availability

System Response
Safety
End Goal
❑ Maximum Availability
❑ Minimize False Alarm Rate
❑ Bigger MTBF
❑ Quick Turn-around time
 Building Safety Envelope Required Navigation Performance
“Safety Envelope for flight path”
Tolerance Needs high accuracy
Band Safety In-Vehicle Sensor
Lateral Tolerance (IMUs)
Separation Band
Safety
Longitudinal
Separation

Responsibility-Sensitive Safety (RSS)

Don’t hit the car in front of you

The 5 Safety Rules of RSS

Don’t cut in recklessly

(Mobileye)
Speed & Traffic Dependent
Right of way is given, not taken
Safety Envelope
Be cautious in areas with limited visibility
Required Navigation Performance
If you can avoid a crash without causing
“Safety Envelope for Autonomous Driving” another one, you must

44
 Scalable to support
higher level of Need of scalability
autonomy with Fault from L1 to L4 in order
Tolerant (Fail-Op, Fail to reduce cost
Safe) architecture

Objective of Reduction of wiring Reduction of multiple

Physical harness to reduce
weight penalty for
ECUs to few ECUs
and reduce
Architecture Electric Vehicles going
forward
complexity and
increase modularity
Aspects
High network
bandwidth to support
Reduce warranty cost
multiple sensor raw
object data

45
Key Considerations during Architecture Aspects
1. Less Redundant (cost
optimization)
2. Dissimilar architecture,
Dissimilar processors
(controllers & software)
3. Dissimilar monitor and
control functions
4. Heterogeneous Sensor
5. Dissimilar IMUs
6. Dissimilar communication
bus
7. Redundant power supply
8. Active Standby mode to
remove the possibility of
latent failures
9. Learning Based Vs Rule
based Decision Making

46
Agenda
1. About KPIT

2. Autonomous Industry Trends and Challenges

3. Role of System Engineering in Autonomous Driving

4. Key Strategies – CONOPS, Requirements & Design

5. How to improve the overall effectiveness of higher autonomy systems

6. Q&A

47
 ▪ The way humans needs to learn and get guidance
on continuous basis to continually acquire and
improve the knowledge and behaviour to
successfully adapt to changing work and life
demands,

▪ The Highly Automated Driving system

operating in real world, also needs continuous
feed to adapt to changing environment and to
learn from its own experiences

Digital Thread enables Continuous Learning

Highly Automated
Improving System on Driving System

the Fly… Real world

Experiences

48
Digital Thread for Digital Twin
Adaptation of DevOps in System Engineering

PLM Tool
Provider
Data Connected
Standardizatio Services
n

Eco
Cyber System Cloud
Technology &
Security Infrastructure

Cyber-
Physical
Telematics
Systems
(CPS)

Digital
Thread
Operati
Mechani
Verificati Validati Productio on &
Concept Requirement Design Development cal
on on n Suppor
Design
t
49
Systems of System PHYSICAL DOMAIN

Architecture to benefit • Vehicle Operating in real world

• Transferring Critical Data sets via Vehicle

from Digital Thread

Telematics
• Receiving Online Updates via SOTA
ADS • Receiving Schedule Maintenance
Vehicle ADS OEDR
Dynamics Actuator Data

• Physics Based Model – Sensors,

Demands
Interaction between Human Driver & ADS
Vehicle Telematics
Plant (if any)
• FEM Model for Mechanical
Components
• Predictive Health Monitoring DIGITAL DOMAIN

Software Defined
Vehicle SOTA
Update

Running DevOps
via Digital Thread
 Reimagining Mobility with YOU

Thank you
For your Time & Attention!

Q&A

If you would like to have detailed discussion on today’s topic,

do reach out to us on:
Rohit.jain@kpit.com