组合产品的检测边界怎么划

结论：边界跟着预期用途走，不跟着物理形态走

一套产品由主机、附件、耗材、软件组成时，检测该覆盖到哪里，常常没有共识。有人按物理边界划——装在一个箱子里的都算；有人按供货范围划——我们卖什么就测什么。

比较可靠的依据是预期用途。 完成预期用途需要哪些部分参与，这些部分就在检测边界内，不论它们是不是同一次供货、是不是自己生产。

三个判断问题

第三个问题指向一类麻烦情形：产品设计成可以搭配第三方部件使用，比如通用接口的传感器、开放规格的耗材。这时候边界怎么划需要单独考虑。

可选配第三方部件怎么处理

有三种做法，各有代价：

一是限定兼容清单。 明确列出可搭配的型号，只对清单内的组合做验证。代价是限制了使用灵活性，也增加了清单维护工作。

二是规定接口参数。 不限定具体型号，但规定接口必须满足的参数范围，并验证在参数范围边界上的表现。这种做法更灵活，但验证工作要覆盖参数范围而不是单点。

三是在说明书中明确责任边界。 说明产品仅在使用指定部件时保证性能。这是成本最低的做法，但如果实际使用中普遍搭配其他部件，风险并没有真正转移。

选哪种取决于产品的使用现实，而不是哪种最省事。如果明知使用者会搭配其他部件，只在说明书里免责是不够的。

组件送检与整体送检的取舍

第三种是多数情况下的合理选择。 做法是组件级完成各自的基础项目，系统级只做那些必须在完整状态下才有意义的项目，比如整机的电气安全、EMC、以及涉及多组件协同的性能。

判断哪些属于系统关键项，依据是：这一项的结果会不会因为组件组合而改变。电气安全会（接地路径、漏电流是整机的）；单个部件的材料生物学通常不会。

接口部分容易被漏掉

组合产品里最容易漏测的是接口本身：连接器的机械可靠性、通信的抗干扰、供电的兼容性、误连接的防护。

这些项目在组件各自送检时都不在范围内——A 组件测自己，B 组件测自己，中间的连接没人管。而实际故障恰恰不少出在接口上。

建议把接口单独列成一组项目，明确由谁负责、测什么。这一组在项目清单上往往是空白，需要主动补。

软件作为组件时的处理

软件在组合产品里的边界更难划。要区分：嵌入在设备中的软件、运行在通用计算平台上的配套软件、以及云端服务。

三者的验证方式不同，而它们之间的数据流是连贯的。验证时要覆盖数据流的完整路径，而不是各自验证各自的模块。常见的遗漏是模块各自都对，但在传递过程中出现单位换算、精度损失或者时序问题。

注册单元与检测边界的关系

这两者相关但不等同。注册单元决定的是申报时怎么组织，检测边界决定的是测什么。

可能出现的情形是：一个注册单元里包含多个型号，检测按覆盖论证只测其中部分；或者几个注册单元共用某个组件，该组件的数据可以复用。

厘清这个关系能省不少重复工作。 建议在排检测计划之前先把注册单元的划分定下来。

谁来负责系统级验证

组合产品常常涉及多个供应方：主机是自己的，某个模块是外购的，软件是第三方开发的。这时候系统级验证由谁负责容易出现推诿。

原则是：谁把它们组合成最终产品并以自己名义上市，谁负责系统级验证。 各组件供应方对自己的部分负责，但组合之后的相互影响不是任何单一供应方能覆盖的。

这一点应当在与供应方的协议里写明，包括供应方需要提供哪些数据、出现系统级问题时的配合义务。

检测计划的组织方式

组合产品的检测计划建议按矩阵组织：横轴是组件，纵轴是项目，在交叉点标明该项目对该组件是否适用、在哪一层执行。

这张矩阵的好处是一眼能看出空白——哪个组件的哪个项目没人管。前面说的接口项目，通常就是在这张矩阵上被发现遗漏的。

耗材与主机的关系

耗材是组合产品里的特殊角色：它随主机使用但独立供货，可能由第三方生产，而且是重复购买的。

验证上要处理三件事：耗材自身的性能与安全；耗材与主机配合时的系统表现；使用非指定耗材时的后果。第三项常被跳过，但实际使用中替换耗材的情况很普遍，风险需要评估而不是只在说明书里禁止。

边界之外的说明义务

划在边界外的部分，不等于完全不用管。对于边界外但会影响使用的因素，说明书应当给出要求：比如对配套电源的规格要求、对使用环境的限制、对第三方部件的最低要求。

这些说明的依据同样应当来自验证，而不是凭经验写一个宽泛的范围。

我们的做法

接到组合产品的委托，我们会先请委托方提供一张系统组成图，标明各部件的功能、连接关系和供货方式。有这张图，边界讨论才有基础。

然后按三层列清单：组件级项目、系统级项目、接口项目。接口这一层在委托方原本的清单里通常是缺的，补上之后项目数会增加，但它对应的是实际故障率较高的部分。

如果你的产品由多个部件组成，检测范围不确定，可以把系统组成图发过来一起划边界，或者直接联系：132 4819 8029。能力范围见服务介绍，送检要求见送检要求，更多内容见知识库。

English version

Conclusion. Where a product comprises a main unit, accessories, consumables and software, opinions differ on how far testing should reach. Some draw the line physically, covering whatever ships in the box; others draw it commercially, covering whatever they sell. A more reliable basis is intended use: whatever participates in delivering the intended use falls inside the boundary, regardless of whether it ships together or is made in-house.

Three questions. Does this part participate in delivering the intended use? Would its failure affect safety or performance? Is it user-selected from an open specification? Yes to either of the first two places it inside the boundary. Yes to the third indicates a case needing separate treatment.

User-selected third-party parts. Three approaches exist. Define a compatibility list and validate only listed combinations, at the cost of flexibility and list maintenance. Specify interface parameters without naming products, validating behaviour at the boundaries of the parameter range, which is more flexible but requires validation across a range rather than at a point. Or state in the instructions that performance is assured only with specified parts, which is cheapest but does not genuinely transfer risk if users routinely substitute. The choice should follow the reality of use rather than convenience: where substitution is known to be common, a disclaimer alone is not enough.

Component versus system testing. Testing components separately allows parallel work and short individual lead times but cannot reveal interactions. Testing the assembled system covers system-level behaviour but complicates sample preparation and lengthens the schedule. A layered approach usually makes sense: complete baseline items at component level and reserve for system level only those items that are meaningful in the complete state, such as electrical safety, EMC and performance depending on multiple components working together. The test for whether an item belongs at system level is whether its result could change because of how components are combined. Electrical safety does, since earth paths and leakage belong to the whole. A single part's material biocompatibility generally does not.

Interfaces are the common omission. Connector mechanical reliability, communication immunity, power compatibility and protection against mis-connection fall outside every component's own scope: A is tested by itself, B is tested by itself, and nothing covers what lies between. Field failures often occur precisely there. List interface items as a separate group with an owner, because that group is usually blank on the initial item list.

Software as a component. Distinguish embedded software, companion software running on general-purpose platforms, and cloud services. Their verification differs while the data flow between them is continuous, so verification must cover the whole path rather than each module in isolation. A frequent failure is that every module is individually correct while unit conversion, precision loss or timing problems appear in transfer.

Registration units and test boundaries. These are related but not identical. The registration unit governs how the submission is organised; the boundary governs what is tested. One unit may contain several models with only some tested under a coverage argument, or several units may share a component whose data can be reused. Settling the unit structure before planning testing avoids duplicated work.

How we handle it. We ask for a system diagram showing each part's function, connections and supply arrangement, because boundary discussions need that basis. We then list items in three layers: component, system and interface. The interface layer is usually missing from the client's original list; adding it increases the item count but addresses the part with the higher real-world failure rate.

Send us the system diagram and we will work through the boundary. Phone or WeChat: +86 132 4819 8029.