58 sensor applications

I came across a site that lists "top 50 sensor applications for the smarter world".  It actually list 58 applications partitioned to the following areas::  smart cities, smart environment, smart water, smart metering, security & emergencies, retail, logistics, industrial control, smart agriculture, smart animal farming, domestic & home automation, and eHealth.  

I worth digging into the different areas to check the potential applications, and the role of event processing in each of them. 

On reversing the roles - the kid got it!

Earlier this week I spent 2 hours with a group of high school students that were selected to be part of the "President of Israel program to discover and cultivate the inventors and scientists of the future".   The IBM Haifa Research Lab took part in this program, by conducting a sequence of sessions, each with one of   our local scientists (I was the last in the sequence).  

It was a very interactive session, and as part of it I described four scenarios of event processing in different areas (typical examples I am using in my talks:  the car theft example, the intensive care unit scenario, the never-lost luggage scenario, and the cold chain scenario that we use in our recent TEM video clip.  
I have asked them what they think is the common denominator among all these scenarios -- they said many right things, but one kid said the most important thing:   "in these scenarios the roles are reversed, instead of the usual way that the person tells a computer what to do, here the computer tells a person what to do".
This kid will  definitely have a bright future... 

Gartner's recent predictions about business intelligence and analytics

A recent set of predictions by Gartner, state that Business Intelligence and Analytics will remain top focus for CIOs through 2017. 

It mentions two interesting observations:   One is that the confusion in the market about the term "big data" and its tangible results constrain the spending and limit the growth of BI and analytics software.   The second observation is that By 2017, more than 50 percent of analytics implementations will make use of event data streams generated from instrumented instrumented machines, applications and/or individuals.  

This is consistent with the Gartner's term -  "two tier analytics",  where event processing is the second tier, after historical data analytics.  While the need to consolidate analytics and event processing is becoming more pervasive, the utilization barrier and the need to battle complexity is still a common denominator. 

The Event Model: short promo on YouTube

Following the first exposure of "The Event Model" in ER 2013,  we have produced a 5 minutes video clip explaining shortly the idea.  The screenwriters were Fabiana Fournier and Sarit Arcushin and the video was produced by Tammy Dekel, Hanan Singer and Chani Sacharen (who is also the narrator). 

The video clip issues a call for partnership in investigating this model -  either by working with us on use cases to validate the model, or working with us on the challenges in further developing the model.

On Rolls Royce's engine health management

In DEBS 2013, Roger Barga from Microsoft mentioned in his keynote talk that Rolls Royce is proposing to its customers a model of engine hours as a service, and used it as an example that event processing can be enabler of changing business models.    I recently talked with somebody about these type of systems and decided to follow up and learn more about the Rolls Royce system using the available information on its website.   The service is enabled by "Engine Health Management" (EHM)  The illustration above shows some of the engine sensors.   The monitoring follows the scheme: Sense-Acquire-Transfer-Analyze-Act.

The sense phase deals with the activation and capture of the sensors.

The acquire phase stands for a combination of routing reports in various milestones (takeoff, climb, summary at landing)  and detection of abnormal situations (this is the "derive" part of event processing).

The transfer phase deals with the communication to the ground operation  center

The Analyze phase is a manual phase that take the input from the previous phases and adds manual control and decision about next actions 

The Act phase deals with the actions required -- such as servicing and part replacement and determine the urgency and location.

This is consistent with the 4D (Detect-Derive-Decide-Do) model.  Here the decision is mainly manual.  It seems that this is one of the early cases where the use of sensors and event-driven applications are used to employ new business models.   More on business models change  -- later. 

From health persona to societal health by Ramesh Jain

Ramesh Jain uploaded interesting presentation to slideshare. The presentation entitled "From health persona to societal health"  talks about using personal events based on mobile devices to connect sick people to medical services upon detection of situations.     It seems that the area of mobile and personalized healthcare is an emerging area of using events coupled with mobile devices.    This can also be a good area for use of non programmer control (e.g. physicians) on situation detection applications.   I'll write more on this combination soon.  

More on event processing and mobile devices

More than a year ago I have first written about event processing and mobile devices, and illustrated this picture, showing the possible roles of mobile devices as producers, consumers, front-end and dashboard carrier.   Now I am concentrating on the "EPA on mobile", which means that mobile devise (phone, tablet, smart sensor etc...) can host the actual execution engine of event processing.  One of the questions raised is why is it needed, typically people think on mobile devices as end points,  front ends, and collection points, while the actual processing is executed on a server (cloud, mobile back-end server etc...).  

There might be multiple reasons to run event processing on mobile:

First -- mobile devise may be off-line (e.g. when I am travelling abroad, wherever there is no WiFi connection, my mobile phone is in off-line, since mobile data connection is very expensive out of the country).  

Second -- there are various sensors attached to a mobile device,  whether these are the internal sensors of the devise itself, or a sensor network wired locally to a mobile devise (e.g. tablet).   In many cases events are emitted frequently, and raw events are relevant only at the local level.  Sending them to the back-end requires both communication cost, and has high toll on power consumption, which is still the weak spot of mobile devices.   

Third --- there are also privacy considerations,  such as processing events that the owner does not want to share with the rest of the universe.

Recently I have learned about some implementations done now in this area, they are hybrid implementations, certain part of the overall logic might run on a mobile device, while part might run in the back-end.

running open source event processing on mobile devices.   I guess that this will see much more of it, as the world moves to mobility, and to the Internet of Everything.