The Software and Systems Engineering Experts
US: +1 (610) 247-9595 / EU: +48 666 74 71 74
Home · Solutions · Automotive
Solutions · Automotive
Automotive engineering with audit-ready traceability
ISO 26262, ASPICE and ISO/SAE 21434 evidence from one connected IBM Engineering Lifecycle Management (ELM) toolchain, set up by consultants who work with tier-1 suppliers.
Automotive
The automotive sector
Vehicles are now software products
The automotive sector covers vehicle manufacturers (OEMs) and the supply chain behind them: tier-1 suppliers that build complete systems such as braking, steering or infotainment, and tier-2 suppliers of components, chips and software. Each vehicle program runs for years, involves hundreds of suppliers and ships in many markets and variants.
Value is moving from mechanics to electronics and software. Functions that used to be hardware, from braking assistance to battery management, are now defined in code and keep changing after the car leaves the factory.
ShiftSoftware-defined vehicle
Features are delivered and updated in software, including over the air.
ShiftCentralized E/E architecture
Many ECUs are consolidated into domain and zone controllers running software of mixed criticality.
ShiftADAS and automated driving
Perception and decision functions take safety analysis beyond classic failures (SOTIF).
ShiftElectrification and connectivity
Battery systems, charging and connected services add new safety and cybersecurity exposure.
Engineering challenges
What this means for software and systems engineering
System complexity
Requirements are spread across systems, software, electronics and mechanics. Without a model and links between them, nobody sees the whole vehicle function.
Development across company boundaries
Specifications flow from the OEM to tier-1 and tier-2 suppliers and back. Every handover is a place where changes and context get lost.
Safety and security by design
ISO 26262 and ISO/SAE 21434 require hazards and threats to be analysed up front and traced to requirements, design and tests.
Variants and product lines
One platform serves many models, markets and customers. Reuse only works when variants are managed, not copied.
Change after start of production
Software updates continue for years. UN R156 requires a software update management system and evidence for every release.
Process capability
OEMs select and audit suppliers against Automotive SPICE. The evidence has to come out of daily work, not be assembled before the assessment.
What assessors expect
Where automotive teams lose time before an assessment
Safety requirements, HARA and test reports sit in Word and Excel. Before each assessment someone rebuilds the links by hand.
Requirements arrive from the OEM in Requirements Interchange Format (ReqIF) or as spreadsheets. When they change, nobody knows which models and tests are affected.
Each platform and customer variant gets its own copy of the specification, and the copies drift apart release by release.
RiskAn ASPICE finding on SYS.2 or SWE.1 traceability delays the SOP.
With Smarter ProcessWork products are linked in the tool. The trace for SYS.2 and SWE.1 is a saved view, not a spreadsheet.
RiskTests pass against an outdated requirement.
With Smarter ProcessSuspect links flag every model and test that depends on a changed OEM requirement.
RiskThe same fix has to be made five times.
With Smarter ProcessOne specification, reused across variants through global configurations.
Compliance map
ISO 26262, ASPICE and ISO/SAE 21434, mapped to the toolchain
Pick a standard to see what it asks for, and where it lives in your toolchain once we have set it up.
ISO 26262 · Part 3, clause 6
IBM Engineering Requirements Management DOORS Next
What it asks forHazard analysis and risk assessment with safety goals and an ASIL for each
How we cover itHARA module template, ASIL attribute, safety goals linked to hazardous events
IBM Engineering Requirements Management DOORS NextISO 26262 · Part 8, clause 6
IBM Engineering Requirements Management DOORS NextIBM Engineering Test Management
What it asks forSafety requirements specified, managed and traced in both directions
How we cover itSafety requirement types with link rules; suspect links flag every change
IBM Engineering Requirements Management DOORS Next
IBM Engineering Test ManagementISO 26262 · Part 8, clauses 7–8
IBM Engineering Lifecycle Management Global Configuration ManagementIBM Engineering Workflow Management
What it asks forConfiguration and change management of all work products
How we cover itGlobal configurations and baselines per release; change requests linked to items
IBM Engineering Lifecycle Management Global Configuration Management
IBM Engineering Workflow ManagementISO 26262 · Part 6, clauses 9–11
IBM Engineering Test ManagementHCL DevOps Test
What it asks forSoftware unit, integration and embedded testing linked to requirements
How we cover itTest plans and results traced to software requirements; coverage view
IBM Engineering Test Management
HCL DevOps TestASPICE · SYS.2, SWE.1
IBM Engineering Requirements Management DOORS Next
What it asks forRequirements analysis with consistency and bidirectional traceability
How we cover itTrace views and link validity across system and software modules
IBM Engineering Requirements Management DOORS NextASPICE · SUP.8, SUP.10
IBM Engineering Workflow ManagementGitLab
What it asks forConfiguration management and change request management
How we cover itStreams, baselines and change sets tied to work items
IBM Engineering Workflow Management
GitLabISO/SAE 21434 · Clause 15 (TARA)
IBM Engineering Requirements Management DOORS NextIBM Engineering Test Management
What it asks forThreat scenarios, risk values and cybersecurity goals
How we cover itTARA templates; cybersecurity goals linked to requirements and tests
IBM Engineering Requirements Management DOORS NextIBM Engineering Test ManagementUN R155 · CSMS, type approval
IBM Engineering Lifecycle Optimization – Publishing
What it asks forEvidence that the cybersecurity management system is applied to the vehicle type
How we cover itGenerated evidence documents from live IBM Engineering Lifecycle Management data
IBM Engineering Lifecycle Optimization – PublishingBook a 30-min compliance gap review
Compliance is achieved by your organization and confirmed by your assessor or authority. Tools hold the evidence; we set them up so the evidence is complete and easy to show.
Capabilities
What your team can do on day one
Variants without copy-paste
Global configurations reuse one specification across platforms and customers. Each variant keeps its own baseline and change history.
- IBM Engineering Lifecycle Management Global Configuration Management
HARA and safety goals in one module
Hazardous events, ASIL and safety goals live next to the requirements they produce. A change to a hazard flags every linked requirement and test.
- IBM Engineering Requirements Management DOORS Next
ReqIF round-trip with your OEM
Import customer specifications, comment on them and send them back without losing history or links to your own system requirements.
- IBM Engineering Requirements Management DOORS Next
ASPICE evidence on demand
Traceability, review records and test coverage come out of the tools as reports, so preparing for an assessment takes days rather than weeks.
- IBM Engineering Lifecycle Optimization – Publishing
- IBM Engineering Test Management
Models linked to requirements
System and software architecture in SysML, with every block traced to the requirement it satisfies and the test that checks it.
- IBM Engineering Systems Design Rhapsody
Cybersecurity next to safety
TARA, cybersecurity goals and requirements use the same links and reviews as functional safety, ready for ISO/SAE 21434 audits.
- IBM Engineering Requirements Management DOORS Next
See every product we implement and support
IBM Engineering Lifecycle Management, HCL and GitLab: licences, set-up, training and support from one team.
All products →
ECU test bench
Case studyBury Technologies: requirements and tests in one IBM Engineering Lifecycle Management toolchain
How an automotive supplier connected IBM Engineering Requirements Management DOORS Next and IBM Engineering Test Management so that ASPICE assessors see one trace from customer requirement to test result.
One toolchainfor requirements and tests
ReqIFexchange with OEMs
Reportsfor ASPICE assessments
“Our assessors now see the trace in the tool, not in a spreadsheet we built the week before.”Engineering lead, Bury Technologies (quote to confirm)
Learn more
Training, articles and services
Training
Introduction to IBM Engineering Requirements Management DOORS Next
AI requirements management for regulated industries
Tech Blog
AI requirements management for regulated industries
Service
IBM Engineering Requirements Management DOORS (9.x) to IBM Engineering Requirements Management DOORS Next migration
FAQ
Questions automotive teams ask us
How do we qualify IBM Engineering Lifecycle Management under ISO 26262-8 clause 11 without qualifying every feature?
Qualification follows your use cases, not the product. For each use case (for example, baselining safety requirements or reporting test coverage) you set tool impact and error detection to get a TCL. Many requirements and test use cases reach TCL1 because reviews and suspect links catch tool errors. Where a higher TCL remains, we prepare the validation tests and the known-issues review for your IBM Engineering Requirements Management DOORS Next, IBM Engineering Test Management and IBM Engineering Systems Design Rhapsody versions, and repeat them at each upgrade.
Our OEMs use different tools and ReqIF dialects. How do we keep round trips clean?
We set up one exchange definition per OEM: attribute and enumeration mapping, the OEM identifier kept as a read-only attribute, and the scope of each export. Each OEM delivery is imported into its own module and compared with the previous baseline, so you see exactly what changed and suspect links flag the affected system requirements. Before the first live exchange we run a test round trip with the OEM, including rich text, tables and deleted objects.
How do we manage platform and customer variants without drowning in streams?
We design the component and stream structure before migrating anything: shared platform components, customer-specific components only where content really differs, and IBM Engineering Lifecycle Management Global Configuration Management configurations that combine them per program. Small differences stay as attributes and views rather than new streams. Change sets and baselines per release keep each variant auditable, and we agree on deliver and merge rules so that a fix reaches every variant that needs it.
We have years of IBM Engineering Requirements Management DOORS (9.x) data, link modules and DXL. What happens to them?
Modules, attributes and links move to IBM Engineering Requirements Management DOORS Next with the original IDs kept, link modules become link types, and the history you need for audits is preserved as baselines. DXL is inventoried first: most scripts are replaced by configuration, views or SmarterProcess widgets, and the rest are rewritten in JavaScript or OSLC. We migrate in waves with a short parallel run and give you a reconciliation report per module, so nothing is lost silently.
Do we have to replace Atlassian Jira or GitLab, and how do they stay part of the trace?
No. Developers keep working in Atlassian Jira and GitLab. We link issues, merge requests and pipeline results to requirements and tests through OSLC or a synchronization connector, depending on whether you need live links or copied records. Change requests then appear in impact analysis and ASPICE traceability reports alongside the rest of the evidence, without asking developers to change tools.
How do ISO/SAE 21434 and UN R155 evidence live alongside functional safety?
In the same project, with separate artifact types and link rules. TARA results, threat scenarios and cybersecurity goals link to the same system requirements, architecture and tests as the safety goals, so one change triggers both safety and security impact analysis. IBM Engineering Lifecycle Optimization – Publishing templates produce the cybersecurity case and the work products a type approval authority asks for under UN R155 from the same baselines.
New · SmarterWidgets 2.0
Ready-made widgets for IBM DOORS Next
Add them to the ELM Mini Dashboard and hand repetitive requirements work over to them. Each one previews its changes first.
Browse all widgets- Content qualityClean text and glossary linksStyle Cleaner, Link Checker and more
- Links and traceabilityFix, move and inspect linksLink Remover, Module To Base Links and more
- Module structureBuild and repair module hierarchyModule Fill, Module Explorer 2.0 and more
- Configuration and governanceBaselines, data models and auditsBaseline Archiver, Compare Data Models and more
- Reporting and publishingCharts, maps and publishingPublishing URLs, Module Insights and more
- See all widgetsScreenshots and details for every widget
Watch and learn
Our Videos
Demos, tutorials and customer stories on requirements, traceability and test.
Talk to our consultants
Leave your details and we will get back to you, usually within one business day.
