3.1.1 日常巡查场景

日常巡查通常由业务科室或基层单位根据管养路线、路段等级、季节特点和重点隐患安排巡查任务，巡查人员驾驶车辆沿既定路线开展巡查。现有方式下，巡查过程多依赖人工观察、纸质记录、手机拍照和事后整理，巡查轨迹、巡查时间、覆盖里程、现场影像和人员记录之间缺少稳定关联。

在长距离、多路段、多气候条件下，人工巡查容易出现记录不完整、问题位置描述不准确、照片与桩号难以对应、是否按计划覆盖线路缺少核验依据等情况。业务科室在事后检查时，往往只能看记录结果，难以准确判断巡查是否真实执行、是否覆盖重点路段、是否存在漏巡和漏记。

3.1.2 病害发现与识别场景

巡查过程中发现路面裂缝、坑槽、沉陷、拥包、路肩损坏、交安设施异常等问题后，巡查人员需要记录病害类型、位置、照片、简要描述和处置建议。现有方式依赖人员经验，病害名称和严重程度判断口径不容易统一，部分轻微或连续性病害容易被漏看，夜间、逆光、降雪、扬尘等环境也会影响人工判断。

对于管理部门而言，病害发现不仅要“看到问题”，还要能够形成可审核、可定位、可转办的结果。若病害图片、坐标、桩号、路线、发现时间和巡查任务不能绑定，后续审核、派单和复核都会增加沟通成本。

3.1.3 任务派发与处置场景

病害确认后，业务科室需要根据病害类型、影响范围、处置难度和责任范围，将问题交办至对应基层单位、养护站或处置队伍。现有工作中，任务派发可能通过电话、微信群、纸质单据或表格流转完成，处置要求、完成时限、责任边界和现场证据不一定完整记录。

这种方式在少量问题时可以运行，但当巡查频次提高、病害数量增加、责任单位较多时，容易出现任务遗漏、重复交办、处置状态不清、逾期任务难提醒、整改过程难追踪等问题。管理层也难以及时掌握每个问题当前处于待派发、待处置、处置中、待复核还是已归档状态。

3.1.4 整改复核与归档场景

养护处置人员完成整改后，通常需要反馈现场照片、处置说明和完成时间，由复核人员或业务科室确认整改质量。现有方式下，整改前后照片、现场位置、工单要求和复核结论之间容易分散保存，复核人员需要通过线下沟通确认问题是否处理到位。

如果复核不合格，需要退回重办，但退回原因、再次整改、再次复核的过程往往缺少完整留痕。长期看，这会影响质量追溯、责任界定和养护成效评价，也不利于形成标准化的病害处置档案。

3.1.5 统计分析与领导监管场景

业务科室需要定期汇总巡查里程、发现病害数量、病害类型分布、整改完成情况、逾期任务、重点路段和各单位处置效率。现有统计多依赖人工汇总表格，数据来源分散，口径容易变化，临时调取历史数据和形成专题分析成本较高。

领导监管更关注辖区路况总体态势、重点隐患位置、任务推进情况、整改闭环率和养护资源使用效果。如果缺少持续沉淀的数据，监管只能依赖阶段性汇报和人工整理材料，难以及时发现趋势性问题和薄弱环节。

3.3.1 一线巡查人员需求

出车前，巡查人员需要明确当天巡查路线、起止范围、重点关注路段、车辆设备状态和任务要求。系统应支持任务领取、车辆与设备状态检查、定位和采集设备自检，避免车辆已经出发后才发现设备未启动、定位异常或任务信息不完整。

巡查中，巡查人员主要任务是安全驾驶、观察路况和处理突发情况，不宜承担大量手工录入工作。系统应自动采集视频、图片、轨迹、时间、坐标和速度信息，对明显异常可支持快速标记或补充说明，减少停车记录、反复拍照、事后回忆位置等工作。

巡查后，巡查人员需要确认本次任务是否完成、数据是否上传、是否存在采集中断或弱网未回传数据。系统应提示采集完整性、轨迹覆盖情况和补传状态，使一线人员能够在任务结束时完成必要确认，减少后台审核阶段才发现数据缺口的情况。

3.3.2 业务科室需求

计划管理方面，业务科室需要根据管养路线、重点路段、季节性病害和上级检查要求安排巡查任务，并核验巡查是否按计划执行。系统应提供计划下发、任务状态、轨迹回放、覆盖里程和异常记录，支撑业务科室判断巡查质量。

病害审核方面，业务科室或审核人员需要对 AI 输出的疑似病害进行确认，判断病害类型、严重程度、位置和图片证据是否满足派单要求。系统应提供审核、修正、退回、重复合并和样本留存功能，保证进入工单环节的数据是经过业务确认的结果。

派单督办方面，业务科室需要把审核通过的病害转化为可执行任务，明确责任单位、处置要求和完成时限，并持续跟踪处置进度。系统应让业务科室能够看到每个工单的来源、状态、逾期情况和复核结果，避免任务只交办、不跟踪。

统计上报方面，业务科室需要形成月报、专项统计、整改情况和上级检查材料。系统应沉淀统一口径的数据，支持按路线、路段、单位、病害类型、时间周期和工单状态进行统计导出。

3.3.3 养护处置人员需求

接单时，处置人员首先需要看清任务来源和处置要求，包括路线、桩号、坐标、现场照片、病害类型、影响范围、完成时限和责任单位。系统应把这些信息集中在工单中，避免处置人员再通过电话、群消息或多张表格反复确认。

到场时，处置人员需要能够根据坐标、桩号和图片快速找到问题位置。对于长距离干线公路，位置描述不清会直接影响处置效率。系统应支持地图定位、现场图片查看和必要的导航辅助，使工单能够指导现场作业。

处置后，处置人员需要反馈整改说明、完成时间和现场照片。系统应支持移动端或现场便捷上传，反馈内容应与原病害和工单自动关联，为后续复核和归档提供证据。

3.3.4 复核人员需求

复核人员需要对照原始病害、处置要求和整改反馈判断是否达到要求。系统应在复核页面同时呈现原始病害照片、定位信息、工单要求、整改照片、处置说明和历史流转记录，使复核结论有充分依据。

对于整改不到位的情况，复核人员需要明确退回原因、补充要求和再次整改时限。系统应保留退回、再次整改、再次复核的全过程记录，避免质量问题在口头沟通中消失，也便于后续追溯责任和分析常见整改问题。

3.3.5 管理层与领导监管层需求

管理层关注日常业务是否稳定运行，包括巡查覆盖率、病害发现效率、整改完成率、逾期任务、重点路段和各单位处置质量。系统应提供稳定的统计口径和周期性报表，支撑资源调度、考核评价和工作督办。

领导监管层更关注辖区路况总体态势、重大隐患、任务推进和养护成效。系统应通过地图和看板呈现重点信息，让领导能够快速看到风险在哪里、任务卡在哪里、整改推进到什么程度，减少层层询问和临时汇总。

从监管角度看，系统不应只提供静态数据展示，还应能够把巡查、病害、工单、复核和统计结果串联起来，支撑对重点路段、重点病害、重点单位和高频问题的持续跟踪。

4.2.1 车载采集层

车载采集层是整个系统的数据入口，部署在巡查车辆上，主要承担道路影像采集、定位采集、轨迹记录、车辆状态记录和本地数据缓存等任务。该层包括视频采集设备、边缘计算或存储终端、北斗定位模块、通信模块、供电及安装附件、作业交互终端等组成部分。

巡查车辆按计划路线行驶时，车载采集层应自动记录道路前方或重点视角影像，同步记录采集时间、经纬度、速度、方向、车辆、人员和任务信息。对于弱网或无网路段，车载端应具备本地缓存能力，保证巡查数据不因网络波动丢失。

从业务衔接看，车载采集层不仅是“拍视频”，还要为后续 AI 识别、病害定位、巡查核验和责任追溯提供基础数据。只有把影像、轨迹、时间、坐标和任务绑定起来，后续平台才能判断巡查是否执行、病害在哪里、数据是否完整。

4.2.2 网络传输层

网络传输层负责把车载端采集的数据稳定、安全地回传到平台侧。考虑新疆国省道干线公路路段长、区域跨度大、部分路段通信条件不稳定，传输设计不能假设全程网络连续可用，应同时支持移动网络回传、本地缓存、断点续传和恢复网络后的自动补传。

在巡查过程中，系统可根据网络状态对视频、图片、轨迹和识别所需数据进行分级传输。对于病害截图、轨迹、任务状态等关键业务数据，应优先回传；对于大体量视频或历史影像，可按策略分批上传，避免占用过多带宽影响业务使用。

网络传输层还应满足安全传输要求，对接口访问、数据上传、用户认证和传输链路进行必要保护，防止巡查数据在传输过程中出现丢失、错传或未授权访问。该层的建设目标是让一线巡查不受弱网环境明显影响，让业务科室能够在平台端及时看到可用数据。

4.2.3 AI 识别处理层

AI 识别处理层负责把车载采集的影像数据转化为可供业务审核的疑似病害结果。处理过程包括图像质量筛选、关键帧提取、病害目标识别、病害类型判断、置信度输出、截图留证、坐标和桩号匹配、重复病害合并等环节。

该层不应直接把模型识别结果当成最终业务结论，而应形成“AI 初筛 + 人工审核”的工作机制。AI 识别用于提高发现效率和降低人工漏看风险，人工审核用于确认病害类型、位置、严重程度和是否进入后续处置流程。这样既发挥智能识别效率，又避免误报直接影响工单派发。

从长期运行看，AI 识别处理层还应支持样本沉淀和模型优化。审核中确认的正确识别、误报、漏报、重复病害和退回样本，都可以作为后续模型优化和识别规则调整的依据，使识别效果逐步贴合本地道路、气候和病害特征。

4.2.4 平台应用层

平台应用层承载巡查养护业务闭环，是业务人员日常使用的主要界面。平台应围绕巡查计划管理、病害管理、地图展示、工单管理、整改复核、统计报表、权限管理和日志审计组织功能，按业务流程配置页面和数据关系。

在业务流程中，平台应用层负责接收车载采集和 AI 识别结果，提供病害审核、任务派发、处置反馈、复核归档和统计分析能力。业务科室可以在平台上核验巡查计划执行情况，审核疑似病害并转为工单；基层单位和处置人员可以查看任务、定位问题并反馈整改；管理层可以查看巡查覆盖、病害分布、整改进度和逾期情况。

该层的建设目标是把原来分散在纸质记录、表格、电话和群消息中的业务流转统一到平台中，使每个病害从发现、审核、派发、整改、复核到归档都有状态、有责任、有证据、有时间记录。

4.2.5 数据治理层

数据治理层负责统一系统运行所需的基础数据、业务字典、状态口径和统计规则。基础数据包括路线、路段、桩号、管养单位、车辆、人员、设备、病害类型、责任单位等；业务数据包括巡查任务、轨迹、影像、病害、工单、整改、复核和归档资料。

在项目实施中，应对路网、路线名称、桩号范围、单位层级、人员角色和病害分类进行初始化配置，保证平台数据与客户实际管养体系一致。病害状态、工单状态、复核状态、逾期规则和报表口径也应统一配置，避免不同科室、不同单位统计口径不一致。

数据治理层的价值在于把一次次巡查和处置过程沉淀为长期可用的数据资产。通过统一口径，可以支撑病害趋势分析、重点路段识别、单位处置效率评价、养护资金安排和长期科学决策。

4.2.6 运维安全层

运维安全层贯穿设备、网络、平台、数据和模型全流程，保障系统长期稳定运行。该层应包括用户权限控制、角色授权、日志审计、设备状态监测、接口监测、数据备份、故障处理、模型优化、系统升级和应急预案等内容。

在日常运维中，需要持续关注车载设备在线率、数据回传情况、存储容量、接口调用状态、平台访问状态和异常日志。对于设备离线、定位异常、数据上传失败、接口异常、识别服务异常等问题，应形成发现、派发、处理、反馈和归档的运维闭环。

安全管理方面，应按人员职责配置访问权限，保证巡查人员、业务科室、处置单位、复核人员、系统管理员和领导监管层只能访问与岗位相关的数据和功能。系统操作日志、数据修改记录和业务流转记录应可审计，满足项目验收、问题追溯和长期运维管理需要。

5.1.1 视频采集设备

视频采集设备负责获取道路前方及重点视角影像，是病害识别和人工复核的主要证据来源。安装时应保证视野覆盖车道、路肩、附属设施等巡查重点区域，尽量减少车体遮挡、反光、强抖动和画面偏斜。

在巡查过程中，摄像设备随车连续采集道路画面，采集数据与时间、坐标、路线和车辆信息同步绑定。后续 AI 识别所需的关键帧、病害截图和人工审核图片，均来自该设备采集的原始影像。

5.1.2 边缘计算或存储终端

边缘计算或存储终端负责接收、缓存和管理车载采集数据，并根据系统配置完成数据切片、质量初筛、任务状态记录和上传队列管理。对于网络不稳定路段，终端应先保存本地数据，待网络恢复后继续回传。

该终端也是车载设备运行状态的管理节点，可记录摄像头、定位、通信、存储和供电状态。巡查人员或运维人员通过状态提示判断设备是否正常，减少出车后才发现数据缺失的情况。

5.1.3 北斗定位模块

北斗定位模块负责采集车辆行驶过程中的经纬度、速度、方向和时间信息，并与视频图像同步。定位数据是巡查轨迹、病害位置、路线匹配和桩号换算的基础。

在业务使用中，定位结果既用于车辆轨迹展示，也用于病害处置。每一条疑似病害都应尽量关联坐标、路线、桩号、方向和采集时间，使处置人员能够准确到达现场，复核人员能够回查原始位置。

5.1.4 通信模块

通信模块负责车载端与平台之间的数据连接，支撑巡查任务下发、设备状态上报、轨迹回传、病害截图上传和巡查数据补传。考虑干线公路部分路段存在弱网、断网情况，通信模块应与本地缓存和断点续传机制配合使用。

系统应根据网络状态合理安排上传内容。任务状态、轨迹、病害截图等关键业务数据优先回传，大体量视频可按策略分批上传，避免因带宽不足影响业务闭环。

5.1.5 供电与安装附件

供电与安装附件保障车载设备随车稳定运行，包括取电、固定支架、线缆、防松动、防震和必要的保护措施。安装应兼顾采集视角、车辆安全、后期检修和日常使用便利，避免遮挡驾驶视线或影响车辆原有功能。

车辆长期运行中，振动、温差、灰尘和日常维护都会影响设备稳定性。因此安装方案应便于巡检和更换，线缆连接、固定点位和取电方式应形成记录，方便后续运维人员排查问题。

5.1.6 作业交互终端

作业交互终端用于巡查人员查看任务、确认设备状态、接收异常提示和完成必要的人工标记。其设计应尽量简洁，避免增加驾驶和巡查负担，重点提供任务开始、任务结束、设备自检、异常提醒、数据上传状态等信息。

对于一线人员而言，交互终端不应变成新的填报负担，而应帮助其确认“任务是否领取、设备是否正常、数据是否采集、异常是否提示、任务是否完成”。

5.4.1 采集视角要求

视频采集设备应覆盖道路前方主体区域，并结合巡查重点兼顾路面、标线、路肩、边沟、护栏、标志标牌等对象。安装角度应保持稳定，避免画面长期偏向天空、车内、路侧无关区域或被雨刷、仪表台、遮阳板等遮挡。

对于双向或多车道道路，应根据车辆巡查方向和管理要求确定采集视角，保证巡查影像能够说明车辆实际经过的路段和路侧设施状态。

5.4.2 画面质量要求

采集画面应满足病害识别和人工查看需要，画面主体应清晰、稳定、不过度模糊，不应长期出现严重过曝、欠曝、抖动、遮挡、雨雪污渍覆盖等情况。系统应对低质量片段进行标记，便于运维人员判断是设备问题、安装问题还是环境问题。

对于 AI 识别而言，画面质量越稳定，误报和漏报越容易控制。对于人工审核而言，清晰图像可以减少反复回看视频和线下确认位置的工作量。

5.4.3 时间与空间信息绑定要求

影像采集应同步绑定采集时间、经纬度、车辆、人员、路线、任务等信息。病害截图或关键帧不能成为脱离上下文的单张图片，而应能追溯到对应巡查任务、车辆轨迹和采集位置。

当病害进入审核、派单和复核环节时，平台应能够展示原始图片、采集时间、路线桩号、坐标和巡查轨迹，使业务人员判断病害来源可靠、位置可达、证据完整。

5.4.4 连续性与完整性要求

巡查采集应尽量保持连续，避免频繁中断造成路段缺口。系统应记录采集开始、暂停、恢复、结束和异常中断时间，便于业务科室核验巡查覆盖情况。

对于因停车、绕行、网络异常、设备异常导致的数据缺口，应在巡查记录中保留异常原因和时间范围，必要时安排补巡或人工确认，避免数据缺失影响巡查评价。

5.5.1 定位数据采集

车辆巡查过程中应持续记录经纬度、时间戳、速度、方向和定位状态。定位信息应与视频帧、图片、任务和车辆信息同步，避免出现“有图片无位置”或“有轨迹无影像”的情况。

定位数据应能够支撑平台查看车辆巡查轨迹、计算覆盖里程、判断巡查时间，并为病害点位生成提供基础坐标。

5.5.2 路线与桩号匹配

系统应结合基础路网数据，将车辆坐标匹配到对应路线、路段和桩号范围。对于养护处置人员而言，桩号和路线名称通常比经纬度更便于现场使用，因此病害成果应同时保留坐标和桩号信息。

路线匹配还可以用于判断车辆是否偏离计划路线、是否覆盖重点路段、是否存在重复巡查或漏巡区域，为业务科室核验巡查质量提供依据。

5.5.3 轨迹回放与巡查核验

平台应支持按任务、车辆、人员、路线和时间查看巡查轨迹，并能与影像采集记录关联回放。业务科室可通过轨迹核验巡查是否按计划执行、车辆是否经过重点路段、采集数据是否与路线一致。

轨迹回放不仅用于事后查看，也用于管理评价。通过轨迹、里程、时长和采集完整性，可以形成巡查覆盖率、有效巡查里程和异常路段等管理指标。

5.5.4 异常定位处理

在隧道、山区、遮挡区域或信号较弱路段，可能出现定位漂移、短时丢星、坐标跳变等情况。系统应记录定位异常状态，并结合轨迹连续性、路线匹配和人工校核进行处理。

对于定位异常导致的病害位置不确定，平台应在审核环节提示人工确认，必要时通过前后轨迹、原始影像和路线桩号进行修正，避免错误位置直接进入工单处置。

5.6.1 网络异常处理

当车辆进入弱网或断网区域时，车载端应继续本地采集和缓存数据，不应因网络中断停止巡查记录。网络恢复后，系统按任务、时间和数据类型自动补传，并记录补传状态。

平台端应能够查看数据是否已回传、是否存在待补传片段、是否补传失败。对于长时间未回传的数据，应提示系统管理员或运维人员处理。

5.6.2 设备异常处理

摄像头离线、存储不足、供电异常、终端重启、通信模块异常等问题，会直接影响采集完整性。系统应在出车前和巡查过程中提供设备状态检查，发现异常时提示巡查人员或运维人员。

设备异常应形成记录，包括异常时间、车辆、设备、影响范围和处理结果。对于影响巡查质量的异常，应支持后续补巡、数据补充或运维工单处理。

5.6.3 定位异常处理

定位漂移、坐标丢失或轨迹跳变会影响病害位置和巡查核验。系统应保留异常定位状态，并在平台端对异常轨迹进行提示，避免将明显异常位置作为最终病害坐标。

病害审核人员可结合前后轨迹、道路影像、路线方向和桩号规则对位置进行确认或修正。修正过程应保留记录，保证后续处置和归档可追溯。

5.6.4 图像质量异常处理

雨雪、扬尘、逆光、夜间照明不足、镜头污渍、强烈抖动等因素可能导致图像质量下降。系统应对低质量图像进行标记，避免低质量数据直接影响 AI 识别结果。

对于连续出现图像质量异常的车辆或设备，应纳入运维检查范围，判断是否需要清洁镜头、调整安装角度、检查固定支架或更换设备。

5.6.5 任务中断与补充记录

巡查过程中如因车辆故障、临时绕行、交通管制、恶劣天气或人员操作导致任务中断，系统应记录中断时间、位置和原因。任务恢复后，应继续关联原任务或形成补充巡查记录。

业务科室可根据中断范围判断是否需要补巡。补巡记录应与原巡查计划关联，避免巡查覆盖情况失真。

7.1.1 巡查计划管理

服务环节：巡查准备、任务下发、车辆安排、执行核验。业务科室可根据路线、路段、周期、巡查频次、重点区域和专项任务制定巡查计划，明确巡查车辆、巡查人员、计划时间、路线范围和任务要求。

使用人员：业务科室负责计划制定和核验，巡查人员或车辆驾驶员接收任务并执行，车辆管理人员配合车辆安排，系统管理员维护车辆、人员和路线基础数据。

功能要求：支持计划新增、编辑、下发、变更、取消、完成确认和查询统计；支持按路线、车辆、人员、时间周期查看任务；支持计划与实际轨迹、采集时长、覆盖里程和异常记录关联。通过该功能，招标要求中的巡查作业管理、车载采集数据留痕和任务执行核验可以落到平台流程中。

7.1.2 病害管理

服务环节：AI 识别、人工审核、病害入库、病害转办。车载采集数据经 AI 初筛后形成疑似病害，病害管理功能负责承接识别结果，并由审核人员确认是否进入正式病害库。

使用人员：病害审核人员查看识别结果，业务科室确认病害是否需要处置，基层单位可查看与本单位相关的病害信息。对于疑似误报、重复病害或位置不准的结果，应由审核人员修正、合并或退回。

功能要求：支持病害图片、视频片段、路线、桩号、坐标、采集时间、病害类型、置信度、审核状态和审核意见展示；支持病害确认、类型修正、位置修正、重复合并、误报退回、人工补录和病害转工单。该功能响应招标文件中图像或视频处理、病害识别、识别结果管理和人工审核的要求。

7.1.3 地图展示

服务环节：空间定位、巡查核验、病害查看、路段监管和现场处置。地图展示功能将巡查轨迹、病害点位、工单状态、责任区域和重点路段叠加在统一地图中，解决“问题在哪里、车辆巡到哪里、任务推进到哪里”的管理问题。

使用人员：领导监管层通过地图掌握辖区总体态势，业务科室查看巡查覆盖和病害分布，基层处置人员根据地图定位现场，系统管理员维护路网和图层基础数据。

功能要求：支持路线、路段、桩号、坐标、病害点位、巡查轨迹、热力分布、工单状态和重点路段展示；支持按时间、路线、病害类型、责任单位和工单状态筛选；支持点位详情查看和轨迹回放。该功能响应招标文件中定位、地图展示、巡查轨迹管理和病害空间化管理要求。

7.1.4 工单管理

服务环节：任务派发、责任落实、过程跟踪和逾期督办。经审核确认的病害可转为工单，平台应把病害位置、图片证据、处置要求、责任单位和完成时限同步带入工单，避免二次录入和信息丢失。

使用人员：业务科室负责派单和督办，基层公路段或养护站负责接收任务，养护处置人员负责现场处置，管理层查看各单位任务推进和逾期情况。

功能要求：支持病害转工单、责任单位选择、处置要求填写、完成时限设置、工单接收、状态流转、催办提醒、逾期标识、退回重派和批量查询。工单状态应覆盖待派发、待接收、处理中、待复核、已完成、已归档、逾期、退回等业务节点。该功能响应招标文件对任务派发、处置跟踪和闭环管理的要求。

7.1.5 整改复核

服务环节：现场整改、材料反馈、复核验收、退回重办和归档。处置人员完成整改后，应通过平台上传整改说明、现场照片、完成时间和必要的补充材料，复核人员依据原始病害和整改反馈判断是否合格。

使用人员：养护处置人员负责反馈整改结果，复核人员负责质量核验，业务科室负责监督闭环，管理层可查看整改完成率和退回情况。

功能要求：支持整改材料上传、前后照片对比、复核意见填写、合格归档、不合格退回、再次整改、再次复核和历史记录查询。复核结论应与病害、工单、处置人员、复核人员和时间节点关联，形成完整证据链。该功能响应招标文件对整改复核、验收归档和全过程留痕的要求。

7.1.6 统计报表

服务环节：业务汇总、绩效评价、领导监管和科学决策。统计报表功能将巡查计划、轨迹、病害、工单、整改、复核和运维数据进行汇总，形成可查询、可导出、可复盘的管理数据。

使用人员：业务科室用于月报、专项汇总和上报材料，管理层用于考核评价和资源调度，领导监管层用于查看路况态势、重点隐患和整改推进情况。

功能要求：支持按路线、路段、单位、车辆、人员、病害类型、时间周期、工单状态、整改时效和逾期情况统计；支持巡查覆盖率、病害数量、整改完成率、复核通过率、逾期率、重点路段和趋势分析；支持报表导出和历史查询。该功能响应招标文件对数据统计、成果输出和管理分析的要求。

7.1.7 权限管理

服务环节：组织协同、分级管理、数据边界和账号维护。系统涉及管理部门、业务科室、基层单位、巡查人员、处置人员、复核人员、运维人员和领导监管层，必须按岗位职责配置功能权限和数据范围。

使用人员：系统管理员负责组织、角色、账号和权限维护；业务科室可根据管理需要分配业务角色；运维人员按授权范围处理设备和系统问题。

功能要求：支持组织机构、用户账号、角色权限、菜单权限、数据权限、操作权限和账号启停管理；支持按单位、责任区、角色和业务范围控制可见数据，避免不同层级数据混用或越权操作。该功能响应招标文件对系统管理、安全管理和多角色协同使用的要求。

7.1.8 日志审计

服务环节：操作追溯、安全审计、问题排查和运维管理。日志审计功能记录用户登录、数据新增、修改、删除、审核、派单、整改、复核、导出、接口调用和异常事件。

使用人员：系统管理员和运维人员用于排查故障、定位异常操作和分析系统运行状态；管理人员可在出现争议或质量问题时追溯业务流转过程。

功能要求：支持按用户、时间、功能模块、业务对象和操作类型查询日志；支持异常操作记录、接口调用记录、数据变更记录和导出记录留痕。该功能响应招标文件对系统安全、运行维护、日志审计和可追溯管理的要求。

8.2.1 数据采集闭环

触发节点：业务科室下发巡查计划后，巡查车辆按路线任务开始外业巡查。计划中应明确路线范围、车辆、人员、巡查时间、重点路段和任务要求，使后续采集结果能够与计划对应。

流转过程：车辆行驶过程中，车载端自动采集道路影像、定位坐标、行驶轨迹、速度、方向和采集时间。巡查结束后，平台对采集数据进行回传确认，核验覆盖里程、轨迹完整性、影像质量和异常补传情况。

闭环结果：平台沉淀巡查计划、车辆人员、轨迹、影像、采集时间、覆盖里程、数据回传和异常补传记录。业务科室可以据此判断巡查是否真实执行、重点路段是否覆盖、采集数据是否完整，为后续 AI 识别和责任追溯提供基础。

8.2.2 病害处置闭环

触发节点：AI 从巡查影像中识别出疑似病害，或巡查人员人工补录现场问题后，病害进入审核队列。此时病害仍处于待确认状态，需要经过业务审核。

流转过程：病害审核人员查看病害图片、视频片段、路线、桩号、坐标、类型、置信度和历史同点记录，对识别结果进行确认、修正、合并或退回。审核通过后，病害进入正式病害库，并根据处置需要转为工单。

闭环结果：平台沉淀病害类型、位置、证据图片、识别置信度、审核意见、审核人员、审核时间和历史同点记录。病害成果经过业务确认后，方可作为处置和统计对象使用。

8.2.3 任务管理闭环

触发节点：审核通过的病害需要现场处置、专项核查或责任单位确认时，由业务科室将病害转为工单。工单应继承病害的路线、桩号、坐标、图片和类型信息，减少重复录入。

流转过程：业务科室在工单中明确责任单位、处置要求、完成时限和补充说明，基层公路段、养护站或处置人员接收后开展现场处置。平台跟踪待接收、处理中、待复核、逾期、退回、已完成、已归档等状态，并保留催办记录和状态变化。

闭环结果：平台沉淀工单编号、来源病害、责任单位、处置要求、状态节点、完成时限、催办记录和逾期记录。病害从“被发现”推进到“有人负责、有时限、有过程、有结果”，不再停留在待处理清单中。

8.2.4 验收归档闭环

触发节点：养护处置人员完成现场整改后，提交整改说明、现场照片、完成时间和必要的补充材料，工单进入复核环节。

流转过程：复核人员对照原始病害、处置要求和整改材料进行审核。整改合格的，平台归档病害和工单资料；整改不合格的，填写退回原因和再次整改要求，工单返回处置人员继续处理。多轮整改和复核过程均应保留记录。

闭环结果：平台沉淀整改说明、前后照片、复核意见、退回原因、再次整改记录、归档时间和处置用时。验收归档闭环把“做没做、做得怎么样、谁确认的”转化为可核验档案，支撑质量抽查、责任追溯和后续绩效评价。

8.2.5 数据分析闭环

触发节点：巡查、病害、工单、整改、复核和运维数据持续积累后，平台按管理口径进行统计分析。分析结果用于调整巡查计划、识别重点路段、安排专项治理和优化模型样本。

流转过程：平台按路线、路段、单位、时间、病害类型、工单状态、整改时效、逾期情况和复核结果进行统计，形成巡查覆盖、病害分布、整改效率、重点路段、趋势变化和处置绩效等分析结果。

闭环结果：业务科室可根据分析结果调整巡查频次和重点路段，管理层可据此开展督办和考核，领导监管层可掌握辖区路况态势和养护成效，运维和算法人员可利用误报、漏报、退回样本优化模型与规则。数据分析闭环使养护工作从事后汇总转向持续改进。

9.3.1 《公路技术状况评定标准》JTG 5210-2018

该标准可作为公路技术状况评价、路面损坏指标、重点路段分析和养护决策分析的技术口径参考。本项目在病害管理和统计分析中，应将病害类型、路段分布、发生频次和处置结果按统一口径沉淀，为后续路况评价、重点路段识别和科学养护决策提供数据基础。

落地方式包括：病害分类与道路养护管理口径保持一致；统计报表支持按路线、路段、病害类型和时间周期汇总；重点路段可结合病害高发、重复发生、整改频次和趋势变化进行分析。

9.3.2 《公路养护技术标准》JTG 5110-2023

该标准可用于指导日常巡查、养护处置建议、质量控制、技术文件和养护数据管理。本项目在业务流程设计中，把巡查发现、病害确认、处置整改、复核验收和资料归档纳入统一流程，平台既记录问题，也服务养护管理全过程。

落地方式包括：巡查计划管理支撑日常巡查组织；工单管理支撑养护处置责任落实；整改复核支撑质量控制；统计报表和归档资料支撑养护管理文件和后续检查。

9.3.3 《公路路面技术状况自动化检测规程》JTG/T E61-2014

该规程可作为车载自动化采集、检测数据处理、结果校核和成果报告流程的参考。本项目虽定位为轻量化日常巡查，不等同于重型专项检测，但在数据采集质量、结果校核和成果输出方面应吸收自动化检测的规范化要求。

落地方式包括：明确采集路线、车辆、时间、坐标和轨迹；对图像质量、采集连续性和异常数据进行标记；AI 识别结果须经过人工审核；成果报告应说明数据来源、处理过程、审核结果和统计口径。

9.3.4 《路面损坏视频检测方法》GB/T 26769-2011

该标准可用于视频采集、图像有效性评价、检测数据处理和成果报告。本项目的车载视频采集和病害识别应关注画面清晰度、视野完整性、采集连续性、图像有效性和结果可核验性。

落地方式包括：图像采集标准中明确视角、清晰度、遮挡、抖动、过曝和连续性要求；低质量图像应标记或剔除；病害截图应关联坐标、桩号、时间和原始巡查任务；成果输出应保留图片证据和审核记录。

9.3.5 《公路路面轻量化智能养护巡检技术要求》T/ITS 0259-2024

该团体标准可作为轻量化车载巡查系统、视频智能分析系统和智能应用平台设计的补充参考。本项目采购定位即为轻量化车载智能巡查设备及系统服务，应在车载设备、智能识别、平台应用和业务闭环方面体现轻量化、可部署、可运维的特点。

落地方式包括：车载设备避免重型检测化，优先满足日常巡查稳定采集；AI 识别服务与人工审核结合；平台围绕计划、病害、工单、复核和统计组织功能；运维服务覆盖设备状态、数据回传、模型样本和月度巡检。

9.3.6 视频联网、网络安全与密码算法相关标准

如项目涉及视频联网、平台交换和视频资源接入，可参考《公共安全视频监控联网系统信息传输、交换、控制技术要求》GB/T 28181-2022 的相关接口和交换控制口径。系统安全方面，可参考《信息安全技术 网络安全等级保护基本要求》GB/T 22239-2019，落实身份鉴别、访问控制、安全审计、数据备份和运行维护要求。

如项目环境对国密适配有要求，可结合《信息安全技术 SM2 椭圆曲线公钥密码算法》GB/T 32918-2016 系列进行接口认证、数据传输或平台对接的安全适配。落地时应根据客户现有平台、安全策略和接口要求确定具体实现方式。