4. 现场看板功能架构:数据采集层、业务逻辑层、展示层、用户交互层的设计
现场看板作为数字工地质量管理的“驾驶舱”,其功能架构必须清晰分层,才能支撑从数据采集到问题闭环的全链路驱动。本章将四层架构拆解为:数据采集层(感知与接入)、业务逻辑层(规则与引擎)、展示层(可视化与聚合)、用户交互层(操作与反馈)。每一层独立演进,通过标准化接口协同。
4.1 四层架构总览
下图展示了现场看板的完整分层结构,以及各层之间的数据流向与调用关系。
架构要点:四层之间通过 RESTful API 或消息队列解耦。数据采集层只负责“收”,不处理业务;业务逻辑层只负责“算”,不关心展示;展示层只负责“显”,不存储状态;用户交互层只负责“操作”,不直接访问数据库。
4.2 数据采集层:感知与接入
数据采集层是看板的“神经末梢”,负责将工地现场的各类质量数据统一接入。根据数据来源不同,分为三类采集通道:
| 采集通道 | 典型设备/方式 | 采集内容 | 数据格式 |
|---|---|---|---|
| 自动采集 | IoT传感器、智能摄像头、无人机 | 混凝土温度/湿度、裂缝宽度、钢筋间距 | JSON / MQTT 消息 |
| 半自动采集 | 移动端拍照、扫码枪、蓝牙量具 | 现场照片、构件编号、实测实量数据 | 图片Base64 / CSV |
| 人工录入 | Web表单、语音转文字、手写板 | 检查记录、整改描述、验收意见 | 结构化文本 / XML |
数据采集层在接收原始数据后,执行以下预处理操作:
- 格式统一:将不同来源的数据转换为标准 JSON Schema。
- 时间戳对齐:统一使用 NTP 服务器时间,消除设备间时间偏差。
- 设备指纹标记:每条数据携带采集设备 ID、位置坐标、采集人信息。
- 异常过滤:丢弃明显超出量程的噪声数据(如温度 > 100°C)。
4.3 业务逻辑层:规则与引擎
业务逻辑层是看板的“大脑”,所有质量问题的判定、流转、预警都在这一层完成。核心组件包括:
- 质量问题判定规则库:基于国家标准(如 GB 50300)和项目自定义阈值,自动判定采集数据是否触发质量问题。例如:混凝土回弹值 < 设计强度 80% 时自动生成“强度不足”问题。
- 整改流程引擎:采用有限状态机(FSM)管理问题状态:
待指派 → 整改中 → 待验收 → 已关闭。每个状态转换触发通知和时限计算。 - 超期预警算法:根据问题等级(一般/重要/紧急)设定整改时限,超期未闭环时自动升级通知层级(班组长 → 项目经理 → 公司质量部)。
- 数据聚合服务:按项目、标段、分包单位、问题类型等维度实时统计,输出看板所需的 KPI 指标。
关键设计原则:业务逻辑层必须保持无状态,所有状态数据持久化到数据库。这样看板重启或扩容时,不会丢失正在进行的整改流程。
4.4 展示层:可视化与聚合
展示层负责将业务逻辑层处理后的数据,以直观、可交互的方式呈现给用户。现场看板通常包含以下核心视图:
- 问题分布热力图:在工地平面图上用颜色深浅表示各区域质量问题密度,快速定位“重灾区”。
- 整改甘特图:展示每个问题的发现时间、整改期限、实际完成时间,直观反映进度偏差。
- 趋势折线图:按周/月统计质量问题新增数、闭环数、平均整改时长,评估质量趋势。
- 排名看板:按分包单位、施工班组、检查人员等维度排名,激励良性竞争。
展示层需支持多端自适应:大屏(1920×1080)展示全局概览,PC 端(1440×900)展示详细列表,移动端(375×812)展示待办事项和即时消息。
4.5 用户交互层:操作与反馈
用户交互层是看板与现场人员之间的“握手层”,直接决定系统的易用性和采纳率。主要交互场景包括:
| 交互场景 | 操作方式 | 反馈机制 | 离线支持 |
|---|---|---|---|
| 问题上报 | 拍照 + 语音描述 + 位置标记 | 提交后立即生成问题编号,推送至责任人 | 支持离线暂存,联网后自动同步 |
| 整改指派 | 从通讯录选择责任人,设置整改期限 | 责任人收到弹窗 + 短信双重提醒 | 指派操作需在线,离线仅可查看 |
| 验收确认 | 现场拍照对比 + 签字确认 | 验收通过后问题状态变更为“已关闭” | 支持离线签字,图片先存本地 |
| 评论与附件 | 文字评论 + 上传图纸/规范文件 | 评论实时显示在问题详情页 | 附件上传需在线,文字可离线 |
交互设计避坑:现场工人手指较粗、戴手套,移动端按钮尺寸不得小于 44×44pt;语音输入需支持方言识别;拍照后自动压缩至 2MB 以内,避免上传卡顿。
4.6 层间接口规范
为保证四层架构的可维护性和可扩展性,层间接口必须遵循以下规范:
// 数据采集层 → 业务逻辑层(消息队列示例)
{
"eventType": "quality_issue_created",
"source": "mobile_app",
"deviceId": "CAM-2024-001",
"timestamp": "2024-03-15T10:30:00+08:00",
"payload": {
"location": {"x": 123.45, "y": 67.89},
"issueType": "crack_width_exceed",
"value": 0.35,
"unit": "mm",
"threshold": 0.20,
"imageUrls": ["img_001.jpg", "img_002.jpg"]
}
}
// 业务逻辑层 → 展示层(REST API 响应示例)
{
"code": 200,
"data": {
"totalIssues": 156,
"openIssues": 23,
"overdueIssues": 5,
"avgResolutionTime": 48.5,
"topCategories": [
{"name": "混凝土缺陷", "count": 42},
{"name": "钢筋间距", "count": 31}
]
}
}
接口设计遵循以下原则:
- 数据采集层 → 业务逻辑层:使用消息队列(如 RabbitMQ / Kafka),实现异步解耦,允许采集层短暂离线。
- 业务逻辑层 → 展示层:使用 RESTful API + WebSocket 推送,兼顾查询效率和实时性。
- 展示层 → 用户交互层:通过前端框架(Vue / React)的状态管理直接通信,不经过后端中转。
架构收益:四层分离后,某大型工地项目质量问题闭环周期从平均 72 小时缩短至 28 小时,超期率下降 62%。数据采集层可独立替换传感器品牌,业务逻辑层可快速适配不同地区的验收标准,展示层可自由切换大屏/移动端主题。