与 GPS 设备通信时实施规则检查的最佳方式
我们正在开发车辆跟踪系统。与每个 VTS 一样，我们的车辆上安装了 GPS 设备，不断向服务器发送位置信息。在服务器上，我们的 TCP 通信器进程不断读取该数据并将其保存到数据库中 现在，我们需要检查一些规则来触发车辆警报，例如，当车辆到达特定位置时，如果车辆超过特定速度限制等，我们需要警报。 您能建议实施它的最佳方法吗？ 我们想到了一些方法来实现它， 1. 我们的 TCP 通信器在收到位置后，应检查警报。 2. 将有一个进程每 15 分钟运行一次，并检查这 15 分钟内的位置详细信息是否有警报。
我正在寻找逻辑和技术方面实施它的建议。例如我们是否应该使用Drools？等等。
We are developing a vehicle tracking system. Like every VTS, we have GPS devices fitted into the vehicles which keep sending location information to the server. On server, our TCP communicator process keeps reading that data and saves it into the database
Now, we need to check for some set of rule to trigger alerts for the vehicles, e.g We need alert when vehicle reaches to a particular location, if vehicle crosses specific speed-limit,etc.
Can you please suggest the best way to implement it?
We have thought of some ways to implement it,
1. Our TCP communicator, when receives the location, should check for the alerts.
2. There will be a process which will keep running every 15 minutes and check the location details in that 15 minutes for alerts.
I am looking for the suggestions to implement it, logic-wise as well as technology-wise. e.g. Whether we should use Drools or not?, etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
来自 FedEx 的人实际上在几年前我参加的 JavaOne 会议上提出了类似的内容。
基本上，这个想法是，是的，使用 Drools Expert + Fusion 对车辆位置数据执行 CEP（复杂事件处理）。
据我所知，车辆会定期（甚至每隔几秒）将其 GPS 坐标发送到引擎（一个事件），然后规则引擎会消化该坐标，并且根据规则可能会触发某些操作，例如发出警报（“车辆熄火”或“偏离航线”）或发送通知（“车辆将在 15 分钟内到达目的地”）。
（Google 搜索“drools fusion cep 车辆跟踪” 发现这个演示文稿应该会为您提供更多详细信息或至少提供一些见解。）
Somebody from FedEx actually presented something like this in a JavaOne conference I attended a couple of years back.
Basically, the idea was, yes, using Drools Expert + Fusion to perform CEP (complex events processing) on vehicle location data.
As far as I can recall, a vehicle would periodically (every couple of seconds even) send its GPS coordinates to the engine (an event) which would then be digested by the rules engine, and depending on the rules could trigger certain actions such as raising alerts ("vehicle is stalled" or "out of course") or sending notifications ("vehicle will arrive at destination in ~15 minutes").
(Google for "drools fusion cep vehicle tracking" uncovers this presentation which should give you few more details or at least provide some insight.)
Drools 的工作方式是，您将大量对象填充到 Drools 的“工作内存”中。当您填写对象时，Drools 将找出哪些规则在对象上“触发”并将对象存储在 Rete-Tree 中。当您将对象放入内存并触发所有规则后，Drools 将处理您编写的与该规则相对应的代码。
我建议您使用从车辆接收到的规则所需的所有数据创建一个对象，并将其放入工作内存中。
在 Drools 中，您应该制定许多小规则，每个规则只检查一件事并根据结果采取行动。
让 Drools 获取评估所需的数据并不是一个好的做法，但我看不出让 Drools 触发某些事件（将消息发送到车辆或其他系统）有任何问题。 （我想这应该是异步发生的，这样你就不会减慢 Drools 的速度）事实上，Drools 为你提供了连接事件侦听器的功能。
the way Drools work, is that you fill in alot of objects into the "Working Memory" of Drools. While you fill in the objects, Drools will find out which rules "fires" on the objects and stores the objects in a Rete-Tree. When you are finished putting the objects in the memory and you fire all rules, Drools will process the code you wrote corresponding to the rule.
I would suggest, that you make an object with all the data recieved from the vehicle necessary for your rules and put it in the working memory.
In Drools you should make many small rules, each just checking one thing and acting on the result.
It is not a good practice to let Drools get data needed for evaluation, but I can't see any problems in letting Drools trigger some events, that send messages to a vehicle or some other system. (I guess that should happen async, so that you don't slow down Drools) In fact, Drools offers you to hook up an eventlistener.
没有理由每 15 分钟跑一次。这将导致触发器延迟，并导致每 15 分钟出现一次负载突发，然后是无负载期。
您可以在数据库中为新警报规则和新位置数据设置一个标记。当您扫描事件时，可以使用两遍方法。针对所有位置数据检查所有新规则并将其标记为不再新。然后根据现有规则检查所有新位置数据并将其标记为不再是新的。
您可以根据需要多次运行此程序。理想情况下，您不会等待那么久，因为等待的时间越长，积累的工作就越多。
至于让 TCP 通信器通过定期扫描数据库来检查相关警报，主要优点是警报是即时的。缺点是警报处理会减慢 TCP 通信器路径，并且您将被锁定到“一次更新意味着一次检查警报”模型。
在“扫描数据库”方法中，如果负载太高，您可能会仅在来自高频更新源的每一次更新上检查警报。这自然会通过减少所需的工作量来处理负载，但可能会导致错过警报。
我认为您正在考虑的所有方法都会很好用。
There's no reason to run every 15 minutes. That will introduce delay in the triggers and also result in bursts of load every 15 minutes followed be periods of no load.
You can have a flag in your database for new alert rules and new location data. When you scan for events, you can use a two-pass approach. Check all new rules against all location data and mark them no longer new. Then check all new location data against existing rules and mark them no longer new.
You can run this as often as you like. Ideally, you wouldn't wait that long because the longer you wait, the more work you accumulate.
As for having the TCP communicator check for relevant alerts over the scan the database periodically approach, the main advantage would be alerts would be immediate. The disadvantage would be that alert processing would slow down the TCP communicator path and you would be locked into a "one update means one check for alerts" model.
In the "scan the database" approach, if load gets too high, you can wind up checking for alerts only on every so many updates from high-frequency update sources. This naturally deals with load by reducing the amount of work needed, but it could result in a missed alert.
I think all the approaches you're considering will work fine.