Standards & Compliance

Overview

Modern automotive development must comply with an increasingly complex web of standards and regulations. Understanding how ISO 26262, ISO/SAE 21434, ASPICE, and UNECE regulations interact is essential for project planning.

This course provides a comprehensive overview of all major standards, their requirements, and practical strategies for achieving compliance efficiently without duplicating effort across overlapping standards.

You'll learn to create integrated compliance strategies that satisfy multiple standards simultaneously, reducing overhead while ensuring full regulatory coverage.

Course Modules

1

Automotive Standards Landscape

5 chapters • 3.5 hrs reading

Standards Overview & EvolutionFREE PREVIEW 35 min read

▸ Timeline of key automotive standards: IEC 61508 (1998, base functional safety) → ISO 26262:2011 (first automotive FS edition) → ISO 26262:2018 (2nd edition, adds motorcycles, trucks, semiconductors) → ISO/SAE 21434:2021 (cybersecurity) → UNECE R155/R156:2021 (binding type approval regulation)

▸ Standards Development Organisations: ISO publishes ISO standards; SAE International publishes SAE J standards; IEC publishes base IEC 61508; UNECE WP.29 publishes UN Regulations (legally binding for EU/global type approval); AUTOSAR consortium publishes open AUTOSAR specifications

▸ Standard tiers: Regulation (legally binding - UNECE R155 must be satisfied for EU type approval), Standard (voluntary technical spec - ISO 26262 is industry best practice, referenced by OEM contracts), Guideline (informative - SAE J3061, predecessor to ISO/SAE 21434)

▸ Impact on ECU development: ISO 26262 Part 6 → V-cycle, MC/DC coverage, MISRA C; ISO/SAE 21434 → TARA, security requirements, vulnerability management; AUTOSAR → standardised BSW interfaces; UNECE R155 → CSMS certification; all four frameworks intersect in a modern automotive embedded development lifecycle

Regulatory vs Voluntary StandardsFREE PREVIEW 40 min read

▸ Regulatory standards (mandatory for type approval): UNECE R155 (cybersecurity) and R156 (software updates) became mandatory for new vehicle types in EU from July 2022; China GB/T 44495/44496 cybersecurity regulations mandatory from 2023; FMVSS (US) covers specific safety systems - non-compliance prevents market entry

▸ Voluntary ISO/SAE standards used as contractual obligations: ISO 26262 functional safety is NOT a regulation - but OEMs specify ASIL levels in PPDS/SOR; supplier delivery is rejected without compliance evidence; ISO/SAE 21434 compliance assessed by third-party certification body (TÜV, DEKRA, SGS)

▸ Standards as contractual instruments: AUTOSAR conformance testing (AUTOSAR Validation Suite) is contractual between OEM and Tier 1; Classic BSW modules must pass conformance tests; ASPICE assessment results are OEM qualification gate criteria - suppliers below Level 2 SWE are disqualified from safety-relevant projects

▸ Tool qualification grey area: ISO 26262 Part 8.6 requires tool qualification for all development tools above TCL1; Tool Confidence Level (TCL1/2/3) determination is engineer's responsibility; AUTOSAR tools (DaVinci, tresos) typically include pre-existing qualification kits - reducing OEM/Tier 1 effort but still requiring integration review per project

UNECE R155 & R156 - Type Approval 45 min read

▸ UNECE R155 (Cybersecurity): OEM must establish and maintain a Cybersecurity Management System (CSMS) covering TARA, security requirements, development, production, post-production monitoring; CSMS certified by national type approval authority (KBA in Germany, DVSA in UK); annual 3rd-party re-assessment; references ISO/SAE 21434 as implementation standard

▸ UNECE R156 (SUMS): OEM must document a Software Update Management System covering update identification, authentication, integrity verification, rollback capability, and customer notification; every software update affecting type-approval features requires documented re-verification and updated compliance record

▸ Type approval timeline: new vehicle types in EU must comply from July 2022; all new vehicles from July 2024; China MIIT issued equivalent GB 44495 (cybersecurity) and GB 44496 (software updates) mandatory from 2023; non-compliant OEMs face type approval suspension = vehicles cannot be sold in affected market

▸ R155 evidence package: CSMS documentation (security policy, TARA methodology, threat catalogue), TARA reports per vehicle model per ISO/SAE 21434 Clause 15, penetration test reports, production security measure documentation (key injection procedures), incident response and field monitoring plan - all reviewed by type approval authority

Standards Interrelationship Map 35 min read

▸ IEC 61508 as root standard: generic functional safety for E/E/PE systems; ISO 26262 is a domain-specific automotive adaptation; ISO 25119 for agricultural machinery; IEC 62061 for industrial machinery - all share common Safety Integrity Level concept and V-cycle methodology

▸ ISO 26262 ↔ ISO/SAE 21434 intersection: safety goals (from 26262 HARA) and security goals (from 21434 TARA) can conflict - adding encryption increases latency for safety-critical CAN messages; joint safety+security co-engineering resolves conflicts; SOTIF (ISO 21448) addresses intended-function failures not covered by 26262

▸ AUTOSAR ↔ ISO 26262: AUTOSAR BSW modules include Safety Analysis Documents (SADs) listing Assumed Safety Measures (ASMs) the integrator must implement; E2E library, WdgM, and DEM are 26262-aware components; AUTOSAR Adaptive Platform supports ASIL decomposition via Freedom from Interference mechanisms

▸ IATF 16949 ↔ ASPICE: IATF 16949 (quality management system) is the OEM-mandated quality framework; ASPICE is the software process assessment model; IATF 16949 requires software development capability assessed using ASPICE; OEM SOP gate typically requires supplier ASPICE Level 2 minimum for all safety-relevant software components

Hands-On: Compliance Matrix Creation 50 min read

▸ Compliance matrix purpose: maps each standard requirement clause to responsible role, applicable work products, compliance status (Planned/In Progress/Complete/Not Applicable), and evidence location; serves simultaneously as audit evidence and project management tool; typically in Excel, Polarion, or IBM DOORS NG

▸ ISO 26262 matrix structure: Part 3 (System), Part 4 (HW), Part 6 (SW) each have requirement tables; columns: Requirement ID, Requirement Text, ASIL level, Responsible Role, Work Product, Status, Evidence Reference (hyperlink), Tailoring Justification (if requirement is tailored or excluded with justification)

▸ ISO/SAE 21434 matrix: Clauses 8–15 cover cybersecurity lifecycle; Clause 15 TARA generates Security Goals; each Security Goal links to security controls in Clause 10; matrix maps each security control to implementation evidence + test evidence; tools: Polarion with custom cybersecurity work product types

▸ Audit preparation use: before third-party assessment, compliance engineer reviews matrix for all "In Progress" items, escalates blockers, tests all evidence links (no broken URLs); auditor walks matrix clause by clause; gaps flagged as Major Finding (blocks certification) or Minor Finding (corrective action plan required within 90 days)

2

Safety Standards Deep Dive

5 chapters • 4.0 hrs reading

ISO 26262 Essentials for Compliance 50 min read

▸ HARA (Hazard Analysis and Risk Assessment): identify hazards per function; classify using S (Severity 0–3), E (Exposure 0–4), C (Controllability 0–3) → ASIL A/B/C/D or QM; output = Safety Goals with ASIL; e.g., "No unintended steering torque > 3 Nm at > 30 km/h" = ASIL C Safety Goal from HARA

▸ ASIL decomposition: ASIL C can be decomposed into two independent channels each achieving ASIL A(B) + ASIL B(A); independence must be demonstrated - no shared hardware, compiler, or software block; independence argument documented in Safety Case; decomposition audited by independent assessor

▸ Work products per Part 6 (Software): Safety Plan, SW Requirements Spec (SRS), SW Architecture Design, SW Detailed Design, Source Code (MISRA C compliant), Code Reviews, Unit Tests (MC/DC for ASIL C/D), Integration Tests, SW Safety Analysis (FMEA/FTA), SW Verification Report

▸ Functional Safety Assessment (FSA): independent assessor (Independence Level I2 internal or I3 external from different company for ASIL D) reviews work products and assesses conformance; FSA report lists Observations, Recommendations, and Confirmed Findings; all findings must be resolved before final Safety Case closure and SOP gate

ISO 21448 (SOTIF) Integration 45 min read

▸ SOTIF scope: addresses hazards from performance limitations of intended functionality - sensor limitations, algorithm edge cases - not covered by ISO 26262 (which addresses faults/failures); primarily applicable to Level 2+ ADAS (emergency braking, lane keeping, adaptive cruise) and Level 3–5 automated driving functions

▸ SOTIF 4-zone model: Zone 1 (known unsafe - identified hazardous behaviour under triggering condition), Zone 2 (unknown unsafe - unidentified triggering conditions still possible), Zone 3 (known safe), Zone 4 (unknown safe); engineering goal = eliminate Zone 1, reduce Zone 2, expand safe zones with validation evidence

▸ SOTIF analysis methods: Functional Insufficiency Analysis (FIA) - for each sensor/algorithm, identify conditions where it cannot perform adequately (camera blindness in heavy rain, radar clutter in urban environment); Triggering Condition Analysis identifies driving scenarios where functional insufficiencies occur

▸ ISO 26262 co-engineering: SOTIF functional insufficiencies that cause harm are mapped to HARA hazards; if hazard is caused by intended-function limitation (SOTIF) rather than fault (26262), safety case argument changes - no ASIL assignment, but safety measures and validation evidence still required; joint HARA + FIA workshop recommended at system design phase

ISO/PAS 21448 & Perception Safety 40 min read

▸ Perception system challenges: camera + radar + LiDAR fusion performance varies by illumination, weather, and target size; ISO/PAS 21448 requires performance characterisation over the full Operational Design Domain (ODD) - explicitly define ODD with speed range, weather conditions, road type, and light levels

▸ Scenario-based validation: ISO/PAS 21448 Annex B defines validation approach - identify worst-case scenarios from FIA; simulate in virtual environment (CARLA, RoadRunner + MATLAB Automated Driving Toolbox); prove hazardous event probability falls below acceptable residual risk threshold per exposure analysis

▸ ODD boundary monitoring: ADAS system must detect when approaching ODD boundary and trigger degraded mode or driver takeover request; e.g., AEB monitors precipitation_rate MEASUREMENT - if above threshold, AEB operating domain exceeded → reduce sensitivity and alert driver; SOTIF acceptance test verifies correct degradation behaviour

▸ Perception KPIs for SOTIF evidence: false negative rate (missed object detection = unsafe SOTIF scenario), false positive rate (phantom braking = user-annoying and potentially unsafe), detection latency (≤ 200 ms for AEB to trigger within ISO 22737 stopping distance budget); each KPI validated against SOTIF acceptance criteria in test report

Safety & Security Co-Engineering 45 min read

▸ Conflict identification: security measures can create safety hazards (encryption adds processing latency → safety-critical message deadline missed); safety mechanisms can weaken security (unauthenticated watchdog reset → attacker triggers safety reset); co-engineering resolves by joint safety+security risk assessment

▸ Joint TARA + HARA workshop: identify shared failure modes - e.g., "ECU firmware flashed with malicious code" is both a 21434 security threat AND a 26262 ASIL D safety hazard if software controls brakes; mitigations must satisfy both frameworks simultaneously in one documented co-engineering record

▸ Secure boot vs safety startup timing: secure boot delays startup by 50–200 ms for hash verification; safety-critical ECUs (airbag, ESC) may violate startup timing requirements; solution: safety-first startup with deferred security attestation (runtime verification) - residual risk documented and accepted in Safety Case

▸ OEM-supplier Safety-Security Interface Agreement (SSIA): defines which security measures are OEM responsibility (key management, PKI, certificate provisioning) and which are supplier responsibility (HSM integration, secure coding, penetration test evidence); agreed at project kick-off before development starts

Hands-On: Integrated Safety Plan 55 min read

▸ Safety Plan content: project scope (ECU + software version + ASIL level), safety lifecycle phase plan (HARA → Concept → System/HW/SW Design → Integration → Validation → Assessment), roles/responsibilities matrix (Safety Manager, Safety Analyst, Assessor), work product schedule, confirmation measure plan

▸ HARA workshop exercise: function = Electronic Power Steering; hazards: unintended torque assist (S2, E3, C2 → ASIL B) and loss of steering (S3, E3, C1 → ASIL C); Safety Goal: "EPS shall not apply unintended torque > 3 Nm for > 500 ms during normal driving" - observable, measurable, no solution-specific language

▸ Safety Plan management: reviewed at gate reviews (System Design Review, PDR, CDR, SIL gate, SOD); safety issues tracked in JIRA with ASIL impact field and Safety Manager approval required flag; plan updates trigger Safety Manager re-review; sign-off required before each phase gate

▸ Safety Case structure: argument-based assurance using GSN (Goal Structuring Notation) or plain text; top claim "Item achieves intended safety" → sub-claims → evidence leaves (HARA report, FMEA, test reports, code review records, assessment report); incomplete evidence = open issue blocking SOP clearance

3

Quality & Process Standards

5 chapters • 3.5 hrs reading

IATF 16949 Quality Management 40 min read

▸ IATF 16949 automotive additions over ISO 9001: customer-specific requirements (CSRs) per OEM (VW FORMEL Q, BMW Q-01, Toyota TCS); APQP (Advanced Product Quality Planning) 5-phase gate process before SOP; PPAP (Production Part Approval Process) 18-element production readiness evidence package

▸ APQP Phase 1 (Planning): DFMEA, DVP&R (Design Verification Plan and Report), and control plan prerequisites completed; identify Special Characteristics (SC) - safety/regulatory parameters requiring 100% inspection or Cpk ≥ 1.67; engineering changes documented on ECR traceable to all APQP outputs

▸ FMEA requirements: DFMEA (design) and PFMEA (process) per AIAG-VDA FMEA methodology (2019); DFMEA links design failure modes to Design Controls (prevention + detection); managed in APIS IQ-Software or JAMA; RPN = Severity × Occurrence × Detection; actions required for high-RPN items before PPAP submission

▸ Internal audit structure: IATF 16949 requires system audit (full QMS), process audit (per value stream), and product audit (physical product check); non-conformances classified as Major (immediate corrective action, certification suspension risk) or Minor (corrective action plan within 90 days); auditor must be IATF-approved lead auditor

ASPICE for Compliance 45 min read

▸ ASPICE process reference model: 6 groups - Systems Engineering (SYS), Software Engineering (SWE), Supporting Processes (SUP), Management Processes (MAN), Project Management (MAN.3), Reuse Processes (RUS); each process has Base Practices (BPs) and Output Work Products - both must be performed and managed

▸ Capability levels: Level 0 (Incomplete), Level 1 (Performed - BPs executed), Level 2 (Managed - work products planned, tracked, reviewed), Level 3 (Established - defined standard process used); most OEMs require Tier 1 suppliers to achieve Level 2 for SWE processes; ASIL D ECUs typically require Level 3

▸ SWE process chain: SWE.1 SW Requirements Analysis → SWE.2 SW Architectural Design → SWE.3 SW Detailed Design + Unit Construction → SWE.4 SW Unit Verification → SWE.5 SW Integration + Integration Test → SWE.6 SW Qualification Test; bidirectional traceability required across all 6 processes

▸ Assessment methodology: assessor interviews process owners, reviews work products, rates each Base Practice and Generic Practice as Fully/Largely/Partially/Not implemented per ISO 33020; Level 2 achieved when all BPs rated F/L AND Generic Practices 2.1.1–2.1.7 rated F/L; full assessment lasts 3–5 days for typical ECU project

CMMI & Continuous Improvement 35 min read

▸ CMMI-DEV v2.0 process areas relevant to automotive: Requirements Management (REQM), Technical Solution (TS), Product Integration (PI), Verification (VER), Validation (VAL), Configuration Management (CM), Quality Assurance (PPQA), Risk Management (RSKM), Project Planning (PP), Project Monitoring & Control (PMC)

▸ CMMI vs ASPICE in automotive: ASPICE is automotive-specific (VDA scope), widely used in EU OEM supply chains; CMMI-DEV broader (engineering + defence); some North American and Asian OEM contracts specify CMMI Level 3; both frameworks coexist in large Tier 1 suppliers with global OEM customer base

▸ Continual improvement cycle: field escape → Root Cause Analysis (8D report or Ishikawa diagram) → corrective action → PDCA cycle (Plan-Do-Check-Act) → lesson learned entered into process library; CMMI Level 4 adds quantitative measurement with control charts; Level 5 adds innovation and defect prevention programme

▸ Process KPIs: defect detection efficiency = defects_found_in_review / (defects_found_in_review + escaped_to_test); target > 80%; tracked alongside MC/DC coverage %, mean time to close critical defect, code review effectiveness rate, and ASPICE assessment score trend in Quality Management dashboard

Configuration & Change Management Standards 40 min read

▸ ASPICE SUP.8 Configuration Management: baseline = approved snapshot of all configuration items (source code, ARXML, test scripts, tool versions); change request (CR) triggers impact analysis, CCB (Change Control Board) approval, implementation, verification, and new baseline; AUTOSAR ARXML changes require re-regression of affected BSW modules

▸ ASPICE SUP.10 Change Request Management: every change to a baselined work product requires formal CR with impact analysis (safety impact, test scope, schedule); CR state machine: Open → Under Review → Approved/Rejected → Implemented → Verified → Closed; managed in JIRA with custom automotive CR workflow + Safety Manager approval gate

▸ Version control strategy for AUTOSAR projects: separate repositories for Application SW, BSW Configuration ARXML, generated code, and test cases; tagged baselines synchronised across repos using integration manifest; .arxml files are XML → standard diff and merge tools applicable; binary compiler outputs excluded from VCS

▸ SVVP regression scope determination: when SW module changes, regression test scope set by CR impact analysis - full regression (all tests), partial regression (changed module + interface tests), or documentation-only change (no regression); rationale documented in CR; CI pipeline triggers correct scope automatically per CR type

Hands-On: Integrated Process Framework 55 min read

▸ Framework architecture: IATF 16949 as quality system outer shell; ASPICE SWE processes provide software development rigor; ISO 26262 safety lifecycle runs as parallel safety channel; ISO/SAE 21434 cybersecurity process overlaid on development; all processes linked in a Process Reference Model (PRM) document

▸ Tool integration: JIRA for CR/defect/safety issue tracking with custom automotive workflow; Polarion or IBM DOORS NG for requirements and traceability; Git/Gerrit for version control; Jenkins CI pipeline automates static analysis (Polyspace, Helix QAC), unit tests (TESSY), and metrics collection; work products cross-linked in Polarion

▸ Gate review checklist: PDR gate requires: HARA complete with ASIL assignments, SW Architecture reviewed by Safety Analyst, compliance matrix created, ASPICE SUP.8 baseline established, TARA initiated; gate owner signs Compliance Record before proceeding; missing items = gate hold

▸ Continuous compliance monitoring: Polarion dashboard tracks compliance matrix completion % per standard per week; safety issue burn-down chart; ASPICE practice coverage heatmap; static analysis violation trend (must be decreasing); presented at weekly Safety & Quality sync meeting; red KPIs trigger immediate action items with 5-day resolution deadline

4

Compliance Management

5 chapters • 3.5 hrs reading

Compliance Planning & Tailoring 45 min read

▸ Compliance scoping: determine applicable standards based on component ASIL, function type (safety-critical vs QM), and vehicle market (EU: R155/R156, US: FMVSS, China: GB44495); create compliance matrix skeleton from standards structure; assign responsible roles; define evidence requirements per clause

▸ ISO 26262 tailoring process: certain requirements may be tailored with justification - e.g., ASIL B software does not require MC/DC coverage (only required for ASIL C/D per Part 6 Table 10); tailoring agreed with Safety Manager and documented in Safety Plan; unjustified tailoring = Major Finding in FSA

▸ SEooC (Safety Element out of Context): supplier develops component without full vehicle HARA context; supplier defines assumed vehicle-level Safety Goals and derives Safety Requirements from those assumptions; OEM verifies assumptions match actual vehicle Safety Goals at system integration - assumption gap = integration blocker

▸ Risk-based resource allocation: maximum resources focused on highest-ASIL work products (ASIL D SW = most evidence required); ASIL A/QM components receive lighter oversight; safety budget (person-hours for safety activities) tracked separately from development budget; ASIL breakdown across system informs resourcing plan

Evidence Management & Audit Trails 40 min read

▸ Evidence types: work products (documents, source code, test reports, analysis reports, review minutes), review records (participant list, issues raised, resolution dates), tool qualification records, independence confirmation letters (assessor CV + independence declaration), baseline records (commit hash + build timestamp)

▸ Retention requirements: ISO 26262 Part 2 requires evidence retention for vehicle service life + 10 years minimum; all safety-relevant work products stored in DMS (Windchill, SharePoint with ISO-compliant audit trail); DMS records who accessed, modified, and approved each document with timestamp

▸ Git + JIRA as audit trail: Git commit history + Gerrit code review approvals create natural evidence chain for source code changes; JIRA safety issues show full history of comments, state transitions, and approver names - auditor reviews JIRA tickets as evidence of SW unit verification process

▸ Pre-assessment evidence completeness check: compliance manager reviews 4 weeks before audit; every matrix row must have a valid evidence link (no broken URLs); "In Progress" items need completion plans with dates; assessor receives evidence package 2 weeks before assessment for pre-read; broken links = critical gap requiring immediate remediation

Tool Qualification Strategies 35 min read

▸ ISO 26262 Part 8.11 Tool Confidence Level: TCL1 (no failure possible or immediately detected - no qualification needed), TCL2 (failure has limited impact - operational experience evidence sufficient), TCL3 (failure could cause undetected safety violation - full qualification with validation suite required)

▸ TD × TI → TCL determination: TI1 (tool output not integrated in safety item) = TCL1 always; TI2 + TD1 (failure immediately detectable) = TCL2; TI2 + TD2/TD3 (failure not easily detected) = TCL3; common misclassifications: compiler = TCL3, static analysis tool = TCL3, requirements management tool = TCL2

▸ TCL3 qualification methods: (1) Vendor-provided Tool Qualification Kit - e.g., IAR Embedded Workbench TQK for ISO 26262, MATLAB Polyspace Qualification Kit; (2) Increased confidence from operational use - documented usage history with no failures on similar projects; (3) In-house validation suite against tool specification

▸ Toolchain management: OEM specifies accepted tool versions in project SVVP; tool version upgrade requires re-run of qualification suite; CI pipeline enforces version lock (Docker container with pinned tool versions) to prevent unqualified tool usage in safety-relevant builds; tool version = configuration item under CM

Supplier Compliance Management 40 min read

▸ OEM-supplier compliance model: OEM specifies compliance requirements in PPDS/SOR; supplier responds with Compliance Assessment Report (CAR) before nomination; CAR includes ASPICE capability level (self-assessment + last 3rd-party assessment date), ISO 26262 status, and known deviations requiring OEM waiver

▸ Supplier monitoring during development: OEM project team conducts supplier audits at 6–12 month cadence; quality team tracks PPAP status; safety team tracks Safety Plan milestones (HARA gate, Safety Case gate); ASPICE assessment results reviewed at DRBFM (Design Review Based on Failure Mode) workshops

▸ SOP gate compliance deliverables: Safety Case (ISO 26262 Part 2 with FSA report), Product Cybersecurity Assurance Report (ISO/SAE 21434), PPAP Level 3 package (IATF 16949), ASPICE assessment report (Level 2+ for SWE processes), Type Approval documentation support materials; missing any deliverable = SOP hold

▸ Supplier escalation process: non-conformance → supplier issues 8D report within 14 days → Root Cause Analysis → corrective action plan with dates → implementation + verification → OEM approves closure; repeated non-conformances → ASPICE capability gap assessment → mandatory process improvement plan monitored quarterly by OEM quality team

Hands-On: Compliance Audit Preparation 55 min read

▸ Pre-assessment checklist: compliance matrix fully populated (no "Unknown" status), all evidence links tested (no 404 errors), assessor-requested documents in evidence package folder, process owners briefed on their ASPICE practice ownership, independence declarations signed, traceability demonstrations prepared

▸ Traceability walkthrough practice: simulate auditor request "Show traceability from SWR-042 to test result" - navigate DOORS XT link module: SWR-042 → SW Architecture element → SW Unit → TESSY test case → TESSY test report; demonstrate completeness both ways (no orphan test cases, no untested requirements)

▸ Common audit findings: incomplete traceability (test case exists but not linked to requirement), informal review records ("reviewed and approved" stamp insufficient - need issue list + resolution dates), tool qualification not covering actual version used, safety assumption not verified at integration level, co-author reviewed own work (independence violation)

▸ Post-audit improvement cycle: findings categorised Major (blocks compliance claim) or Minor (requires corrective action plan); create action per finding: Root Cause, Planned Action, Owner, Target Date; Major findings require 30-day follow-up assessment; update compliance matrix, evidence links, and ASPICE assessment plan after each completed corrective action

Tools Used

DOORS Polarion codeBeamer Enterprise Architect Compliance Tracking Tools Audit Management Systems

What You'll Learn

Map the complete automotive standards landscape

Create integrated compliance strategies across standards

Plan ISO 26262 and ISO/SAE 21434 co-engineering

Prepare for ASPICE assessments and regulatory audits

Manage compliance evidence and documentation

Evaluate and qualify development tools per standards

Prerequisites

General automotive development understanding

Awareness of software development processes

No specific technical prerequisites

Standards & Compliance

Overview

Course Modules

Tools Used

What You'll Learn

Prerequisites

This course includes: