GPS, GeoLogging and CEP
I recently purchased a Holux M-231 GPS Logger and have been having some fun geoblogging, for example, see my new microblog, What’s On Chiang Mai, a mashup blog with WordPress and GeoPress. As many of you Geotaggers already know, it is really amazing that you can spend less than $100 USD on a geologger that connects relatively seamlessly with a mobile phone and blog-and-tag within 10 meter accuracy.
Geoblogging is especially useful in countries where the tourist magazines have so many repeated articles about the same “touristy” places, but there is almost no information on how to get to that great mom-and-pop noodle shop, tailor or market that is “off the map”. Geoblogging can and does open up “the world” for tourists, revolutionizing the future of tourism. This, in turn, connects consumers and local producers in ways never before imaginable.
Often, you will read or hear me speak on What is Complex Event Processing?. In most of my talks, presentations, and online discussions, I emphasis the difference between tracking and tracing events and creating higher-order situational knowledge. In the remainder of this post, I will use geologging as an illustration of this concept.
First of all, when you have a geologger in your pocket (I have a big, round one, LOL) you can stream your position (longitude, latitude, altitude, time, speed and direction) to a device, including your cell phone, your computer or even the Internet (via GPRS, for example). This is simply geologging, GPS track-and-trace. Tracking and tracing is a component of an overall event processing architecture and an important component of most CEP applications. However, tracking and tracking alone is not CEP.
As an editorial note, a software vendor recently discussed a simple track-and-trace application of tracking runners and their temperatures (I don’t think they used GPS, only temperature as I recall). The software vendor overhyped this as a great example of CEP in practice. The truth of the matter is that this use case was a logging application, not a true CEP application.
So, what does it take to be a CEP application?
To be a true CEP application there needs to be higher situational knowledge inferred (created) from the lower level events under observation. Let’s turn our attention to GPS, geologging and CEP to illustrate this concept.
Geologging is not CEP. Geologging is tracking and tracing an object based using streaming GPS data (events). Actually, Geologging is a form of event stream processing (ESP) but let’s not introduce more terms today. We can easily track-and-trace objects with GPS (albeit not as accurately as we would like with a $100 logger). Complex event processing is when we take multiple objects and infer (create) higher, complex situational knowledge from lower level data or events.
For example, if we are geologging all the member of a team climbing up a tall, snow capped mountain, we could infer the health and status of the team. Is the team on schedule, ahead of the approaching storms? Is the team currently in good health? Is the team in trouble? We infer these situations because we can track-and-trace each member of the team and infer situations from the relationships between the members of the team (the set of event objects). This is Complex Event Processing.
In another example, let’s say we are geologging the Polar Bears in the Artic. By observing the patterns of their movements over time, as a group, and correlating this with recorded climate changes, we can infer about the effect of global warming and climate change on our fuzzy friends the Polar Bears. This is CEP.
Today, as readers know, we are constantly seeing CEP misrepresented as various logging and track-and-trace applications. Of course, if that was truely the case, then my mobile phone with Nokia Maps and my Holux GeoLogger is a CEP application! Unfortunately, there are still folks who equate lower order logging as CEP; and, as I have mentioned many times, CEP is not about lower order tracking, logging, scheduling or BAM. Tracking is required for many CEP applications; however, a single part of the architecture, in this case track-and-trace, does not define the whole.
If there is any reader who doubts this, I strongly encourage them to enter into the world of GPS and geologging or geoblogging. When you do, you will easily see that our world is ripe with interesting and mature logging and tracking applications. These applications are wonderful; they are very userful; they are very interesting; but they are not CEP. On the other hand, tracking and tracing applications can support an endless, almost unlimited vision, of future CEP applications.
Filed under: Advanced Event Processing, CEP Terminology, CEP Tutorials, Complex Event Processing, Event Processing, Use Cases
GPS + CEP is a very nice combination. We have actually spent some time now to learn ruleCore to read a map
So now it can give instant alerts when it detects that a GPS is in the wrong place at the wrong time.
Very nice to build all kinds of fleet management or mobile asset tracking solutions. We built a simple ‘geofencing’ app on top of ruleCore (The unnamed geospatial version not released yet) and have packaged it as a service which you access through web services.
The idea is that adding live geofencing alert to any telematic application should not be more than a web service call away.
There has been some nice showcase on this topic recently. One from Esper and DataFusionResearchCenter on aircraft identification - http://avasseur.blogspot.com/2008/10/complex-event-processing-and-data.html - and one from Coral8 on an homeland security use case - http://www.coral8.com/blogs/blog-entry/cool-demo-coral8-homeland-security
In both cases there are some visual demos that aim at showing it goes beyond simple track and trace.
There is great value in augmenting the CEP event processing language with some geo functions. It is easy to get done if the EPL supports extensions points and custom user defined functions. Great to hear work from Marco about this.
Hi Alex and Marco,
Yes, I have seen these demos and certainly applaud them. I agree that these demos are starting to move beyond track-and-trace and headed toward object-object correlation and situational inference.
However, relative to current generation systems already in operations, these demos are quite elementary (simple). In other words, you guys are demonstrating a correlation technology that has been around for a few decades.
From a practical perspective, it is still unconvincing how much practical utility these simple rule-based application scenarios have in the real world, compared to existing operational systems that go far beyond these simple demos.
I think it would be more impressive if the demos went much further in the creation of new situational knowledge, versus demonstrating quite simple correlation scenarios on top of track-and-trace.
In other words, these demonstrations are illustrating what many (including yours truly) would call “simple event processing” because the situational scenarios appear to be quite simple. We need to create and solve more complex scenarios, hence “complex event processing”.
Yours faithfully, Tim
Tim, I would agree that the rules needed for this kind of mobile asset tracking are very simple. For us, the reason is that our customers have not asked for anything more complex. There seems to be a small subset of real-world problems where you don’t need very complex event correlations, and still provide good value for the money.
At least our customers tend to have very simple requirements when it comes to this kind of functionality. So for adding simple mobile asset tracking to an application you can easily build the supporting event processing rules for that with ruleCore, Esper, Coral8 or, I suppose, many other CEP products. Other verticals than those we have customers in might need more complex solutions. Military use comes into mind as one of these.
Hi Marco,
Thanks for visiting and posting. I hope you do not my my frankness, but I do not “buy” the (often heard) counterpoint that customers are not asking for more sophistication. In both the use cases you mentioned, they are simple pre-sales demos (for the most part), they are not operational systems and they would not meet real operational requirements for either scenarios.
We all know “the game” where software companies say “their customers ask for this” and “ask for that” because I took a 1.5 year break from being a top-gun consultant and worked for a leading software company, and we, like all software vendors, had myriad “mythical customers” that we “cannot name”, blah blah. Most of which were not real operational scenarios by real customers, but pre-sales demos by our solution architects.
If your customers are only asking for these simple applications in operational scenarios, please send me their contact info (or just ask them to post here, please!), without the “oh, we can’t, it is a secret” reply.
Honestly, I am not trying to be difficult, however, I have been doing this a very long time, including working on my first complex event processing problem nearly 20 years ago, and I can tell you that these simple rule-based scenarios that are being demonstrated are no different that what we built with PERL scripts 20 years ago. They are nice for demos, but too simple for real operations. The mashups with Google Earth are new, but that is not event processing, that is the art and wonder of mashups and web APIs.
If customers are only interested in very simple situations, then I would say these customers are inexperienced event processing folks who have little experience in detection. It is not just the military that has requirements beyond simple situations. Just about every real detection-oriented problem that is “complex”. Folks I talk to in financial services laugh at the simple scenarios. The military looks for adaptive, self-learning… they are far past these “toy” detection scenarios!
Anyway, I don’t want to belabor the point. I really like the direction I am seeing from you guys. You are moving beyond the basics. I like the fact you are using terms like “situational awareness” and “data fusion”, this is a good sign. However, there is a difference between “talking the talk” and “walking the talk” and in reality, most all operational data fusion applications are not based purely on rule-based systems (read the handbook on multi-sensor data fusion), due to issues with uncertainly, the trade off between false positives and false negatives, and economies of scale.
If running rules across stream data was all that is required for situational knowledge, we would have solved these complex detection problems 20 years ago or longer, because rule-based systems have been around as long as I can remember. If you build an very good operational Kalman Filter, then I will be impressed
for track and trace!
Send your customers to this blog and have them comment on the complexity, or lack of, of their situational scenarios. Let’s get the critical dialog going!!
Yours sincerely, Tim
Dear Marco and Alex,
Thank you for stimulating and motivating comments. You have moved me to start this discussion:
What Defines Complexity in Rule Processing?
http://www.thecepblog.com/2008/11/11/what-defines-complexity-in-rule-processing/
Please share your thoughts (in that post). Thanks.
Yours faithfully, Tim
Ring! Ring! Hot News, 10th November 2008…
In Today’s Issue : Your churning handset market; Apple beats RIM into third; horrible quarter in…