Blog

자동차 SW용 ASPICE L2: 12개월 로드맵

info@hermessol.com (Hermes Solution) — Fri, 11 Jul 2025 02:28:33 GMT

For automotive software development organizations, ASPICE Level 2 certification is no longer optional; it's a critical capability global OEMs demand. Does ASPICE Level 2 seem daunting? This comprehensive guide from the Hermes Solution blog will walk you through everything, from the importance of ASPICE Level 2 and a practical achievement roadmap to common pitfalls and effective resolution strategies, helping you achieve it and boost your business value.

1. Why is ASPICE Level 2 Crucial, and What Value Does it Offer?

The automotive industry is rapidly accelerating its software-defined innovation. Consequently, global OEMs (Original Equipment Manufacturers) now require ASPICE Level 2 certification as a fundamental qualification from their suppliers. Notably, major European OEMs are increasingly specifying ASPICE CL2 or higher in their Statements of Work (SOW) and Requests for Information (RFI) when selecting component suppliers.

Why is ASPICE Level 2 Essential?

Level 2 goes beyond merely performing processes; it signifies an organization's ability to systematically manage and control them. This demonstrates that your organization possesses the following core capabilities:

Predictable Project Management: Accurately forecast project timelines and ensure on-schedule progress.
Complete Traceability: Maintain seamless, traceable connections from requirements to testing across all development stages.
Early Quality Issue Detection & Resolution: Identify and systematically resolve defects in the early stages of development.

What's the Decisive Difference Between Level 1 and Level 2?

Tangible Business Benefits of Achieving ASPICE Level 2

Level 2 certification is more than just a title; it brings significant benefits to your organization:

Enhanced Customer Trust & Expanded Business Opportunities:
- Objectively demonstrating development capabilities provides a strong differentiator in bidding.
- Gaining the trust of OEMs and Tier 1 suppliers opens doors to new business opportunities.
Significant Reduction in Rework & Quality Costs:
- Systematic processes increase the probability of defect detection in the early development stages.
- Correcting defects in the requirements/design phase is tens of times cheaper than in the integration testing phase, leading to massive savings in rework and quality costs.
Improved Project Predictability:
- Complete projects within predictable schedules and budgets.
- Engineers can focus more on technical innovation, freed from uncertainty.

2. In-Depth Explanation of Level 2 Requirements for Key Processes

To achieve ASPICE Level 2, you must satisfy two 'Process Attributes (PA)' across all processes.

Understanding Process Attributes (PA)

PA 2.1 - Process Performance Management: Define process performance objectives, monitor actual performance, and adjust for deviations.
PA 2.2 - Work Product Management: Clearly define work products, manage versions, and control them through review and approval procedures.

⭐ MAN.3 Project Management: The Core Command Center for CL2

MAN.3 is the most critical process, coordinating and leading all others.

Key Activities: Define work scope and lifecycle, evaluate project feasibility, define/estimate/monitor activities based on WBS, manage interfaces and schedules, ensure consistency among planning documents, review and report progress.
Practical Tip: Milestones in the project plan and baselines in the configuration management plan must align.

⚙️ In-Depth Analysis of Software Engineering V-Model (SWE.1 ~ SWE.6)

The true value of the V-Model lies in its horizontal traceability, connecting the left side (definition/design) with the right side (verification/testing).

SWE.1 Software Requirements Analysis: Transform system requirements into concrete, verifiable SW requirements and manage them.
SWE.2 Software Architectural Design: Define major components, design interfaces, allocate requirements, record design decisions, and manage configuration.
SWE.3 Software Detailed Design and Unit Implementation: Design internal algorithms/data structures for components, adhere to coding standards, and manage code review records.
SWE.4 Software Unit Verification: Establish unit verification strategies, perform static/dynamic testing and code coverage measurement, and manage test specifications/results configuration.
SWE.5 Software Integration and Integration Test: Establish integration strategies, verify interfaces/interactions, and track discovered defects with SUP.9.
SWE.6 Software Verification Test: Final verification of all requirement satisfaction, with a focus on requirements-test case traceability, performed in the actual target environment.

Support Processes (SUP): The Strong Pillars of a Managed Project

SUP.1 Quality Assurance: Independent verification of process adherence, regular audits, and tracking non-conformities.
SUP.8 Configuration Management: Maintain the integrity of all critical work products, utilize version control systems, establish baselines, and track status.
SUP.9 Problem Resolution Management: Systematically track all problems (using Jira, Redmine, etc.) and manage their status.
SUP.10 Change Request Management: Formally record all change requests, perform impact analysis, obtain CCB approval, and track through verification of change results.

3. Your 12-Month Roadmap to ASPICE Level 2 Achievement

Critical Prerequisite: Existing Product vs. New Development Project

This 12-month ASPICE Level 2 roadmap is designed for new projects or projects undergoing significant improvement. Attempting to certify an already completed product is challenging due to ASPICE's 'plan → execute → record' sequence and traceability requirements. Objective evidence, such as meeting minutes, review records, and approval documents, is often lacking from past projects.

✨ Realistic Alternatives:

Hybrid Approach: Define the next version development of an existing product as a new project and apply ASPICE processes.
Pilot Strategy: Apply ASPICE processes to specific module refactoring or new feature development.
Honest Acknowledgment: Apply Level 1 to existing projects and target Level 2 for new projects (this scenario typically takes 18-24 months).

Now, let's outline the 12-month roadmap for a new project applying ASPICE from the outset.

4. Learning from Failure: How to Avoid Common Pitfalls

We share insights from common ASPICE certification pitfalls to help you achieve success.

❌ 1. The "Mere Facade Document" Trap: Formal Documentation

Symptoms: Voluminous documents detached from actual work, content inconsistencies, developers unaware of document locations.
Solution: Continuous Update Document Approach:
- Manage information primarily through ALM tools (documents are extractions).
- Consider code comments and commit messages as part of documentation.
- Automate anything that can be auto-generated.
- Aim for concise documents containing only core information.

❌ 2. The "Panacea" Trap: Blind Tool Reliance

Symptoms: Misconception that "expensive tools = ASPICE achievement," only using 10% of tool features, eventually resorting to parallel Excel management.
Solution: Gradual Tool Adoption:
- Establish processes with simple tools, then expand functionality as needed.
- Process understanding is paramount over tools.
- Assign a dedicated Tool Administrator.

❌ 3. The "Resistance to Change" Trap: Cultural Inertia

Symptoms: Lack of cooperation ("It's working fine now, why change?"), adherence to old methods, perfunctory participation.
Solution: Combined Top-Down and Bottom-Up Approach:
- Processes built by practitioners (fostering ownership).
- Consistent management attention and support.
- Promote early success stories to demonstrate process value.
- Emphasize the tangible benefits derived from processes.

5. Practical Tips for Level 2 Assessment Preparation

This is the final check before a successful ASPICE assessment.

Evidence Preparation: Quality Over Quantity!

Auditors primarily look for consistency, traceability, objective evidence, and temporal accuracy.

Create an Evidence Map: Map evidence documents to each process practice, specifying document names, page numbers, ALM links, etc., to facilitate the auditor's work.

️ Interview Response Strategy

Familiarize yourself with common critical questions and how to respond during the audit.

Example Questions: "When was this requirements review meeting held?", "Show me the impact analysis results for change request CR-001," "Which detailed design does unit test case TC_234 verify?"
Response: Systematically prepare evidence like meeting minutes, impact analysis documents, and traceability matrices. Maintain a logical order in your documents.

⭐ Interview Golden Rule:

Listen carefully to the question, re-ask if you don't understand, and answer concisely only what was asked. Avoid absolute terms like "always" or "never." If you don't know, state you'll "check and respond."

✅ Final Checklist 2 Weeks Before Assessment

Document Preparation: Finalize all work products to the latest version and baseline, complete and check links in the evidence map, perform a final consistency review.
Team Preparation: Confirm interviewees and conduct mock interviews, assign roles.
Environment Preparation: Prepare audit room and equipment, network access, finalize agenda.

Towards True Process Maturity with Hermes Solution!

Achieving ASPICE Level 2 is not just about gaining a certification; it's a strategic journey to mature your organization's development culture. The key to success lies in the harmonious blend of three elements:

Process: A traceable and consistent, organically managed system.
People: An organizational culture that understands the value of processes and participates voluntarily.
Tools: Automated systems that efficiently support processes.

Set Realistic Expectations:

The 12-month roadmap is a realistic timeline for applying ASPICE to new projects from the ground up. For existing products, the limitations of reverse-engineering documentation require a longer-term perspective of 18-24 months. Prioritize "proper achievement" over "short-term gains" to avoid generating merely formal documentation driven by unrealistic immediate goals.

Key Success Factors:

Strong Management Support: Real resource allocation, not just lip service.
Dedicated Organization: A TF team focused on process improvement.
Phased Approach: Verification through pilots before company-wide expansion.
Continuous Improvement: Consistent improvement is more crucial than a perfect start.
Change Management: Building consensus among members and encouraging voluntary participation.

The essence of ASPICE is about "better development processes," not a "pile of documents." Hermes Solution helps your organization develop systematic development capabilities and a mature organizational culture through this process, leading to sustainable growth in the future automotive software market.

You don't need to be perfect from the start. What matters is to start, improve, and persevere. In 12 months, your organization won't just hold an ASPICE CL2 certificate; it will truly become a mature organization with 'managed' development processes. With Hermes Solution, your ASPICE journey will be the cornerstone of a successful business.

스마트 팩토리 기능 안전 가이드: 진정한 스마트 팩토리는 안전한 공장입니다 - IEC 61508 구현

info@hermessol.com (Hermes Solution) — Fri, 04 Jul 2025 07:40:11 GMT

A Truly Smart Factory is a Safe Factory

Hello engineers! Hermes Solution brings you this week's comprehensive guide on implementing functional safety based on the IEC 61508 standard. As smart factories buzz with advanced robotic arms and conveyor belts, productivity has improved remarkably. However, haven't you ever wondered: "As automation equipment increases, doesn't the risk of safety accidents also grow?"

The transition to smart factories has accelerated dramatically, leading to unprecedented improvements in productivity. However, increasingly complex automation systems are creating new forms of safety risks. In modern manufacturing environments where robotic arms work tirelessly and autonomous guided vehicles navigate factory floors, the question "Are all these automated systems operating safely?" has become more critical than ever.

IEC 61508 is an international standard for functional safety of electrical/electronic/programmable electronic (E/E/PE) systems. Rather than simply adding safety devices, it presents a systematic safety management approach throughout the entire safety lifecycle. This guide will comprehensively cover the core concepts of IEC 61508 and practical implementation methods.

What is Functional Safety?

Functional Safety refers to the ability of a control system to detect hazardous situations and transition to or maintain a safe state. IEC 61508 defines this as "the part of the overall safety of the EUC (Equipment Under Control) and EUC control system that depends on E/E/PE safety-related systems."

Why is Functional Safety Important?

Traditional manufacturing facilities primarily relied on physical protection devices (safety fences, protective covers, etc.). However, smart factory environments introduce new risk factors:

Software Defects: Errors in complex control logic or unexpected situations
System Interactions: Previously safe independent systems becoming hazardous when integrated
Cybersecurity Threats: External intrusions compromising safety systems
Sensor and Communication Failures: Malfunctions due to incorrect information

These risks are invisible but can cause catastrophic consequences, making systematic functional safety approaches essential.

️ IEC 61508-Based Functional Safety Implementation Strategy

IEC 61508 defines functional safety not as an element added at the end of development, but as an essential component that must be systematically managed throughout the Overall Safety Lifecycle. This integrated approach considers and manages safety at every stage from system concept to decommissioning.

What is Functional Safety?

Why is Functional Safety Important?

Traditional manufacturing facilities primarily relied on physical protection devices (safety fences, protective covers, etc.). However, smart factory environments introduce new risk factors:

Software Defects: Errors in complex control logic or unexpected situations
System Interactions: Previously safe independent systems becoming hazardous when integrated
Cybersecurity Threats: External intrusions compromising safety systems
Sensor and Communication Failures: Malfunctions due to incorrect information

These risks are invisible but can cause catastrophic consequences, making systematic functional safety approaches essential.

️ IEC 61508-Based Functional Safety Implementation Strategy

Expert Personnel Acquisition

Successful IEC 61508 standard implementation requires Functional Safety Engineers (FSE) as key personnel. They must possess not only technical requirements knowledge but also practical application experience, with certified consultant support when necessary.

Cost Optimization Strategy

Risk-based approaches should allocate appropriate SIL to each hazard. Excessive safety levels generate unnecessary costs, making it important to derive the most economical solutions within acceptable risk levels.

Industry-Specific Standard Application

IEC 61508 provides a comprehensive framework standard. Machinery should apply sector-specific standards like ISO 13849 or IEC 62061, while process industries should use IEC 61511 to clarify practical implementation.

Systematic Documentation Management

All activities and decisions throughout the entire safety lifecycle must be documented for traceability. This is essential for certification acquisition, regular audit responses, impact analysis during system changes, and responsibility determination in case of accidents.

⚙️ Machinery Safety Standards Framework

IEC 62061 - Safety of Machinery: Safety-related electrical, electronic and programmable electronic control systems

Sector standard derived from IEC 61508 for machinery
Uses Safety Integrity Level (SIL) concept
Provides requirements specific to electrical/electronic control systems

ISO 13849 - Safety of Machinery: Safety-related parts of control systems

Covers all technologies (electrical, hydraulic, pneumatic, mechanical)
Uses Performance Level (PL) concept
Combines category structure with probabilistic approach

Standard Selection Guide

Electrical/Electronic Control-Centered Systems

IEC 62061 application suitable
Complex programmable logic performs major safety functions
SIL-based quantitative reliability calculation feasible

Multi-Technology Systems

ISO 13849 application recommended
Hydraulic, pneumatic, mechanical elements involved in safety functions
Integrated evaluation of diverse technologies possible

Highly Complex Systems

Consider direct IEC 61508 application
Complexity difficult to handle with machinery standards
New technologies or specialized applications

Practical Implementation Considerations

Standards can be used complementarily, with the most suitable standard as the main framework while referencing other standards' concepts as needed. The key is consistently applying the chosen standard and meeting all its requirements.

✅ Conclusion: Functional Safety as Investment for Smart Factory Sustainability

IEC 61508-based machinery functional safety implementation goes beyond regulatory compliance to become essential investment for smart factory sustainable growth. While pursuing production efficiency and innovation, it represents the most fundamental commitment to protecting worker lives and corporate assets.

Key Success Factors:

Technical Excellence:

Systematic hazard analysis and SIL determination
Objective decision-making through quantitative risk assessment
Independent, reliable safety system design following IEC 61508 principles
Robust architecture ensuring safety even during failures

Lifecycle Management:

Comprehensive functional safety management from development to operation
Continuous safety performance maintenance and improvement

Organizational Infrastructure:

Expert personnel acquisition, cost efficiency, related standard integration, thorough documentation
Essential infrastructure for successful implementation

These elements have become core competencies that all smart factories and industrial automation companies must possess. Through the compass of functional safety, we can build safe and productive future smart factories.

A factory without accidents is truly a smart factory. Join Hermes Solution in creating a smart and safe future through IEC 61508-based functional safety!

5단계 자동차 사이버 보안 전략: ISO/SAE 21434

info@hermessol.com (Hermes Solution) — Mon, 23 Jun 2025 06:31:46 GMT

Cars Are No Longer Just Transportation Vehicles

Modern vehicles have evolved far beyond simple transportation devices. Today's automobiles, equipped with over 100 Electronic Control Units (ECUs), have become "computers on wheels" that form complex networks through various internal communication protocols including CAN, CAN-FD, FlexRay, and Ethernet.

While this connectivity provides unprecedented convenience and safety features, it also exposes vehicles to cybersecurity threats. The scenario where hackers remotely control a vehicle's steering or braking systems—once confined to movies—has become a real possibility.

Recent Automotive Cyber Attacks

Several high-profile incidents have demonstrated the reality of automotive cybersecurity threats:

2015 Chrysler Jeep Hacking Incident: Researchers remotely controlled a Jeep Cherokee through its infotainment system
2016 Tesla Model S Remote Control Case: Security researchers demonstrated remote access to critical vehicle functions
Ongoing Threats: Continuous reports of attackers penetrating internal networks through infotainment systems to compromise core vehicle functions

These incidents highlight that automotive cybersecurity is no longer optional—it's essential.

Why In-Vehicle Network Security Matters

The Vehicle as a Neural Network

A vehicle's internal network functions like the human nervous system, connecting ECUs that perform different functions—powertrain, chassis, Advanced Driver Assistance Systems (ADAS), and infotainment—enabling seamless data exchange.

Security Limitations of Legacy Network Protocols

Traditional communication protocols like CAN (Controller Area Network), designed in the 1980s, assumed closed network environments and didn't account for external threats. These protocols have inherent vulnerabilities:

Key Security Gaps:

No Message Encryption: All communications transmitted in plain text
Lack of Authentication: Cannot verify message sender legitimacy
Broadcast Characteristics: All nodes can receive all network messages
Priority-Based Arbitration: Malicious high-priority messages can disrupt normal communication

Real Attack Scenarios

An attacker who infiltrates the internal network through a vulnerable infotainment system could:

Access Diagnostic Ports (OBD-II): Physical network entry
Bypass Gateways: Exploit network separation device vulnerabilities
Manipulate CAN Messages: Forge and transmit powertrain control messages
Hijack Vehicle Control: Abnormal control of acceleration, braking, and steering systems

Such successful attacks could cause vehicles to accelerate uncontrollably or lose braking capability, creating life-threatening situations.

Defense-in-Depth Strategy is essential—not only providing primary defense against external attacks but also preventing spread to core networks even if some systems are compromised.

ISO/SAE 21434 Overview

ISO/SAE 21434 has established itself as the core global standard for automotive cybersecurity. Rather than simply listing specific technologies, this standard provides a process framework for systematically managing and implementing cybersecurity throughout a vehicle's entire lifecycle: planning, development, production, operation, and decommissioning.

The standard defines security as a "Security-by-Design" essential requirement that must be considered from the design stage, not as a feature added during final development phases.

5-Step Security Enhancement Strategy

Step 1: Threat Analysis and Risk Assessment (TARA)

All security begins with "knowing your enemy." TARA systematically identifies potential threats in vehicle internal networks and analyzes their impact to determine risk levels.

Key Activities:

Asset Identification:

Hardware Assets: Steering control ECUs, brake systems, engine management systems
Software Assets: Firmware, bootloaders, diagnostic software
Data Assets: CAN messages, vehicle diagnostic data, personal information
Communication Assets: Network protocols, gateways, communication pathways

Threat Scenario Development:

"Inject malicious firmware through diagnostic port (OBD-II) to bypass gateway and send malicious messages to powertrain CAN network"
"Exploit wireless key system vulnerabilities to gain remote vehicle access, then probe internal networks and disable critical systems"

Risk Assessment Matrix:

Step 2: Security Objectives and Requirements Definition

Based on TARA results, establish Cybersecurity Goals to address high-risk threats, converting abstract risks into concrete technical objectives.

Security Objective Examples:

Risk Scenario: Manipulated messages from infotainment ECU cause brake system malfunction

Derived Security Goals:

"Block unauthorized communication between infotainment and powertrain networks"
"Ensure all powertrain network messages maintain integrity and authenticity"
"Detect and respond to abnormal network activity in real-time"

Detailed Requirements:

Functional: Gateway must allow only authorized message IDs for inter-domain transmission
Performance: Message authentication delays must be under 1ms
System Impact: Security functions must not affect overall system performance by more than 5%

Step 3: Security Architecture Design and Control Implementation

Network Segmentation

Central Gateway-Based Domain Separation:

Control and filter communication between domains (infotainment, powertrain, chassis, ADAS) through central gateway
Implementation Considerations:
- Hardware Security Module (HSM) based gateway implementation
- Whitelist-based message filtering per domain
- Dedicated hardware acceleration for real-time performance

Message Authentication

SecOC (Secure On-board Communication) Implementation:

AUTOSAR-defined standard adding Message Authentication Code (MAC) to CAN/CAN-FD messages
Process:
- Sender generates HMAC using original message and secret key
- Receiver extracts and verifies MAC from received message
- Process only if validation successful

Performance Optimization:

Hardware encryption engine utilization for minimal latency
Selective SecOC application to safety-related messages only
Efficient key management system establishment

Intrusion Detection and Prevention System (IDPS)

Real-time Network Monitoring:

Detection Techniques:

Signature-based Detection: Compare against known attack pattern database
Anomaly Detection: Learn normal traffic patterns and detect unusual activity
Protocol Analysis: Detect violations in vehicle-specific protocols (CAN, FlexRay)

Response Mechanisms:

Alert Generation: Notify driver and control center of anomalies
Traffic Blocking: Immediate blocking of malicious messages
Network Isolation: Temporary network separation of compromised ECUs

Secure Boot and Access Control

Trust Chain Establishment:

Secure Boot: Digital signature verification of bootloader and OS
Remote Attestation: Remote verification of ECU integrity status
Runtime Protection: Memory protection and control flow integrity during execution

Access Control Framework:

Role-Based Access Control (RBAC): Apply principle of least privilege by function
Multi-factor Authentication: Require multiple authentication methods for critical functions
Session Management: Time limits and automatic termination for diagnostic sessions

Step 4: Verification and Validation

Fuzz Testing

Network-Level Fuzzing:

CAN Fuzzing: Test with abnormal CAN IDs, data lengths, transmission cycles
Protocol Fuzzing: Boundary value testing of vehicle standards (AUTOSAR, UDS)
State-based Fuzzing: Input manipulation testing across various ECU operational states

Automated test environments

Penetration Testing

Systematic Penetration Testing:

Physical Access Scenarios:

OBD-II port diagnostic tool connection
ECU firmware dumping and reverse engineering
Hardware debugging interface exploitation

Remote Access Scenarios:

Wireless communication vulnerabilities (WiFi, Bluetooth, Cellular)
Internal network penetration through infotainment systems
Cloud service integration security weaknesses

Security Code Review

Static/Dynamic Analysis Tools:

SAST (Static Application Security Testing): Source code security vulnerability analysis
DAST (Dynamic Application Security Testing): Runtime environment vulnerability detection
IAST (Interactive Application Security Testing): Combined static/dynamic analysis

Step 5: Continuous Monitoring and Incident Response

Vehicle Security Operation Center (VSOC)

Integrated Control System:

Real-time Monitoring: Unified surveillance of global vehicle fleet security status
Threat Intelligence: Collection and analysis of new attack techniques and vulnerabilities
Automated Response: Automated response measures based on risk levels

Over-the-Air (OTA) Updates

Security Patch Distribution System:

Patch Integrity: Digital signature verification of patch files
Rollback Capability: Recovery to previous version if update fails
Differential Updates: Transmit only changed portions to minimize communication costs
User Consent: Driver approval process for critical updates

Incident Response Process

Staged Response Framework:

Detection: Recognize security incident occurrence
Analysis: Determine incident cause and impact scope
Containment: Prevent damage spread
Eradication: Complete removal of attack source
Recovery: Restore normal service
Lessons Learned: Establish recurrence prevention measures

Real-World Implementation Considerations

Performance vs Security Balance

Vehicles are real-time systems where security functions must not impact safety functions:

Latency Constraints: Guarantee safety-related message delivery within specified timeframes
Resource Usage: Minimize CPU and memory impact on existing functions
Power Consumption: Optimize additional power consumption from security features

Cost Efficiency

Risk-Based Priority: Apply to high-risk systems first
Proven Standards: Prioritize validated standard technologies like AUTOSAR SecOC
Supply Chain: Establish security responsibility sharing with component suppliers

Regulatory Compliance

International Regulations: Reflect UN-R155, UN-R156 requirements
Security Certifications: Obtain Common Criteria, FIPS 140-2 certifications
Documentation Management: Systematic documentation for audits and certifications

Future of Automotive Cybersecurity

Emerging Technologies

AI-Powered Threat Detection: Machine learning algorithms for advanced threat identification
Blockchain for Supply Chain Security: Immutable records for component authenticity
Quantum-Resistant Cryptography: Preparation for post-quantum security threats

Industry Collaboration

Information Sharing: Collaborative threat intelligence sharing among manufacturers
Standard Evolution: Continuous updates to ISO/SAE 21434 and related standards
Cross-Industry Learning: Adopting best practices from other critical infrastructure sectors

Conclusion: Security Investment for Trust

Enhancing in-vehicle network security through ISO/SAE 21434 goes beyond regulatory compliance—it's a fundamental commitment to protecting driver lives and safety in the future mobility era.

Key Success Factors:

✅ Systematic TARA Implementation: Risk-based security design through comprehensive threat analysis
✅ Robust Security Architecture: Application of strong security frameworks and proven technologies
✅ Lifecycle Security Management: Continuous security management throughout vehicle lifecycle
✅ Balanced Approach: Harmonizing performance, cost, and regulatory requirements

These elements have become core competencies that all automotive manufacturers and component suppliers must possess. Through the ISO/SAE 21434 compass, we can open a safe and trustworthy connected car era.

Our ultimate goal extends beyond simply preventing cyber attacks—we must build a smart mobility ecosystem where drivers and passengers can use vehicles with complete confidence and peace of mind.

주니어 임베디드 엔지니어를 위한 로드맵: ISO 26262 ASPICE

info@hermessol.com (Hermes Solution) — Fri, 13 Jun 2025 02:04:40 GMT

Hello Hermes Solution blog visitors! This week, we've prepared a special topic for engineers taking their first steps into the automotive embedded systems field. The automotive industry is rapidly evolving, and in embedded systems, Functional Safety and Process Quality are more crucial than ever. For a new embedded engineer, these concepts might seem complex and challenging. However, with a structured roadmap, you can master them. This article, focusing on ASPICE and ISO 26262, outlines the learning journey necessary for new embedded engineers to kickstart a successful career.

Step 1: Building Foundational Knowledge – Understanding the "Why" First!

In any field, understanding the 'why' is paramount. In the automotive sector, functional safety and process quality go beyond mere regulatory compliance; they are critical for protecting lives and safeguarding a company's reputation. Understanding the associated risks and recognizing the benefits of compliance is the starting point for your learning. Since ASPICE and ISO 26262 are complex and filled with specialized terminology, establishing a solid conceptual foundation is essential.

Recommended Online Resources/Courses:

YouTube Channels: Explore various free videos on ISO 26262 and ASPICE standards, testing capabilities, and functional safety. These are highly useful for beginners.
Focus on Key Concepts & Terminology: Prioritize clearly understanding the definitions of ASPICE, ISO 26262, V-model, Capability Levels, ASIL, HARA, and more. A strong grasp of these terms will enable you to effectively absorb detailed content.

Step 2: In-Depth Process and Practical Learning – Applying Theory to Practice

Once you've built your foundation, it's time to delve deeper into the ASPICE process areas and ISO 26262 lifecycle phases. This is crucial for understanding the core of automotive embedded system development.

Learn Specific ASPICE Process Areas: Focus on the SYS (System Engineering) and SWE (Software Engineering) process groups. These are central to embedded development, and understanding the fundamental practices of each process is important.
Study ISO 26262 Lifecycle Phases: Dive deep into the Concept Phase (HARA, ASIL determination, FSC functional safety concept), System Level Development, Hardware Development, and Software Development. It's vital to grasp what activities occur in each phase.
Importance of Documentation & Traceability: Both standards emphasize thorough documentation and end-to-end traceability from requirements to testing. These are essential capabilities for demonstrating compliance and managing changes.
Introduction to Common Tools: Become familiar with various types of tools used in the industry. Understanding how these tools implement theoretical concepts into actual development workflows is key.
- ALM (Application Lifecycle Management) Tools: Used for requirements management, traceability, and change management (e.g., DOORS, IBM ELM, Vector PREEvision, Polarion, Jama, Codebeamer, Visure Requirements ALM Platform).
- Static Analysis Tools: Used for code quality, adherence to coding guidelines (e.g., MISRA C), and error detection (e.g., Polyspace, Axivion).
- Model-Based Development (MBD) Tools: Used for system design and verification, and code generation (e.g., MATLAB/Simulink, System Composer, Embedded Coder).
- Testing and Validation Tools: Used for unit, integration, and system testing, and automated testing (e.g., Simulink Test, NI tools).

Step 3: Real-World Application & Certification – Proving Your Expertise and Expanding Your Career

This stage involves applying theoretical knowledge to real-world scenarios and proving your expertise through certification. Practical experience and certifications will enhance your value in the automotive functional safety domain.

Gain Practical Experience:
- Personal Projects: Apply the principles you've learned to personal embedded projects, focusing on structured development, requirements, and basic safety considerations.
- Internships/Entry-Level Positions: Look for opportunities at automotive companies that actively implement or comply with ASPICE and ISO 26262. Even if it's not a functional safety role, exposure to these processes is invaluable.
- Safety Analysis Tool Experience: Gain experience with tools like HARA (Hazard Analysis and Risk Assessment), FMEA (Failure Mode and Effects Analysis), FTA (Fault Tree Analysis), and FMEDA (Failure Mode, Effects, and Diagnostic Analysis).
Obtain Certifications:
- ISO 26262 Functional Safety Engineer (Level 1): Offered by certification bodies like TÜV SÜD. It covers an overview of functional safety, safety management, HARA, ASIL, and the safety lifecycle, concluding with an exam. No prior experience is required for Level 1.
- ASPICE Provisional Assessor: Recommended to pursue after gaining practical experience.

These steps are crucial for validating theoretical knowledge with practical understanding and staying up-to-date in a rapidly evolving field.

Core Competencies & Career Impact – Your Expertise Drives the Future

An automotive functional safety/process engineer isn't just about technical knowledge. You need to possess the following core competencies:

Technical Expertise: Proficiency in system engineering principles, embedded system development, knowledge of hardware/software/network systems, programming languages (C/C++), modeling tools (Simulink, UML), and coding guidelines (MISRA C).
Risk Assessment Capability: Ability to identify potential risks, analyze hazards, and prioritize mitigation strategies. Experience with HARA, FMEA, FTA, FMEDA.
Safety Standards & Regulations Knowledge: Deep understanding and application ability of ISO 26262, ASPICE, and related standards like IEC 61508, ISO 21434 (Cybersecurity), and ISO 21448 (SOTIF).
Analytical & Problem-Solving Skills: Ability to analyze complex systems, identify safety risks, and effectively implement solutions.
Communication & Collaboration: Ability to clearly convey complex technical information, lead cross-functional teams, and collaborate with OEMs and suppliers.
Documentation & Traceability: Meticulous attention to process documentation and ensuring traceability of requirements and work products.
Continuous Improvement Mindset: Willingness to improve safety processes and tools, and stay updated on standards and new technologies.

These competencies illustrate that functional safety engineering acts as a vital bridge between technical implementation, regulatory compliance, and organizational processes, going beyond simply writing code or analyzing circuits.

Career Opportunities & Growth in Automotive Embedded Systems

The rise of electric vehicles and autonomous driving has dramatically increased the demand for functional safety engineers. Roles include SQA Engineer – Embedded Systems, Functional Safety Engineer, Staff Engineer, System Engineer, and more. These roles are often in high demand due to a limited pool of qualified candidates, offering long-term job security. Career paths can progress from entry-level to mid-level, senior, and expert roles.

The high demand and specialized nature of functional safety roles suggest that investing in ASPICE and ISO 26262 knowledge provides a significant competitive advantage in the embedded automotive job market. This specialization offers a more stable and potentially more lucrative career path compared to more general software engineering roles.

The Value of Standards for Professional Development

Adhering to ASPICE and ISO 26262 enhances a company's reputation and prevents costly recalls and legal claims. It improves internal processes, making development more predictable and efficient, leading to better products and faster time-to-market. It also fosters a culture of continuous improvement and innovation within the organization.

Mastering these standards not only benefits an individual's career but also contributes to raising the quality and safety standards of the broader industry. This means an engineer's personal development directly contributes to the evolution of the automotive industry itself, making their expertise impactful on a larger scale. By ensuring quality, mitigating risks, and fostering continuous improvement, these standards elevate the entire automotive product development lifecycle. This implies that engineers proficient in these areas are not just fulfilling job duties but actively contributing to the safety and advancement of future mobility, making their expertise highly valuable and influential.

Your Path to Becoming an Automotive Embedded Systems Expert

In the modern automotive embedded systems field, ASPICE and ISO 26262 are indispensable standards. They address process quality and functional safety, demanding an integrated understanding and application. For new embedded engineers, following a structured learning roadmap is the surest path to success.

The automotive industry is dynamically changing with continuous advancements in areas like autonomous vehicles, AI/ML integration, and cybersecurity. The inclusion of hardware and ML engineering in ASPICE 4.0, the expansion of ISO 26262:2018, and the emergence of new standards like ISO/PAS 8800 for AI/ML safety demonstrate that these standards are constantly evolving. Therefore, for professionals in this field, lifelong learning and active participation in professional communities are essential to remain relevant and excel. Your expertise will directly contribute to the safety and advancement of future mobility.

Are you ready to start a successful career in automotive embedded systems? Through continuous learning and experience, become an expert who leads the future of mobility! Hermes Solution is ready to support your learning journey and build a successful career with you. Join Hermes Solution now!

IEC 62443 및 ISO/SAE 21434: 산업 및 자동차 사이버 보안 표준에 대한 심층 분석

info@hermessol.com (Hermes Solution) — Thu, 05 Jun 2025 08:10:17 GMT

Hello everyone, and welcome to the Hermes Solution blog, your go-to source for in-depth analysis on cybersecurity, a critical survival strategy in the digital age!

As cyber threats become increasingly sophisticated, the core sectors that sustain our lives and industries are at risk. Industrial Automation (Industry 4.0, IIoT) and Automotive (Connected Cars, Autonomous Driving), in particular, are experiencing an explosion in connectivity, making cybersecurity not just an option, but a necessity. Past incidents, like the Stuxnet attack on industrial systems or remote car hacking incidents, vividly demonstrate the devastating impact of cyber threats in the real world.

To counter these threats, international standardization organizations are proposing cybersecurity frameworks tailored to specific sectors. Today, we'll dive deep into IEC 62443, the stalwart shield for the industrial sector, and ISO/SAE 21434, the guiding compass for the automotive industry. If you're wondering which standard is more suitable for your business, or how these two standards can create synergy, this article will serve as a clear guide.

1. Why Are Sector-Specific Cybersecurity Standards Necessary?

The acceleration of digital transformation, coupled with increasing regulatory pressure and market demands, is strongly driving the adoption of specialized cybersecurity standards for specific industries.

Automotive Sector: International regulations like UN R155 mandate compliance with ISO/SAE 21434 as a prerequisite for vehicle type approval, making it an essential gateway for automotive manufacturers and component suppliers to enter the market.
Industrial Sector: Regulations such as the North American Electric Reliability Corporation's (NERC) Critical Infrastructure Protection (CIP) standards encourage adherence to industrial best practices like IEC 62443 for protecting critical infrastructure.

This signifies that complying with these standards is no longer just about "following best practices"; it has evolved into a mandatory requirement for market entry and legitimate operation.

As Information Technology (IT) and Operational Technology (OT) converge, IEC 62443, a cornerstone for OT security, and ISO/SAE 21434, which addresses the specific OT domain of automotive, share fundamental security principles like risk management and lifecycle approaches. However, they also exhibit clear differences due to their distinct operating environments, safety-related impacts, and unique threat landscapes. Therefore, understanding the precise standard relevant to your business is paramount.

2. IEC 62443: A Robust Shield for Industrial Automation and Control Systems (IACS)

Core Mission: IEC 62443 focuses on protecting Industrial Automation and Control Systems (IACS) and Operational Technology (OT) within critical infrastructures such as energy, transportation, manufacturing, healthcare, and public utilities from cyber threats. Beyond mere data confidentiality, its top priority is the availability, integrity, and resilience of industrial processes. This is crucial because security breaches can lead to massive financial losses, environmental damage, and even human casualties.

Structural Framework (6 Categories): As of 2024, IEC 62443 is comprised of an expanded series of 6 categories:

General (1-x): Provides an overview, core concepts, and definitions.
Policies & Procedures (2-x): Details requirements for IACS security management systems (CSMS) and security programs for asset owners and service providers.
Systems (3-x): Includes guidelines for designing, installing, and maintaining secure systems in industrial environments, along with technical requirements for industrial control architectures.
Components (4-x): Focuses on technical requirements for individual components of industrial systems, including devices and software, as well as secure development processes.
Profiles (5-x): Defines industry-specific cybersecurity requirements and provides a structured approach for implementing measures based on the cybersecurity profiles described in IEC 62443-1-5.
Evaluation (6-x): Describes evaluation methodologies to ensure consistent and reproducible assessment results for the requirements of individual parts.

Notably, IEC 62443-2-1 (security program for asset owners), -2-4 (security program for IACS service providers), -3-2 (security risk assessment for system design), -3-3 (system security requirements and security levels), -4-1 (secure product development lifecycle requirements), and -4-2 (technical security requirements for IACS components) are highly practical for implementation.

Latest Update (2024): The IEC 62443-2-1:2024 revision includes significant technical changes such as the revision of requirement structures with SP elements, removal of ISMS redundancy, and definition of a maturity model for requirement evaluation. This acknowledges the reality of legacy IACS systems, many of which operate for over 20 years and include unsupported hardware and software, demanding a more realistic approach to security.

Lifecycle and Risk Management Philosophy: The risk management philosophy of IEC 62443 heavily emphasizes the characteristics of OT. Unlike IT security's focus on confidentiality, IEC 62443 prioritizes the availability and integrity of industrial processes. This is clearly reflected in its goals, such as "reducing the potential for cyber-physical failures" and "maintaining production during incidents."

Key Concepts:

Security Levels (SLs): Defined from SL 0 to SL 4, these levels outline security objectives and capabilities based on the sophistication of threats a system must protect against. For example, SL 1 protects against unintentional misuse, while SL 4 guards against sophisticated attacks from highly resourced adversaries.
Zones and Conduits: This methodology involves segmenting a system into logical zones and identifying communication pathways (conduits) between them, enabling a "defense-in-depth" strategy with targeted security measures.
Risk Assessment: IEC 62443-3-2 details system segmentation and SL determination, while Part 2-1 covers risk identification, assessment, and management.
Foundational Requirements (FRs): Seven core FRs, including user authentication and access control, backup and recovery, form the basis of a "secure-by-design" approach. The standard also emphasizes the balanced contribution of people, processes, and technology.

Governance and Supply Chain Dynamics: Industrial security cannot be achieved through the efforts of a single entity. IEC 62443 explicitly defines the roles and responsibilities of all participants throughout the supply chain, including asset owners, product suppliers, and service providers, encouraging close collaboration.

Zero Trust Alignment: In 2024, the ISA Global Cybersecurity Alliance (ISAGCA) published guidance on how IEC 62443 principles support Zero Trust methodologies, outlining how to apply Zero Trust in OT environments and shaping the future of OT security.

3. ISO/SAE 21434: The Standard for Road Vehicle Cybersecurity

Core Mission: ISO/SAE 21434 addresses cybersecurity for Electric/Electronic (E/E) systems in road vehicles, such as motorcycles, passenger cars, and trucks. It covers the entire vehicle lifecycle, from the concept phase through product development, production, operation, maintenance, and decommissioning, aiming to foster a common understanding and culture of cybersecurity.

Structural Framework (15 Clauses): The process-oriented ISO/SAE 21434 covers various aspects of cybersecurity engineering and management:

Organizational cybersecurity management (Clause 5): Governance, policies, culture.
Project-dependent cybersecurity management (Clause 6): Management of individual projects.
Distributed cybersecurity activities (Clause 7): Supplier management.
Continuous cybersecurity activities (Clause 8): Monitoring, vulnerability management.
Concept phase (Clause 9): Initial definition, objective setting.
Product development (Clause 10): Design, integration.
Cybersecurity verification (Clause 11)
Production (Clause 12)
Operation and maintenance (Clause 13): Incident response, updates.
End of cybersecurity support and decommissioning (Clause 14)
Threat analysis and risk assessment (TARA) method (Clause 15)

The core of this standard is the Cybersecurity Management System (CSMS), a systematic risk-based approach.

Lifecycle and Risk Management Philosophy: ISO/SAE 21434's risk management philosophy emphasizes the specific nature of the automotive sector, particularly its close link to safety. This standard supplements the functional safety standard ISO 26262, recognizing cybersecurity as a prerequisite for functional safety, as cyberattacks can directly impact the physical safety of a vehicle.

Key Risk Management Elements:

Threat Analysis and Risk Assessment (TARA): As the core of risk management (Clause 15), TARA is a systematic process that identifies assets, threats, vulnerabilities, impacts, and attack paths to determine risk values and derive cybersecurity objectives.
Continuous Activities: The standard emphasizes vulnerability analysis and management throughout the lifecycle, mandating post-production activities such as vulnerability management and incident response.
Fuzz Testing Recommendation: Clause [RQ-10-12] specifically recommends fuzz testing, emerging as an essential testing method for components with Cybersecurity Assurance Levels (CAL) 2 or higher.

Governance and Supply Chain Dynamics: ISO/SAE 21434 emphasizes robust organizational governance (Clause 5) and requires OEMs to manage cybersecurity across the entire supply chain (Clause 7). This is a core requirement directly linked to regulatory approvals like UN R155, meaning ISO/SAE 21434 compliance is mandatory for all suppliers participating in the automotive market. It explicitly clarifies responsibilities between customers and suppliers through documentation like Cybersecurity Interface Agreements (CIAs).

4. IEC 62443 vs ISO/SAE 21434: Key Differences Analysis

These two standards exhibit distinct differences in their application domains and risk management philosophies, which are crucial to understand.

Key Differences Summary:

Application Domain: Industrial vs. Automotive (reflecting directness of safety impact, lifecycle, and environmental characteristics).
Risk Assessment: IEC 62443 focuses on system segmentation using 'Security Levels' and 'Zones/Conduits' to provide more prescriptive objectives. ISO/SAE 21434 emphasizes a detailed analytical process ('TARA') to derive tailored cybersecurity objectives based on specific vehicle item risks.
Core Objectives: IEC 62443 prioritizes 'Availability/Integrity/Resilience', while ISO/SAE 21434 focuses on 'Vehicle Safety/Data Privacy/Functional Security'.

5. Choosing the Right Standard and Leveraging Synergy

✔ When IEC 62443 is Needed:

Strengthening OT system security in industrial sites, manufacturing facilities, and critical infrastructures (energy grids, water treatment plants).
Defining and procuring security requirements for IACS components, systems, and solutions.
Establishing and operating IACS cybersecurity programs (for asset owners, system integrators, product suppliers).
Managing security for industrial systems with long operational lifespans (20+ years).
Environments where operational continuity and availability are paramount.

✔ When ISO/SAE 21434 is Essential:

Developing E/E systems, components, or software for road vehicles (automotive OEMs and suppliers).
Entering markets requiring compliance with automotive cybersecurity regulations like UN R155.
Establishing a CSMS that covers the entire vehicle lifecycle.
Meeting regulatory requirements for vehicle type approval.
Managing complex, multi-tiered automotive supply chains.

Overlapping Areas and Synergies: While these standards address different sectors, they share common security principles and can create synergy.

Vehicle Manufacturing Plant Security: IEC 62443 applies to OT systems (robots, control systems) within the plant, while ISO/SAE 21434 applies to vehicle components and finished vehicles produced. Security in the production environment directly impacts vehicle security, necessitating an integrated approach.
Common SDLC (Secure Development Lifecycle) Principles: Utilizing common secure development practices such as threat modeling, secure coding, testing, and vulnerability management can enhance efficiency.
Cross-Domain Expertise: Knowledge of IEC 62443's Zone/Conduit model or SL determination can be applied to automotive architecture design, while ISO/SAE 21434's TARA methodology can be adapted for IACS risk assessment.
System of Systems Approach: When vehicles connect with external systems, such as V2X (Vehicle-to-Everything) communications or connected services, securing the boundary and interaction between the vehicle (ISO/SAE 21434) and external infrastructure (IEC 62443 or other standards) requires integrating principles from both.

6. Wise Cybersecurity Choices: A Path to Sustainable Growth

Cybersecurity isn't a one-time project; it's an ongoing journey of continuous improvement. As technology and the threat landscape constantly evolve, organizations must regularly assess and update their security posture.

Standard compliance is trust. In complex supply chains and in relationships with end-users/customers, adherence to standards is a key factor in building trust and gaining a competitive edge. Especially when linked to international regulations, standard certifications inform the market that a product complies, provides confidence to users, demonstrates a commitment to cybersecurity, and enhances trust among stakeholders.

Ultimately, standards provide a framework, but their effectiveness depends on skilled personnel, a robust security culture, and sustained management commitment. This is why IEC 62443 emphasizes the "balanced contribution of people, processes, and technology," and ISO/SAE 21434 highlights "cybersecurity culture" and "top management commitment."

In an increasingly interconnected and complex environment, ensuring organizational resilience, safety, and reliability through cybersecurity is a strategic imperative. We hope this article has helped you find the most suitable cybersecurity compass for your business and guided you towards a secure future!

Hermes Solution offers expert consulting and solutions for compliance with industrial and automotive cybersecurity standards. Partner with Hermes Solution to build a secure and trustworthy future in the complex cybersecurity landscape!

ISO 26262 기능 안전: ASIL 레벨별 소프트웨어 아키텍처 설계 가이드

info@hermessol.com (Hermes Solution) — Fri, 23 May 2025 01:46:24 GMT

The Essential Role of Software Architecture in ISO 26262 Functional Safety

Hello, this is Hermes Solution! This week's blog post delves into the crucial role of software architecture within ISO 26262 functional safety, the core safety standard in the automotive industry.

In today's automotive industry, the safety of electrical/electronic (E/E) systems is paramount, and the ISO 26262 standard has become the key guideline for ensuring this safety. This standard provides a comprehensive risk-based framework to identify potential hazards, evaluate risks, and implement safety mechanisms to prevent system failures that could lead to accidents. It applies to all aspects of the vehicle development lifecycle, from concept and design to implementation, verification, production, and decommissioning, ensuring systems operate safely in both normal and fault conditions. In this context, software architecture must be recognized as more than just a development phase; it's a fundamental foundation for achieving functional safety objectives.

Innovations in modern vehicles, such as Advanced Driver-Assistance Systems (ADAS), autonomous driving technologies, and Electric Vehicle (EV) control systems, are driven by software, and its role and complexity are increasing exponentially. The rapid growth and networking of in-vehicle E/E systems further highlight the importance of functional safety, meaning that ensuring software safety is a critical component of overall vehicle safety. Functional safety cannot be achieved merely by adhering to coding rules or conducting thorough testing. How a system is structured, how safety requirements are implemented, how potential faults are managed, and how system integrity is maintained are all fundamentally determined by the software architecture. A well-defined architecture serves as a blueprint for safety.

ISO 26262 encourages a proactive approach to safety by emphasizing safety activities throughout the entire development lifecycle, integrating safety considerations from the design phase. Addressing safety issues late in development incurs significant costs and time, and often makes it difficult to find optimal solutions. Conversely, architectural decisions made during the concept and design phases have the greatest impact on achieving safety objectives effectively and efficiently. A flawed architecture, no matter how much it's tested, struggles to guarantee inherent safety. Furthermore, ISO 26262 mandates traceability and compliance at every stage of development, and a clear, well-documented software architecture is essential for demonstrating this traceability. The architecture provides a structure that identifies components, boundaries, and interfaces, offering a clear path from safety requirements to actual implementation, which serves as key evidence to support the Safety Case.

In this blog post, we will delve into how the ASIL (Automotive Safety Integrity Level) classification, a core element of automotive functional safety, specifically influences software architecture design decisions, and what considerations are necessary for each level.

ASIL Levels: How Automotive Risk Levels Shape Architecture Strategies

At the heart of ISO 26262 is the ASIL risk classification scheme. ASIL, short for Automotive Safety Integrity Level, indicates the potential risk level of an automotive system and dictates the rigor of the safety measures required. ASIL is divided into four levels: A, B, C, and D, with ASIL A representing the lowest risk and ASIL D the highest. Non-safety-related items are classified as QM (Quality Management).

ASIL levels are determined by evaluating three factors for each hazardous event:

Severity (S): The potential injury severity that can result from a malfunction (e.g., injury or fatality).
Exposure (E): How frequently the vehicle is exposed to specific driving situations where the hazard could occur.
Controllability (C): The ability of the driver or other systems to prevent or mitigate harm after a fault occurs.

The combination of these three factors determines the ASIL level for each hazardous situation, which in turn leads to the ASIL level of the safety goal that the system must meet to mitigate that hazard. The core principle is that a higher ASIL level demands stricter safety requirements, more robust safety mechanisms, and more rigorous development and verification processes.

ASIL levels are not merely labels attached to a system; they are fundamental drivers that determine architectural strategies from the initial design phase. ASIL defines safety goals and directly impacts the system architecture. For instance, an ASIL D safety goal necessitates robust mechanisms for fault tolerance and freedom from interference from the very beginning of architectural conception, whereas an ASIL A system might suffice with relatively less complex safety measures. Thus, the choice of architectural patterns, redundancy strategies, and error handling mechanisms are all directly influenced by the assigned ASIL level.

Furthermore, ASIL levels are closely linked to the "cost of safety." Generally, a higher ASIL level requires more effort and resources for development and verification. However, architectural choices can significantly impact these costs. For example, designing an ASIL D system with a complex monolithic architecture can exponentially increase the cost and time involved in proving freedom from interference or implementing robust fault tolerance. Conversely, a well-partitioned and modular architecture can enable efficient implementation and verification of safety requirements, contributing to optimizing the "cost of safety." This is a crucial business consideration for automotive manufacturers and suppliers.

Foundational Architectural Principles for Safety-Critical Software

In safety-critical software development, the robust application of several universally beneficial software architecture principles is crucial to meeting the requirements of specific ASIL levels. The importance and rigor of applying these principles increase with higher ASIL levels.

Modularity and Componentization: Break down software into manageable, clearly defined components, with each component designed to have a single responsibility. This enhances software understanding, maintainability, and verifiability. It's essential for fault isolation and complexity management, crucial for ensuring safety.
Cohesion: Elements within a component should be closely related, contributing to a single purpose or tightly coupled purposes. This strengthens encapsulation, reduces the likelihood of error propagation, and improves maintainability, robustness, and reusability, leading to a less complex software architecture.
Coupling: Minimize dependencies between components, with interactions occurring only through well-defined, minimal interfaces. This reduces the ripple effect of changes, improves testability and reusability, and limits error propagation.
Hierarchical Structure: Organize components into layers of abstraction. This enhances overall system understanding and promotes structured design.
Interface Design: Interfaces between components should be minimal and explicit, clearly defining how components interact. This promotes simplicity, verifiability, and encapsulation, reduces testing effort, and is key to managing interactions and potential interference.
Testability and Maintainability by Design: The architecture should inherently support ease of unit testing, integration testing, and system testing, and allow for easy future modifications. As ASIL levels increase, verification and validation (V&V) efforts intensify, making an architecture that is difficult to test significantly increase cost and risk.

These foundational principles serve as the bedrock for the advanced safety strategies required at higher ASIL levels. For instance, strategies like Freedom from Interference (FFI) heavily rely on clear boundaries and controlled interfaces, which are outcomes of modularity, loose coupling, and well-defined interface principles. A monolithic "spaghetti code" structure cannot effectively implement FFI or ASIL decomposition. Therefore, mastering these foundational principles is not just good software engineering practice; it's an essential step toward achieving high ASIL compliance.

Software Architecture Design Considerations by ASIL Level

The ASIL levels defined in ISO 26262 directly influence the required design complexity and sophistication of safety mechanisms in software architecture.

A. ASIL A & B: Building a Robust Foundation

ASIL A and B levels address relatively lower risk levels, but focus on establishing fundamental principles for safe software development. The architectural focus is on simplicity, readability, maintainability, and basic error detection capabilities. The architecture should support clear logical flows and intuitive data flows. Coding and design practices should include basic coding rules (e.g., meaningful variable names, using constants instead of magic numbers) and simple error handling mechanisms like basic input validation. Safety mechanisms primarily focus on detecting obvious errors, and extensive fault tolerance may not be required. V&V focuses on proving functional correctness and adherence to basic design principles.

B. ASIL C: Enhancing Safety and Design Rigor

From ASIL C onwards, the system's safety and design requirements significantly increase. An architecture that supports enhanced robustness, improved error handling and recovery capabilities, and more stringent V&V activities is required. All input data must be thoroughly validated, and the system must be able to recover safely from error states. Advanced coding techniques considering reusability, modularity, and testability are necessary, and adherence to coding standards like MISRA C becomes more critical. The architecture must also consider how software interacts with hardware components and responds to environmental stresses. More sophisticated error detection mechanisms and some fault tolerance concepts are introduced. Evaluation of Diagnostic Coverage for residual faults is required. Extensive testing, including unit, integration, and system testing, is mandatory, and formal code reviews and static analysis tools are strongly recommended.

C. ASIL D: Architecture Design for Highest Integrity and Fault Tolerance

ASIL D represents the highest safety requirement level. The architecture must ensure the highest level of integrity, comprehensive fault tolerance, and the ability to operate safely (fail-operational) or transition to a safe state (fail-safe). The architectural focus is on implementing methods to identify and address potential errors in all parts of the system, aiming for the highest level of safety by considering all possible fault scenarios. Demonstrable independence and freedom from interference are essential. Coding and design practices require detecting and handling all abnormal behaviors, and the system must remain in a safe state under any circumstances. Extensive safety mechanisms include:

Fault Tolerance: Using hardware or software redundancy and diversity to prevent single failures from violating overall safety goals.
Error Detection and Correction: Utilizing ECC for memory errors and robust communication protocols.
Timing and Execution Monitoring: Employing watchdog timers and deadline monitoring to detect abnormal program halts or timing violations.
Memory Protection: Using Hardware Memory Protection Units (MPUs) to enforce spatial isolation between components and block unauthorized memory access.
Transition to Safe State (Fail-Safe): Ensuring the system transitions to a pre-defined safe state upon critical fault detection.

The most stringent level of V&V is required for ASIL D. All development stages and changes must be fully documented, and independent verification is necessary to prove code safety. Formal Verification methods are strongly recommended, along with extensive use of static and dynamic analysis tools and Fault Injection Testing. Confirmation measures, including Functional Safety Audit and Functional Safety Assessment by independent parties, are extremely important.

The transition from ASIL B/C to ASIL D signifies not just a quantitative increase in requirements but a qualitative shift. ASIL D explicitly demands that the system either continues to operate safely or transitions to a safe state upon fault occurrence, requiring demonstrable protection of these capabilities from interference. This may necessitate architectural patterns like N-version programming, Triple Modular Redundancy (TMR) considerations, or robust partitioning, which are uncommon in lower ASIL levels.

Key Architectural Strategies for Achieving Functional Safety

To meet ISO 26262 requirements, especially for higher ASIL levels, it's crucial to understand and apply several key architectural strategies.

A. Freedom From Interference (FFI) in Mixed-ASIL Systems

The "Freedom From Interference" principle is critical when software components of different ASIL levels (or QM components) coexist on the same ECU. Higher ASIL components must not be negatively affected by lower ASIL components. FFI includes three essential requirements: memory protection, execution time guarantees, and data transfer integrity. Architectural techniques to achieve FFI include partitioning (logical and often physical separation), spatial isolation (MPU/MMU), temporal isolation, controlled interfaces, shared resource management, and data integrity at interfaces. Standards like AUTOSAR and microkernel-based OSs contribute to FFI by providing foundational mechanisms for partitioning and memory protection.

B. ASIL Decomposition and Its Architectural Impact

ASIL decomposition is a technique for dividing high ASIL safety requirements into multiple redundant and independent lower ASIL requirements, assigning them to different architectural elements. This reduces the complexity, development cost, and required tool level for individual elements. Architectural prerequisites for ASIL decomposition include redundancy and independence. The architectural implementation may involve diverse redundant channels, separate microcontrollers, or functionally distinct software paths. It's crucial to ensure that a failure in one decomposed path does not affect other redundant paths. While ASIL decomposition can lower the ASIL level of individual elements, the overall safety goal must still be met.

C. Architectural Integration of Safety Mechanisms

Various safety mechanisms are distributed and integrated throughout the architecture. These include:

Error Detection and Handling: Input validation, range checks, plausibility checks, and internal error detection (e.g., control flow errors, data corruption). Architecturally, these checks can be located in specific architectural layers or modules.
Fault Tolerance Techniques: Designing the architecture to withstand faults and continue safe operation or transition to a safe state. This includes redundancy (hardware, software, information, temporal), watchdog timers, and Error Correction Code (ECC). Redundancy requires careful architectural planning for managing redundant elements, voting mechanisms, and switching logic.
Diagnostic Functions: Mechanisms to detect, report, and record faults to aid maintenance and prevent further risks. This may include dedicated diagnostic modules and communication paths.
Fail-Safe / Fail-Operational Design: Ensuring the system transitions to a pre-defined safe state upon critical fault, or in some very high ASIL functions, maintains limited functionality (fail-operational). This requires clear definition of safe states and architectural logic to achieve them.

These safety mechanisms are often implemented distributed across the architecture rather than concentrated in a single "safety module." Therefore, the architecture must define where these mechanisms are located, how they interact, and how their combined operation contributes to the overall safety goals.

Verification and Validation (V&V) of Safety-Centric Architectures

ISO 26262 compliant V&V is not limited to code testing. The software architecture itself must undergo rigorous verification and validation, with methods and intensity adjusted according to the ASIL level. While code V&V focuses on implementation accuracy for unit design, architectural V&V focuses on ensuring the architecture correctly implements system-level safety requirements, supports FFI, properly allocates functions, and defines and uses interfaces correctly.

Higher ASIL levels demand more formal, comprehensive, and often independent architectural V&V. For ASIL A/B, reviews or walkthroughs may suffice, but for ASIL C/D, more formalized methods, extensive analysis, and tool-supported verification are necessary.

Key architectural V&V methods include:

Architecture Design Review: A systematic evaluation of the architecture against safety requirements and design principles.
Architecture Static Analysis: Using tools to check consistency, adherence to architectural rules, interface discrepancies, and potential FFI violations.
Model-Based Verification: Applying formal verification or simulation to the architecture when it's represented as a model (e.g., SysML, AUTOSAR models).
Dependent Failure Analysis (DFA): A critical analysis to identify potential Common Cause Failures (CCF) and Cascading Failures (CF) that could violate independence or FFI. It's used to inform and verify architectural choices regarding redundancy and partitioning. DFA analyzes various aspects of software architecture, including timing, memory, and information exchange.
Fault Injection Testing (System/Integration Level): Considered part of system testing, its results can validate the architecture's resilience to faults.

Confirmation Measures under ISO 26262 Part 2 are independent checks to ensure that ISO 26262 processes and objectives have been met. Regarding architecture, this includes verifying correct ASIL decomposition, confirming DFA execution and resolution, and proving sufficient independence between elements implementing redundant safety requirements. For ASIL (B), C, and D items, Functional Safety Audits and Assessments are crucial.

Early validation of the architecture through static analysis and formal reviews significantly reduces project risk and rework. Therefore, investing in robust architectural V&V methods and tools pays off in terms of reduced integration issues, cost savings, and improved confidence in safety. The V&V activities for architecture are part of building the "argument" or "case" that the architecture is safe and meets its assigned safety requirements, and the related deliverables (review reports, analysis results, tool outputs, etc.) are essential components of the overall safety case submitted for assessment and certification.

Proactive Architecture Design for a Safer Automotive Future

As we've explored, ASIL levels are more than just compliance items; they are essential guidelines that direct software architecture to manage risks appropriately. Integrating functional safety considerations into the architecture design process from the early stages of development is far more effective than attempting to "add" safety later. A well-designed and ASIL-appropriate architecture plays a fundamental role in creating reliable, robust, and certifiable safe automotive software.

The automotive industry faces new challenges, including the increasing complexity of ADAS and autonomous driving systems, ensuring the safety of AI/ML components, the interaction between cybersecurity (ISO 21434, etc.) and functional safety, and managing high-voltage systems in electric vehicles. In this environment, the importance of architectural solutions will only grow.

Companies that skillfully execute ASIL-driven architectural design can develop safer systems more efficiently. Smart architectures that effectively meet high ASIL requirements can shorten time-to-market, reduce development costs, and build a strong reputation for safety and reliability. This can be a significant competitive advantage in the automotive industry. Therefore, investing in architectural capabilities and expertise for functional safety is not just a technical decision but a strategic business decision.

As new technologies (AI, SoCs, multi-sensor fusion, etc.) are introduced, software architecture must evolve to address new types of risks and ensure safety. While the principles of ISO 26262 will remain, their application in architectural design will require continuous adaptation. The field of safety-critical software architecture is dynamic, and continuous learning and adaptation of architectural patterns, as well as the development of new V&V techniques for architecture, will be essential for the industry. Ultimately, a proactive, safety-first architectural design approach will be the core driving force in creating a safer automotive future. Partner with Hermes Solution to build a safer automotive future!

자동차 소프트웨어 품질 관리: ASPICE 결함 관리에 대한 심층 분석

info@hermessol.com (Hermes Solution) — Thu, 15 May 2025 01:22:59 GMT

Hello. This is Hermes Solution. Today, we would like to talk about Defect Management within the ASPICE (Automotive Software Process Improvement and Capability determination) framework, which is essential for ensuring the quality and safety of automotive software.

The amount of software in a single vehicle is growing exponentially, and its importance is increasing daily. Beyond simple convenience features, software is now responsible for core functions directly related to driver and passenger safety, such as engine control, braking, and autonomous driving. Amidst these changes, securing the quality and safety of automotive software has become a paramount concern.

This is where the ASPICE framework comes in. ASPICE is an international standard for evaluating and improving the capability of automotive software development processes. It acts like a systematic guideline for precisely diagnosing and improving the performance of automotive software development. It evolved from the existing software process assessment standard, ISO/IEC 15504 (SPICE), adapted specifically for the automotive industry.

The ASPICE framework defines various activities spanning the entire software development lifecycle, and among these, 'Defect Management' is an indispensable core element. ASPICE views defect management not just as an activity to fix found bugs but as a crucial means to enhance the quality of the software development process itself.

How is Defect Management Handled in ASPICE? SUP.9 and SUP.10

Within the ASPICE framework, defect management is performed integrally across various process areas, but key activities are primarily defined in two core processes: SUP.9 (Problem Resolution Management) and SUP.10 (Change Request Management).

SUP.9 Problem Resolution Management: This process focuses on the activities of identifying, analyzing, managing, and resolving all types of 'problems' (including software defects) discovered during development. The goal is to systematically track problems from the moment they are first identified until they are finally resolved, ensuring product quality. The main activities (Base Practices - BPs) of SUP.9 are as follows:

- SUP.9.BP1: Develop problem resolution strategy
- SUP.9.BP2: Identify and record problems
- SUP.9.BP3: Track problem status
- SUP.9.BP4: Analyze and evaluate problems
- SUP.9.BP5: Propose problem resolutions
- SUP.9.BP6: Implement problem resolutions
- SUP.9.BP7: Close problems
- SUP.9.BP8: Analyze problem trends
SUP.10 Change Request Management: This is the process for systematically managing 'change requests' related to development artifacts such as requirements, design, and code. Activities like modifying code to fix a defect are managed through the SUP.10 process. The main activities (Base Practices) of SUP.10 are as follows:

- SUP.10.BP1: Develop change request management strategy
- SUP.10.BP2: Identify and record change requests
- SUP.10.BP3: Record and track change request status
- SUP.10.BP4: Analyze and evaluate change requests
- SUP.10.BP5: Approve change requests
- SUP.10.BP6: Implement and close change requests
- SUP.10.BP7: Maintain bi-directional traceability for change requests

Generally, once a defect is identified and analyzed in SUP.9, the actual work to fix it, often involving code modifications, proceeds according to the change request management process in SUP.10. These two processes form the core pillars of defect management in ASPICE.

Why is Defect Management So Crucial in ASPICE?

Defect management is critical in ASPICE for the following reasons:

A Mirror of Process Quality: Defect data, such as defect occurrence rate, discovery phase, and inflow/outflow rates, are key objective indicators showing how efficient and defect-free the current development process is.
Evidence for Safety and Compliance: Proving compliance with standards like automotive functional safety (ISO 26262) requires demonstrating that safety-related defects are thoroughly managed and resolved. Systematic defect management provides the foundation for this evidence.
Engine for Continuous Improvement: Analyzing the root causes and patterns of defects helps identify weaknesses in the development process, leading to activities that improve development methods, coding standards, or testing strategies to prevent similar defects in the future.
Project Risk Management Tool: Defect discovery and resolution trends provide important information for assessing project progress, evaluating product readiness for release based on the number of unresolved critical defects, and managing resource allocation and potential schedule risks.

From these perspectives, defect management is not merely a maintenance activity but a fundamental basis for achieving the ASPICE framework's goals of process improvement and quality enhancement.

Key Elements Required for Defect Management in ASPICE

To establish effective defect management in ASPICE, the following key elements must be in place:

Defect Lifecycle Management: The entire journey of a defect, from its identification and reporting, through analysis and planning, resolution, and finally verification and closure, must be systematically managed. Necessary activities and outputs for each phase must be clearly defined, and status tracking must be possible. Post-activities including defect analysis and improvement are also included.
Defect Classification System: A consistent classification system is needed for effective defect analysis. Defects should be classified using various criteria such as Severity (Critical, High, Medium, Low), Priority (Urgent, High, Medium, Low), Defect Type (e.g., Functional Error, Interface Issue), Origin Phase (e.g., Requirements, Design, Implementation), and Root Cause (e.g., Specification Error, Coding Error).
Traceability: Defects must be linked and tracked in relation to requirements, design elements, code, test cases, and change requests. This helps in understanding the impact scope of a defect and managing the effects of defect resolution on related artifacts.
Documentation: All information related to defect management, including the defect management plan, detailed records for each defect (including occurrence info, analysis, resolution steps), and defect metrics reports, must be thoroughly documented and managed. This serves as crucial evidence for ASPICE assessments.
Analysis and Prevention: Going beyond simply fixing defects, it is essential to identify the root cause of defects (e.g., 5-Why analysis, Fishbone diagram) and undertake process or technical improvements (e.g., strengthening coding standards, enhancing reviews) to prevent similar defects from occurring again. This is vital for advancing ASPICE maturity levels.

Practical Advice for Implementing ASPICE Defect Management Process

Here are some practical tips for effectively meeting the ASPICE defect management requirements:

Utilize Integrated Tools: Use an ALM (Application Lifecycle Management) tool that integrates requirements, test, defect, and change management to improve traceability and process efficiency.
Clear Process Definition and Training: Clearly define and document defect management procedures, responsibilities, and classification criteria, ensuring all team members are thoroughly trained on how to follow them.
Defined Roles and Responsibilities: Clearly define roles like Defect Manager and classification 담당자, assigning specific responsibilities for each step to ensure accountability.
Culture of Continuous Improvement: Foster a culture of continuous improvement by holding regular defect review meetings to discuss key defects and trends, and consistently implementing process improvements based on defect analysis results.

Conclusion

Systematic defect management within the ASPICE framework is a critical activity for enhancing automotive software quality, meeting functional safety requirements, and continuously improving development processes. By managing the entire defect lifecycle focusing on the SUP.9 and SUP.10 processes, and effectively analyzing defect data to drive preventive actions, we can create safer and more reliable automotive software.

If you require expert support in establishing and operating a systematic ASPICE-based defect management process, Hermes Solution can help. Hermes Solution provides the expertise and solutions necessary for meeting ASPICE requirements and achieving effective quality management.

ISO 21434: 연결된 자동차 OTA 보안

info@hermessol.com (Hermes Solution) — Mon, 28 Apr 2025 08:58:18 GMT

The Era of Connected Cars and the Importance of OTA, and Security Threats

Hello, Engineers! This is Hermes Solution.

Today, cars are rapidly transforming from mere means of transportation into 'smart devices on wheels,' intricately connected by sophisticated software and networks. This transformation is accelerating even further as we enter the era of the Software-Defined Vehicle (SDV).

One of the core drivers of this connected car revolution is the OTA (Over-the-Air) update technology. Through OTA, manufacturers can keep vehicle software up-to-date without requiring a service center visit, add new features, and most importantly, quickly resolve security vulnerabilities.

However, as vehicle connectivity strengthens and OTA utilization increases, potential security threats that attackers can exploit also grow. If attackers inject malicious updates or intercept and manipulate the update process, it can go beyond vehicle malfunction and pose a serious threat to passenger safety. Malicious update injection, update tampering, Man-in-the-Middle (MitM) attacks, Denial-of-Service (DoS) attacks, authentication bypass, supply chain attacks, and exploitation of API vulnerabilities are emerging as major security threats targeting connected cars. These attacks can lead to devastating consequences such as data breaches, immense financial loss, and damage to brand image.

Against this backdrop, international standards like ISO/SAE 21434 for automotive cybersecurity and international regulations based on it, such as UN R155/R156, provide essential guidelines for building a safe and reliable OTA update environment. In this blog post, we aim to delve deeply into how to establish and implement a secure OTA update security strategy from the perspective of the ISO/SAE 21434 standard. Now, OTA security is no longer a technical option, but an essential strategy for business continuity and legal compliance in the connected car business.

OTA Security: Why Essential? New Risks for Connected Cars

OTA is a powerful tool for managing vehicle software, but it simultaneously provides attackers with new attack vectors. It has a broad attack surface, including in-vehicle clients, backend servers, and communication channels.

Key Threat Scenarios:

Malicious Update Injection: Attackers distribute malware by compromising servers or intercepting communications (e.g., disabling braking systems).
Update Tampering: Altering update content during transmission (e.g., manipulating engine parameters).
Man-in-the-Middle (MitM): Intercepting communications to steal authentication information or deliver counterfeit updates.
Denial-of-Service (DoS): Paralyzing server or vehicle update functions, delaying patches.
Authentication/Authorization Bypass: Forcing the installation of specific vehicle updates through unauthorized access.
Supply Chain Attacks: Infected software from the development/production stage being distributed via OTA.
API Vulnerability Exploitation: Attempting data theft or unauthorized updates by exploiting vulnerabilities in backend/connected service APIs.

These threats can lead to functional safety risks, data breaches, financial loss, recalls, and brand damage. Recent attacks are evolving towards ransomware and data theft for financial gain, extending to the entire automotive ecosystem. The surge in automotive-related security vulnerabilities (CVEs) is linked to the expansion of OTA, highlighting the importance of rapid security patching.

International regulations UN R155 (Cyber Security Management System, CSMS) and UN R156 (Software Update Management System, SUMS) mandate the establishment of CSMS and SUMS, which are essential requirements for type approval in major markets like the EU, Japan, and Korea. Secure OTA is central to compliance with these regulations and must satisfy both CSMS and SUMS requirements.

Roadmap for Secure OTA: ISO/SAE 21434 Standard

ISO/SAE 21434 is the international standard for 'Cybersecurity Engineering' in road vehicles, providing a framework for identifying, evaluating, and managing risks throughout the vehicle lifecycle.

Key Principles:

CSMS: Establishment of an organizational-level cybersecurity management system (Mandated by UN R155).
Risk-Based Approach: Prioritizing security activities based on Threat Analysis and Risk Assessment (TARA).
Security by Design: Considering security from the initial development stages and performing security activities throughout all phases.
Full Lifecycle Management: Emphasizing continuous security activities in the post-production phase (vulnerability monitoring, updates, incident response).

OTA updates are a core function in the 'Operation and Maintenance' phase, and ISO/SAE 21434 defines specific requirements for this phase. While ISO/SAE 21434 itself is a standard, UN regulations effectively require compliance with ISO/SAE 21434 for type approval, making it a practical path to regulatory compliance.

Building a Robust OTA Ecosystem: ISO/SAE 21434-Based Approach

Establishing a secure OTA strategy involves comprehensive activities from risk analysis to design, implementation, testing, and ongoing management.

1. Starting Point: Performing OTA System TARA

This is a systematic process (ISO/SAE 21434 Clause 15) for identifying, evaluating, and determining the risk level of potential threats and vulnerabilities in the OTA system.

Asset Identification: Clearly defining assets to protect (client, firmware, keys, servers, etc.).
Threat Scenario Identification: Deriving threat situations that could harm assets (malicious injection, tampering, etc.).
Vulnerability Analysis: Analyzing weaknesses in design, implementation, and operation.
Impact Assessment: Evaluating the severity of damage if a threat succeeds (safety, financial, operational, privacy).
Risk Level Determination: Synthesizing likelihood and impact to prioritize. TARA results serve as the basis for deriving security goals and requirements.

2. Building the Defense Line: Defining Core OTA Security Requirements

Concrete security requirements are defined based on TARA and reflected in the system design.

Integrity and Authentication: Preventing update tampering and confirming trusted origin (Hash, Digital Signature, PKI).
Confidentiality: Protecting update content from unauthorized access (Strong encryption).
Secure Communication: Protecting vehicle-to-server communication (TLS, Mutual Authentication).
Vehicle/Server Authentication and Authorization: Verifying the identity of the target vehicle and server, confirming update suitability (Certificates, HSM, DID/VC).
Secure Storage: Safely storing sensitive information (Secure memory, HSM).
Secure Update Process: Verification before installation, secure installation and recovery (Signature/hash verification, Secure Boot, Rollback).

3. Fortifying the Vehicle: Secure Implementation Strategy

Defined requirements are effectively implemented in the system.

Establishing Trust Anchors (Secure Boot): Ensuring the integrity of initial boot software to secure the OTA process.
Hardware Security Enhancement (HSM): Providing strong security through dedicated secure hardware for key management and cryptographic operations. Used in Secure Boot, certificate management, etc.
Secure Coding Practices: Adhering to secure coding standards, utilizing static/dynamic analysis to prevent vulnerabilities.
Defense in Depth and Isolation: Applying multiple layers of security mechanisms, isolating communication between critical systems.

4. Preparing for Failure: Designing a Robust Rollback Mechanism

A function is essential to prevent vehicle bricking in case of update failure and restore a stable state.

A/B Partitioning: Using two partitions, booting from the previous partition on failure (Fast rollback, requires double memory).
Backup-Based Caching: Storing the new update in a separate space, restoring from backup on failure (Hardware flexibility, downtime occurs). Anti-downgrade functionality to prevent malicious rollback to an older version should also be considered.

5. Verifying Strength: Performing Comprehensive Security Testing

Verification of the implemented system's defenses is essential.

Penetration Testing: Actively searching for vulnerabilities from an attacker's perspective.
Fuzz Testing: Inputting abnormal data to identify vulnerabilities.
Code Review & Static/Dynamic Analysis: Analyzing source code and execution stages for vulnerabilities.
Cryptographic Implementation Verification: Confirming compliance with cryptographic standards and security strength. Robust OTA security is achieved through a multi-layered, holistic approach combining technology, hardware, software, processes, and resilience.

Preparing for the Future: Latest OTA Security Threats and Defense Technologies

The threat landscape evolves, and OTA security must also advance.

Supply Chain Security Enhancement: Countering supply chain vulnerability attacks through supplier security requirements, SBOM utilization, and firmware distribution security enhancement.
API Security: Preventing API vulnerability exploitation through strong authentication/authorization and input validation.
AI-Based Attacks and Defense: Emergence of sophisticated AI-powered attacks, countered by AI-based IDS and other defenses.
Advanced HSM Utilization: Utilizing HSM beyond key management for enforcing secure boot, access control, etc.
DLT/Blockchain Utilization: Researching improvements in update transparency, integrity, and auditability using DLT/blockchain.
In-Vehicle IDPS: Establishing the final line of defense by monitoring internal network traffic. Continuous threat intelligence analysis and consideration of adopting new technologies are essential.

Security Beyond the Vehicle: Protecting the Entire OTA Infrastructure

Securing the backend infrastructure for generating, managing, and distributing updates is critically important as it directly impacts the safety of the entire fleet.

Server-Side Security Enhancement: Preventing server breaches through strong access control (MFA), regular vulnerability management, penetration testing, secure configuration, logging/monitoring, etc.
Continuous Security Activities in the Post-Production Phase: ISO/SAE 21434 requirements (Clause 8, 13, 14).
Continuous Monitoring: Detecting security events and abnormal behavior.
Vulnerability Management: Analyzing new vulnerabilities and promptly deploying patches.
Incident Response: Establishing and executing procedures for security incident detection, analysis, and recovery.
CSMS Integration: Systematically managing OTA security activities as part of the organizational CSMS to ensure consistency and effectiveness.

A backend compromise can affect the entire vehicle fleet, so infrastructure security is as crucial as individual vehicle security. The safety of the entire OTA ecosystem is determined by its weakest link.

Driving Towards a Safely Connected Future

OTA is a core technology for modern cars and an essential element of future mobility, but innovation cannot be sustained without robust security. ISO/SAE 21434 provides the essential engineering framework for building and maintaining a secure OTA system, and it is the practical methodology for complying with UN R155/R156 regulations.

Successful OTA security is a holistic effort based on CSMS, encompassing technology, processes, and people. It requires continuous processes such as TARA, security requirement definition, secure implementation, testing, continuous monitoring, vulnerability management, and incident response.

Expert knowledge and proactive response are essential for complex OTA security and regulatory compliance. Strengthening internal capabilities and collaborating with specialized external partners are crucial. Hermes Solution provides the expertise and support needed on this journey. Through this, we can respond to constantly evolving threats and ensure a safe and reliable connected car experience.

자동차 기능 안전: ISO 26262 HARA, 안전 목표 및 검증

info@hermessol.com (Hermes Solution) — Tue, 22 Apr 2025 02:23:30 GMT

In the automotive industry, the increasing prevalence and complexity of Electrical/Electronic (E/E) systems have significantly highlighted the importance of functional safety. ISO 26262 is an international standard addressing the functional safety of these automotive E/E systems, providing a systematic framework for accident prevention and risk management.

In this Hermes solution blog post, we will briefly overview the ISO 26262 standard and delve into the Hazard Analysis and Risk Assessment (HARA) methodology, which is the starting point for functional safety development and the process for setting Safety Goals. We will also explore the verification methodology used to confirm that the defined Safety Goals have been achieved.

ISO 26262 Overview and the Safety Lifecycle

Fundamental Purpose and Scope of ISO 26262

The fundamental purpose of ISO 26262 is to identify, evaluate, and manage unreasonable risks arising from malfunctions of automotive E/E systems, thereby preventing accidents. It is not merely a technical specification but a comprehensive framework encompassing process models for the entire development lifecycle, requirements definition, evidence management, and specific methodologies.

Initially limited to passenger cars weighing up to 3,500kg, the second edition published in 2018 expanded the scope to include all road vehicles except mopeds. The standard's comprehensiveness was further enhanced with the addition of guidelines for semiconductor safety (Part 11) and application to motorcycles (Part 12).

Safety Lifecycle Approach

ISO 26262 is based on the Safety Lifecycle model. This means that safety-related activities must be systematically performed throughout the entire product lifecycle, starting from the initial concept phase, through development (system, hardware, software), production, operation, service, and finally decommissioning.

The V-Model development process is widely used to visually represent these safety lifecycle activities and clearly show the relationship between development and verification phases. The V-Model depicts the development process in a V-shape: the downward path on the left represents development activities from requirements definition to detailed design and implementation, while the upward path on the right represents verification and integration activities for the outputs of each development phase.

Hazard Analysis and Risk Assessment (HARA) and Safety Goal Setting

Importance of the HARA Process

Hazard Analysis and Risk Assessment (HARA) is a core activity performed in Part 3 (Concept Phase) of the ISO 26262 standard. It is the process of systematically identifying potential hazards that can arise from malfunctions of the item under development, evaluating the associated risks, and deriving the highest-level safety requirements, known as Safety Goals, to mitigate these risks.

HARA is the starting point for the functional safety development process. The Safety Goals and ASIL (Automotive Safety Integrity Level) ratings derived from HARA determine the direction and rigor of all subsequent development and verification activities.

HARA Process Steps

HARA typically consists of the following steps:

Item Definition: Clearly define the scope, functional behavior, boundary conditions, and interfaces with external systems for the system or function being analyzed.
Situation Analysis and Hazard Identification: Analyze various operational scenarios (e.g., highway driving, city driving, parking) and identify potential hazards that could occur due to item malfunction in each scenario.
Hazardous Event Classification: Combine identified hazards with specific operational situations to define concrete hazardous events (e.g., 'complete failure of the braking system during highway driving') and predict potential consequences.
Risk Assessment and ASIL Determination: Evaluate three factors – Severity (S), Exposure (E), and Controlability (C) – for each hazardous event to determine the ASIL rating (QM, A, B, C, D).
Safety Goal Definition: Define the highest-level Safety Goals required to reduce the assessed risk to an acceptable level.

Hazard Element Evaluation: Severity (S), Exposure (E), Controlability (C)

The evaluation criteria for Severity (S), Exposure (E), and Controlability (C), the key elements for ASIL determination, are as follows:

Severity (S): Degree of potential injury to the driver, passengers, or other road users if the hazardous event occurs, rated from S0 (No injuries) to S3 (Life-threatening or fatal injuries).
Exposure (E): Probability of the vehicle being in specific operational situations that could lead to the hazardous event, rated from E0 (Extremely unlikely) to E4 (High probability).
Controlability (C): Ability of the driver to respond appropriately and in a timely manner to avoid or mitigate injury or damage if the hazardous event occurs, rated from C0 (Generally controllable) to C3 (Difficult or impossible for most drivers to control).

ASIL Determination and Safety Goal Derivation

The ASIL rating is determined based on the combination of the S, E, and C evaluation results. ASIL is divided into 5 levels, from QM (Quality Management, no specific safety measures required) to ASIL D (the highest risk level). Higher ASIL ratings demand more stringent development processes, verification activities, and independence requirements.

Finally, a Safety Goal is defined for each hazardous event. The Safety Goal is the highest-level safety requirement defined at the vehicle level and inherits the ASIL rating of the corresponding hazardous event.

Definition of the Safety Goal and Requirements Decomposition

Role and Attributes of the Safety Goal

The Safety Goal is the highest-level functional safety requirement aimed at mitigating risks identified through HARA to an 'acceptable level'. It is defined at the vehicle level, should be functionally oriented, and should avoid specifying particular technical solutions.

Functional Safety Concept and Technical Safety Concept

Safety Goals are progressively elaborated in subsequent development phases:

Functional Safety Concept (FSC): Defines the Functional Safety Requirements (FSRs) necessary to achieve the Safety Goal and outlines the initial system architecture. FSRs are described in terms of the safety-related functions the system must perform, independent of specific implementation methods.
Technical Safety Concept (TSC): Defines the specific Technical Safety Requirements (TSRs) for implementing the FSRs. Unlike FSRs, TSRs include implementation-related details, specifying the behavior of safety mechanisms, interfaces, performance constraints, and more.

Through this process, the Safety Goal (SG) is hierarchically decomposed into SG → FSR → TSR → Hardware Safety Requirements (HSR) / Software Safety Requirements (SSR), ultimately transforming into concrete requirements that can be implemented and verified by developers.

Attributes of Desirable Safety Goals and Requirements

Effective Safety Goals and requirements should possess the following attributes:

Clear/Unambiguous: Meaning should be uniquely interpretable.
Atomic: Describe only a single requirement that cannot be further divided.
Verifiable: Ability to objectively confirm whether the requirement is met.
Feasible: Possible to implement under given constraints.
Consistent: Should not conflict with other requirements.
Complete: Should include all aspects from the higher-level requirement.
Traceable: Clear bidirectional link between the requirement's source and the item for implementation/verification.

ASIL Decomposition Concept

ISO 26262 permits a special technique called ASIL Decomposition. This involves splitting a single requirement with a high ASIL (e.g., ASIL D) into multiple redundant sub-requirements that together achieve the same Safety Goal, assigning a lower ASIL (e.g., ASIL B(D)) to each sub-requirement.

A key condition for ASIL decomposition is that the elements implementing the decomposed sub-requirements must be sufficiently independent of each other. This must be demonstrated through Dependent Failure Analysis (DFA).

Safety Goal Verification Methodology

Establishing the Verification Plan

The Verification Plan is a document defining the scope, methods, schedule, responsibilities, and required resources for all verification activities to be performed throughout the entire safety lifecycle. It includes verification targets and scope, methods and criteria, environment and tools, schedule and responsibilities, independence requirements, and results reporting and management.

Application of Key Safety Analysis Techniques

ISO 26262 recommends applying various safety analysis techniques to verify the validity of Safety Goals and analyze the causes and effects of potential system failures:

FMEA (Failure Mode and Effects Analysis): A bottom-up, inductive analysis technique to identify potential failure modes of system components and analyze their effects.
FTA (Fault Tree Analysis): A top-down, deductive analysis technique using logic gates to analyze combinations of root causes for a specific undesirable top event.
DFA (Dependent Failure Analysis): Analyzes the possibility of redundant elements failing simultaneously due to a single event or cause to verify independence.
FMEDA (Failure Mode, Effects and Diagnostic Analysis): An extension of FMEA that quantitatively evaluates the effectiveness of diagnostic mechanisms for each hardware component's failure mode and its effects.

Performing Verification Activities

Actual verification activities include the following methods:

Review: Identifying errors, omissions, and inconsistencies in requirements specifications, design documents, source code, etc.
Static Analysis: Analyzing the structure, style, potential errors, and coding standard compliance of software code without executing it.
Unit Testing: Verifying that the smallest units of software function correctly.
Integration Testing: Verifying that individually tested units interact and function correctly when combined.
System Testing: Verifying that the fully integrated system meets the defined requirements.
Hardware Evaluation: Evaluating hardware components and systems to ensure they meet requirements and safety mechanisms are effective.
Safety Validation: Final confirmation that the developed system satisfies the Safety Goals within the overall vehicle environment.

Building the Safety Case

A Safety Case is a structured set of arguments and evidence demonstrating that the developed system achieves its Safety Goals and possesses sufficient safety. It typically has a structure where a top-level claim is decomposed into specific sub-claims, supported by evidence (e.g., HARA report, safety analysis results, test reports). The Safety Case serves purposes such as building internal confidence, convincing external stakeholders, providing justification for safety approval, knowledge management, and legal defense.

Real-World Application Cases and Challenges

Electric Vehicle Battery Management System (BMS) Case

EV BMS is a safety-critical system due to the risk of lithium-ion battery thermal runaway. Hazardous events related to thermal runaway are likely evaluated as ASIL D (S3, E4, C3). Consequently, a Safety Goal such as "The battery system shall prevent thermal runaway under all operating conditions" is set. This is decomposed into functional safety requirements like cell voltage/temperature monitoring, overcurrent detection, cell balancing, and safe state transitions. Verification involves safety analyses (FMEA, FTA, FMEDA) along with HIL testing, environmental/EMC testing, and vehicle testing.

ADAS (Advanced Driver Assistance Systems) Case

ADAS functions are highly safety-critical as they directly control vehicle behavior. For instance, a malfunction of a Lane Keeping Assist (LKA) system (e.g., unintended steering, excessive steering, steering in the wrong direction) if occurring during high-speed driving, could be evaluated as ASIL D. Accordingly, a Safety Goal like "The LKA system shall not cause steering interventions that jeopardize the vehicle's safe path" is set, and various safety mechanisms (sensor data validation, algorithm robustness, steering command verification, etc.) are implemented and verified to achieve this.

Key Challenges in Practical Application

Major challenges when applying ISO 26262 include:

Complexity of the standard and difficulty in interpretation.
Organizational cultural resistance to changes in development processes.
Increased cost and development time.
Issues with applying the standard to legacy systems and reusable components.
Lack of tool support and automation.
Difficulty in ensuring standard compliance across the entire supply chain.
Challenges in establishing a robust safety culture within the organization.

Overcoming these challenges requires management's strong support, systematic training and expert development, standardized processes and templates, utilization of automation tools, strengthening supply chain management, a stepwise adoption and continuous improvement approach, along with the crucial effort of establishing a strong safety culture.

Concluding Thoughts: The Present and Future of Functional Safety

ISO 26262-based Safety Goal setting and verification is not just a formal process of complying with standard requirements. It is a systematic problem-solving process that involves identifying potential risks in advance, clearly setting goals to eliminate or control them, and objectively proving that these goals have been achieved with tangible evidence.

As the automotive industry rapidly evolves with electrification, autonomous driving, and connectivity, an integrated approach considering ISO 26262 alongside SOTIF (ISO 21448) and Cybersecurity (ISO/SAE 21434) standards is becoming increasingly important. Furthermore, continuous development of safety assurance methodologies is needed to address new technology trends like AI/ML-based systems, OTA updates, and data-driven safety analysis.

Recognizing that automotive functional safety goes beyond regulatory compliance and is a core value directly linked to customer lives is essential. Systematic Safety Goal setting and thorough verification according to ISO 26262 will be the most fundamental and critical starting point for these continuous efforts to ensure safety in line with technological advancements. Hermes solution deeply recognizes the importance of this functional safety field and contributes to the technological development for a safe future in the automotive industry.

ASPICE와 Agile의 통합: 자동차 소프트웨어 개발을 위한 미래 전략

info@hermessol.com (Hermes Solution) — Thu, 10 Apr 2025 08:21:02 GMT

The modern automotive industry is rapidly transitioning into an era of software-driven innovation. With the increasing importance of software in vehicles, developers face the challenge of balancing structured frameworks that ensure quality and safety with flexible methodologies that enable rapid innovation. Against this backdrop, harmonizing ASPICE (Automotive Software Process Improvement and Capability dEtermination) with Agile methodologies is emerging as a key strategic approach for the future of automotive software development.

This week at Hermes Solution, we delve deeply into practical strategies for integrating ASPICE and Agile methodologies under the theme "Practical Integration of ASPICE and Agile: Future Strategies for Automotive Software Development."

ASPICE and Agile: Two Different Worlds

Understanding ASPICE

ASPICE is a framework designed to evaluate and improve software development processes in the automotive industry. Based on the ISO/IEC 15504 standard, ASPICE has the following characteristics:

Closely related to the V-model, focusing on verification and validation at each development stage.
Comprised of various process groups, including management, engineering, and support processes.
Provides capability levels from 0 to 5 to measure process maturity and organizational capability.
Emphasizes traceability and documentation, essential for safety-critical systems.

Many automotive OEMs, particularly German manufacturers, require suppliers to adhere to a minimal set of processes called the "VDA scope." ASPICE has become essential for ensuring quality, reliability, and safety in complex automotive systems.

The Value and Benefits of Agile

Agile methodology is based on four core values from the Agile Manifesto:

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

Scrum and Kanban are common Agile frameworks used in automotive software development:

Scrum: Roles include product owner, scrum master, and development team, utilizing sprint-based workflows.
Kanban: Focuses on workflow visualization, limiting work-in-progress (WIP), and continuous flow.

Agile's main advantages include improved adaptability, faster market launch, enhanced quality, stronger collaboration, higher customer satisfaction, and reduced risks.

ASPICE and Agile: Conflict and Complementarity

Potential Conflict Areas

ASPICE and Agile methodologies have several clear conflict areas:

Structured, sequential ASPICE vs. iterative, flexible Agile.
Extensive documentation required by ASPICE vs. Agile's emphasis on "working software."
Different views on changes after design freezes.

Complementary Elements

Despite these conflicts, both approaches share complementary elements:

Common goals such as high-quality products, continuous improvement, and customer satisfaction.
Agile's iterative development and early feedback can help achieve ASPICE's quality objectives.
ASPICE's structured framework provides necessary rigor for safety-critical areas.

A critical perspective shift is focusing ASPICE on "what" (outcomes), while Agile concentrates on "how" (implementation), enabling the flexibility to adopt Agile methods within the ASPICE framework.

Practical Strategies for Harmonious Integration

Hybrid Models and Agile SPICE™

Several practical strategies support harmonious integration:

Hybrid models combining structured ASPICE planning and documentation with Agile sprints and daily stand-ups.
Agile SPICE™, an Automotive SPICE add-on designed to meet ASPICE requirements while maintaining Agile methods, focusing on outcomes and redefining process attributes to incorporate agility.
Mapping Agile activities and ASPICE processes: Strategies to map Agile outputs like user stories, sprint backlogs, and retrospectives to ASPICE processes and work products (e.g., using sprint reviews for joint reviews, product backlog for requirements management).

Real-world Success Cases

Several companies have successfully integrated ASPICE and Agile:

Bosch: Improved development speed while maintaining quality standards through a hybrid model.
Audi and Porsche: Successfully integrated Agile methodologies within the ASPICE framework.
Luxoft, YASA, Panasonic Automotive: Leveraged industry-specific approaches to maximize advantages of both methodologies.

These cases demonstrate that integrating ASPICE and Agile is practical, not merely theoretical. Many successful implementations utilize tools like Codebeamer, Jira, and YAKINDU Traceability to enhance traceability and collaboration in hybrid environments.

Benefits and Challenges of Integration

Key Benefits

Integrating ASPICE and Agile offers significant benefits:

Improved quality: Combining ASPICE rigor with Agile's early and continuous testing.
Faster development: Iterative Agile approach accelerates market entry while ensuring process compliance.
Increased customer satisfaction: Strengthened customer collaboration combined with quality assurance.
Enhanced risk management: Early feedback and structured processes facilitate risk identification and management.
Improved team collaboration: Enhanced communication among stakeholders.
Greater adaptability: Flexibility within a structured framework.

Challenges to Overcome

Several key challenges must be addressed for successful integration:

Documentation balance: Finding equilibrium between ASPICE's documentation requirements and Agile's emphasis on working software.
Change management: Resolving potential conflicts between structured processes and flexibility.
Organizational support: Securing leadership support and organization-wide buy-in.
Training and skill enhancement: Educating teams in both ASPICE and Agile principles.
Tools and infrastructure: Implementing appropriate tools to support traceability and collaboration.
Overcoming misconceptions: Changing perceptions of ASPICE and Agile as mutually exclusive.
Consistency: Ensuring consistent interpretation and application across teams and projects.

Conclusion: A Balanced Approach for the Future

Integrating ASPICE and Agile is becoming essential rather than optional in automotive software development. Viewing these approaches as complementary rather than conflicting maximizes their value.

By combining ASPICE’s systematic quality management with Agile’s flexible, rapid development, automotive companies can maintain safety and regulatory compliance while responding quickly to market changes. This approach is crucial for remaining competitive in the complex automotive software landscape.

As the industry becomes increasingly software-centric, a balanced approach is essential to achieving optimal innovation speed and rigorous quality control. Implementing hybrid models and specialized frameworks like Agile SPICE™ enables automotive companies to reduce development time, maintain quality, and swiftly introduce new features while meeting safety requirements.

Ultimately, this integrated approach is key to finding an optimal balance between quality, safety, innovation, and market responsiveness. Hermes Solution is your trusted partner on this journey, committed to helping you solve complex challenges and leveraging the strengths of both ASPICE and Agile to deliver innovative, safe, and tailored software solutions.