Mixed Criticality in Autonomous Vehicles

Autonomous vehicles execute tasks across multiple time horizons, each with distinct latency requirements:

• Strategic level (mission planning): route optimization, 10+ seconds response time
• Tcatical level (traffic navigation): lane changing, following, obstacle response, 1-10 seconds
• Operative level (vehicle control): lateral/vertical control, 0.01-0.1 seconds
• Active safety (imminent threat response): emergency braking, collition avoidance, 0.1-1.5 seconds

The severity of failure consequences varies across these layers. This variance enables classification of automotive systems by criticality:

Safety-critical: Highest priority. Failures cause human injury or death.
                 Examples: steering, braking systems.

Mission-critical: High priority. Failures prevent mission completion
                 without direct harm. Examples: navigation.

Low-critical: Minimal impact. Failures affect user experience only.
              Examples: infotainment, radio.

Mixed criticality: Multiple criticality levels coexist on a single
                  platform. Autonomous vehicles exhibit this characteristic.

The autonomous driving subsystem operates at the highest safety-critical level, with failure potentially causing fatalities among passengers and pedestrians.

Automotive Safety Pillars

Modern connected vehicles address safety through three complementary disciplines:

Functional Safety: Mitigates hazards from electrical/electronic system
                  failures in safety-related systems.
                  Standard: ISO 26262
                  Origin: IEC 61508

SOTIF (Safety of The Intended Functionality): Addresses hazards from
                  insufficiencies in intended functionality or
                  reasonably foreseeable misuse.
                  Standard: ISO 21448

Cybersecurity: Protects against unauthorized access, modification,
              or theft of vehicle systems and data.
              Standards: ISO/SAE 21434, SAE J3061

Safety vs Security: Safety targets internal system failures (malfunction prevention), governed by ISO 26262. Security targets external threats (protection against attacks or misuse), encompassing SOTIF and cybersecurity domains.

Among these pillars, functional safety represents the most mature framework. Cybersecurity typically integrates into functional safety processes for unified management. SOTIF methodology remains primarily qualitative, continuing to evolve.

ISO 26262 Framwork

Standard Evolution

The 2011 release encompassed ten parts covering functional safety management, concept phase, system/hardware/software development, and supporting processes. The 2018 revision expanded to twelve parts, broadening scope beyond passenger vehicles to motorcycles, trucks, and buses, incorporating autonomous driving and ADAS provisions, and addressing electric/hybrid vehicle requirements.

Twelve-Part Structure

Part 1  - Vocabulary
          Unified terminology across all subsequent parts

Part 2  - Functional Safety Management
          Planning, implementation, monitoring, improvement
          across automotive lifecycle

Part 3  - Concept Phase
          Early project activities: risk assessment, hazard analysis,
          safety goals, safety requirements

Part 4  - Product Development: System Level
          Safety-related E/E system development processes,
          design analysis, verification, validation

Part 5  - Product Development: Hardware Level
          Hardware component safety lifecycle,
          design, implementation, evaluation

Part 6  - Product Development: Software Level
          Software development safety aspects,
          architecture, design, implementation, verification, testing

Part 7  - Production, Operation, Service, Decommissioning
          Manufacturing through end-of-life safety maintenance

Part 8  - Supporting Processes
          Evaluation, verification, configuration management

Part 9  - ASIL-Oriented Safety Analyses
          Qualitative/quantitative methods: FTA, FMEA,
          automotive safety integrity level determination

Part 10 - Guidelines on ISO 26262
          Additional interpretation and implementation examples

Part 11 - Semiconductor Application Guidelines
          Specific guidance for semiconductor manufacturers

Part 12 - Motorcycle Adaptation
          Specialized provisions for motorcycles and components

Learning Progression

Phase 1: Foundation

• Part 1 provides essential definitions
• Part 2 establishes management context
• Part 10 offers interpretive guidance

Phase 2: Role-Based Specialization

• System engineers: Parts 3 and 4
• Hardware engineers: Part 5
• Software engineers: Part 6
• Quality/safety managers: Parts 2 and 9

Certification Pathways

ISO 26262 remains publicly available for organizational adoption. However, automotive OEMs, particularly European manufacturers, typically require suppliers to obtain third-party certification before procurement consideration.

TÜV Rheinland represents the most recognized certification body in this domain. Beyond organizational certification, they offer professional training and credentialing for individuals pursuing functional safety expertise.

Development Methodology

Three Development Paradigms

Waterfall: Sequential, non-iterative, assumes complete
           upfront requirements. Changes between phases
           are prohibitively expensive.

V-Model:  Extension emphasizing traceability, verification,
          and validation between phases. Non-iterative.
          Standard approach for safety-critical systems.
          Adopted by ISO 26262.

Agile:    Human-centered, iterative evolution of design,
          testing, and requirements. Suitable for
          knowledge-intensive development with uncertain
          initial requirements. Common in internet development.

V-Model Structure

Definition Phase:

• Requirements analysis
• System design
• Architecture design
• Module design

Validation Phase:

• Unit testing
• Integration testing
• System testing
• User acceptance testing

Key Distinctions:

• Verification (internal): Confirms correct implementation → "Have you built it correctly?"
• Validation (external): Confirms stakeholder needs met → "Have you built the right thing?"

ISO 26262 systematically maps its twelve parts to V-model phases, establishing traceability between requirements and validation activities.

Hybrid Approach for Autonomous Driving

Pure V-model application presents challenges given rapid autonomous driving technology evolution and unstable requirements. The industry addresses this through agile systems engineering, combining V-model rigor with iterative agility.

ODD-Based Development:

Operational Design Domain (ODD) defines specific operational
conditions for autonomous driving functions, including:
- Environmental conditions
- Geographic constraints
- Temporal limitations
- Traffic/road characteristics

Each ODD maps to a complete V-model instance. Iterative ODD
expansion enables controlled feature addition while managing
system complexity.

This approach decomposes the overall system by operational domain, applying V-model rigor within each domain while enabling flexible expansion across the portfolio.