Engineering Responsibility Matrix
This Engineering Responsibility Matrix defines and clarifies engineering responsibilities between the hardware supplier and the customer or system integrator. It is intended to reduce miscommunication, project risk, and integration delays in industrial projects.
ON THIS PAGE
1. Hardware Platform
| Engineering Scope | Supplier | Customer / SI | Notes |
|---|---|---|---|
| Hardware design & validation | Responsible | Not responsible | Standard product platforms |
| CPU / chipset selection | Responsible | Not responsible | Verified industrial platforms |
| Peripheral compatibility | Shared | Shared | Requires joint confirmation |
2. Industrial I/O & Electrical Characteristics
| Engineering Scope | Supplier | Customer / SI | Notes |
|---|---|---|---|
| I/O electrical specifications | Responsible | Not responsible | As per datasheet |
| Interface isolation (CAN / Serial) | Responsible | Not responsible | Model-dependent |
| Field wiring & cabling | Not responsible | Responsible | Site-specific |
| EMI / grounding handling | Not responsible | Responsible | System-level responsibility |
3. OS / BSP / Software
| Engineering Scope | Supplier | Customer / SI | Notes |
|---|---|---|---|
| OS installation (Linux / Android / Windows) | Responsible | Not responsible | Standard images |
| BSP / driver support | Responsible | Not responsible | For listed hardware |
| Kernel modification | Shared | Shared | OEM project scope |
| Application software | Not responsible | Responsible | Customer-owned |
4. AI / Application Software ( If Applicable )
| Engineering Scope | Supplier | Customer / SI | Notes |
|---|---|---|---|
| AI hardware platform | Responsible | Not responsible | CPU / NPU / GPU |
| SDK & inference framework | Shared | Shared | Optional support |
| AI model training & accuracy | Not responsible | Responsible | Business-specific |
| Application logic | Not responsible | Responsible | Customer scope |
5. System Integration
| Engineering Scope | Supplier | Customer / SI | Notes |
|---|---|---|---|
| Single-unit functional test | Responsible | Not responsible | Factory testing |
| Multi-device system topology | Not responsible | Responsible | Integration scope |
| PLC / camera / sensor integration | Not responsible | Responsible | SI responsibility |
6. Environment & Reliability
| Engineering Scope | Supplier | Customer / SI | Notes |
|---|---|---|---|
| Environmental testing (temp / vibration) | Responsible | Not responsible | Specified limits |
| Site condition evaluation | Not responsible | Responsible | Real deployment |
| Over-spec operation | Not responsible | Responsible | Out of warranty |
7. Certification & Compliance
| Engineering Scope | Supplier | Customer / SI | Notes |
|---|---|---|---|
| CE / FCC / UKCA (unit-level) | Responsible | Not responsible | Standard compliance |
| System-level certification | Not responsible | Responsible | Final product |
| Industry-specific certification | Shared | Shared | Project-based |
8. Support & Lifecycle
| Engineering Scope | Supplier | Customer / SI | Notes |
|---|---|---|---|
| Standard warranty | Responsible | Not responsible | As published |
| RMA (manufacturing defects) | Responsible | Not responsible | Hardware only |
| On-site debugging | Not responsible | Responsible | System-level |
| Long-term supply | Shared | Shared | Contract-based |
9. Engineering Support SLA
Every project is handled by an application engineer — not a sales bot. These are the response commitments you can hold us to.
| Stage | Commitment |
|---|---|
| First response | An application engineer replies within 2 business days |
| Technical / design query | Engineering assessment within 2 business days |
| RFQ / configuration proposal | Returned within 2–3 business days |
| Evaluation sample | 10 business days |
| Custom carrier board | 4 weeks to first articles |
| Full custom mainboard | 1–3 months to first articles |
| Escalation | Unresolved issues escalate to a lead engineer within 1 business day |
| RMA turnaround | Average turnaround confirmed per project scope |
| Lifecycle / PCN notice | Minimum 6 months advance notice before any component change |
Coverage
- Overseas enquiries answered next business day (GMT+8 09:00-18:00); urgent project matters handled asynchronously across EU / US time zones
- Support languages: English · Chinese
- Direct engineer contact — you talk to the people who build the hardware, not a ticket queue
Commitments apply to business days. Timelines for custom work are confirmed per project scope at kickoff.
This matrix is provided to support transparent engineering collaboration and does not replace formal contractual agreements.
Need to Discuss Project Responsibilities?
Our engineering team can clarify scope boundaries for your specific OEM project.
Responsibility Matrix & Project Interface FAQs
Why is a formal responsibility matrix critical for industrial pilot line projects?
Industrial projects involve complex intersections between hardware, software, and mechanical integration. A formal matrix prevents "scope creep" and "responsibility gaps" by clearly defining who manages firmware validation,現場 (on-site) fieldbus tuning, and data layer integration, ensuring no task falls between the cracks during high-pressure pilot phases.
How does BITECH define the hardware-software integration boundary?
We define the boundary at the driver and middleware level. BITECH typically holds responsibility for the hardware abstraction layer (HAL), BSP stability, and CAN Bus/Fieldbus interface hardware validation, while the client or integrator manages the upper-level application logic and specific SCADA integration rules.
Who is responsible for EMI/EMC compliance validation on-site?
BITECH provides hardware that meets specified EMI/EMC standards (e.g., industrial CE/FCC). However, onsite system-level integration compliance is a joint responsibility. We provide the technical documentation and shielding guidelines for the integration, while the system integrator manages the actual cabinet-level wiring and physical grounding implementation.
How are firmware updates managed during the pilot validation phase?
During pilot validation, BITECH provides version-controlled firmware images. The responsibility matrix designates BITECH as the owner of the core BSP and stability updates, while the client manages the deployment timeline to ensure updates align with pilot test windows without disrupting ongoing production validation.
What happens if there is a conflict in fieldbus communication?
Our responsibility matrix categorizes fieldbus issues. If the issue is related to the physical layer (e.g., hardware-level signal loss), BITECH takes the lead in troubleshooting. If it is an application-layer data protocol conflict, BITECH provides the technical API documentation and protocol logs to assist the client’s software team in rapid root cause identification.