门禁这东西平时没人在乎直到某个周一早上八点半全楼的人堵在闸机前刷不开门物业的电话十分钟内就会打到你手机上。我在这行待了十来年从最早的ID读头、指纹机到后来的二维码、人脸机再到这两年被问得最多的一句话——你们这套东西是国产的吗能不能过信创验收——行业的水温变化基本都摸过一遍。深圳云识客提出的那套基于开源鸿蒙的人脸门禁方案第一眼看到的时候我的反应是终于有人把操作系统国产化这件事从办公室的PC和服务器挪到了门禁这种带外设、带实时控制、还要跑AI推理的边缘终端上来了。简单说清楚这个东西是什么它以开源鸿蒙OpenHarmony为系统底座在一颗国产主控上跑人脸门禁的完整业务——人脸注册、活体检测、比对开门、韦根输出、消防联动、考勤上报——整个软硬件栈基本都落在国产供应链里目的是让信创场景下的通行管理设备不再依赖境外操作系统和芯片。它能干的事说白了就是把原来跑在安卓/Linux上的那台人脸机换成一台可控、可审计、可长期维护的机器同时把识别速度、误识率和设备寿命保持在能交付的水平。这篇文章写给谁看如果你是系统集成商的项目经理正在头疼一个写字楼、园区或者数据中心的门禁国产化替换怎么落地如果你是嵌入式工程师第一次拿到OpenHarmony的源码不知道怎么把摄像头和继电器接起来如果你是甲方的信息化负责人要写一份能过评审的技术方案——下面这些内容应该都能直接拿去用。我不会只讲概念会把选型逻辑、驱动适配、迁移节奏、现场踩过的坑都摊开说。1. 门禁行业为什么绕不开国产化这道坎1.1 供应链的现实压力比政策文件更早到来很多人以为门禁国产化的推动力来自验收文件其实最早感受到压力的是采购和供应链。一台人脸门禁机拆开看主控SoC、内存、闪存、Wi-Fi模组、加密芯片、摄像头传感器过去有相当比例来自境外厂商。2020年前后那波缺货做门禁的同行应该都有印象某些型号的芯片交期从8周拉到40周报价一天一个样项目签了合同设备到不了场违约金自己扛。从那时候起能不能找到第二供应源就成了硬件选型的硬指标。信创在门禁这个品类上的要求本质上是三件事芯片自主可控、操作系统自主可控、整套产品的认证资料齐全。前两件是技术问题第三件是流程问题而流程问题往往比技术问题更折磨人。因为一个门禁项目要交付的不只是设备还有一堆材料芯片的国产化证明、操作系统的版本说明、软件著作权、检测报告。设备本身跑得再快材料凑不齐一样过不了验收。我个人的判断是门禁国产化不是要不要做的选择题而是什么时候做、怎么做代价最小的时间题。现在还有大量安卓人脸机在项目上跑着这些设备未来三到五年会集中进入替换周期谁来接这个盘子取决于谁现在把方案磨成熟了。1.2 门禁终端看着简单实际是最难换的一类设备如果只是把一台办公电脑从Windows换成国产系统工作量大但路径清晰。门禁机就麻烦得多它同时踩了三个雷区实时性要求刷卡到开门用户的心理预期是立刻。继电器从收到指令到吸合整个过程不能有明显延迟否则体验直接崩。一个通用操作系统如果没有做实时性裁剪调度抖动会让人抓狂。外设碎片化严重一个门禁项目里可能同时存在韦根读头、RS485梯控、消防干接点、电锁、门磁、出门按钮每种外设的时序和电平都不一样。这些驱动原来在安卓生态里有大量现成的换到新系统上全得自己写或者自己改。算法要跑在本地人脸比对必须本地完成把图片传到云端再返回结果一次网络抖动就是一队人堵在门口。这意味着底板上要同时扛住系统调度、视频流采集、神经网络推理三件事。所以一个门禁方案的国产化绝不是换个系统镜像这么简单它是系统层、驱动层、算法层、业务层的同步迁移。这也是为什么大部分厂商宁愿继续用安卓拖两年也不愿意现在动。1.3 开源鸿蒙为什么适合做门禁的底座开源鸿蒙在这个场景里的优势我说几个实际感受到的点不谈宣传口径。第一是组件化裁剪能力强。OpenHarmony的内核层支持轻量、小型、标准三种系统类型门禁这类设备不需要图形化的完整桌面环境也不需要浏览器内核那一整套东西可以把系统裁到几百兆以内剩下的资源全部让给算法和缓存。我做过的对比测试里同样一颗主控裁剪之后的系统冷启动时间比通用Linux方案短一截这在需要快速上电恢复的场景比如断电重启后闸机要立刻工作里很关键。第二是分布式软总线带来的组网可能性。一个园区里有几十上百台门禁如果每台设备都要单独配置、单独升级、单独拉数据运维成本会爆炸。软总线这套机制让设备之间、设备与边缘网关之间可以建立相对可信的连接做批量下发和状态汇总会顺手很多。当然这一块要真正用好还得自己在应用层做不少工作不是开箱即用。第三是供应链与生态的匹配度。开源鸿蒙的芯片适配列表里国产主控的覆盖度这两年提升很明显从入门级到带NPU的型号都有对应移植版本。对一个要过信创验收的项目来说这意味着芯片系统可以打包成一个互相背书的组合材料准备起来省事。不过我得先把丑话说前面开源鸿蒙不是万能药。它的工具链、调试体验、社区文档的成熟度和安卓比还有差距尤其是涉及具体型号NPU的推理框架、某些冷门外设的驱动你大概率要自己啃源码。抱着换个系统就完事的心态进来第一个月就会撞墙。下面几章我会把这些墙一块一块标出来。2. 整套方案拆开看一台人脸门禁里到底装了什么2.1 硬件选型别在第一步就把自己锁死硬件这块我的原则很简单先定认证范围再定性能指标最后才看价格。顺序反了后面全是返工。一块门禁主板要重点看这几项部件关注点常见坑主控SoC是否在国产适配列表内、是否有NPU、算力多少TOPS只看CPU主频不看NPU推理全靠CPU跑帧率上不去内存1GB起步跑人脸多路外设建议2GB512MB在压力测试下频繁触发OOM存储eMMC 8GB起步人脸库大要留足空间人脸模板写满后没有告警机制直接写失败摄像头宽动态、红外补光、全局快门优先用卷帘快门做活体快速移动时拖影导致误判加密芯片是否支持国密算法、密钥是否可安全存储人脸模板明文存eMMC安全评估直接挂继电器/IO干接点输出、门磁输入、消防输入数量消防联动接口预留不足后期加板子改结构关于算力我一般按这个经验值估算1:1比对刷脸找自己在200ms内完成1:N检索几百到几千人库在500ms内完成这是能接受的体验下限。如果NPU算力只有0.5TOPS做1:N检索就得靠分级策略——先粗筛再精比否则排队。这个后面第5章会展开。注意主控选型一定要确认开源鸿蒙的移植版本是否包含你要用的那一路摄像头接口MIPI还是USB。有些移植版本只适配了USB摄像头而门禁结构件里通常预留给MIPI的空间更小改起来要动模具。2.2 系统分层把资源花在刀刃上OpenHarmony的标准分层是内核层、系统服务层、框架层、应用层。放到门禁上我通常是这么分配的内核层保留Linux内核加必要的驱动摄像头、显示、GPIO、网络、看门狗把不需要的子系统全部裁掉。这里有个细节看门狗必须留而且必须配好。门禁设备装在弱电井或者门框顶上一旦死机没人会去重启狗要能自己把设备拉回来。我一般设置喂狗周期和业务线程心跳绑定超过阈值没喂就硬复位。系统服务层重点保留分布式软总线、安全子系统、电源管理。图形这块看情况如果用的是简单的段码屏或者小尺寸LCD其实可以不用完整的图形框架直接走framebuffer绘制省下来的内存给算法用。应用层就是门禁业务本身设备管理、人员管理、识别服务、通行控制、记录上报。我习惯把识别服务做成独立的常驻进程和业务UI解耦这样界面刷新卡顿不会影响刷脸响应。2.3 人脸算法本地化是底线不是选项人脸识别在门禁里的技术路线这几年基本收敛了检测对齐特征提取比对四步全部在本地完成。云端只做人员信息同步和记录汇总不做实时比对。为什么这么坚持三个原因。一是延迟走公网一次往返少说一两百毫秒加上服务端排队高峰期体验极差二是可靠性网络断了门还得开这是物理安全的底线三是合规人脸属于敏感个人信息能不往外传就不往外传把特征值存在本地加密分区里是最省事的合规姿势。算法选型上我倾向于用轻量级的人脸模型参数量控制在几MB级别输入分辨率一般用112×112或者160×160。这里有个常见的误区很多人觉得输入分辨率越高识别越准其实在门禁这种近距离、正脸为主的场景里过高的输入分辨率只会拖慢推理收益非常有限。我做过对比320×320输入相比160×160输入识别率提升不到1个百分点但推理耗时翻了一倍多。活体检测必须做而且要明确告诉甲方你做的是哪种。目前门禁上主流是近红外活体加一路红外摄像头靠反射率差异判断和可见光活体靠纹理、微动、摩尔纹。近红外的抗照片攻击能力强成本高一点可见光方案便宜但对屏幕翻拍这类攻击的防护要弱一些。我的建议是园区、写字楼这类场景用红外方案成本可以接受内部考勤点如果预算紧可见光方案也能顶但要明确写在方案里别到时候被抽查打脸。2.4 人脸数据怎么存、怎么删这件事必须在设计阶段定死数据这块我踩过大坑。早期项目为了方便把人脸特征值和姓名、工号、部门明文存在同一张表里结果安全评估的时候被指出特征值和个人身份信息未做分离存储整改花了两周。现在的做法是特征值单独加密存储密钥走安全芯片或者TEE业务层只持有索引ID。设备本地不留原始人脸图片注册时在App或者管理端完成采集和特征提取只把特征模板下发到设备。删除人员的时候要先删特征再删索引最后写一条操作日志三者顺序不能反否则会出现特征还在但查不到人的脏数据。还有一点常被忽略设备报废或返厂维修时的数据清除流程。我在方案里会明确写一条设备下线前必须执行恢复出厂并物理擦除加密分区出具清除记录。这既是合规要求也是甲方安全部门最在意的东西。很多厂商在这块只说支持删除但没告诉甲方怎么验证删除是不是真的删干净了交付时会很被动。3. 从裸板到刷脸开门核心环节的实操过程3.1 开发环境搭建与源码准备环境这块第一次搞OpenHarmony的人最容易卡在工具链上。我的建议是用官方推荐的Ubuntu LTS版本做编译环境不要在Windows子系统里硬搞绑定USB设备调试的时候会各种玄学问题。大致的准备流程是这样# 1. 基础依赖一次性装齐别一个个试 sudo apt-get update sudo apt-get install -y git-lfs curl python3-pip \ build-essential gcc-arm-linux-gnueabi \ libssl-dev libncurses5-dev # 2. 拉取repo工具 curl -s https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 repo chmod x repo sudo mv repo /usr/local/bin/ # 3. 初始化代码仓版本号按你拿到的适配包填 repo init -u 对应版本仓地址 -b release分支 --no-repo-verify repo sync -c -j8 --force-sync拉代码这一步源码体积不小网络不稳的话建议用-j4甚至-j2别贪快断一次重来更费时间。同步完之后先别急着改代码先跑一次全量编译确认环境是通的这一步能帮你排除掉八成的环境问题。./build/prebuilts_download.sh ./build.sh --product-name 你的产品名 --ccache--ccache强烈建议加上第一次编译慢后面增量编译能省大量时间。我第一次没加改一行驱动等了四十分钟那感觉相当酸爽。3.2 外设驱动适配门禁的功夫全在这儿人脸门禁和普通开发板最大的区别就是外设特别杂。我按踩坑频率从高到低说。摄像头。MIPI摄像头的适配通常芯片原厂会提供参考驱动把它挂到HDF硬件驱动框架下面重点是确认三件事分辨率档位、帧率、以及ISP图像信号处理有没有正常工作。我遇到过最诡异的一次问题是画面整体偏绿查了两天发现是ISP的白平衡参数没有加载因为配置文件路径在产品目录下没被正确打包进去。韦根接口。这是门禁行业的老朋友26位、34位协议都用得多。它是单向、时序敏感的协议用GPIO加定时器实现比较稳。核心逻辑是检测数据线的下降沿按间隔区分0和1最后校验奇偶位。/* 韦根26接收的核心思路伪代码实际要结合GPIO中断和硬件定时器 */ static void wiegand_edge_handler(int d0_level, int d1_level) { if (d0_level 0) { bit_buffer[bit_index] 0; } else if (d1_level 0) { bit_buffer[bit_index] 1; } /* 超过约 25ms 无新边沿判定一帧结束 */ reset_timer(25); } static void wiegand_frame_timeout(void) { if (bit_index 26 check_parity(bit_buffer)) { uint32_t card_no (extract_bits(bit_buffer, 1, 24)); notify_access_service(card_no); } bit_index 0; }注意韦根协议没有时钟线完全靠约定时序。如果同一根线上挂了两台设备或者线缆过长超过100米边沿会变形导致读到错误卡号。现场施工时一定要求用双绞屏蔽线并且只做单向接收。继电器与门磁。继电器控制电锁门磁反馈门的状态。这里最重要的是失败安全设计断电时门应该是开还是关消防通道必须断电开Fail Safe金库、机房必须断电关Fail Secure。这个不是软件逻辑问题是接线和选型问题但软件层面要提供配置项让同一个固件适配两种接法。我在实际项目里会额外加一个开门超时告警继电器吸合超过设定秒数比如10秒门磁还没反馈闭合就上报告警防止长时间通电烧锁。消防联动。消防信号一般是干接点输入要求收到信号后强制常开。这个东西平时不动作但验收必测而且必须做成硬联动——不能只靠软件轮询GPIO最好同时走硬件通路软件挂了消防信号也得能开门。3.3 人脸识别业务的完整闭环把上面的零件串起来一次刷脸的完整流程是这样的摄像头持续采集检测线程按固定频率比如每200ms一帧做人体/人脸检测没有人脸就丢弃省算力检测到人脸后触发跟踪等目标稳定连续N帧检测到同一张脸再送对齐模块对齐后裁剪出标准人脸区域做质量评分评分过低太暗、太糊、角度过大直接提示请正对摄像头不进入比对活体检测并行执行红外和可见光交叉验证特征提取得到特征向量与本地库做1:N检索命中且相似度超过阈值触发开门逻辑未命中则提示并记录全程写通行记录异步上报。这里面有两个参数是调优的关键我单独说。相似度阈值。这个值定得太低误识率上升可能出现长得像的人能开别人的门定得太高本人刷不开用户体验崩。我的经验是先在一批真实数据上跑出FAR误识率和FRR拒识率的曲线然后按场景选工作点。写字楼可以选FAR稍高一点的位置体验优先数据中心、机房这类高安全区域把阈值往上提同时加一道卡脸的双因子验证。质量评分门限。这个值定得太严用户在门口来回晃半天开不了门定得太松低质量图片进比对误识率就上去了。我一般设置成正常人站定1秒内能过。如果实测下来平均耗时超过2秒就说明门限过严要往下调。/* 开门决策的骨架逻辑 */ int access_decision(float similarity, float liveness_score, uint32_t card_no, int scene_mode) { float sim_th (scene_mode MODE_HIGH_SECURITY) ? 0.86f : 0.78f; float live_th 0.70f; if (liveness_score live_th) { report_event(EV_FAKE_FACE, card_no); return ACCESS_DENY; } if (scene_mode MODE_HIGH_SECURITY card_no 0) { /* 高安全场景必须卡脸双因子缺一不可 */ return ACCESS_NEED_CARD; } if (similarity sim_th) { report_event(EV_PASS, card_no); return ACCESS_GRANT; } report_event(EV_NO_MATCH, card_no); return ACCESS_DENY; }这段代码看着简单但阈值和场景模式的组合方式是决定一个项目现场能不能顺利交付的核心。我的习惯是把阈值做成可远程下发的配置现场调试的时候不用重新烧固件直接改配置重启服务就行效率高很多。3.4 与上层平台的对接门禁设备终究是个终端数据要回平台。对接这块主流的几种方式对接方式适用场景优缺点HTTP/HTTPS 轮询小规模、实时性要求低实现简单服务器压力大延迟高MQTT 长连接中大规模、需要实时下发双向通信好需要维护Broker私有TCP协议存量平台改造性能好但协议不透明维护成本高标准门禁协议如OSDP对接第三方控制器互通性好功能受限我一般推荐MQTT。设备上电后连Broker订阅自己的指令主题上报通行记录和心跳。人员数据下发走一个批量接口一次下发一张增量表。这样平台侧不用去猜设备在线状态靠心跳超时就能判断。这里有个实际教训下发人员数据一定要做幂等和分页。我遇过一个园区项目一次下发五千人设备端解析的时候内存爆了直接重启重启后又从头下发死循环。后来改成每页200人带序号和校验设备确认一页平台才发下一页问题就解决了。4. 存量门禁的国产化替换怎么落地4.1 迁移前的资产盘点这一步千万别省接手一个替换项目第一件事不是报价是盘点。我一般会做一张表把每台设备的现状摸清楚盘点项为什么重要设备型号与年限超期设备直接换还没到期的考虑保留或者做网关兼容通信方式韦根、RS485、TCP还是私有协议决定替换难度卡片类型ID、IC、CPU卡决定是否要动用户手里的卡人员数据量决定人脸库规模和设备存储选型现有平台厂商决定要不要保留原平台、做协议转换还是整体换掉点位物理条件有没有网口、有没有预留电源、门框能不能装新设备这张表看着朴素但它能帮你判断出哪些点位可以快速替换、哪些点位是硬骨头。我见过太多项目因为没盘点清楚施工队到了现场才发现门框是内嵌式的新设备尺寸不匹配只能现场改结构工期一拖再拖。4.2 分区分期替换别想着一次性推倒重来存量项目的替换我的主张是永远不要一次性全网切换。原因很实在门禁是通行刚需切换失败就是全员堵门这个风险没人担得起。具体节奏我一般这么安排第一阶段并行试点选一个人流量中等、影响面可控的点位比如某个侧门或者后勤通道新老设备并行运行两到四周。这个阶段的目标不是验证功能是验证稳定性——连续跑一个月不出故障才敢往下推。第二阶段分区替换按楼栋或者楼层分批每批替换前一周通知替换当天安排人到现场盯准备好回滚方案把老设备留在库房出问题半小时内换回去。第三阶段数据收口所有点位换完之后老平台的数据做一次全量归档形成历史记录然后下线老平台。每个阶段的间隔不要太短尤其是第一阶段我宁可多跑两周。试点跑出来的问题越多越好这些问题在试点阶段是麻烦在全网阶段就是事故。4.3 卡片兼容最容易被低估的坑人员数据迁移里最麻烦的往往不是人脸是卡。很多老项目用的是ID卡只读卡号新设备如果不支持ID读头用户手里的卡就等于作废得重新发卡。一个几千人的园区重新发卡光是通知、收集、制卡、发放就是几周的工作量还要处理我的卡刚好丢了这种突发情况。我的处理方式分三种第一种新设备直接支持原有卡类型。这是最省事的成本是硬件上多一个读头或者多一个模块但对甲方来说体验最好用户无感。第二种保留老读头通过韦根接入新控制器。适合老读头还能用、只是主控要换的场景。这样卡不动人不动只换大脑。第三种过渡期双轨。新老系统同时识别发新卡的同时老卡继续有效一段时间等大家都拿到新卡了再停老卡。这个方案最贵但风险最低适合对通行连续性要求极高的场景。提示做卡片迁移前一定要抽一批卡做实测确认卡号读取方式和原系统一致。我遇到过原系统读的是卡号的某一段新设备读的是完整卡号导致数据对不上全员无法开门那场面相当难看。4.4 国产化终端的日常运维命令行是绕不过去的设备上线之后运维才是长跑。国产化终端里很多现场工程师最不习惯的就是没有图形化工具什么都要敲命令行。这里我把最常用的几个动作整理一下都是实测可用的。进入命令行一般有这么几种途径串口调试口板子上通常有调试串口波特率常见115200、SSH设备开了网口和SSH服务的话、以及通过ADB类似的调试通道。现场最稳的是串口因为它不依赖网络设备网络配错了也能进去救。登录之后文件操作是最基础的。查找文件用find删除用rm但这两个命令在设备上要格外小心# 按名称查找限制深度避免遍历整个文件系统拖慢设备 find /data/app -maxdepth 3 -name *.log -type f # 按时间查找找出最近一天修改过的配置 find /etc -type f -mtime -1 # 查看大文件占用找出是谁把空间吃掉了 du -sh /data/* | sort -rh | head -10 # 删除前先确认强烈建议先 ls 一遍 ls /data/log/2024*.log rm -f /data/log/2024*.log # 危险操作不要碰这几条删了设备就起不来了 # rm -rf /system /vendor /data/service我的习惯是任何rm -rf之前必须先跑一遍对应的ls确认输出的是你想删的东西。这个习惯救过我至少三次。还有一条设备上如果做的是只读文件系统删除操作会失败或者重启后恢复别以为是没删掉先确认挂载方式。5. 常见问题与排查技巧实录5.1 现场故障速查表这张表是我这些年攒下来的基本上现场八成的报修都能对上号现象可能原因排查方向刷脸没反应屏幕正常识别服务进程挂了查进程、看日志最后一行、确认内存是否耗尽识别变慢越用越卡人脸库过大或内存泄漏看内存曲线是否持续上涨确认1:N检索规模偶尔误开别人的门阈值过低或特征相似调高阈值检查是否用了质量过差的注册照片刷卡无效人脸正常韦根线序或读头供电量电压、换线、确认协议位数门锁吸合但门没开机械卡滞或电锁功率不足手动推门测试量电锁供电电流设备频繁重启电源不稳或看门狗误触发测电源纹波延长喂狗周期查是否有死循环网络时通时断IP冲突或网线质量换静态IP用长ping观察丢包红外活体误拒补光不足或镜头脏污清洁镜头检查红外灯是否点亮表格只能给方向真正的定位还得看日志。我强烈建议在固件里做一个本地日志滚动机制保留最近若干天的关键事件别指望现场连网去平台捞日志很多时候网络本身就是故障原因。5.2 识别率调优先看数据再动参数调优这件事最忌讳的就是凭感觉改参数。我的做法是固定一套测试流程准备一个测试集包含本单位真实人员的照片这是关键用一个公开数据集调出来的参数在你这个单位的灯光下可能完全不适用。在早、中、晚三个时段各测一轮记录每组数据的通过率和平均耗时。只有拿到这个基线你才知道改参数到底有没有用。几个最常调的参数和作用方向检测阈值调低更容易检出人脸但会带来更多误检调高则相反人多的时候可能漏检。质量门限调低更快通过但低质量图片进比对会拉高误识率谨慎下调。比对阈值最敏感的参数每次调整幅度不要超过0.02调完必须重测。跟踪帧数决定目标稳定多久才送比对调大更稳但更慢一般3到5帧。我的经验是先把检测和质量环节调顺让送进比对环节的都是好图再动比对阈值。顺序反了会陷入改了阈值发现还是不稳的死循环。另外一个容易被忽略的点是注册照的质量。很多单位的员工照片是从工牌系统里直接导入的有的模糊、有的侧脸、有的还戴着帽子。这些照片注册进去识别率必然差。正确做法是统一用设备现场采集注册或者至少对导入的照片做质量校验不合格的强制重新采集。这一步做扎实识别率能提升一大截比调参数有效得多。5.3 稳定性与功耗决定设备能不能活满五年门禁设备的交付周期一般标五年实际很多人希望用八年。能不能撑住看三件事。散热。带NPU的主控满载时发热不小而门禁机的结构往往很小、甚至全封闭。我做过的项目里夏天高温环境下设备表面温度能到六七十度长期下来eMMC寿命衰减很快。解决办法是降低推理频率——没必要每帧都跑人脸检测可以按固定间隔执行配合运动检测触发。这一调整能把平均功耗降下来不少。写操作次数。eMMC有写入寿命日志和记录如果无节制地写几年下来可能就写坏了。我一般会把日志分区单独划出来做滚动覆盖通行记录先写内存队列批量落盘避免每条记录都触发一次写盘操作。断电保护。门禁断电是常态但断电瞬间如果在写数据可能造成文件系统损坏。方案里要么加超级电容做掉电保存要么把关键数据做成先写临时文件再原子替换的方式避免写到一半断电留下半个文件。6. 信创选型与合规资料的一份实操清单6.1 认证和目录怎么看别被销售话术带跑信创相关的认证和目录种类不少名称也容易混。作为方案负责人你需要搞清楚的是你交付的这台设备具体要满足甲方的哪一条要求。有的项目只要求操作系统和芯片在目录内有的项目要求整机有检测报告有的还要求软件著作权和代码自主率说明。这三种要求对应的准备工作量差得很远。我的建议是做一份资料清单逐项确认资料项由谁提供常见问题芯片国产化说明主控厂商型号写法和目录不一致需要厂商出函操作系统版本说明系统方案商版本号要能对应到具体发布版本整机检测报告整机厂商送检样机和量产机不一致会出问题软件著作权开发方著作权名称和产品名称对不上密码模块相关材料安全模块供应商用了国密算法但拿不出证明材料数据安全说明方案方人脸数据存储和清除流程说明缺失这里面最容易出问题的是型号一致性。芯片厂商的正式型号、目录里的登记型号、你BOM里的写法经常是三套不同的字符串。交付前一定要把这些对齐让厂商出一份盖章的说明。这个事在项目后期做会非常被动最好在选型阶段就锁定。6.2 方案选型的几个判断标准最后说点选型上的个人偏好供参考。第一看系统的长期维护能力不看一时的功能列表。开源鸿蒙的版本迭代比较快选方案商的时候要问清楚这个版本你们计划维护几年安全补丁怎么跟系统大版本升级的时候我的应用要不要跟着改这些问题答不上来的后期大概率会变成孤儿版本。第二看驱动适配的完备程度不看演示效果。演示的时候接一路摄像头、一个继电器谁都能跑通。要问的是韦根读头支持哪些协议位数RS485能不能做梯控消防输入是否支持硬联动这些边角料才是门禁的真实工作量所在。第三看数据方案是否经得起追问。人脸数据怎么存、存多久、怎么删、谁能看到这四个问题如果有任何一个答得含糊就别往高安全场景里推。宁可多花点成本做加密存储和分级权限也别在验收环节被卡住。第四算总成本不算设备单价。国产化门禁的单台价格通常比同规格的安卓设备略高但要看全周期功耗、故障率、运维人力、替换周期。我做过几个项目的粗略测算如果一台国产设备能多稳定运行两年省下的现场维护人力和停用损失基本能覆盖掉这部分差价。当然这个账每个项目情况不同得按实际算。我个人在实际操作中的体会是门禁国产化这件事技术难点其实集中在外设适配和现场调试这两块系统本身反而不是最大的障碍。真正让项目翻车的往往是资料不齐、型号对不上、卡迁移没测、试点没跑够。这些活儿看着琐碎但它们决定了一个方案是从能演示走到能交付还是停在PPT里。最后再分享一个小技巧做这类替换项目的时候我会在库房里额外留两台调试机一台保持出厂状态一台保持和生产完全一致的固件。现场出了问题可以立刻拿同配置机器复现比远程猜要快得多。这个习惯是从一次半夜被叫去机房、结果发现是现场网络配置错了之后养成的代价不小但很值。