我们计划是用 java 写一个跑在工控机的脚本，然后脚本会广播出一个后台管理的网页。脚本还会管理视频流，控制闸道的开启之类的操作。工控机连公网，定期分发配置信息（停车场价格的），然后定期上传订单信息等。
这个方案靠谱吗？还有啥其他更靠谱的方案吗？

没太看懂...

意思是这个脚本还要识别车牌？控制闸机？生成订单？ 但为什么是定期上传呢..

不靠谱

用 java 写一个脚本。。。广播出一个后台管理网页。。。请问 lz 是研发吗？

不识别车牌，车牌识别是摄像头自带的程序。之所以定期上传因为服务器不需要实时的订单信息。

不太懂后台开发。

那有啥更好的方案？我看过一个商业的产品，也是电脑跑一个脚本程序，只是用户端是 PC 客户端。

问题不大吧。
现在停车管理基本这样，但是否 java 跑脚本...我就不清楚。
闸机-摄像头
|
工控机 /x86
|
配置分发(局域网 /互联网)

＃1 一般定期上传都是做备份而已，实际业务估计本地机器进行处理了。

一般是什么语言写的？因为我们后台研发都是 java ，所以首先考虑 java 。

架构和我计划的差不多。难点是脚本有办法自动更新吗？

＃8
C -> C++ -> (JAVA/JS/PY/GO/PHP....)
你要看你工控机配置在去选择，最求性能稳定性的那就 C/C++，资源利用充足且相对稳定。
我之前弄过就餐类的，场景是提前一天 18:00 前确认次日中午 /晚上是否就餐，次日通过二维码识别进行取餐。
后台是 PHP ，本地机器（ x86 工控）是 nodeJS 。

不过你这种场景我不清楚，我用过的停车系统都是包含微信支付的，如果你这个也涉及线上支付的话，要考虑网络环境，一般都是 支付网关<->服务器<->工控机，很少会直接支付完->工控机，这种我只见过崁入式硬件有直接和第三方支付对接的。

第三方支付当然是要联网的，但现在我们系统的问题是，设备如果断网了，包月的车都无法进出。所以有工控机的话，可以局域网保存一个白名单。离线支付的话，我看过阿里巴巴的摄像头的方案，可以用户支付后显示一个二维码，然后给停车场的摄像头去识别。

＃10
说错了，早期是
服务器->本地服务器(nodejs/sqlite)->触摸屏工控机->窗口二维码摄像头
后期改为
服务器->触摸屏工控机->窗口二维码摄像头

一开始是本地服务器是为了缓存第二天点餐信息，后来由于多一台机器多一个维护所以把它取消了。
另外 触摸屏工控机 上是用 C＃开发的界面，主要是显示二维码识别信息和外接音箱播报。
那时候还专门问老板取消了本地服务器的话那断网怎么办。
老板说把产品改名云就餐系统就行了........
最后一直稳定运行至今.

＃11
工控机就做管理就好了，对外提供接口即可。
如：
进：摄像头->车牌->工控机(本地判断是否车位已满)->闸机开
出：摄像头->车牌->工控机(计费方式)->已缴费 /包月 /特殊车牌->闸机开

工控机 API->（ web 形式提供公网 /局域网调用）
1 、获取车牌列表
2 、获取车牌详情
3 、修改 /删除 /新增车牌信息（包月 /特殊车牌..）
4 、获取账单
5 、开闸 /关闸
。。。。。

这样就可以不需要强同步，客户端随便上个 electron ，然后通过本地 api 管理工控机的数据。
如果要外网管理，那通过 ddns 的形式，让外网能访问这台工控机的 api 即可。

＃8 另外用什么语言，
我觉得应该看你的终端设备支持什么语言控制吧，比如我之前弄的二维码扫码的，只有 dll 接口，那就用 C＃来写。
说白了这个控制机只是作为一个控制终端设备，并暴露接口给服务器调用即可。

我是做这个的, 相机(一体机) + 道闸 + 屏卡 + 摄像头监控 , 线上支付平台等等..

相机都是由 TCP 协议支持的, Java 可以做(网络编程这块 用 Netty Mina 都行).
道闸的开闸信息是可以通过相机透传的, 就是闸接到相机上, 屏卡也是 TCP 的一般各种私有协议, 这边也是用 Netty 做的.

相机也可以透传屏卡的信息给屏卡, 屏卡接到相机上.
硬件上总结: 基本都可以用 Java 实现, 岗亭软件用 Java 做的话就是网页端了, 做的最大的科拓(速停车) 也是用 Java 做的
如果车场做桌面端 那就基本上要 C++实现了, 也有不少厂家这么做

线上和车场交互: TCP 长连接, 车场注册到服务端.

线上部分总结: Java 最合适, 支付或者各种线上的信息 命令下发, Sokect 服务端, 肯定 Java 做最合适

普通的摄像头监控: 这个牵扯到存储, 网络带宽等等各种问题, 一般车场本地存 3 个月就拉倒把.. 不然处理很麻烦

相机也会提供动态库接口 , Java 去调用也可以.. 我两种都实现过, 动态库毕竟提供的接口比较少嘛. TCP 是一体机相机最全的接口了

加个 QQ 交流下？ 763818096

工控机有推荐的吗？比如 DDNS 这种功能，有工控机自带吗？还是说要自己开发？

DDNS 对网络有要求的, 必然我在的江苏电信 你很容易要到动态 IP, 移动就不一定了, DDNS 对车场网络有一定要求的, 财大气粗当然都没所谓, 有的甲方甚至自己有 IP, DDNS 实现也很成熟了, 基本不用开发. 我们还是用长链接的形式, 这样车场只要能上外网就行

工控机指的是铁壳子电脑小电脑嘛? 这种就是迷你笔记本, 配置蛮落后的, 我们也主要用这个, 因为我是做 Java 的我也不用管工控机, 但是我自己也是 DIY 玩家.. 我觉得这种铁壳子小电脑也没好到那里去.... 质量还是性价比. 就是普通电脑级别的
我们体量小, 工控机买的也很杂, 因为工控机没什么技术含量, 用的好多年前的 CPU 和硬件.... 各个牌子都用

＃18
DDNS 主要解决的是动态 IP 的问题，但是如＃19 所说，DDNS 最大阻碍就是部分地区运营商不分配外网 IP ，移动家用 100%没公网 IP 且不支持申请。

另外长连接效率确实是更高，并且当工控作为客户端连接服务器时，可以忽略公网 IP 的问题，但是长连接需要自己维护好，主要是心跳重连这一块。

我上面提到的那个项目当时考虑到信息量性能要求不大，所以没使用自行维护长连接，用的是 http 协议的短连接，权鉴直接用 http auth 就可以了。

DDNS 一般第三方都有免费 API ，把外网 IP 获取后通过 API 同步过去就行了。

＃19
X86 工控机性价比确实不高，但是解决了占位和功耗的问题，不是 mini 笔记本，是 itx 主板。itx 的由于是 x86 所以基本兼容大部分语言作为客户端。
如果有崁入式开发经验的，其实 arm 系列的才是最优选择，无论从功耗还是稳定性来说，之前看过 jvm on arm ，但不清楚具体如何，如果 jvm 能在 arm 上完美运行，其实买个 arm 系列的工控可能会更加好。

另外 mqtt+流量卡 好像是现在 IOT 的标配，建议可以关注一下。

1 、长链接就是 socket 这种吗？
2 、工控机淘宝可以搜到，最便宜的大概 600 。配置前期可能不是最要考虑的吧，因为我们程序也不是很复杂。如果后期配置不够，应该可以再找性价比更高的方案。

1 、长连接具体是什么方案？比如在公网的服务器搭建一个 MQTT 服务器？
2 、我们这边没有有嵌入式开发经验的人，暂时也没有这方面预算。然后功耗这块也是小事。之所以用工控机而不用普通的台式电脑，另一方面也是因为觉得以后可以将这个硬件盒子和软件一起打包出售。
3 、选择 x86 上跑 windows 觉得可能本地的维护人员好维护一些，然后可以自己写自动更新脚本的程序可能简单点。

1 、长连接就是建立持久的 tcp 链接。
优点：不需要频繁创建销毁，创建链接后后续消息载体直接通过连接发送，并且可随时客户推去服务器 /服务器推客户端。
缺点：自行维护链接，如网络波动或异常时做好重连。

2 、3 、非性能场景下，其实看维护简易度。这个看你们公司吧。

我之前是 http 短连接的形式，因为不需要服务端推送数据给客户端，都是客户端请求服务端，但是如果联网异常的话没法告警，只能显示屏上显示断网。你用长连接的话可以自己监控链路状态，持续异常多久则服务端发出告警信息。*短连接其实也可以告警，只是我们当初的场景对这个不敏感。

还有一个问题，第三方支付的处理可以放在这个设备里吗？不依赖公网的服务器，如果盒子没固定 IP 的话。因为希望每个盒子之间是相互独立的，即使公网的服务器炸了也不影响停车场设备的运行。

你在做毕业设计吗