# PROCESS PURPOSE
The purpose is to provide an analyzed design, including dynamic aspects, that is consistent with the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements and suitable for manufacturing, and to derive production-relevant data.
# PROCESS OUTCOMES
O1
A (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) architecture and (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) detailed design is developed that identifies the elements of the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) and describes their behavior as well as their interfaces, and the dynamic interactions of the (Hardware element = Generic term; can represent a hardware component, a hardware part, a hardware interface, or the hardware.).
O2
The (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) architecture and the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) detailed design is analyzed, and the special characteristics are identified.
O3
Consistency and bidirectional traceability are established between the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements and the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) design.
O4 (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) production data are derived from the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) detailed design and communicated to all affected parties.
O5
The (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) architecture and (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) detailed design and the special characteristics are agreed and communicated to all affected parties.
# BASE PRACTICES
BP1
Specify the hardware architecture. (
O1, O4 )
Develop the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) architecture that identifies the (Hardware component = Logical (e.g., functional block) or physical group of hardware parts realizing a functionality, which
cannot be realized by any of its hardware parts alone, e.g. voltage monitoring, power supply.
may be organized hierarchically, i.e., a hardware component can contain lower-level hardware components.
Note: Depending on the application, e.g., the populated PCB, a system-on-chip, a microcontroller, or an SBC can be considered a HW component.). Document the rationale for the defined (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) architecture. Note 1: Examples for aspects reflected in the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) architecture are ground concept, supply concept, EMC concept. Note 2: Examples for a design rationale can be implied by the reuse of a standard (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.), platform, or product line, respectively, or by a make-or-buy decision, or found in an evolutionary way.
Linked Knowledge Nuggets: arrow_forward "What is the difference between a model, view and a diagram in (system) architecture?"
personAuthor: Process Fellows
In model-based development, it's essential to distinguish between the concepts of "model", "view", and "diagram", as each serves a specific purpose.
A "model" is an abstraction of reality. It represents the complete system description, but only in terms of the essential elements that are relevant to the modeling context. Irrelevant details are deliberately excluded to maintain clarity and focus. The model is considered "complete" not because it includes every possible detail, but because it captures all significant influencing factors necessary for understanding and analysis within its intended scope. Remark: This definition is applicable as well for the various disciplines, e.g. in case a model is used to define a software architecture. If needed, different modelling techniques (e.g. SysML versus UML) might be used for different disciplines.
A "view" focuses on a particular aspect of the model, such as its structure or behavior. Views are tailored to the needs of specific stakeholders, which means that certain details may be intentionally omitted. However, a view never contains more information than the model itself—it is always a subset or projection of the model. The model remains the authoritative source of truth, while views help stakeholders concentrate on what matters most to them.
A "diagram" is a visual representation of a model with respect to a specific view. It helps communicate the model’s content in a clear and accessible way. Multiple types of diagrams can be used to illustrate different views, depending on the aspect being analyzed and the audience’s needs.
BP2
Specify the hardware detailed design. (
O1, O4 )
Based on the components identified in the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) architecture, specify the detailed design description and the schematics for the intended (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) variants, including the interfaces between the (Hardware element = Generic term; can represent a hardware component, a hardware part, a hardware interface, or the hardware.). Derive the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) layout, the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) bill of materials, and the production data. Note 3: The identification of the (Hardware part = Fundamental HW element the purpose and functionality of which cannot be further subdivided or separated. Note: Examples are transistors, resistors, diodes, non-populated PCB. Note: Depending on the application, e.g., a system-on-chip, a microcontroller or an SBC can be considered a HW part. Note: the term ‘unit’ is considered to apply to the software domain only. The term ‘hardware part’ can be viewed as the hardware counterpart of ‘software unit’.) and their suppliers in the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) bill of materials may be subject to a pre-defined repository (see also IATF 16949:2016, clause 8.4.1.2.). Note 4: The (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) detailed design may be subject to constraints such as availability of (Hardware part = Fundamental HW element the purpose and functionality of which cannot be further subdivided or separated. Note: Examples are transistors, resistors, diodes, non-populated PCB. Note: Depending on the application, e.g., a system-on-chip, a microcontroller or an SBC can be considered a HW part. Note: the term ‘unit’ is considered to apply to the software domain only. The term ‘hardware part’ can be viewed as the hardware counterpart of ‘software unit’.) on the market, (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) design rules, layout rules, creepage and clearance distances, compliance of HW parts with industry standards such as AEC-Q, REACH.
Linked Knowledge Nuggets: arrow_forward "What is the difference between a model, view and a diagram in (system) architecture?"
personAuthor: Process Fellows
In model-based development, it's essential to distinguish between the concepts of "model", "view", and "diagram", as each serves a specific purpose.
A "model" is an abstraction of reality. It represents the complete system description, but only in terms of the essential elements that are relevant to the modeling context. Irrelevant details are deliberately excluded to maintain clarity and focus. The model is considered "complete" not because it includes every possible detail, but because it captures all significant influencing factors necessary for understanding and analysis within its intended scope. Remark: This definition is applicable as well for the various disciplines, e.g. in case a model is used to define a software architecture. If needed, different modelling techniques (e.g. SysML versus UML) might be used for different disciplines.
A "view" focuses on a particular aspect of the model, such as its structure or behavior. Views are tailored to the needs of specific stakeholders, which means that certain details may be intentionally omitted. However, a view never contains more information than the model itself—it is always a subset or projection of the model. The model remains the authoritative source of truth, while views help stakeholders concentrate on what matters most to them.
A "diagram" is a visual representation of a model with respect to a specific view. It helps communicate the model’s content in a clear and accessible way. Multiple types of diagrams can be used to illustrate different views, depending on the aspect being analyzed and the audience’s needs.
intacs® Certified Mechanical SPICE
Sponsored
The official intacs® Certified training for Mechanical SPICE.
BP3
Specify the dynamic aspects of the hardware architecture and the hardware detailed design. (
O1 )
Evaluate and document the dynamic behavior of the relevant (Hardware element = Generic term; can represent a hardware component, a hardware part, a hardware interface, or the hardware.) and the interaction between them. Note 5: Not all (Hardware element = Generic term; can represent a hardware component, a hardware part, a hardware interface, or the hardware.) have dynamic behavior that needs to be described.
Linked Knowledge Nuggets: arrow_forward "What is the difference between a model, view and a diagram in (system) architecture?"
personAuthor: Process Fellows
In model-based development, it's essential to distinguish between the concepts of "model", "view", and "diagram", as each serves a specific purpose.
A "model" is an abstraction of reality. It represents the complete system description, but only in terms of the essential elements that are relevant to the modeling context. Irrelevant details are deliberately excluded to maintain clarity and focus. The model is considered "complete" not because it includes every possible detail, but because it captures all significant influencing factors necessary for understanding and analysis within its intended scope. Remark: This definition is applicable as well for the various disciplines, e.g. in case a model is used to define a software architecture. If needed, different modelling techniques (e.g. SysML versus UML) might be used for different disciplines.
A "view" focuses on a particular aspect of the model, such as its structure or behavior. Views are tailored to the needs of specific stakeholders, which means that certain details may be intentionally omitted. However, a view never contains more information than the model itself—it is always a subset or projection of the model. The model remains the authoritative source of truth, while views help stakeholders concentrate on what matters most to them.
A "diagram" is a visual representation of a model with respect to a specific view. It helps communicate the model’s content in a clear and accessible way. Multiple types of diagrams can be used to illustrate different views, depending on the aspect being analyzed and the audience’s needs.
BP4
Analyze the hardware architecture and the hardware detailed design. (
O2 )
Analyze the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) architecture and the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) detailed design regarding relevant technical aspects, and support (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.) management regarding (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.) estimates. Identify the special characteristics. Note 6: Examples for technical aspects are manufacturability for production, suitability of pre-existing (Hardware component = Logical (e.g., functional block) or physical group of hardware parts realizing a functionality, which
cannot be realized by any of its hardware parts alone, e.g. voltage monitoring, power supply.
may be organized hierarchically, i.e., a hardware component can contain lower-level hardware components.
Note: Depending on the application, e.g., the populated PCB, a system-on-chip, a microcontroller, or an SBC can be considered a HW component.) to be reused, or availability of (Hardware element = Generic term; can represent a hardware component, a hardware part, a hardware interface, or the hardware.). Note 7: Examples of methods suitable for analyzing technical aspects are simulations, calculations, quantitative or qualitative analyses such as FMEA.
Linked Knowledge Nuggets: arrow_forward "Analysis of an architectural design"
personAuthor: Process Fellows
The analysis of an architectural design is a substantive examination of the quality of an architecture.
It should never depend on the background knowledge or experience of a single person.
For this reason, the analysis must involve a (interdisciplinary) team of experts, be based on predefined criteria and the analysis method should be documented in a comprehensible manner.
Examples of analysis criteria can be found in the Automotive Spice Guideline, but please do not hesitate to define additional criteria that are appropriate to the task and the environment!
BP5
Ensure consistency and establish bidirectional traceability. (
O3 )
Ensure consistency and establish traceability between the (Hardware element = Generic term; can represent a hardware component, a hardware part, a hardware interface, or the hardware.) and the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements. Ensure consistency and establish traceability between the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) detailed design and the components of the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) architecture. Note 8: There may be non-functional (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements that the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) design does not trace to. Examples are development process requirements. Such requirements are still subject to verification. Note 9: Bidirectional traceability further supports consistency, and facilitates impact analysis of change requests, and demonstration of coverage. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent.
Linked Knowledge Nuggets: arrow_forward "Consistency vs. Traceability – What’s the Difference?"
personAuthor: Process Fellows
Consistency ensures that related content doesn’t contradict itself – e.g., requirements align with architecture and test. Traceability, in contrast, is about links: can you follow a requirement through to implementation and verification? Both are needed – consistency builds trust, traceability enables control. Typically, traceability strongly supports consistency review.
arrow_forward "The role of traceability in risk control"
personAuthor: Process Fellows
Traceability isn’t just about completeness — it’s about managing impact. When a requirement changes, trace links tell you what’s affected. That’s your early-warning system.
arrow_forward "The true benefit of traceability
"
personAuthor: Process Fellows
Sometimes the creation of traceability is seen as an additional expense, the benefits are not recognized.
Traceability should be set up at the same time as the derived elements are created. Both work products are open in front of us and the creation of the trace often only takes a few moments.
In the aftermath, the effort increases noticeably and the risk of gaps is high.
If the traceability is complete and consistent, the discovery of dependencies is unbeatably fast and reliable compared to searching for dependencies at a later stage, when there may also be time pressure.
It also enables proof of complete coverage of the derived elements and allows the complete consistency check.
BP6
Communicate the agreed hardware architecture and hardware detailed design. (
O4, O5 )
Communicate the agreed (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) architecture and the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) detailed design, including the special characteristics and relevant production data, to all affected parties.
# OUTPUT INFORMATION ITEMS
15-51
Analysis results (
O2 )
Results of analysis of an object or (Task = A definition, but not the execution, of a coherent set of atomic actions.).Identifies:
Object under analysis
Analysis criteria
Selection criteria or prioritization scheme
Decision criteria
Quality criteria
Includes:
Decisions and selections performed
Assumptions and constraints
Evaluation criteria, for example correctness, completeness or consistency to a work product
Examples and references:
Verifiability analysis results, for example when a test machine becomes defective
Results of a feasibility analysis
Used by these processes:
ACQ.4 Supplier Monitoring
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
MAN.5 Risk Management
MAN.6 Measurement
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
PIM.3 Process Improvement
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
13-52
Communication evidence (
O5 )
Evidence of interpersonal communication.Identifies:
Scope of information
Need for feedback, for example an expected confirmation within one week
Meta data, for example time when communication was done or how information was distributed.
Includes:
Personal information
Work-flows, for example within tools
Examples and References:
E-mails and other forms of memos
Verbal statements
Meeting minutes, for example in standups
Electronic media, for example webcasts, blog posts intranet forum
Chat protocols
Wiki pages
Photo protocol
Used by these processes:
ACQ.4 Supplier Monitoring
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
PIM.3 Process Improvement
REU.2 Reuse of Products
SUP.1 Quality Assurance
SUP.11 Machine Learning Data Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
Used by these process attributes:
PA2.1 Process performance management process attribute
13-51
Consistency evidence (
O3 )
Evidence of information to be semantically coherent alongrelevant artifacts, ensuring completeness, purpose maturity of processes, (Task = A definition, but not the execution, of a coherent set of atomic actions.) and products throughout their lifecycle.Identifies:
Traceability information, for example hyperlinks, repository location or editorial references.
Naming conventions
Relevant artifacts
Revision and revision history information
Change documentation and analysis information
Includes:
Meta-information, for example database identifiers notes in Git commits comments
Examples and References:
Evidence of Definition of Done (DoD) adherence.
Used by these processes:
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
SUP.8 Configuration Management
SUP.10 Change Request Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
04-52
Hardware Architecture (
O1 )
High-level design and structure of physical components in an electronic device (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.).Identifies:
Overall (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) structure
(Hardware component = Logical (e.g., functional block) or physical group of hardware parts realizing a functionality, which
cannot be realized by any of its hardware parts alone, e.g. voltage monitoring, power supply.
may be organized hierarchically, i.e., a hardware component can contain lower-level hardware components.
Note: Depending on the application, e.g., the populated PCB, a system-on-chip, a microcontroller, or an SBC can be considered a HW component.)
Own developed and supplied (Hardware component = Logical (e.g., functional block) or physical group of hardware parts realizing a functionality, which
cannot be realized by any of its hardware parts alone, e.g. voltage monitoring, power supply.
may be organized hierarchically, i.e., a hardware component can contain lower-level hardware components.
Note: Depending on the application, e.g., the populated PCB, a system-on-chip, a microcontroller, or an SBC can be considered a HW component.)
(Hardware component = Logical (e.g., functional block) or physical group of hardware parts realizing a functionality, which
cannot be realized by any of its hardware parts alone, e.g. voltage monitoring, power supply.
may be organized hierarchically, i.e., a hardware component can contain lower-level hardware components.
Note: Depending on the application, e.g., the populated PCB, a system-on-chip, a microcontroller, or an SBC can be considered a HW component.) interfaces
Includes:
Justifying rationale for the chosen architecture
Relationship and dependency between (Hardware component = Logical (e.g., functional block) or physical group of hardware parts realizing a functionality, which
cannot be realized by any of its hardware parts alone, e.g. voltage monitoring, power supply.
may be organized hierarchically, i.e., a hardware component can contain lower-level hardware components.
Note: Depending on the application, e.g., the populated PCB, a system-on-chip, a microcontroller, or an SBC can be considered a HW component.)
Specifics for (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) variants
Power supply, thermal and grounding concepts
Examples and references:
Integrated circuits (IC) components placement is documented on “floorplan” architecture document.
Used by these processes:
HWE.2 Hardware Design
14-54
Hardware Bill of Materials (
O1, O4 )
Description of subcomponents, material and assemblies Included within a (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) product.Identifies:
Type of components
Number of (Hardware part = Fundamental HW element the purpose and functionality of which cannot be further subdivided or separated. Note: Examples are transistors, resistors, diodes, non-populated PCB. Note: Depending on the application, e.g., a system-on-chip, a microcontroller or an SBC can be considered a HW part. Note: the term ‘unit’ is considered to apply to the software domain only. The term ‘hardware part’ can be viewed as the hardware counterpart of ‘software unit’.)
Supplier name
Revision information
Includes:
Structure and hierarchical information
Used by these processes:
HWE.2 Hardware Design
04-53
Hardware Detailed Design (
O1 )
Internal structure and behavior of (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) subsystems.Identifies:
Interconnections between the (Hardware part = Fundamental HW element the purpose and functionality of which cannot be further subdivided or separated. Note: Examples are transistors, resistors, diodes, non-populated PCB. Note: Depending on the application, e.g., a system-on-chip, a microcontroller or an SBC can be considered a HW part. Note: the term ‘unit’ is considered to apply to the software domain only. The term ‘hardware part’ can be viewed as the hardware counterpart of ‘software unit’.)
Interfaces of the (Hardware part = Fundamental HW element the purpose and functionality of which cannot be further subdivided or separated. Note: Examples are transistors, resistors, diodes, non-populated PCB. Note: Depending on the application, e.g., a system-on-chip, a microcontroller or an SBC can be considered a HW part. Note: the term ‘unit’ is considered to apply to the software domain only. The term ‘hardware part’ can be viewed as the hardware counterpart of ‘software unit’.)
Includes:
Dynamic behavior in modes of operation and internal states, for example in power-up and power-down sequences.
Timing specifications, for example frequencies and delays
Technologies and their characteristics, for example modulations and filter settings.
Justifying rationale for the chosen design
References to datasheets, application notes
Constraints for layout
Used by these processes:
HWE.2 Hardware Design
04-56
Hardware Element Interface (
O1 )
Description of interactions between different physical components within a (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.).Identifies:
Electrical interconnections
Thermal interfaces
Electrical characteristics
Signal tolerance
Performance needs, for example bandwidth
Includes:
Definition of output, input, type
heat dissipation
communication parameters
signal parameters
Examples and references:
Standardized interfaces and protocols like SPI, I2C CAN.
Used by these processes:
HWE.2 Hardware Design
04-55
Hardware Layout (
O1, O4 )
Physical arrangement of components on a circuit board or within a device.Identifies:
Placement of the (Hardware part = Fundamental HW element the purpose and functionality of which cannot be further subdivided or separated. Note: Examples are transistors, resistors, diodes, non-populated PCB. Note: Depending on the application, e.g., a system-on-chip, a microcontroller or an SBC can be considered a HW part. Note: the term ‘unit’ is considered to apply to the software domain only. The term ‘hardware part’ can be viewed as the hardware counterpart of ‘software unit’.)
Manufacturing data, for example circuit paths, testing points
material specific adaptations
Shapes, masks, labels
layout identification
Includes:
Justifying rationale for the chosen design
Examples and references:
Printed circuit boards (PCB) layouts include vias different layers
Soldering mask
Used by these processes:
HWE.2 Hardware Design
03-54
Hardware Production Data (
O1, O4 )
Data used and created during (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) production.Identifies:
Layout data, e.g., in GERBER format
Test coverage
Includes:
Bill of material
Examples and References:
In semiconductor development, layout data can be mask data, for example in GDS2 format.
Used by these processes:
HWE.2 Hardware Design
04-54
Hardware Schematics (
O1, O4 )
Detailed diagrams of components and connections of a (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.).Identifies:
(Hardware part = Fundamental HW element the purpose and functionality of which cannot be further subdivided or separated. Note: Examples are transistors, resistors, diodes, non-populated PCB. Note: Depending on the application, e.g., a system-on-chip, a microcontroller or an SBC can be considered a HW part. Note: the term ‘unit’ is considered to apply to the software domain only. The term ‘hardware part’ can be viewed as the hardware counterpart of ‘software unit’.)
Connections of the (Hardware part = Fundamental HW element the purpose and functionality of which cannot be further subdivided or separated. Note: Examples are transistors, resistors, diodes, non-populated PCB. Note: Depending on the application, e.g., a system-on-chip, a microcontroller or an SBC can be considered a HW part. Note: the term ‘unit’ is considered to apply to the software domain only. The term ‘hardware part’ can be viewed as the hardware counterpart of ‘software unit’.)
Includes:
Identification information of (Hardware part = Fundamental HW element the purpose and functionality of which cannot be further subdivided or separated. Note: Examples are transistors, resistors, diodes, non-populated PCB. Note: Depending on the application, e.g., a system-on-chip, a microcontroller or an SBC can be considered a HW part. Note: the term ‘unit’ is considered to apply to the software domain only. The term ‘hardware part’ can be viewed as the hardware counterpart of ‘software unit’.) and variants.
Used by these processes:
HWE.2 Hardware Design
17-57
Special Characteristics (
O2 )
Product or process characteristics that impact safety, legal compliance, fit, function, performance, or further processing, and therefore require special treatment.Identifies:
Product characteristics
Production process parameters
Domain impact references, for example security.
References to regulations (compliance)
Conformity requirements
Includes:
Processing and performance requirements
Examples and References:
IATF 16949, VDA 6.x Guidelines, ISO 26262 ISO/SAE 21434
FMEA rating within FMEA can consider special characteristics.
HWE.2
Hardware Design
