这是一个创建于 1001 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们计划是用 java 写一个跑在工控机的脚本，然后脚本会广播出一个后台管理的网页。脚本还会管理视频流，控制闸道的开启之类的操作。工控机连公网，定期分发配置信息（停车场价格的），然后定期上传订单信息等。 这个方案靠谱吗？还有啥其他更靠谱的方案吗？
 |
1
l1ve 2022-02-12 13:10:50 +08:00
没太看懂...
意思是这个脚本还要识别车牌？控制闸机？生成订单？ 但为什么是定期上传呢.. |
 |
2
cssk 2022-02-12 13:13:13 +08:00 via iPhone
不靠谱
|
 |
3
darkengine 2022-02-12 13:36:28 +08:00  1
用 java 写一个脚本。。。广播出一个后台管理网页。。。请问 lz 是研发吗？
|
 |
4
Michelangelono OP @l1ve 不识别车牌，车牌识别是摄像头自带的程序。之所以定期上传因为服务器不需要实时的订单信息。
|
|
5
Michelangelono OP @darkengine 不太懂后台开发。
|
|
6
Michelangelono OP @cssk 那有啥更好的方案？我看过一个商业的产品，也是电脑跑一个脚本程序，只是用户端是 PC 客户端。
|
 |
7
markgor 2022-02-12 13:45:41 +08:00
问题不大吧。
现在停车管理基本这样，但是否 java 跑脚本...我就不清楚。 闸机-摄像头 | 工控机 /x86 | 配置分发(局域网 /互联网) @l1ve #1 一般定期上传都是做备份而已，实际业务估计本地机器进行处理了。 |
|
8
Michelangelono OP @markgor 一般是什么语言写的？因为我们后台研发都是 java ，所以首先考虑 java 。
|
|
9
Michelangelono OP @markgor 架构和我计划的差不多。难点是脚本有办法自动更新吗？
|
|
10
markgor 2022-02-12 13:55:07 +08:00
@Michelangelono #8
C -> C++ -> (JAVA/JS/PY/GO/PHP....) 你要看你工控机配置在去选择，最求性能稳定性的那就 C/C++，资源利用充足且相对稳定。 我之前弄过就餐类的，场景是提前一天 18:00 前确认次日中午 /晚上是否就餐，次日通过二维码识别进行取餐。 后台是 PHP ，本地机器（ x86 工控）是 nodeJS 。 不过你这种场景我不清楚，我用过的停车系统都是包含微信支付的，如果你这个也涉及线上支付的话，要考虑网络环境，一般都是 支付网关<->服务器<->工控机，很少会直接支付完->工控机，这种我只见过崁入式硬件有直接和第三方支付对接的。 |
|
11
Michelangelono OP @markgor 第三方支付当然是要联网的，但现在我们系统的问题是，设备如果断网了，包月的车都无法进出。所以有工控机的话，可以局域网保存一个白名单。离线支付的话，我看过阿里巴巴的摄像头的方案，可以用户支付后显示一个二维码，然后给停车场的摄像头去识别。
|
|
12
markgor 2022-02-12 14:00:41 +08:00
@markgor #10
说错了，早期是 服务器->本地服务器(nodejs/sqlite)->触摸屏工控机->窗口二维码摄像头 后期改为 服务器->触摸屏工控机->窗口二维码摄像头 一开始是本地服务器是为了缓存第二天点餐信息，后来由于多一台机器多一个维护所以把它取消了。 另外 触摸屏工控机 上是用 C#开发的界面，主要是显示二维码识别信息和外接音箱播报。 那时候还专门问老板取消了本地服务器的话那断网怎么办。 老板说把产品改名云就餐系统就行了........ 最后一直稳定运行至今. |
|
13
markgor 2022-02-12 14:16:31 +08:00
@Michelangelono #11
工控机就做管理就好了，对外提供接口即可。 如： 进：摄像头->车牌->工控机(本地判断是否车位已满)->闸机开 出：摄像头->车牌->工控机(计费方式)->已缴费 /包月 /特殊车牌->闸机开 工控机 API->（ web 形式提供公网 /局域网调用） 1 、获取车牌列表 2 、获取车牌详情 3 、修改 /删除 /新增车牌信息（包月 /特殊车牌..） 4 、获取账单 5 、开闸 /关闸 。。。。。 这样就可以不需要强同步，客户端随便上个 electron ，然后通过本地 api 管理工控机的数据。 如果要外网管理，那通过 ddns 的形式，让外网能访问这台工控机的 api 即可。 |
|
14
markgor 2022-02-12 14:19:41 +08:00
@Michelangelono #8 另外用什么语言，
我觉得应该看你的终端设备支持什么语言控制吧，比如我之前弄的二维码扫码的，只有 dll 接口，那就用 C#来写。 说白了这个控制机只是作为一个控制终端设备，并暴露接口给服务器调用即可。 |
 |
15
coala 2022-02-12 14:26:05 +08:00
我是做这个的, 相机(一体机) + 道闸 + 屏卡 + 摄像头监控 , 线上支付平台等等..
相机都是由 TCP 协议支持的, Java 可以做(网络编程这块 用 Netty Mina 都行). 道闸的开闸信息是可以通过相机透传的, 就是闸接到相机上, 屏卡也是 TCP 的一般各种私有协议, 这边也是用 Netty 做的. 相机也可以透传屏卡的信息给屏卡, 屏卡接到相机上. 硬件上总结: 基本都可以用 Java 实现, 岗亭软件用 Java 做的话就是网页端了, 做的最大的科拓(速停车) 也是用 Java 做的 如果车场做桌面端 那就基本上要 C++实现了, 也有不少厂家这么做 线上和车场交互: TCP 长连接, 车场注册到服务端. 线上部分总结: Java 最合适, 支付或者各种线上的信息 命令下发, Sokect 服务端, 肯定 Java 做最合适 普通的摄像头监控: 这个牵扯到存储, 网络带宽等等各种问题, 一般车场本地存 3 个月就拉倒把.. 不然处理很麻烦 |
|
16
coala 2022-02-12 14:27:50 +08:00
相机也会提供动态库接口 , Java 去调用也可以.. 我两种都实现过, 动态库毕竟提供的接口比较少嘛. TCP 是一体机相机最全的接口了
|
|
17
Michelangelono OP |
|
18
Michelangelono OP |
|
19
coala 2022-02-14 08:57:11 +08:00
@Michelangelono DDNS 对网络有要求的, 必然我在的江苏电信 你很容易要到动态 IP, 移动就不一定了, DDNS 对车场网络有一定要求的, 财大气粗当然都没所谓, 有的甲方甚至自己有 IP, DDNS 实现也很成熟了, 基本不用开发. 我们还是用长链接的形式, 这样车场只要能上外网就行
工控机指的是铁壳子电脑小电脑嘛? 这种就是迷你笔记本, 配置蛮落后的, 我们也主要用这个, 因为我是做 Java 的我也不用管工控机, 但是我自己也是 DIY 玩家.. 我觉得这种铁壳子小电脑也没好到那里去.... 质量还是性价比. 就是普通电脑级别的 我们体量小, 工控机买的也很杂, 因为工控机没什么技术含量, 用的好多年前的 CPU 和硬件.... 各个牌子都用 |
|
20
markgor 2022-02-14 09:50:15 +08:00
@Michelangelono #18
DDNS 主要解决的是动态 IP 的问题，但是如#19 所说，DDNS 最大阻碍就是部分地区运营商不分配外网 IP ，移动家用 100%没公网 IP 且不支持申请。 另外长连接效率确实是更高，并且当工控作为客户端连接服务器时，可以忽略公网 IP 的问题，但是长连接需要自己维护好，主要是心跳重连这一块。 我上面提到的那个项目当时考虑到信息量性能要求不大，所以没使用自行维护长连接，用的是 http 协议的短连接，权鉴直接用 http auth 就可以了。 DDNS 一般第三方都有免费 API ，把外网 IP 获取后通过 API 同步过去就行了。 @coala #19 X86 工控机性价比确实不高，但是解决了占位和功耗的问题，不是 mini 笔记本，是 itx 主板。itx 的由于是 x86 所以基本兼容大部分语言作为客户端。 如果有崁入式开发经验的，其实 arm 系列的才是最优选择，无论从功耗还是稳定性来说，之前看过 jvm on arm ，但不清楚具体如何，如果 jvm 能在 arm 上完美运行，其实买个 arm 系列的工控可能会更加好。 另外 mqtt+流量卡 好像是现在 IOT 的标配，建议可以关注一下。 |
|
21
Michelangelono OP 1 、长链接就是 socket 这种吗？
2 、工控机淘宝可以搜到，最便宜的大概 600 。配置前期可能不是最要考虑的吧，因为我们程序也不是很复杂。如果后期配置不够，应该可以再找性价比更高的方案。 |
|
22
Michelangelono OP @markgor
1 、长连接具体是什么方案？比如在公网的服务器搭建一个 MQTT 服务器？ 2 、我们这边没有有嵌入式开发经验的人，暂时也没有这方面预算。然后功耗这块也是小事。之所以用工控机而不用普通的台式电脑，另一方面也是因为觉得以后可以将这个硬件盒子和软件一起打包出售。 3 、选择 x86 上跑 windows 觉得可能本地的维护人员好维护一些，然后可以自己写自动更新脚本的程序可能简单点。 |
|
23
markgor 2022-02-14 14:56:03 +08:00
1 、长连接就是建立持久的 tcp 链接。
优点：不需要频繁创建销毁，创建链接后后续消息载体直接通过连接发送，并且可随时客户推去服务器 /服务器推客户端。 缺点：自行维护链接，如网络波动或异常时做好重连。 2 、3 、非性能场景下，其实看维护简易度。这个看你们公司吧。 我之前是 http 短连接的形式，因为不需要服务端推送数据给客户端，都是客户端请求服务端，但是如果联网异常的话没法告警，只能显示屏上显示断网。你用长连接的话可以自己监控链路状态，持续异常多久则服务端发出告警信息。*短连接其实也可以告警，只是我们当初的场景对这个不敏感。 |
|
24
Michelangelono OP @markgor 还有一个问题，第三方支付的处理可以放在这个设备里吗？不依赖公网的服务器，如果盒子没固定 IP 的话。因为希望每个盒子之间是相互独立的，即使公网的服务器炸了也不影响停车场设备的运行。
|
 |
25
lqw3030 2022-02-14 21:46:02 +08:00
你在做毕业设计吗
|
|
26
Michelangelono OP @lqw3030 公司的产品
|
|
27
lqw3030 2022-02-15 09:53:11 +08:00
@Michelangelono 我前段时间做过，道闸只接收开关信号，建议前期产品未成形前直接用厂商的设备，成型了再考虑替换设备成本优化
|
|
28
Michelangelono OP @lqw3030 厂商的设备是指什么？我们现在已经有在运行的产品了，但道闸是直接连公网的，稳定性和开闸速度都不够好，所以想加个本地控制设备。
|
|
29
Michelangelono OP @lqw3030 还有就是公网断了以后，停车场基本就瘫痪了。
|
 |
30
julyclyde 2022-02-15 12:22:10 +08:00
这东西现在已经成熟了吧
建议抱着学习而不是创业的态度来研究这个东西 |
|
31
Michelangelono OP @julyclyde 客户已经有了，必须要弄出来……
|
|
32
julyclyde 2022-02-15 14:34:19 +08:00
@Michelangelono 找现成的买一套？
|
|
33
Michelangelono OP @julyclyde 我们有免费的人力，但没有钱去买现成的。
|
|
34
Michelangelono OP @julyclyde 最顶级的产品肯定是很成熟了，但大部分市面上用的产品，应该都是不太成熟的。比如我看过主流的产品，一般是一个停车场放一个台式机上面跑一个服务器脚本。但缺点是必须要台式机太占地方了，岗亭端也得是用电脑控制。
|
|
35
julyclyde 2022-02-15 15:52:18 +08:00
@Michelangelono 笔记本电脑也行。这东西也很少“真正无人运行”吧，总要提供紧急开门之类的功能。要不然万一故障了，难道让客户撞杆出去吗？
|
 |
36
lx0758 2022-02-15 15:56:22 +08:00
@Michelangelono 你这所谓的用台式电脑的是很老的方案了, 现在都是无人值守, 数据上云. 很巧我两年年就是做这块的
|
|
37
markgor 2022-02-15 16:09:41 +08:00
@Michelangelono #24 微信支付的话有 IOT 模块，但是我没了解过这个接口。
如果是使用 H5/微信 支付这些接口的话，建议是公网服务器进行接收支付回调，相比客户端设备的网络而言，公网服务器网络稳定很多。 车进库->识别车牌-> [ 工控机 判断是否白名单，记录数据，推送给服务器 ] 车出库->识别车牌-> [ 工控机 判断是否白名单，轮询服务器支付结果] 月租客户： 公众号进入 H5 页面，输入车牌，线上支付月租费用。 工控机：间隔 30 分钟同步一次服务器月租数据。 单次停车： 公众号进入缴费 h5 页面，输入车牌，线上支付费用。 工控机：间隔 1 分钟同步一次服务器支付数据。 如果长连接的话把间隔 X 分钟去掉，有信息服务器推给终端设备即可。 工控机做好数据的同步， 1 、局域网管理的数据，同步上服务器； 2 、服务器的数据，同步到工控机； 自行考虑当断网或人工操作情况下导致数据冲突的情况即可了。要么服务器的为主，要么本地为主...... 预案： 断网： 断网前已开通月租的车辆不受影响，临停车辆支付信息如果在断网前有同步到工控机的也不受影响，其他情况只能人工兜底。 服务器异常： 影响：临时付费的，开通月租的，但已开通月租或已付费临时车不受影响。这一步一样只能人工兜底。另外可以通过监控自主发现异常，一般可能性比较少。 服务器炸了这个情况估计比较少， 哪怕你们有 100 个客户，并发数也高不到哪里去。 如果是轮询形式的，可能服务器压力会大点， 如果是长连接形式的，服务器压力会小很多（因为不需要轮询） 而且停车场出入这些，除非你们是打算做 0 人工值守的，否则有人工做兜底，就算出问题也不会太大。 |
|
38
Michelangelono OP @lx0758 局域网的控制设备的架构有什么建议吗？
|
|
39
Michelangelono OP @julyclyde 现实是很少有完全无人的停车场，但实现无人肯定是目标之一。现在有的停车场已经有远程客服设备了，按一下按钮就可以呼叫客服，可以作为出故障的处理方法。我们现在主要的问题是太依赖公网服务器。
|
|
40
Michelangelono OP 经过几个月的研发第一个版本已经上线跑了几周了，感谢大家。有这方面项目需求和技术问题的也可以随时和我联系。QQ763818096
如果有这方面实际项目经验，后面可能会找兼职，也可以提前沟通下。 []( https://imgtu.com/i/XHngx0) []( https://imgtu.com/i/XHn6Gn) |
Select Language