Blog

Practical Configuration Management 5-Step Process Guide for Engineering Teams

info@hermessol.com (Hermes Solution) — Tue, 02 Dec 2025 03:01:33 GMT

1. Start with the Most Common Questions from Practitioners

In the previous Configuration Management Series 1, we covered the basic concepts and importance of configuration management.
Many readers shared a common question:

"Now I understand the concept. So what do I actually do in real projects?"

In Series 2, we summarize a practical 5-step configuration management process that can be implemented immediately in engineering teams.
This includes key check points, checklists, and ready-to-use practical templates, all explained in one place.

2. Why Do Organizations Fail in Execution Even with Perfect Documents?

Even when companies possess configuration management documentation, execution often collapses due to the following reasons:

Process procedures exist, but engineering work is not performed according to the defined process.
Only the configuration manager understands the changes, while developers and test engineers are unaware of them.
Documents and real workflows operate independently and never synchronize.

On the other hand, organizations that successfully build configuration management as an internal capability share these traits:

Start small and improve rapidly.
Maintain a structure that can be understood by all engineers after hearing it once.
Keep documents aligned with real project workflows and ensure full traceability, including past history.

3. Practical 5-Step Configuration Management Framework for Real Engineering Work

Step 1 — Create the Configuration Management Plan (A Plan is More Than Documentation)

The configuration management plan is defined as a mandatory requirement in ISO 26262 Part 8.
However, writing the document alone is not planning. The real purpose of planning is team-level agreement on how configuration work will actually operate inside the project.

Core Elements of the Plan

Scope Definition
Clearly classify:

Which projects apply configuration management
Which work products must be managed
Which artifacts are excluded from control

Configuration Management Organization & Role Structure
Define organizational boundaries, responsibilities, and authority for configuration activities.

Naming & Version Identification Rules
A practical and widely-used engineering pattern:

[ProjectCode][ArtifactType][ModuleName]v[Version][Date].Extension

Example:
CM01_SRS_BrakeModule_v1.0_20251127.xlsx

Baseline Definition
Specify baseline points through formal review and approval flows, marking a confirmed version as the reference baseline.
Tools, Schedule, Status, and Change History Management Policies
Ensure tools are defined and compatible with project needs
Set policies for scheduling, history logging, version status, and archiving

Checklist for Step 1

Has the artifact scope been shared with all project members?
Are all teams applying the same naming & identification rules?
Have document storage location, baselines, and approval rules been agreed upon?

Step 2 — Identify What to Manage

All major work products and engineering decision evidence created throughout the safety lifecycle must be configuration-managed.

Example Artifacts to Control

Requirements specifications
Design descriptions
Test cases and results
Safety plan & safety case
Decision meeting records
Manuals & guidelines
Release versions
Change history logs

Checklist for Step 2

Are there missing artifacts?
Is ownership assigned for each work product update responsibility?
Are versions kept up-to-date regularly?

Step 3 — Control Change Flow

Change itself is natural. But uncontrolled change becomes safety risk, failure risk, and certification risk.

Typical Uncontrolled Change Failure Cases

A developer modifies code, but the team is unaware, leading to system failure after release.
Test teams repeat outdated test cases because they never received the update.
A failure occurs after release, but root cause analysis is impossible due to lack of history tracking.

Safety Impact Analysis (Mandatory for Every Change)

Does the failure mode change?
Is the safety goal impacted?
Are safety mechanisms affected?
Are additional safety measures required?

Ready-to-Copy Change Request Template

Item	Description
Change ID	CR-YYYY-001
Change Target	documents / design / code / system
Reason for Change	background & issue description
Change Description	detailed modification
Impact Analysis	safety impact & risk impact
Priority	Critical / High / Medium / Low
Owner	execution responsible
Schedule	implementation closure
Status	Draft / Approved / Archived / etc

Configuration work repeats the flow: Change Request → Review → Approval → Implementation → Re-verification → History Logging.

Step 4 — Build Traceability as a Core Capability

Audit and certification assessments always include the question:

"How was this requirement designed, implemented in code, and validated in test?"

Poor Responses When Traceability is Missing

"It should exist somewhere…"
"I think we tested it…"
"Let me check again…"

Result: audit failure or assessment failure.

Strong Benchmark Response When Traceability Exists
REQ-001 was designed in DES-005 → implemented in MOD-010 → validated in TC-025/026.
(And traceability matrix is presented immediately.)

The ability to retrieve and explain evidence instantly proves configuration success.

Step 5 — Audit as a Maturity Gate

Configuration maturity splits at audit execution:

Does the system satisfy safety requirements?
Is audit frequency defined?
Is audit ownership assigned?
Is failure verification performed per module?

4. Three Core Operating Principles for Success

Execution fails if attempting perfection too early.
Configuration fails if owned by only one person.
Documents must update when reality updates.

Following these principles automatically prepares teams for version history control → traceability → ISO audit readiness.

5. Why Organizations Trust Configuration Management from Hermes Solution

Expertise from Hermes Solution comes from over 10+ years and 100+ successful ISO consulting and project experiences across multiple industries.

Industry-specific configuration strategies for:

Automotive (ISO 26262)
Aviation
Semiconductor
Industrial embedded systems

What Makes This Approach Different

Templates that can be applied instantly by practitioners
CCB process and configuration culture design included
Document-driven trigger architecture
Execution and documentation remain synchronized
Supports baseline and change control flow design for real engineering teams

Hermes Solution does not build document-only configuration.
It builds configuration where the document becomes the engineering trigger.

6. Conclusion — Real Configuration Feels Different for Practitioners

The 5-step method introduced here is not a theoretical document guide.
It is an execution-driven engineering reality guide.

Change immediately triggers request → safety impact analysis → agreement → implementation → verification → history.
Traceability originates from document architecture design.
Audits evaluate execution more than documentation review.

Success can be defined as:

Configuration that anyone can understand, apply, and trace back through history.

7. Ready to Start?

Build configuration with a trigger-driven process structure together with Hermes Solution—not as separate document work and separate project execution work.

The next post will return with a document management process guide, following configuration management.

ISO Configuration Management Guide for Engineers: A Complete Roadmap

info@hermessol.com (Hermes Solution) — Tue, 18 Nov 2025 07:55:23 GMT

ISO Configuration Management Guide for Engineers: A Complete Roadmap

Hello, this is Hermes Solution.
Starting this week, we are launching a new series for engineers preparing for ISO certifications — a practical and easy-to-follow guide to Configuration Management (CM).

Configuration Management is a core requirement across major industry standards such as:

ISO 26262 (Functional Safety)
ISO 42001 (AI Management System)
ISO/SAE 21434 (Automotive Cybersecurity)
ISO 9001 (Quality Management)

If you are new to ISO standards, you may often wonder:

“What exactly is Configuration Management?”
“Isn’t it just version control using Git?”

This roadmap is designed to help beginners clearly understand Configuration Management from the ground up and apply it effectively in real engineering environments.

1. Understanding the Why Behind Configuration Management

Configuration Management (CM) refers to the systematic control of changes to all components — including products, software, documents, and system elements.
Before learning the standards, it is crucial to understand why such management is necessary.

What Is Configuration Management?

Let’s explain it with a simple analogy.

Imagine you are building a complex LEGO castle:

Recording which blocks are used → Configuration Identification
Asking for approval before changing a block → Configuration Control
Keeping track of who made what changes → Status Accounting
Checking if the final castle matches the design → Configuration Audit

Without CM, if 10 people freely modify the castle, the structure collapses — the same happens in software development.

Real-World Software Example

Developers modify files independently
Testers use outdated versions
The team loses track of which version is deployed

Such issues frequently lead to failures or safety incidents.
With proper CM, organizations maintain stability, traceability, and quality consistency.

2. Configuration Management vs Version Control: Key Differences

Many engineers assume CM and version control are the same, but they serve different purposes.

Category	Version Control	Configuration Management
Scope	Individual files	Entire system configuration
Focus	Tracking change history	Managing relationships among elements
Tools	Git, SVN	Jira, Confluence, ALM systems
Examples	Document v1.0 → v1.1	Requirement → Design → Code → Test traceability

Version control manages file revisions.
Configuration Management manages the entire lifecycle flow, including changes, approvals (CCB), baselines, and traceability.

In simple terms:
Version control is part of CM, while CM is a broader discipline that ensures product integrity across the entire development lifecycle.

3. Essential Terminology in Configuration Management

For beginners, these foundational CM terms are important:

Configuration Item (CI): Any managed artifact (documents, software, components)
Baseline: An approved reference version
CCB (Configuration Control Board): The group that reviews and approves changes
Traceability: Linking requirements, design, code, and tests
Change Request (CR): A formal request to update a configuration item

4. Why Configuration Management Matters: The Toyota Recall Case

A well-known example shows how CM failures lead to massive risks.

Toyota Unintended Acceleration Incident

Millions of vehicles recalled
Severe financial losses and global brand damage

NASA’s investigation found software issues and a major lack of CM, including:

No clear record of software versions installed in each vehicle
No ability to trace change history
Difficulty identifying configuration of affected vehicles

If Proper CM Had Been Implemented:

Faulty software version identified immediately
Only affected vehicles would be recalled
Costs could have dropped from trillions of won to mere billions

Configuration Management is not “just documentation”—
it is essential for safety, risk management, and product reliability.

5. The Four Core Activities of Configuration Management

According to ISO 10007 and ISO 26262, CM consists of four main activities.

1) Configuration Identification

Defines what needs to be managed
(including CI selection, naming rules, and baseline setup)

2) Configuration Control

Ensures only approved changes are applied
(Flow: CR → Impact Analysis → CCB Approval → Implementation → Verification → Baseline Update)

3) Status Accounting

Tracks real-time configuration status
(Which version is deployed? Where? When?)

4) Configuration Audit

Checks whether CM processes are followed and outputs match approved baselines

6. Tools Used in Modern CM Practices

Understanding CM tools is essential for practical implementation.

Git / SVN – version control
Jira / Confluence – change management & documentation
ALM tools (Polarion, Jama, DOORS) – requirements & traceability
Notion – collaborative document management

These tools help automate traceability, document control, and baseline management.

7. Benefits of Strong Configuration Management

Effective CM leads to:

Easier ISO certification
Higher development efficiency
Fewer defects and quality issues
Improved team collaboration
Greater customer trust
Reduced risk exposure
More predictable product releases

As technologies evolve — autonomous driving, AI systems, smart factories — CM is becoming a mandatory capability, not an optional one.

8. Configuration Management Roadmap Summary

Step 1: Understand core concepts
Step 2: Learn the four CM activities deeply
Step 3: Apply CM using tools and real workflows

Mastering CM makes ISO certification significantly easier.

Why Choose Hermes Solution?

Many companies provide ISO consulting — but Hermes Solution offers real, operational CM systems, not just documentation.

1) We Build Executable, Not Theoretical Systems

Most consultants deliver documents that aren’t used.
We design processes that developers, QA engineers, and PMs can actually apply daily.

2) Deep Experience Across Automotive, Semiconductor, and AI Industries

Our team has real field experience in highly regulated industries,
so we provide solutions that work in real engineering environments.

3) Cross-Domain Expertise (ISO 26262 + 42001 + 21434 + ASPICE)

Modern development requires integrated governance across safety, AI, cybersecurity, and quality.
Hermes Solution is one of the few firms that can support all these domains together.

4) Designed for Certification and Re-Certification

Many companies struggle when re-certification comes.
We build systems that function independently within your organization long-term.

5) Education + Consulting + Tool Integration (All-in-One)

ISO compliance requires people (training) + process (procedures) + tools (systems).
Hermes Solution provides all three in a unified approach.

Why Automotive Suppliers Should Prepare for ISO/IEC 42001 Certification Now

info@hermessol.com (Hermes Solution) — Fri, 31 Oct 2025 06:07:30 GMT

“In December 2023, the global AI industry reached a turning point with the publication of ISO/IEC 42001 certification, the world’s first AI management system standard. The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) officially published ISO/IEC 42001:2023, the world’s first AI Management System (AIMS) standard. Many global companies have already obtained the certification, and tech giants like Microsoft and AWS have begun requiring their suppliers to comply.

For automotive suppliers, this development is more than a formality. With 67% of automakers already integrating AI into their supply chains, OEMs are increasingly demanding that their partners demonstrate strong AI governance capabilities. ISO 42001 certification is no longer just a certificate — it is becoming a core competitive advantage for survival in the global automotive industry.

What Exactly Is ISO/IEC 42001?

ISO 42001 is an international management system standard designed to ensure the responsible development and operation of AI systems. Jointly developed by ISO and IEC, it can be applied to any organization that designs, develops, or uses AI — across all industries.

Unlike general management standards such as ISO 9001 (quality) or ISO 27001 (information security), ISO 42001 addresses AI-specific challenges: algorithmic bias, transparency and explainability, data quality and privacy, safety of continuously learning systems, and accountability for automated decisions.

The standard follows a clear 10-clause structure — from understanding organizational context and leadership to planning, support, operation, performance evaluation, and continual improvement. Annex A includes 38–39 concrete control measures covering data management, AI lifecycle, transparency, human oversight, and bias mitigation.

A full certification process typically takes 6–12 months: starting with a gap analysis and AI risk assessment, followed by policy development, internal audits, and a two-stage external audit. The certificate is valid for three years, with annual surveillance audits.

Importantly, ISO 42001 integrates seamlessly with existing management systems. Automotive suppliers already certified under IATF 16949 or ISO 9001 will find it efficient to align processes, as all these standards share the Annex SL High-Level Structure (HLS) framework.

How AI Is Transforming the Automotive Industry

AI has already become an integral part of the automotive value chain.

The global AI-in-supply-chain market reached $7.1 billion in 2024, and is projected to surpass $190 billion by 2034, with the automotive sector accounting for about 18%.

Quality Control: Audi uses machine-learning systems to detect micro-cracks in body panels, while Volvo Trucks partnered with SAS to cut diagnostic time by 70% and repair time by 25%.
Predictive Maintenance: BMW’s Regensburg plant uses AI to prevent over 500 minutes of assembly-line downtime annually; McKinsey reports predictive maintenance can reduce downtime by 30–50%.
Supply Chain Optimization: Toyota’s collaboration with Google Cloud saved 10,000 manual hours per year, achieving 15% lower logistics cost, 35% less inventory, and 65% higher service levels.

However, risks are escalating too. In 2024 alone, 409 automotive cybersecurity incidents were reported — 60% affecting millions of vehicles. With autonomous and connected vehicles generating up to 25 GB of data per hour, privacy and security risks are rapidly increasing.

OEMs are also reshaping supplier expectations. Renault’s AI-based digital-twin supply chain shortened its EV Twingo development cycle to 100 weeks — nearly half the previous timeline — setting new standards for supplier innovation.

Regulations are tightening as well. The EU AI Act will take effect in 2025, with high-risk AI system provisions enforced by 2027. The U.S. is expanding state-level AI laws, and major Asian economies, including Korea, are establishing their own AI governance frameworks.

Why ISO/IEC 42001 Matters for Automotive Suppliers

The automotive sector is fundamentally about safety — and AI malfunctions can cause not just quality issues, but life-threatening incidents. Modern vehicles contain over 100 million lines of code, four times that of an F-35 fighter jet. Ensuring transparency and reliability in AI-driven decision-making is now mandatory, not optional.

Complex supply chains further amplify this need. Tier 1–3 suppliers are tightly interconnected, and even a single faulty component can disrupt entire vehicle production. Every minute of line downtime costs roughly $5,000. ISO 42001 helps maintain consistent AI governance across such complex networks.

Customer requirements are also shifting fast. Microsoft’s SSPA v10 program mandates ISO 42001 certification for sensitive AI systems, and by 2028, 60% of regulated-industry AI contracts are expected to require governance certification. Companies like Synthesia — a supplier to 70% of Fortune 100 firms — have already achieved certification for that reason.

ISO 42001 also strengthens legal accountability and compliance by establishing traceable audit mechanisms that clarify responsibility for AI-based decisions. It aligns naturally with EU AI Act, ISO/SAE 21434 (cybersecurity), and ISO 26262 (functional safety).

Because it follows the same structural foundation as IATF 16949 and ISO 9001, integration is straightforward — minimizing redundancy and audit burdens while enhancing efficiency.

Most importantly, it delivers a competitive edge: early adopters achieve 35% higher contract-win rates, stronger OEM trust, and smoother global market access.

Business Value of ISO/IEC 42001 Certification

Trust & Reputation: Certified organizations report a 34% boost in consumer trust and 29% improvement in brand reputation — directly increasing client acquisition and deal success.
Cost Savings & ROI: Reduced recall and breach risk saves millions; typical ROI is achieved within 12–18 months. Deloitte estimates AI-driven quality management alone can save £200 million per year.
Market Access: Certified firms gain preferential status with OEMs and major tech partners like Microsoft, AWS, Google Cloud, and Synthesia.
Operational Efficiency: Standardized risk management reduces project uncertainty and accelerates product launches.
ESG & Talent Attraction: Certification demonstrates ethical AI leadership, appealing to ESG-minded investors and skilled professionals — as 83% of corporate boards now discuss AI risk directly.

Global Leaders Already Certified

Synthesia – First AI video company certified (Sep 2024); achieved major growth in trust and media visibility.
ORO Labs – First certified procurement platform; featured in the Gartner Hype Cycle.
AWS / Microsoft / Google Cloud – Applied ISO 42001 to core AI services (Bedrock, Copilot, Gemini), setting new industry standards.
AI Clearing / OrionStar Robotics – Manufacturers integrating ISO 42001 with ISO 9001, 27001, and 45001 for unified management systems.

The automotive parts industry is the next frontier. ISO and major certification bodies already include smart-factory, predictive-maintenance, and AI-based quality-control systems within their audit scopes.

Why Now Is the Time to Act

AI is no longer a future technology — it is today’s determinant of manufacturing competitiveness. By 2025, 96% of global manufacturers plan to expand AI investment, and 76% intend to undergo AI audits or certification within two years.

ISO 42001 is emerging not just as a compliance requirement but as a strategic language of competitiveness in the AI era. Certified companies report 35% higher contract success, 12–18-month ROI, and multi-million-dollar risk reduction. Above all, clients and partners are beginning to trust responsibly managed AI.

Global leaders — Microsoft, AWS, Google Cloud, Synthesia, ORO Labs — are already setting the bar, and OEMs are extending those expectations to their suppliers. By 2028, certification will be a standard prerequisite for most AI-related contracts in regulated sectors.

For automotive suppliers, the choice is clear:
Adopt ISO 42001 now and lead as an early mover — or lag behind under customer pressure later. Establishing an AI inventory, performing gap analysis, and implementing a governance roadmap over the next 6–12 months will define your competitiveness for the next decade.

If IATF 16949 and ISO 9001 laid the foundation for quality, ISO/IEC 42001 now defines the future of AI governance.
Technology evolves rapidly — but the demand for responsible and transparent AI does not.

Begin that transformation with Hermes Solution today.

The The Two Pillars of Automotive Safety: How ISO/SAE 21434 Threats Link to ISO 26262 Hazard

info@hermessol.com (Hermes Solution) — Thu, 23 Oct 2025 02:13:01 GMT

Hello, this is Hermes Solution.
This week’s blog explores the two core pillars of automotive safety: cybersecurity (ISO/SAE 21434) and functional safety (ISO 26262).
In today’s automotive industry, cybersecurity and functional safety can no longer be treated as separate disciplines. As vehicles become increasingly connected and autonomous, cyberattacks are evolving from simple data breaches into direct threats to human life.

As of 2024, more than 95% of vehicle cyberattacks are executed remotely, revealing a new class of risks introduced by connectivity and wireless interfaces.

This article explains how “Threats” (under ISO/SAE 21434) and “Hazards” (under ISO 26262) are interrelated and why both standards must be addressed together throughout the vehicle development lifecycle.

ISO/SAE 21434: Understanding “Threats” from a Cybersecurity Perspective

ISO/SAE 21434 defines the automotive cybersecurity management framework across the entire vehicle lifecycle—from concept and design to production, operation, and decommissioning.

A Threat is defined as a potential malicious act that could cause harm to a system or organization.
For example, if an attacker infiltrates an ECU (Electronic Control Unit) or communication channel and manipulates data or injects false control commands, they could directly influence steering or braking functions—transforming a cybersecurity issue into a safety incident.

Core Elements of a Cybersecurity Threat

Intentionality: The threat originates from a deliberate, malicious human act—not accidental system failure.
Attack Path: The route an attacker takes to reach the target system.
Example: External Network → Gateway ECU → Internal CAN Bus → Braking ECU
Attack Feasibility: Difficulty of execution based on required time, skill, equipment, and access.
Asset: Anything that must be protected, such as ECUs, communication channels, encryption keys, or firmware code.
Vulnerability: Weaknesses that an attacker could exploit, such as poor encryption, faulty authentication, or open ports.

ISO/SAE 21434 evaluates threats based on the CIA Triad:

Confidentiality – Prevent unauthorized data access
Integrity – Ensure data and functions cannot be modified arbitrarily
Availability – Ensure the system operates when needed

The required protection level is expressed as CAL (Cybersecurity Assurance Level, 1–4):

Level	Risk Level	Assurance Level	Typical Security Measures	Example Systems
CAL 1	Low	Basic protection	Access control, basic authentication	Infotainment, diagnostic ports
CAL 2	Medium	Standard protection	Encrypted communication, logging, user authentication	OBD interface, vehicle gateway
CAL 3	High	Advanced protection	Intrusion detection, integrity checks	ECU-to-ECU communication, OTA update system
CAL 4	Very High	Multi-layered defense	HSM, key protection, intrusion prevention	Braking/steering ECUs, ADAS control systems

ISO 26262: Understanding “Hazards” from a Functional Safety Perspective

ISO 26262 addresses risks caused by malfunctioning E/E systems in vehicles.
A Hazard refers to a potential source of harm resulting from system malfunction or random hardware/software failure.

While cyberattacks are intentional, hazards are unintentional—arising from faults such as sensor failure, logic errors, or unstable power supply.

HARA: Hazard Analysis and Risk Assessment

ISO 26262 uses three key parameters:

Severity (S): Potential level of harm
Exposure (E): Likelihood of encountering the situation
Controllability (C): Driver’s ability to control or mitigate the situation

Combining these factors yields the ASIL (Automotive Safety Integrity Level), ranging from A to D, with D representing the highest integrity level.
Example: Brake failure at highway speed → ASIL D

Fundamental Differences Between Threats and Hazards

Aspect	ISO/SAE 21434 (Threat)	ISO 26262 (Hazard)
Cause	Intentional malicious attack	Random system fault
Nature of Risk	Adaptive adversary	Statistically predictable failure
Assessment	TARA (Impact × Attack Feasibility)	HARA (Severity × Exposure × Controllability)
Integrity Level	CAL 1–4	ASIL A–D
Time Dynamics	Continuously evolving	Relatively static
Focus	Unknown, emerging attacks	Known failure modes

In essence, Threats intentionally disrupt system operation, while Hazards result from unintentional malfunctions.
However, they are not independent—a cyber threat can become a safety hazard.

How a Threat Becomes a Hazard

Modern research confirms that cyberattacks can trigger safety incidents:

Sensor Data Manipulation: Tampering with radar or camera signals leads to misperception and potential collision.
ECU Control Override: Attackers inject commands that alter braking or steering behavior.
Communication Interference: Disruption of V2V messages causes cooperative driving systems to malfunction.

These cybersecurity threats can escalate into functional safety hazards under ISO 26262, posing immediate physical risks.

Real-World Example: Remote Brake System Attack

In a controlled test, researchers exploited vulnerabilities in a telematics ECU via a 5G network, gaining access to the in-vehicle CAN bus.
They successfully sent forged braking commands, causing the car to stop abruptly without driver input.

Assessment by Standards:

Attack Feasibility: Medium (Skilled attacker within ~1 month effort)
Severity (S): S3 – Life-threatening potential
Exposure (E): E4 – Highway driving is common
Controllability (C): C3 – Driver cannot react
→ ASIL D

This experiment demonstrates how a single cybersecurity breach can directly lead to a functional safety failure—proving that security equals safety.

Comparing TARA and HARA Methodologies

Item	TARA (ISO/SAE 21434)	HARA (ISO 26262)
Target	Cyber threats	System malfunctions
Key Factors	Impact × Attack Feasibility	Severity × Exposure × Controllability
Outcome	Cybersecurity goals + CAL	Safety goals + ASIL
Frequency	Continuous (upon new vulnerabilities)	Event-driven (upon design changes)
Evaluation	Semi-quantitative	Qualitative

Both are preventive analyses—TARA anticipates human-driven attacks, whereas HARA models system-driven failures.

Toward Integration: The Rise of HATARA

The industry is now embracing HATARA—an integrated approach combining HARA + TARA to jointly evaluate threats and hazards within one framework.
This unified process aligns ASIL and CAL levels for consistent risk management.

Advantages:

Eliminates duplicate analysis
Ensures consistency between safety and security requirements
Reduces project cost and lead time
Enables holistic system-level risk control

Conclusion: Safety and Security Must Converge

Modern vehicles are software-defined, network-connected systems, making isolated management of safety and security impossible.
A security breach can instantly create a safety risk, merging the two domains in practice and lifecycle management.

The automotive industry is already adopting HATARA and STPA-SafeSec methodologies to unify these disciplines.
Ultimately, the ability to integrate ISO/SAE 21434 and ISO 26262 will determine the reliability and trustworthiness of future mobility systems.

Key Takeaways

Cybersecurity threats are intentional; functional safety hazards are unintentional.
In reality, a single threat can evolve into a hazard.
ISO/SAE 21434 and ISO 26262 must be implemented in tandem.
HATARA will likely become the industry’s de facto standard.
Safety without security is impossible.

This article was prepared by Hermes Solution to emphasize the importance of integrated automotive safety and cybersecurity management.
Hermes continues to provide expert insights on ISO/SAE 21434, ISO 26262, and AI-driven vehicle safety systems.
Design the future of safe mobility with Hermes.

Functional Safety and Cybersecurity in Autonomous Ships

info@hermessol.com (Hermes Solution) — Fri, 12 Sep 2025 03:13:04 GMT

Autonomous Shipping Revolution: Are We Truly Ready?

Functional safety and cybersecurity in autonomous ships are no longer optional—they are the foundation of the autonomous shipping revolution.

Autonomous ships are no longer science fiction.
Japan plans to deploy 250 AI-powered cargo vessels by 2025, while China has positioned smart ships as a core of its “Made in China 2025” strategy.
Global players such as Rolls-Royce, Kongsberg, and Google are leading commercial unmanned-ship projects, and Korean giants HD Hyundai and Samsung Heavy Industries are accelerating development of autonomous navigation solutions and even unmanned combat ships.

This technology promises dramatic cost savings, higher efficiency, and fewer human errors.
Analysts estimate that an autonomous ship can save about USD 7 million in crew and fuel costs over a 25-year life cycle.
Yet the real question remains:

“Can we prove that a vessel will stay safe and secure under the harshest, most unpredictable conditions?”

The Role of Functional Safety and Cybersecurity in Autonomous Ships

Two Pillars: Functional Safety and Cybersecurity

To answer this question, we must understand two interdependent concepts.

Functional Safety

A commitment that a system will operate as intended—even during malfunctions or unforeseen events—so that catastrophic accidents are prevented.

Cybersecurity

The ability to stop external attackers from hijacking or manipulating a system to force dangerous actions.

These are not separate concerns. Functional safety and cybersecurity are the twin pillars that support the survival, legal defensibility, and public acceptance of autonomous shipping.
If one collapses, the other quickly follows.

Why It Matters Now

Many companies are racing to market, placing speed ahead of safety and security.
History shows the danger: in the early IoT era, security was an afterthought, leading to costly failures.
With billions of dollars in assets—and lives—at stake, designing for functional safety and cybersecurity from day one is the only path to sustainable innovation.

First Pillar: Functional Safety in a Crew-Free World

Functional safety is not just about smooth sailing on calm seas.
The true test is whether a vessel can withstand internal faults or environmental failures—even without malicious attacks.

Example:
An autonomous ship performing a complex port-docking maneuver suddenly loses satellite communication with its shore control center.
The vessel cannot simply stop. To avoid collisions, it must follow a pre-defined fail-safe protocol and autonomously reach a safe position.
Because external rescue is slow at sea, self-directed safety measures are critical.

Another scenario: heavy fog degrades LiDAR sensors, GPS signals drop out, and radar data conflicts with electronic chart information.
A human navigator would cross-check data and choose the best action.
An autonomous system must achieve the same resilience through advanced sensor-fusion algorithms, preventing either decision paralysis or catastrophic choices based on corrupted inputs.

The global standard IEC 61508 provides a structured answer.
It requires identifying every potential hazard early in development, assigning quantitative Safety Integrity Levels (SILs), and enforcing rigorous design and validation so a company can confidently state:
“Our system meets internationally certified SIL 3 safety.”

Second Pillar: Expanding Cyber Threat Surface

Modern vessels are floating data centers where IT and OT (operational technology) systems converge.
High-speed satellite links and marine LTE keep ships permanently connected—creating an irresistible target for cyber criminals and state-sponsored attackers.

Among many threats, GPS spoofing is especially dangerous:

MSC ANTONIA Grounding (May 2025):
Near Jeddah, Saudi Arabia, a massive container ship ran aground.
Analysts traced the likely cause to GPS spoofing, where average false-position “jumps” skyrocketed from 600 km in late 2024 to 6,300 km in early 2025.
Persian Gulf Tanker Collision (June 2025):
Two tankers collided and caught fire. AIS records showed one vessel “sailing” across impossible inland terrain—another clear sign of GPS manipulation.

These incidents prove that data manipulation—not data theft—is the gravest threat.
Hackers need not break into navigation controls; altering the external data that autonomous algorithms trust is enough to steer a ship onto rocks while the system believes it is acting safely.

The international IEC 62443 standard provides the cybersecurity blueprint.
It applies Defense-in-Depth architecture, segmenting systems into logical zones and conduits so any breach remains contained.
It also mandates a Secure Development Lifecycle, embedding security from the earliest design stage.

When Cybersecurity Failure Becomes a Safety Disaster

Real-world accidents show that functional safety and cybersecurity are inseparable.
A single vulnerability can nullify years of safety engineering:
malware in the navigation system (cybersecurity failure) leads directly to a collision (functional-safety failure).

This reality demands a new paradigm: Digital Seaworthiness.
In the 21st century, a ship is truly seaworthy only when it can withstand both internal malfunctions and external cyber attacks.

Risk Category	Conventional Ships	Autonomous Ships
Navigation Error	Human fatigue, poor judgment	Algorithm errors, corrupted sensor data, GPS spoofing
System Control	Mechanical failure, operator mistake	Remote hijacking, cascading software faults, IT/OT breaches
Situational Awareness	Bridge team observation, radar, VHF	Sensor-fusion failure, lost communications, data-integrity attacks
Security	Piracy, stowaways, sabotage	Ransomware, network intrusion, malicious data injection
Core Weakness	Human fallibility	System complexity and hyper-connectivity

How to Achieve Functional Safety and Cybersecurity in Autonomous Ships

Navigating the New Regulatory and Financial Seas

Functional safety and cybersecurity are not just technical challenges—they are business imperatives shaped by regulation, insurance, and legal liability.

Regulatory Wave:
The International Maritime Organization (IMO) has set a clear roadmap for Maritime Autonomous Surface Ships (MASS):

- 2025 – Voluntary code adopted
- 2032 – Mandatory code enters into force
  The International Association of Classification Societies (IACS) already requires new builds to meet cybersecurity standards (UR E26/E27).
Insurance and Liability:
When a crew-less ship causes an accident, who is responsible—owner, AI developer, remote-operation center, or sensor maker?
Insurers are becoming cautious and will demand objective proof of digital seaworthiness.
Vessels documented to meet IEC 61508 and IEC 62443 will obtain coverage at reasonable rates, while non-compliant ships risk denial or sky-high premiums.

South Korea’s pending Autonomous Ship Development and Commercialization Act even proposes mandatory liability insurance and penalties for non-compliance.

Strategic Investment for Competitive Advantage

Proactive investment in functional safety and cybersecurity is not a cost—it is a competitive edge.
Companies that demonstrate digital seaworthiness will:

Win regulatory approvals faster
Secure favorable insurance terms
Earn the trust of cargo owners and the market

Organizations that treat the IMO’s 2025 voluntary code as a de-facto design standard today will dominate the market as regulations tighten, while late adopters face expensive retrofits and legal fallout from the first major precedent-setting accidents.

Securing a Safe and Secure Voyage

The full potential of autonomous shipping becomes reality only when functional safety and cybersecurity are built in from the very start.
Speed of innovation alone will turn the future into a sandcastle.

The solution is a Safety-and-Security-by-Design approach—integrating both pillars into every phase:
concept design, software architecture, hardware selection, and operational protocols.

Standards IEC 61508 and IEC 62443 provide proven roadmaps not just for what to implement, but how to embed safety and security throughout development.

The challenges of the autonomous era are complex, but with the right expertise, strategic insight, and collaborative approach, they are solvable.
The goal is not to slow innovation but to enable resilient, sustainable innovation.

To achieve true Digital Seaworthiness, companies need new forms of partnership and leadership—combining maritime operations, cutting-edge technology, international regulation, and strategic risk management.

Are you ready to embark on this new era of shipping leadership—with Hermes Solution as your trusted partner?

ASPICE 4.0 Guide: Compliance Isn’t Everything – Real Business Value for Automotive Software

info@hermessol.com (Hermes Solution) — Thu, 28 Aug 2025 06:12:31 GMT

Is Passing the ASPICE Assessment Enough? The Real Value You Might Be Missing

If you are an automotive software developer—or have ever worked on a related project—you’ve probably felt the weight of the word ASPICE. OEM compliance requirements, upcoming assessments, and an ever-growing pile of work products can make ASPICE feel less like a framework and more like a mountain to climb.

Sometimes, after long nights filling out templates and producing documents, you may wonder:

“Are we doing all this just to pass the assessment?”

If that question has ever crossed your mind, read on. Beyond compliance, ASPICE delivers real, long-term value for your team and your product.

ASPICE 4.0 in 2025: What’s New?

The release of ASPICE 4.0 in December 2023 brought significant opportunities—especially for small and mid-sized mobility companies. With the March 31, 2025 transition deadline approaching, resource-limited teams can now compete more fairly with industry giants.

Key updates include:

AI & Machine Learning Processes (MLE.1–MLE.4)
ASPICE now officially covers ML-based development, enabling structured validation of “black box” AI systems—crucial for autonomous driving and ADAS.
Hardware Engineering Processes (HWE.1–HWE.4)
EV battery management systems (BMS), power electronics, and charging infrastructure are now fully recognized within ASPICE.
More Flexible Assessment Model
With a revamped VDA scope, initial implementation effort is cut by about 50%. Teams can begin with just the Basic Part and one Domain-Specific Part, making ASPICE adoption more practical for startups.

Numbers That Prove the Value of ASPICE

Research shows that ASPICE-compliant companies detect 90% of defects 11 months before product launch, while non-compliant companies often find them just 2 months prior.

The impact is clear:

9 months of additional time to resolve critical issues
Reduced warranty costs and recall risks
Stronger customer trust and higher product quality
20% lower development costs through process efficiency
30% faster time-to-market via early issue detection
50% fewer post-release defects after Level 2 certification

Why Do We Still See ASPICE as Just “Compliance”?

For most organizations, ASPICE adoption is driven by customer requirements or project eligibility. The immediate goal becomes “achieving the level,” not transforming how the team works.

This target-driven approach often leads to a dangerous trap: producing documents for the sake of the audit while forgetting the “why” behind the process.

The Hidden Value Beyond the Assessment

A Common Language Across the Team
ASPICE defines clear expectations for every activity and work product. This eliminates misunderstandings such as one engineer’s “design complete” being just a mental sketch while another expects full documentation.
Reducing Dependence on “Star Developers”
Without ASPICE, projects may collapse when a key developer leaves. ASPICE builds bridges between “islands of knowledge,” creating a structured system that anyone can follow.
Traceability for Faster Problem Solving
Bugs in automotive software can become safety risks. ASPICE enforces end-to-end traceability from requirements → design → code → test. This creates a map for quickly locating the root cause, rather than relying on guesswork and late-night debugging.

Real Success Story: EDAG Embedded Systems

Team size: Small development team
Timeline: 2 years
Strategy:
- 2-week sprints with Agile + ASPICE in parallel
- Jira + Confluence automation
- GitLab version control

Result: Achieved ASPICE Level 2 while maintaining consistent customer delivery

Tools for Small and Mid-Sized Companies

Codebeamer ALM – Pre-built ASPICE templates, no coding required, customizable for SMEs (87% satisfaction)
Polarion ALM – Best-in-class traceability, permanent license + 20% annual maintenance
Open-source options – ASPICE-Archi repository, GitHub/GitLab integration, AI-based documentation tools reducing manual effort by 40–50%

Integration is key: Seamless links with GitHub, GitLab, and Azure DevOps allow automated Jira issue creation, vulnerability scanning, and ASPICE-compliant traceability.

EVs & Autonomous Driving: Why ASPICE 4.0 Matters

EV Battery Systems: Companies like Qnovo (98.7% prediction accuracy), Breathe Battery Technologies (30% faster charging + 33% longer battery life), and Texas Instruments (wireless BMS) have demonstrated ASPICE-compliant innovation.
Autonomous Driving: New MLE processes provide structured validation for black-box AI and support continuous learning, making ADAS and AV development more reliable.

ROI: The Business Case for ASPICE

Initial investment includes:

ASPICE consulting and gap analysis
Training for engineers, testers, PMs
Formal ASPICE assessments
Assigning process owners/quality managers
Adopting ALM tools like Jira, Polarion, or Codebeamer

Payback period: 12–24 months, thanks to reduced defect-fixing costs, lower warranty risks, and faster market entry.

Hidden benefits:

Direct access to premium OEM contracts (Level 2+ is often mandatory)
Continuous learning and improvement culture
Competitive advantage—ASPICE-compliant firms resolve issues on average 9 months faster than rivals

ASPICE Implementation Roadmap

Immediate: Complete ASPICE 4.0 training, conduct gap analysis, select key domains (SYS, SWE, HWE, MLE)
6–12 months: Reach Level 1, establish documentation practices, adopt ALM tools, schedule quarterly consultant reviews
18+ months: Scale to Level 2/3, integrate cybersecurity (SEC) and validation (VAL) processes, build internal audit capabilities, and embed ASPICE into the daily way of working

Final Thoughts

ASPICE is not just a regulatory burden—it’s a growth engine for automotive software. By 2030, the automotive software market will reach $32.3 billion, with 90% of vehicle differentiation coming from software.

ASPICE 4.0, with its flexible assessment model and AI/ML processes, opens doors even for small teams. With the right strategy, tools, and partner support, achieving Level 2 in 18–24 months is realistic.

At Hermes Solution, we help teams transform ASPICE from a “compliance checklist” into a strategic foundation for sustainable growth.

What does ASPICE’s real value mean for your team?

Automotive Semiconductor Cybersecurity: UN R155, ISO/SAE 21434, TARA, HSM

info@hermessol.com (Hermes Solution) — Thu, 21 Aug 2025 05:58:53 GMT

1. Paradigm Shift in Automotive Semiconductor Cybersecurity

Today, cars are no longer simple mechanical devices. Whereas vehicles once relied mainly on engines and mechanical parts, they have now become IT platforms on wheels centered on numerous ECUs and software. As connected cars and autonomous driving proliferate, vehicles are continuously linked to external networks via wireless communication, offering new conveniences to drivers and passengers.

This connectivity, however, simultaneously creates new opportunities for attackers. In the past, hacking a vehicle typically required direct access via the OBD-II port; now, remote attacks are possible through wireless channels such as cellular, Wi-Fi, and V2X. Attackers can even target specific models at scale and threaten critical control functions like braking or steering. Consequently, cybersecurity at the semiconductor level is no longer optional—it is essential.

2. Regulatory Environment and Its Industry Impact

In response, strong regulations have emerged across the global automotive industry. Chief among them is UN R155, which since 2022 has been a mandatory condition for new-vehicle type approval in major markets such as Europe, Japan, and Korea. This regulation requires OEMs to establish a Cybersecurity Management System (CSMS) and to manage threats throughout the vehicle lifecycle.

A notable characteristic is that the regulation does not target only OEMs. Through a “regulatory cascade” across the supply chain, semiconductor companies must also certify their own security processes to participate in the market. In other words, cybersecurity has been elevated from an individual feature to a criterion for business eligibility in the automotive sector.

In parallel, the international standard ISO/SAE 21434 has been introduced. If UN R155 defines what must be done, ISO/SAE 21434 explains how to do it. It provides a framework for managing cybersecurity across the entire vehicle lifecycle—from design to decommissioning— guiding organizations to perform security activities suited to their products through a risk-based approach rather than prescribing specific technologies.

3. The Role of TARA (Threat Analysis and Risk Assessment)

A core activity in ISO/SAE 21434 is TARA. Rather than merely listing threats, TARA systematically analyzes which assets may be attacked, the potential impacts if an attack succeeds, and the likelihood of success.

TARA Workflow

Step	Key Activities	Deliverables
Asset Identification	Catalog data, functions, and resources that must be protected	Asset inventory
Threat Scenarios	Derive threats using methods such as STRIDE	Threat scenario list
Impact Assessment	Analyze impacts on safety, financials, operations, and privacy	Impact ratings
Attack Path Analysis	Define the steps an attacker could take	Attack path diagrams
Likelihood Assessment	Evaluate time, knowledge, equipment, and opportunity	Likelihood ratings
Risk Determination	Assess risk = impact × likelihood	Risk register
Risk Treatment	Decide on mitigation, avoidance, transfer, or acceptance	Cybersecurity goals

Through this process, organizations move beyond the vague notion that “security is needed” to concretely identify which functions must be protected and what technical measures are required.
For example, if TARA confirms that an attacker could manipulate the CAN bus to control the steering ECU, a corresponding cybersecurity goal would be: “Unauthorized messages must be blocked.” During development, this goal is then decomposed into implementable requirements.

Thus, TARA serves as the compass for security development and underpins all subsequent activities.

4. The Need for a Secure Development Lifecycle (SDLC)

In the past, security was often added after development, but retrofitting vulnerabilities late in the process incurs far greater time and cost. The Secure Development Lifecycle (SDLC) addresses this by integrating security from the earliest stages—often referred to as a shift-left approach.

Requirements: Reflect TARA outcomes as explicit security requirements
Design: Apply principles such as least privilege and defense-in-depth
Implementation: Follow safe coding standards (e.g., MISRA C) and use static analysis tools
Testing: Employ fuzzing and penetration testing to uncover unforeseen vulnerabilities
Post-release: Maintain OTA updates, vulnerability management, and incident response

Security does not end at vehicle launch. New threats must be addressed via OTA, and vulnerability/incident processes must be operated continuously. In short, SDLC is a lifecycle-long approach to managing cybersecurity.

5. Hardware Root of Trust and HSM

Security cannot rely on software alone. Software can contain bugs and is susceptible to physical attacks. Therefore, ensuring security at the semiconductor level requires a Hardware Root of Trust (RoT).

This role is provided by the Hardware Security Module (HSM), which creates an isolated security domain within the chip to securely store cryptographic keys, accelerate cryptographic operations, and support secure boot so that only trusted code runs at startup.

Not every ECU requires the same security level. The EVITA project classifies HSMs into three tiers: Full, Medium, and Light. Gateways and V2X modules that interface with external networks should use Full HSM; internal domains such as powertrain and chassis can adopt Medium; and simple ECUs for sensors/actuators can use Light. This approach balances cost and performance.

6. Security Strategies of Leading Semiconductor Companies

The automotive semiconductor cybersecurity market is led by a few global players.

Overview Table

Company	Key Products	Security Features	Strengths
N Corp	S32G, EdgeLock	“4+1” security framework; HSE built-in	ISO/SAE 21434 process certification
I Corp	AURIX TC4x	EVITA Full HSM; integrated functional safety & security	First to obtain ISO/SAE 21434 certification
R Corp	RH850, R-Car	Scalable ICU-HSM	TÜV-based CSMS operations

N Corp proposes a “4+1” security framework that provides layered defense from external vehicle communications to internal ECU security. The S32G processors integrate an HSE security engine enabling secure boot, key management, and accelerated network security, while the EdgeLock portfolio delivers security services across the device lifecycle.

I Corp is well known for its AURIX microcontroller series, meeting both functional safety and cybersecurity requirements and being the industry’s first to secure ISO/SAE 21434 process certification. With EVITA Full HSM on-chip, it enables secure key management and cryptographic acceleration.

R Corp offers scalable solutions centered on RH850 MCUs and R-Car SoCs, applicable across diverse ECUs. Its in-house ICU-HSM supports secure boot, communication security, and software update security, with reliability reinforced by a TÜV-certified CSMS.

7. Strategy Going Forward

Automotive semiconductor cybersecurity is no longer a technical option but a baseline requirement for market participation. Compliance with UN R155 and ISO/SAE 21434 is essential, supported by TARA-based risk analysis, SDLC-driven security by design, and hardware-anchored protections such as HSM.

Without close collaboration among OEMs, Tier-1 suppliers, and semiconductor companies, survival in the market will be difficult. In the future, semiconductors without built-in security will have no place, and semiconductor-level security will be both the starting point of vehicle cybersecurity and a core competitive advantage.

Conclusion

Automotive semiconductor cybersecurity has become a core determinant of competitiveness across the industry, going beyond mere regulatory compliance or safety assurance. UN R155 and ISO/SAE 21434, TARA-based risk analysis, SDLC integration, hardware roots of trust, and the latest security solutions from leading semiconductor companies are all part of the same goal: delivering safe and trustworthy future vehicles.

Hermes Solution walks this path with you—helping organizations navigate complex regulations and technical demands. Beyond basic compliance, we partner with you to build tangible cybersecurity capabilities and become a leader in the era of future mobility.

ISO/IEC 42001 for Automotive AI: A Practical Guide for Tier 1/2 Suppliers

info@hermessol.com (Hermes Solution) — Thu, 14 Aug 2025 06:39:20 GMT

AI Innovation and a New Era of Responsibility in the Automotive Industry

Cars are no longer just means of transportation. With the emergence of Software-Defined Vehicles (SDVs), artificial intelligence (AI) is no longer a future technology—it has already become the core of the automotive industry.

From Advanced Driver Assistance Systems (ADAS) and autonomous driving to enhancing in-vehicle user experiences, predictive maintenance, and manufacturing process innovation, there is no area untouched by AI.

However, this innovation comes with new challenges. AI’s inherent unpredictability and opacity create risks that cannot be addressed by traditional quality and safety management methods alone. Issues such as data bias, algorithm uncertainty, and performance degradation are prime examples.

Amid these changes, one international standard is attracting attention—ISO/IEC 42001, the Artificial Intelligence Management System (AIMS). This is not merely a regulation but a strategic framework for developing and operating AI safely and responsibly. Just as the automotive industry has long managed quality and risks through standards such as ISO 9001 and IATF 16949, AI governance will become the key to future competitiveness.

In particular, Tier 1 and Tier 2 suppliers should adopt this standard proactively. OEMs will expand AI management requirements across their supply chains, and compliance with ISO/IEC 42001 will determine future business opportunities.

Understanding ISO/IEC 42001 AIMS: What It Is and Why It Matters

Definition and Objectives
ISO/IEC 42001 is the international standard for establishing, operating, and improving an Artificial Intelligence Management System (AIMS).
Its goal is to ensure responsible and ethical use of AI, manage AI-specific risks such as bias, opacity, and security vulnerabilities, and secure transparency and trustworthiness.

Why Prepare for AIMS Certification Now?

Competitive Advantage: Signals to OEMs and the market that you meet the highest AI governance standards.
Risk Management: Proactively addresses AI bias, data security, and algorithm vulnerabilities.
Trust Building: Enhances trust and brand image with customers and regulators.
Operational Efficiency: Systematizes data, roles, and responsibility management.
Regulatory Readiness: Prepares for evolving global regulations such as the EU AI Act.

Standard Structure and Core Requirements

ISO/IEC 42001 is based on the PDCA (Plan-Do-Check-Act) structure, similar to ISO 9001 and IATF 16949, making integration with existing quality and safety standards straightforward.

Clause	Core Requirement	Automotive Industry Example
Organizational Context	Identify AI-related internal/external issues and stakeholder needs, define scope	Analyze OEM strategies, regulations, and tech trends; define products/processes under AIMS
Leadership	Executive commitment, policies, clear roles/responsibilities	CEO/CTO announces “Responsible AI Policy” and assigns departmental leads
Planning	Identify risks/opportunities, set AI objectives	“Reduce pedestrian detection bias by 15% in Q4”
Support	Resources, training, documentation	Train developers/data scientists; manage data/model documentation
Operation	AI risk/impact assessment, control implementation	Privacy impact analysis for driver monitoring; apply Annex A controls
Performance Evaluation	Monitoring, measurement, internal audit	Check accuracy/bias metrics, operate independent audit team
Improvement	Continual improvement, corrective actions	Root cause analysis, retraining, data enhancement

ISO/IEC 42001 Certification Roadmap for Tier 1/2 Suppliers

Step 1: Preparation and Planning

Leadership & Team Formation: Secure top management support; involve R&D, quality, IT, legal, HR.
Scope Definition: Decide whether to include only products (e.g., ADAS module) or also manufacturing AI.
Gap Analysis & Awareness Training: Compare current processes with standard requirements; train employees on roles/responsibilities.

Step 2: System Development and Execution

AI Policy & Objectives: Set measurable goals (e.g., “100% traceability of training datasets”).
Risk & Impact Assessments:
- Impact Assessment (8.4): Analyze potential societal and personal impacts (e.g., privacy).
- Risk Assessment (8.2): Identify AI-specific risks (data, models, security, ethics).
Control Implementation: Apply Annex A/B procedures for data management, lifecycle, stakeholder communication.
Documentation: Maintain required documents (policies, assessment results, training records).

Step 3: Evaluation and Certification

Internal Audit & Management Review: Validate operational compliance and performance before reporting to executives.
Corrective Actions: Investigate nonconformities and implement prevention measures.
External Audit: Pass document and on-site audits to obtain certification.

Integrating ISO/IEC 42001 with Existing Quality and Safety Systems

When combined with IATF 16949, ISO 26262, and ISO/SAE 21434, ISO/IEC 42001 maximizes its impact—integrating quality, safety, and security activities into one governance system to prevent duplication and omissions.

IATF 16949 (Quality): Extend FMEA to include AI-specific failure modes (bias, noise, poisoning, hallucination, overfitting, adversarial attacks). Incorporate AIMS risk/impact results into APQP and control plans.
ISO 26262 & ISO 21448 (SOTIF, Functional Safety): Address malfunction and insufficient performance risks. Apply Annex B.6 (AI lifecycle integration) and B.7 (data scenario coverage, bias removal, completeness).
ISO/SAE 21434 (Cybersecurity): Link TARA threat analysis with AIMS risk assessment. Include data integrity, model robustness, security-by-design, and secure OTA processes.

ASPICE and ISO/IEC 42001 Integration: Enhancing AI Development Maturity

ASPICE evaluates automotive software development maturity. The new ASPICE for Machine Learning adds AI-specific processes:

MLE.1: ML Requirements Analysis
MLE.2: Architecture Design
MLE.3: Training
SUP.11: Data Management

AIMS provides the “what” and “why” of AI governance, while ASPICE for MLE defines the “how.” Running a mature AIMS naturally supports achieving higher ASPICE for MLE capability levels, ensuring AI quality, safety, and trustworthiness throughout the lifecycle.

Table 2: Integration Management Points Between Key Automotive Standards and ISO/IEC 42001 (continued)

Automotive Standard	Core Processes / Tools	Related ISO/IEC 42001 Clauses	Integrated Implementation and Considerations
IATF 16949	FMEA / Risk-based Thinking	8.2 AI Risk Assessment, 8.4 AI System Impact Assessment	Add AI-specific failure modes (bias, data drift, adversarial attacks) to existing FMEA. Reflect AI impact assessment results in the Severity (S) scoring of the FMEA.
ISO 26262 / ISO 21448 (SOTIF)	HARA / SOTIF Analysis / Safety Assurance	Annex B.6 AI System Lifecycle, Annex B.7 AI Data Management	Include HARA and SOTIF analysis in formal procedures. Ensure scenario coverage and completeness in data management.
ISO/SAE 21434	TARA / Cybersecurity Assurance	8.2 AI Risk Assessment, Annex A.2.6 Information Security	Integrate TARA threats (model inference, adversarial attacks) into AI risk assessment. Include controls for data integrity, model confidentiality, and availability in information security policies.
Automotive SPICE (ASPICE)	Software Development Process Assessment	Overall AIMS processes (especially Clause 8, Annex B)	Link AIMS operational processes to ASPICE for MLE requirements. Avoid duplication of documentation and work products, and improve process maturity.

AI Era: The Time to Act Is Now

AI is now an unstoppable force in the automotive industry. ISO/IEC 42001 is designed to balance AI’s risks and opportunities in increasingly complex technical environments. It is not merely a regulatory shield but a strategic tool for embedding a trustworthy AI culture into your organization and turning it into a competitive advantage.

For Tier 1 and Tier 2 suppliers, now is the time to start—from raising executive awareness to conducting process gap analyses. In fast-changing technological transitions, companies that adopt standards first will become industry leaders and preferred OEM partners.

Hermes Solution is ready to help you move beyond survival to achieve sustainable growth in the AI era.

AI-Powered Anomaly Detection Systems: Building the Future of Automotive Security

info@hermessol.com (Hermes Solution) — Fri, 08 Aug 2025 01:37:22 GMT

The modern automotive industry is at the core of digital transformation. With the rise of Software-Defined Vehicles (SDVs), cars have evolved from simple mechanical transport machines to complex "computers on wheels." While this shift opens up endless possibilities, it also introduces unprecedented cybersecurity threats.

The Security Reality of the SDV Era

Connected Cars on the Rise
According to the Korea Automobile & Mobility Association (KAMA), as of March 2023, South Korea had over 7.08 million registered connected cars—representing 27.6% of all vehicles. In other words, more than one in four cars on Korean roads is exchanging data through external networks. While this connectivity enables smartphone-like convenience, it also introduces new vectors for cyberattacks. Car hacking no longer requires physical access; it can happen remotely, even without the driver's awareness.

Escalating Cyber Threats
A report by Upstream Security highlighted a 165% year-over-year increase in dark web and deep web activity related to the automotive ecosystem in 2023. One major incident involved a well-known EV manufacturer, where an API vulnerability exposed data from over two million vehicles across 130 countries. Hackers exploited this to track vehicle locations and unlock cars remotely—posing real-world safety risks.

Multi-layered Threat Landscape

In-Vehicle Network Threats: Malicious messages injected into the CAN (Controller Area Network) bus can tamper with essential functions like braking and steering.
ECU and Hardware Threats: Reverse engineering or firmware hacking of ECUs (Electronic Control Units) can result in control hijacking or installation of counterfeit ECUs.
External Interface Threats: Interfaces like Wi-Fi, Bluetooth, and OBD-II ports are potential intrusion points, especially when third-party apps are involved.
Backend Server Threats: A compromised backend server could impact millions of vehicles simultaneously, spreading malware through OTA updates.

The Fundamental Limits of Traditional Security Systems

Issues with Signature-Based IDS
Much like antivirus software, these systems rely on known attack "signatures." They're accurate for familiar threats, but powerless against zero-day exploits. They also require constant updates, making them slow to adapt to emerging attacks.

Early Anomaly Detection Pitfalls
Early statistical anomaly detection aimed to solve this, but often failed due to high false positives. Vehicle operating environments are highly dynamic, making rigid threshold-based models ineffective.

AI & ML-Powered Next-Generation Security

Unsupervised Learning with Autoencoders
Autoencoders are neural networks trained solely on "normal" CAN bus data. They learn hidden structures and relationships. When fed abnormal input, reconstruction errors spike, flagging potential threats.

Time-Series Pattern Analysis with LSTM
LSTM (Long Short-Term Memory) models are ideal for sequential CAN data. By learning the rhythm and timing of messages, they can detect deviations caused by intrusions in real time.

Hybrid Architecture for Robust Detection
Combining autoencoders and LSTM provides holistic defense. Autoencoders detect relational anomalies, while LSTM catches sequential disruptions. Together, they offer a robust, complementary system.

Practical Implementation in Vehicles

Edge AI for Real-Time Detection
Safety-critical systems require millisecond-level responses. Cloud-based AI causes latency, whereas Edge AI enables on-board processing with no delay—essential for emergency scenarios.

Federated Learning for Privacy
To protect privacy while training powerful models, Federated Learning sends models (not data) to vehicles. Each car trains locally and sends results to a central server for global model updates—preserving user privacy.

Explainable AI (XAI) for Trust
Deep learning models can be black boxes. XAI methods like LIME or SHAP make decisions understandable—showing which CAN IDs or signals influenced detection. This builds analyst confidence and enables incident investigation.

Meeting Global Compliance Standards

Understanding UN R155 & ISO/SAE 21434
These regulations are mandatory in major markets like the EU, Japan, and Korea. UN R155 became mandatory for all new vehicles from July 2024. Compliance is not optional.

Key Requirement: Cybersecurity Management System (CSMS)
Manufacturers must monitor and respond to threats throughout a vehicle's lifecycle—even post-sale. This includes anomaly detection, incident response, and vulnerability management.

AI-IDS as a Compliance Enabler
AI-IDS allows scalable, real-time monitoring across millions of vehicles. It turns static documentation into dynamic, field-driven compliance. By automating detection, evaluation, and reporting, manufacturers can satisfy UN R155 and ISO/SAE 21434 requirements.

The Road Ahead for Automotive Security

Securing V2X Communication
As Vehicle-to-Everything (V2X) becomes mainstream, securing communication itself becomes critical. 5G-based security architectures will play a vital role.

Predictive Threat Intelligence
AI will evolve to predict threats before they happen, using adaptive models and real-time data.

Security by Design
AI will help embed security into vehicle design from the outset, ensuring ongoing verification and monitoring.

Keys to a Successful AI-Based Security System

A successful production-grade AI-IDS is more than a great algorithm. It requires:

Edge AI for real-time processing
Federated Learning for scalability and privacy
Explainable AI for transparency and trust

All this must work within the constraints of limited onboard computing resources and strict real-time demands.

Automotive cybersecurity must shift from reactive to proactive. In the SDV era, anomaly detection isn't a luxury—it's a necessity. AI and ML aren't just supporting tools; they are the foundation of future-proof, resilient mobility.

Hermes Solution is your strategic partner to ensure your next-generation vehicles are the safest, most compliant, and most resilient to emerging threats. Contact us today to explore how our AI-powered cybersecurity solutions can turn your vision into reality.

ISO 26262 Essential Guide: Automotive Safety Architecture with FMEA & FTA

info@hermessol.com (Hermes Solution) — Tue, 29 Jul 2025 02:52:15 GMT

Hello, everyone leading the future of mobility! This is Hermes Solution. Have you ever thought that cars these days are like “moving smartphones”? In the past, sturdy machines were the best, but now cars have become sophisticated systems that run on hundreds of millions of lines of software code. Especially with the increase in smart features such as ADAS and autonomous driving, the importance of invisible software has grown even more.

But here's the crucial question: what if even a small error occurs in such a system? A simple navigation error might be cute, but errors in steering or braking systems could lead to truly terrifying accidents. That's where the ISO 26262 international standard for automotive functional safety comes in.

This standard goes beyond being a technical guideline; it has become an essential requirement for survival in today's automotive industry. It serves as a “common language” for OEMs and suppliers to trust and collaborate with each other within the global supply chain. Failing to comply with ISO 26262 could result in missed business opportunities, costly recalls, or damage to corporate image, making it a core risk management strategy beyond mere technology.

This post will serve as a comprehensive guide to mastering FMEA (Failure Mode and Effects Analysis) and FTA (Fault Tree Analysis), the core analysis techniques of ISO 26262. This knowledge is essential for anyone interested in safe automotive development!

The Heart of Automotive Safety: A Comprehensive Look at ISO 26262 and ASIL

To effectively apply ISO 26262, it is essential to first understand its core concepts. The standard follows the V-model development process, with the ASIL risk rating system at the center of all safety activities.

Safety Lifecycle (V-Model): The Beginning of Systematic Safety Design

ISO 26262 structures the development process like the letter V. The left wing represents the development stages from planning to design and implementation, while the right wing represents the verification and validation stages to ensure that all these stages function correctly. This ensures that safety requirements from the early stages of development are perfectly tracked and verified all the way to the final product.

Key Concept: Automotive Safety Integrity Level (ASIL) - A Measure of Risk

ASIL is at the core of ISO 26262's risk-based approach. In simple terms, it is a rating system that determines “how safe it needs to be” based on the severity of potential risks.

Quick note: Don't misunderstand! ASIL is not a rating for the component itself. While it is often referred to as an “ASIL D microcontroller,” this means that the component has the capability to be used in a system that requires ASIL D level. The actual ASIL rating depends on the risk caused when the component fails in a specific function.

Example: Even if it's the same front camera, the safety requirements needed for rear parking assistance (low risk, ASIL B) and autonomous emergency braking (very high risk, ASIL D) are totally different, right? So, remember that ASIL is a “context-dependent” requirement for functions!

Three golden keys for determining ASIL

ASIL ratings are determined by comprehensively evaluating the following three factors:

Severity (S): How serious could the injury be if a hazard occurs? (S0: No injury ~ S3: Death/life-threatening)
Exposure (E): How often are you exposed to the hazard? (E0: Almost none ~ E4: Very high)
Controllability (C): How well can the driver control the situation when the risk occurs? (C0: Easy to control ~ C3: Difficult/impossible to control)

The combination of these three factors determines the final ASIL rating (A, B, C, D). ASIL D represents the highest risk and requires the most stringent safety measures. QM (Quality Management) is assigned when the risk is classified as unrelated to functional safety and follows general quality management.

<Table 1: ASIL Determination Matrix>
S0, E0, and C0 ratings are generally resolved by QM, so they are omitted from the table.

From bottom to top! Complete mastery of Failure Mode and Effects Analysis (FMEA)

Once the ISO 26262 safety objectives are set, the next question is, “How will failures occur and what impact will they have?” The powerful technique used here is FMEA!

FMEA: A “bottom-up” analysis that examines every corner of the system

FMEA is a systematic technique that starts with individual components (hardware, software) to thoroughly identify all possible failure modes and analyze the impact of these failures on the system and ultimately on the vehicle. It is a mandatory activity strongly recommended for all ASIL ratings!

How to perform FMEA!

Teamwork is important!: FMEA is a team activity involving design, manufacturing, and quality experts. It should not be performed formally after development is complete, but rather as a “living document” that is repeatedly performed from the early stages of design to prevent problems in advance.
FMEA Worksheet: Key Items
- Item/Function: The component or function to be analyzed (e.g., front camera)
- Potential Failure Mode: How could it fail? (e.g., “Image data stops”)
- Potential Impact of Failure: What would happen if it failed? (e.g., “Causes lane departure”)
- Severity (S): Severity of the final impact (1–10 points)
- Potential Cause of Failure: Why might it fail? (e.g., “Software deadlock”)
- Occurrence (O): Likelihood of the cause occurring (1–10 points)
- Current Control Measures: Methods to prevent or detect failure (e.g., watchdog timer)
- Detectability (D): The likelihood of detecting the failure (1–10 points; note that higher values indicate greater difficulty in detection!)

Prioritizing risks: Beyond RPN to Action Priority!

FMEA uses the formula RPN (Risk Priority Number) = S × O × D to quantify risk. The higher the RPN, the more urgent the need for improvement of the high-risk factor.

However, simply looking at the RPN number is not enough. Even if the RPN is low, failures with very high severity (S) must be managed as a top priority. Therefore, recent FMEA has introduced the concept of “Action Priority” to prioritize severity first. Remember that the true value of FMEA lies not in the RPN number, but in the process itself where the team discusses and analyzes high-risk events first!

FMEA Actual Case: Front Camera Module for LKA

Item: Front Camera Module for LKA System
Failure Mode: Camera continuously outputs frozen images
Impact: LKA system operates inaccurately, causing lane departure (Severity S=9)
Cause: Software deadlock in the camera's internal processor (Occurrence O=3)
Detection Management Measures: Watchdog timer in the image processing ECU monitors frame updates (Detection D=2)
RPN: 9 × 3 × 2 = 54

(This value is used to determine the priority of improvement measures by comparing it with the RPNs of other failure modes.)

From top to bottom! Complete analysis of fault tree analysis (FTA)

While FMEA is a “bottom-up” approach that starts with small parts, FTA is a “top-down” analysis that looks at the entire system.

FTA: A ‘Deductive’ Analysis to Find the Root Cause of the Problem

FTA is a technique that starts with a specific system failure (‘top event’) and logically identifies all possible root causes (‘basic events’) that could lead to that failure. It is particularly essential for systems requiring high safety levels, such as ASIL C and D.

How to Create a Fault Tree!

Top Event: The starting point of the analysis! It must be a clearly defined system failure state, such as “unintended steering torque exceeding X Nm for more than Y ms.”

Logic Gates: Symbols showing the relationships between events.
- AND Gate: All input events must occur simultaneously for the result to appear. (Complex failure modeling)
- OR Gate: The result appears when any one of the input events occurs. (Individual cause modeling)
Intermediate and Basic Events: The process of breaking down the top event into multiple intermediate events, which are then broken down into basic events (component failure, software error, human error, etc.) that cannot be further decomposed.

Qualitative analysis vs. quantitative analysis

Qualitative analysis: Focuses on finding the most critical minimum cause combination (‘minimum cutset’) that triggers the upper-level event. If the cutset consists of a single basic event, it is a ‘single point of failure,’ which is a design flaw that must be eliminated in safety-critical systems!
Quantitative Analysis: Assigns failure probabilities (e.g., FIT) to each basic event to calculate the overall probability of the upper-level event occurring. This is used to demonstrate compliance with the PMHF (probabilistic metric for random hardware failures) target required for ASIL D systems.

FTA Case Study: “Unintended Steering” in the LKA System

[Upper-level event] Unintended steering occurs in the LKA system

[Intermediate event 1] Incorrect steering command from the ECU OR
- [Intermediate event 2] Damaged sensor data input OR
  - [Basic event] Camera internal defect
  - [Basic event] CAN bus communication error
- [Intermediate event 3] Software calculation error OR
  - [Basic event] Algorithm logic defect
  - [Basic Event] Memory corruption (RAM)
- [Intermediate Event 4] ECU hardware defect OR
  - [Basic Event] Microcontroller defect
  - [Basic Event] Power supply (PMIC) defect
- [Intermediate Event 5] Steering actuator malfunction OR
  - [Basic Event] Motor driver defect
  - [Basic Event] Motor defect

Integration of Analysis: Interaction between FMEA and FTA

FMEA and FTA are not simply individual analyses, but rather a pair that interact with each other to produce powerful synergy.

FMEA and FTA: Complementary Partners

These two techniques analyze problems from opposite directions and complement each other's weaknesses.

Analysis Direction: FMEA is top-down (cause → effect), while FTA is bottom-up (effect → cause).
Analysis Scope: FMEA broadly explores “all” failure modes of a specific part, while FTA deeply analyzes “one” specific failure cause.
Strengths: FMEA excels at identifying component weaknesses, while FTA is strong at analyzing failure interactions in complex systems.

FMEA provides the list of potential failure causes that FTA requires, and FTA indicates how critical these causes are to the system. Through this feedback loop, the FMEA team can focus on preventing the most critical failure modes from a system-wide perspective.

Conclusion: Safe cars are no longer a choice, but a necessity!

We have taken an in-depth look at FMEA and FTA. These two analysis techniques are not simple activities, but a process of building core evidence to prove automotive functional safety.

FMEA: Verifies that all parts are designed to be robust and that failure modes are well managed.
FTA: Verifies whether the system architecture has sufficient resilience even in the event of a critical failure.

All these analysis results are ultimately compiled into a “Safety Case,” which is used to logically prove how safe our vehicles are. This is a mandatory requirement for regulatory and certification agencies!

Beyond functional safety: SOTIF and cybersecurity!

The scope of automotive safety is expanding. Now, in addition to functional safety (ISO 26262), we must also consider SOTIF (ISO 21448), which addresses safety in unexpected situations (sensor limitations, external environments, etc.), and cybersecurity (ISO/SAE 21434), which protects systems from hacking attacks. Future automotive engineering is evolving in a direction that encompasses all three of these areas.

In conclusion, thoroughly understanding and utilizing systematic analysis techniques such as FMEA and FTA is no longer an “option” but a core competency for modern automotive engineers. The most important first step in creating safe and reliable future automobiles lies here!

I hope this article has helped you understand automotive safety architecture design. I look forward to sharing more useful information with you in the future! Thank you.