ISO 26262, IEC 61508 Functional Safety (FuSa) Services for Autonomous, Electric Automotive, Industrial, Aerospace and Defence
Our team of Functional Safety Certified Consultants have partnered with customers across US, Europe and India, to help them achieve ISO 26262 compliance (ASIL A/ ASIL B/ ASIL C/ ASIL D) and IEC81508 compliance (SIL1 / SIL2 / SIL3).
Our expertise is not only limited to automotive domain but we also have executed projects including off-highway vehicles, defence and industrial control applications. Our domain expertise spans- electric vehicle, battery management systems, electric fuse boxes, high power charge controllers, Electronic Power Steering (EPS), Telematics Solutions, Body Control Module, , Powertrain ECU, Advanced Driver Assistance Systems (ADAS), and more.
Functional Safety-Compliant Embedded Software Development Services aligned with ISO 26262 and IEC 61508
- Software Safety Requirement Specification: Specify software safety requirement specifications and safe communication protocol specification by formal language establishing traceability to TSR, hardware safety requirements, capturing attributes of safety mechanisms / diagnostic coverage, safety response time, fault tolerant time interval FTTI, diagnostic coverages
- Software Safety Design: Design safety critical software application considering ASIL Decomposition, ASIL Allocation, SeooC using UML /MBD based software architecture design and AUTOSAR architecture to meet the safety FTTI requirements.
- Safety Compliant Coding: Implement software for considering design principles of modularity, maintainability and testability and exhaustive review checklists.
- Safety Compliant Software Static Analysis: Perform static analysis and manage deviations of compliance to MISRA and internal coding standard using industry standard safety qualified tools like QAC, LDRA.
- Safety Compliant Software Dynamic Analysis : Perform dynamic analysis to achieve 100% MC/DC code coverage, fix defects and manage deviations using industry standard safety qualified tools like Vector CAST, LDRA.
- SW Safety Analysis: Perform qualitative FMEA or DFMEA Software to uncover safety related functional, technical or process related failure mode areas.
- SW Tools Qualification: Perform tool qualifications as per TCL levels for tools used across software development and test lifecycle.
- Software Configuration Management, Traceability and Release Strategy: Define guidelines for one of the most important and forgotten aspect of software development related to configuration management, forward and backward traceability and release management.
Successful Functional Safety Case Studies: Projects in Automotive (ISO 26262) and Industrial Systems (IEC 61508)
ASIL-D / SIL3 End to end Compliance for Electric Power Steering system
VerveTronics Role:
- Support for end to end ISO 26262 ASIL-D | IEC 61508 SIL3 compliance and certification
- Safety/Technical Concept and specifications ,
- Safety Analysis for System (HARA), Hardware(FMEDA), Software(FMEA) and Mechanical (FMEA)
- Safety Compliant Hardware Specifications and Assessment
- Hardware Design and development
- Safety Compliant Software Specifications, Validation and Assessment
- ASIL-D / SIL3 Process Development and Improvements
- Safety Assessment and Certifications
ASIL-B grade DC Power Converter System
VerveTronics Role:
- Safety/Technical Concept and specifications ,
- Safety Analysis for Hardware(FMEDA), Software (FMEA) and Mechanical (FMEA)
- Safety Compliant Hardware Specifications and Assessment
- Safety Compliant Software Specifications and Assessment
- Safety Assessment.
ASIL-C grade Electronics DC Protection System
VerveTronics Role:
- Support for end to end ISO 26262 ASIL-C compliance
- Safety/Technical Concept and specifications ,
- Safety Analysis for Hardware(FMEDA), Software (FMEA) and Mechanical (FMEA)
- Safety Compliant Hardware Specifications and Assessment
- Safety Compliant Software Specifications and Assessment
- ASIL-C / ASPICE Process Development and Improvements
- Safety Assessment
Team
Our consultants have experience developing safety critical electrical/electronic systems in a range of vehicle domains including powertrain, chassis, steering and braking systems, and more recently in hybrid/electric vehicles and Advanced Driver Assistance Systems (ADAS).
We have proven our expertise of our Functional Safety Consultants in Complex ISO 26262 (ASIL D/ ASIL C) Automotive projects and IEC 61508 (SIL 3 / SIL2 ) Industrial Projects.
We care about what we do!
Functional Safety Software Engineering Services
Functional Safety Software Engineering for safety-critical embedded systems across automotive, industrial, robotics, energy, semiconductor and other regulated applications. VerveTronics supports software teams from software safety requirements and architecture through implementation, static and dynamic analysis, unit/integration verification, testing, traceability and assessment readiness.
Our engineering-led approach connects the safety concept and technical safety requirements to executable software. We translate system and hardware safety requirements into software safety requirements, software architecture, safety mechanisms, diagnostics, timing behavior and verification objectives, while maintaining bidirectional traceability throughout the development lifecycle.
For automotive programs, ISO 26262 Part 6 defines the software-level product-development framework, including software safety requirements, software architectural design, unit design and implementation, unit verification, software integration and verification, and embedded-software testing. ISO 26262-6:2018 remains the current published edition, while a third-edition draft is under development.
IEC 61508-3 provides software requirements for safety-related software and addresses lifecycle activities, software safety functions and systematic capability.
- Translating technical safety requirements into precise, testable software safety requirements.
- Designing software architecture that supports the required safety integrity, fault detection and fault reaction behavior.
- Maintaining traceability from safety goals and TSR/HSR through software requirements, architecture, implementation and verification.
- Managing ASIL/SIL allocation and decomposition across software components and interfaces.
- Designing safety mechanisms that detect faults within the required FTTI and produce the intended safe-state or degraded-state response.
- Developing safety-critical code while controlling complexity, unintended behavior, interface defects and systematic faults.
- Achieving required structural coverage and MC/DC evidence for applicable safety-critical software.
- Managing static-analysis findings, coding-rule deviations and justified exceptions without weakening the safety argument.
- Qualifying or assessing development and verification tools where required by the applicable safety lifecycle.
- Controlling configuration, change impact, baselines, releases and evidence across evolving software programs.
- Integrating safety software with hardware, AUTOSAR platforms, operating systems, communication stacks and third-party components.
- Demonstrating objective verification evidence rather than relying only on code review or nominal functional testing.
Software Safety Requirements Engineering
What: Software requirements must implement the allocated safety requirements and be sufficiently precise for design and verification.
How: Derive software safety requirements from TSR/HSR, define safety mechanisms, diagnostic behavior, timing, interfaces, fault reactions and verification criteria, and maintain forward/backward traceability.
Safety-Oriented Software Architecture
What: The architecture must control systematic faults and support the required safety behavior.
How: Define safety partitions, components, interfaces, supervision, monitoring, communication safeguards, error handling, timing constraints and HW/SW interactions. Use UML, model-based techniques or AUTOSAR architecture where appropriate.
ASIL/SIL Allocation and Decomposition
What: Safety integrity requirements may be allocated across software elements or decomposed under the applicable standard and architectural constraints.
How: Establish allocation assumptions, independence requirements, interface constraints and verification evidence. Do not treat ASIL and SIL as interchangeable; the applicable standard and safety lifecycle determine the integrity framework.
SEooC and Reusable Safety Software
What: Reusable software components need defined assumptions, safety requirements and integration constraints.
How: Develop or review SEooC-oriented safety requirements, assumptions of use, interfaces, safety mechanisms, verification evidence and integration responsibilities.
Safety-Critical Coding
What: Implementation must minimize systematic faults and remain consistent with the approved architecture and requirements.
How: Apply project coding standards such as MISRA where applicable, modularity, defensive programming, deterministic behavior, controlled complexity, peer review and automated static analysis.
Static and Dynamic Verification
What: Safety software requires multiple complementary verification techniques.
How: Combine requirements review, architecture analysis, code review, static analysis, unit testing, integration testing, fault injection and structural coverage. For applicable high-integrity software, MC/DC evidence is planned against the project’s verification objectives rather than treated as a standalone compliance checkbox.
Safety Mechanisms, Diagnostics and FTTI
What: Software must detect and react to relevant faults within the safety timing constraints.
How: Specify monitoring, plausibility checks, watchdog supervision, communication monitoring, memory checks, state monitoring, timeout handling and fault-reaction logic, then verify detection and reaction timing against FTTI requirements.
Tool Qualification and Confidence
What: Development and verification tools can influence safety evidence when their outputs are relied upon.
How: Identify relevant tools, assess their use and impact, and support the applicable tool qualification/confidence activities and evidence.
Configuration, Traceability and Release
What: Safety evidence can become unreliable if software baselines and relationships between artifacts are not controlled.
How: Establish requirements/configuration management, version control, change impact analysis, bidirectional traceability, release criteria and reproducible verification evidence.
Software Safety Requirements
- Software Safety Requirements Specification (SSRS)
- Derivation of software requirements from TSR/HSR
- Safety mechanism and diagnostic requirements
- Fault reaction and safe-state behavior
- FTTI and timing requirements
- Safe communication requirements
- Hardware-software interface requirements
- Requirements traceability and verification criteria
Software Safety Architecture
- Safety-oriented software architecture
- ASIL/SIL allocation and decomposition support
- UML and model-based software architecture
- AUTOSAR-oriented safety architecture
- Software partitioning and freedom-from-interference considerations
- Safety mechanisms and supervision
- Communication and interface safety
- SEooC architecture and assumptions of use
Safety-Critical Software Development
- Embedded safety software design and implementation
- Modular and maintainable software architecture
- Safety-compliant coding practices
- MISRA C / MISRA C++ compliance support
- Defensive programming and error handling
- Low-level driver and application software safety support
- Safety-oriented state machines and diagnostics
- Code review and software quality controls
Static Analysis & Coding Compliance
- Static analysis planning and execution
- MISRA compliance analysis
- Defect identification and remediation
- Deviation and justification management
- Complexity and coding-rule analysis
- Tool configuration and analysis baseline management
- Safety-relevant warning review
Software Verification & Testing
- Software unit verification
- Unit and integration test development
- Requirements-based testing
- Boundary and robustness testing
- Fault injection
- Dynamic analysis
- Structural coverage analysis
- Statement, branch and MC/DC coverage where applicable
- Software integration verification
- Regression testing
- Verification traceability and evidence
Software Safety Analysis
- Software FMEA / SW FMEA
- Software failure-mode analysis
- Interface and dependency analysis
- Fault propagation analysis
- Safety mechanism effectiveness analysis
- Diagnostic coverage considerations
- Dependent-failure and common-cause considerations where applicable
- Safety analysis support for software architecture and implementation
Tool Qualification & Safety Lifecycle Support
- Tool qualification planning and evidence support
- Tool confidence assessment
- Development and verification tool assessment
- TCL-oriented activities where applicable
- Software configuration management
- Requirements and change management
- Traceability management
- Release and baseline strategy
- Safety case and assessment evidence preparation
Typical deliverables can include Software Safety Requirements Specifications, software architecture specifications, HSI/interface specifications, safety mechanism specifications, software FMEA, coding standards/checklists, static-analysis reports, unit/integration test specifications, coverage reports, traceability matrices, tool-assessment evidence, configuration/release procedures and assessment evidence packages.
- ASIL-D / SIL3 Electric Power Steering & Vehicle Control
- VerveTronics supported a European Tier-1 program involving ISO 26262 / IEC 61508 ASIL-D / SIL3 end-to-end concept-to-assessment/certification support for a premium passenger-car application. The existing project scope includes safety/technical concepts and specifications, system/HARA, hardware FMEDA, software FMEA, safety-compliant software specifications, software validation and assessment, process development and improvement.
- ASIL-B DC Power Converter System
- VerveTronics supported a European Tier-1 supplier on an ASIL-B DC power converter program. The documented role included safety/technical concept and specifications, hardware FMEDA, software FMEA, mechanical FMEA, safety-compliant software specifications and assessment, and safety assessment.
- ASIL-C Electronics DC Protection System
- VerveTronics supported a US Tier-1 supplier on an ASIL-C electronics DC protection system. The documented role included end-to-end ISO 26262 support, safety/technical concept and specifications, hardware FMEDA, software FMEA, mechanical FMEA, safety-compliant software specifications and assessment, ASIL-C/ASPICE process development and improvements, and safety assessment.
- These case studies are retained from the existing VerveTronics page and should be presented as representative project experience rather than as a claim that every activity applies to every engagement.
- Automotive: EV, BMS, powertrain, EPS, braking, steering, ADAS, body control, telematics, domain/zonal controllers and vehicle control ECUs.
- Industrial: safety controllers, automation, drives, power electronics, machine control and critical monitoring.
- Robotics & AMR/AGV: safety-related embedded control, motion control, sensing and supervisory software.
- Energy & Electrification: BMS, battery protection, inverters, DC-DC converters and charge-control software.
- Semiconductors: safety software for MCU/SoC platforms, safety IP, diagnostics and safety verification.
- Off-Highway & Agricultural: safety-related electronic control software and machine-control applications.
- Aerospace & Defence: safety-critical embedded software within applicable development-assurance frameworks.
- Medical and other safety-critical systems: safety-oriented embedded/software engineering within the applicable product and regulatory framework.
- Fixed-Scope Software Safety Work Package – requirements, architecture, static analysis, software FMEA, coverage or verification.
- Dedicated Safety Software Engineering Team – engineers integrated with the customer’s software organization.
- End-to-End Safety Software Development – requirements → architecture → implementation → verification → assessment readiness.
- Independent Software Safety Review – architecture, requirements, code, analysis, traceability and verification evidence.
- Gap Assessment & Remediation – identify gaps against the applicable safety standard and provide closure actions.
- Assessment Readiness Support – organize software safety work products, traceability and verification evidence for independent assessment.
- What is Functional Safety Software Engineering? – It is the engineering of safety-related software so that allocated safety requirements, safety mechanisms, fault reactions and verification objectives are implemented and supported by objective lifecycle evidence.
- What does ISO 26262 Part 6 cover? – ISO 26262-6:2018 covers automotive product development at the software level, including software safety requirements, software architecture, unit design and implementation, unit verification, software integration and verification, and embedded-software testing.
- Is ISO 26262-6:2018 still current? – Yes. ISO currently lists ISO 26262-6:2018 as the published edition and says it was last reviewed and confirmed in 2024. A third-edition ISO/DIS 26262-6 is currently under development and is intended to replace the 2018 edition.
- What is the difference between software safety requirements and functional requirements? – Functional requirements describe intended product behavior. Software safety requirements describe the safety-related behavior allocated to software, including constraints, monitoring, diagnostics, fault reactions and timing necessary to implement the applicable safety requirements.
- Can VerveTronics develop safety-critical software? – Yes. The existing VerveTronics page describes software safety requirements, architecture, coding, static analysis, dynamic analysis, software safety analysis, tool qualification, configuration management, traceability and release strategy as service areas.
- Do you support AUTOSAR? – Yes. The existing service scope specifically includes AUTOSAR-oriented safety software architecture.
- Do you support MISRA compliance? – Yes. The existing page includes static analysis and MISRA deviation management using tools such as QA-C and LDRA.
- Do you support MC/DC testing? – Yes. The existing page describes dynamic analysis with MC/DC coverage using tools including VectorCAST and LDRA. The exact coverage target should be established from the applicable safety standard, project requirements and verification strategy.
- Do you support IEC 61508 software safety? – Yes. IEC 61508-3 is specifically concerned with software forming part of a safety-related system and establishes software safety lifecycle requirements and requirements for systematic capability.
- Do you support ISO 13849 software? – Yes, where software forms part of the safety-related control system. The applicable software development and validation approach should be determined from the ISO 13849 architecture, performance-level requirements and the specific safety function.
- What tools can you work with? – The existing VerveTronics page identifies QA-C and LDRA for static analysis and VectorCAST and LDRA for dynamic analysis. Other tools can be accommodated according to the customer’s toolchain, project constraints and applicable safety process.
- Can you perform Software FMEA? – Yes. Software FMEA / DFMEA is part of the existing Functional Safety Software service scope and is also reflected in the documented ASIL-D, ASIL-B and ASIL-C case studies.
- Can you support software assessment and certification readiness? – Yes. VerveTronics can support software safety evidence, gap assessment, traceability and assessment readiness. Formal independent certification or assessment, where required, is performed by the applicable recognized/accredited organization.
- Can you integrate with our existing software development team? – Yes. The page is designed around flexible engineering work packages, dedicated safety engineers, independent reviews and end-to-end software safety development support.
- Do you support ASIL C and ASIL D software? – The existing VerveTronics project material documents ASIL-C and ASIL-D automotive experience and ASIL-D/SIL3 software specifications, validation and assessment activities.