The Software and Systems Engineering Experts
US: +1 (610) 247-9595 / EU: +48 666 74 71 74
Home · Solutions · Electronics & Semiconductors
Solutions · Electronics & Semiconductors
Chips and electronics with customer‑ready safety evidence
ISO 26262-11 and EU Cyber Resilience Act evidence from one connected IBM Engineering Lifecycle Management toolchain, set up by consultants who work with electronics and semiconductor engineering teams.
Electronics & Semiconductors
The electronics and semiconductor sector
Safety and security now start in the chip
The sector covers semiconductor companies, fabless chip designers, IP vendors and electronics manufacturers that build boards, modules and control units. Their customers are carmakers and their suppliers, aircraft programs, industrial automation and consumer products, each with its own standards and audits.
More of a product's safety and security now depends on the chip, its firmware and its configuration. Customers expect requirements, safety analyses and verification evidence delivered with the part, and kept current through every revision.
ShiftSafety elements out of context
Chips are developed for markets, not single projects, with assumed safety requirements that each customer later checks against its own system.
ShiftFirmware as part of the product
Boot code, drivers and security firmware ship with the hardware and are updated in the field, so hardware and software share one life cycle.
ShiftCyber Resilience Act
From 11 December 2027 products with digital elements sold in the EU need secure development, vulnerability handling and security updates.
ShiftChiplets and complex SoCs
Multi-die packages, IP from several vendors and configurable SoCs multiply the variants and interfaces that need requirements.
Engineering challenges
What this means for software and systems engineering
Evidence for every customer
Automotive, avionics and industrial customers ask for different safety evidence on the same part: ISO 26262, DO-254 or IEC 61508.
Hardware and firmware together
Silicon, register map and firmware requirements stay consistent only when they are linked, not copied between documents.
Product families and derivatives
One design becomes many derivatives with different packages, memory sizes and features, each needing its own baseline.
Exchange with customers and IP vendors
Customer specifications come in, assumptions of use and safety manuals go out, and third-party IP adds its own documentation.
Security by design
The EU Cyber Resilience Act and IEC 62443-4-1 ask for security requirements, threat analysis and vulnerability handling for the life of the product.
Protecting design data
Specifications and IP are valuable, so customers and partners see only the parts they are allowed to see.
What customers audit
Where electronics teams lose time before a customer audit
The chip is developed as a safety element out of context. Assumptions about the customer's system are written once in a document and not linked to the requirements they shape.
The register map lives in a spreadsheet or a generator script. Firmware requirements and drivers are updated from an old copy.
Each derivative, package or customer variant gets a copied requirements set. Fixes reach some copies but not all.
RiskThe safety manual and the design disagree, and the customer finds it in its own assessment.
With Smarter ProcessAssumptions of use are artifacts linked to the hardware safety requirements, and the safety manual is generated from the same data.
RiskA changed bit field reaches the firmware team late, after silicon or at a customer.
With Smarter ProcessThe hardware-software interface is a linked module, so a change marks dependent firmware requirements and tests as suspect.
RiskA customer receives evidence for a configuration that was never verified.
With Smarter ProcessDerivatives are streams that reuse one baseline and are compared item by item in IBM Engineering Lifecycle Management Global Configuration Management.
Compliance map
ISO 26262-11, IEC 61508 and the EU Cyber Resilience Act, 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-11 · Semiconductor as a safety element out of context
IBM Engineering Requirements Management DOORS NextIBM Engineering Lifecycle Optimization – Publishing
What it asks forHardware safety requirements developed against documented assumptions of use, which the integrator then confirms
How we cover itAssumption of use and hardware safety requirement types, linked and exported to the safety manual
IBM Engineering Requirements Management DOORS Next
IBM Engineering Lifecycle Optimization – PublishingISO 26262-11 · Hardware safety requirements and verification
IBM Engineering Requirements Management DOORS NextIBM Engineering Test Management
What it asks forHardware safety requirements traced to the design and to verification, including safety mechanism and fault injection tests
How we cover itRequirement modules linked to verification plans and results; coverage view per baseline
IBM Engineering Requirements Management DOORS Next
IBM Engineering Test ManagementISO 26262 · Hardware-software interface
IBM Engineering Requirements Management DOORS Next
What it asks forA specified hardware-software interface shared by chip and software development
How we cover itHSI module linked to hardware and firmware requirements, with suspect links on every change
IBM Engineering Requirements Management DOORS NextIEC 61508-2 · Hardware safety requirements and verification
IBM Engineering Requirements Management DOORS NextIBM Engineering Lifecycle Management Global Configuration Management
What it asks forE/E/PE hardware requirements specified, designed and verified, under configuration management
How we cover itHardware requirement modules with SIL attributes; baselines and change requests for every revision
IBM Engineering Requirements Management DOORS Next
IBM Engineering Lifecycle Management Global Configuration ManagementDO-254 · Sections 5.1 and 6.2
IBM Engineering Requirements Management DOORS NextIBM Engineering Test Management
What it asks forHardware requirements captured, validated and verified with traceability to the design
How we cover itHardware requirement modules on the same chain as firmware, with review records
IBM Engineering Requirements Management DOORS NextIBM Engineering Test ManagementEU CRA · Annex I essential requirements
IBM Engineering Requirements Management DOORS NextIBM Engineering Test Management
What it asks forSecurity requirements from a risk assessment, secure by default, and vulnerability handling for the support period
How we cover itEssential requirements as a checklist linked to product requirements, tests and technical documentation
IBM Engineering Requirements Management DOORS NextIBM Engineering Test ManagementEU CRA · Vulnerability handling
IBM Engineering Workflow ManagementIBM Engineering Lifecycle Management Global Configuration Management
What it asks forIdentify and fix vulnerabilities, and ship security updates for every product version in support
How we cover itVulnerability reports as work items linked to affected requirements, releases and tests
IBM Engineering Workflow ManagementIBM Engineering Lifecycle Management Global Configuration ManagementIEC 62443-4-1 · SR and SVV practices
IBM Engineering Requirements Management DOORS NextIBM Engineering Test Management
What it asks forSecurity requirements, a threat model and security verification and validation testing for the product
How we cover itThreat and security requirement types traced to design and to security tests, with review workflow
IBM Engineering Requirements Management DOORS NextIBM Engineering Test ManagementBook a 30-min compliance gap review
Compliance is achieved by your organization and confirmed by your assessor or customer. 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
Baselines for every derivative
Freeze a configuration for each tape-out, revision or derivative and compare it with the next one, item by item. Customers see exactly what changed and why.
- IBM Engineering Lifecycle Management Global Configuration Management
Hardware and firmware in one chain
Silicon, register map and firmware requirements are linked, so one change shows every requirement and test to recheck.
- IBM Engineering Requirements Management DOORS Next
Safety manuals from live data
Assumptions of use, safety mechanisms and verification summaries are generated from the tools, in your own templates.
- IBM Engineering Lifecycle Optimization – Publishing
- IBM Engineering Requirements Management DOORS Next
Customer exchange without retyping
Customer specifications come in and compliance statements go out through Requirements Interchange Format (ReqIF), compared with the previous delivery.
- IBM Engineering Requirements Management DOORS Next
Verification coverage per revision
Simulation, silicon validation and firmware test results link to each requirement, with a coverage view per baseline.
- IBM Engineering Test Management
Security and vulnerability handling
Threats, security requirements and vulnerability reports are linked to the releases they affect, ready for the Cyber Resilience Act.
- IBM Engineering Workflow Management
- 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 →
Validation labHow we work
We start from your hardware and firmware life cycle, not from the tool
We map ISO 26262, IEC 61508 and Cyber Resilience Act work products to artifact types, link rules and views in IBM Engineering Lifecycle Management, connect the tools your hardware and firmware teams already use, and train them on their own projects.
Life cyclemapped to artifact types and links
Derivativesas streams, not copies
Exchangewith customers and IP vendors
FAQ
Questions electronics and semiconductor teams ask us
Do we need to qualify IBM Engineering Requirements Management DOORS Next and IBM Engineering Test Management under ISO 26262-8?
Only where you rely on their output without checking it. ISO 26262-8 sets a tool confidence level from the tool's impact and the chance of detecting a tool error. Requirements and test management usually reach the lowest level, because reviews and verification catch errors. Coverage reports or generated safety manuals that you take credit for without review can raise it. We classify each use case with you and record the result in the safety plan.
Each automotive customer sends specifications in its own format. How do we answer them?
Customer specifications come in through ReqIF or document import, into a module per customer, with their IDs kept. Your compliance statement and comments are attributes on each requirement and go back in the same format, compared with the previous round. Customer requirements link to your own product requirements, so you see which customers a change affects before you agree to it, and answers stay consistent across customers.
How do we manage derivatives and revisions without copying requirement sets?
With streams and baselines in IBM Engineering Lifecycle Management Global Configuration Management. The platform or base die is one stream. Each derivative reuses it and holds only its own differences, and every tape-out or metal fix gets a baseline. You compare derivatives item by item, bring fixes across where they apply, and deliver evidence to a customer for exactly the configuration it buys.
Our requirements are in IBM Engineering Requirements Management DOORS (9.x), with years of DXL scripts. How do we move?
Product family by product family. Parts in production often stay on IBM Engineering Requirements Management DOORS (9.x) until their next revision, while new developments start in IBM Engineering Requirements Management DOORS Next. When a family moves, modules, attributes and links move with their original IDs, and released baselines are kept, so evidence sent to customers stays reproducible. DXL scripts are inventoried first. Most become configuration, views or link rules.
Firmware teams work in Atlassian Jira and GitLab, hardware teams in their own flow. How does it connect?
Requirements stay in IBM Engineering Requirements Management DOORS Next. Firmware work items and merge requests in Atlassian Jira or GitLab link to them through OSLC connectors or a synchronization we configure. Results from simulation and lab tools are imported into IBM Engineering Test Management as test results linked to requirements. Each team keeps its tools, and the coverage view shows hardware and firmware verification side by side.
What does the EU Cyber Resilience Act change for our requirements and test process?
It turns security into a documented product requirement. When the main obligations apply on 11 December 2027, you need a risk assessment, security requirements that answer the essential requirements, evidence that they were tested, and vulnerability handling for the support period. We set these up as linked artifact types next to your safety requirements, aligned with IEC 62443-4-1 practices, so the technical documentation comes from the same data as your safety evidence.
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.
