Having explored very high level architectures for both the vehicle and cloud  I will begin to review on this blog some currently available (or soon to be available) products that may fit somewhat into the structure I have outlined.  I don’t expect an exact fit, but this will help me to narrow my choices about what technologies I should test first.

The first is a forthcoming product from Kynetx  named Fuse   Kynetx claims that “Fuse combines a sensor, a mobile app and the Cloud to create a new experience around owning and using a car.” The system includes three basic parts:

1. A device that plugs into the OBD II port on your car, has a GPS and cellular connection, and constantly stream data from your car.
2. A mobile app for interacting with the data.
3. A personal cloud platform, under the car owner’s control, where the data is stored and processed.

Phil Windley, founder and CEO of Kynetx and well-known author and innovator, posted an interesting article on his blog yesterday: “Fuse is a Telemetrics Platform for Your Car: Trips on Your Calendar.”

I particularly like three things about the Fuse approach:

1. The ODB II monitoring device has both cellular and GPS connections, allowing it to monitor the vehicle while the driver is not in it.  Other devices I have seen require the driver’s smartphone to provide connectivity beyond the vehicle.
2. The Personal Cloud Platform from Kynetx is an innovative approach to providing a repository and programmable functionality in a highly personalized, privacy-protected manner.  While this approach is quite different than the enterprise-centric architecture proposed by Oracle, it may be better suited for my Yellow Jeep Journey objectives.
3. Fuse will have a published event-driven API to access and manipulate functionality.

I don’t know if it will allow other inputs from the vehicle that are not available through the ODB II port interface.  Sensors like GPS, accelerometers, magnetometers, etc., may require a separate interface.

I pre-ordered a couple of the Fuse devices during its Kickstarter campaign a couple of months ago.  I anxiously await delivery, which should be in about 2 months.

On April 5th, I posted a high level architecture diagram of sensors, subsystem controllers, gateway and supporting functions that will need to exist on the Jeep.  Today’s post offers a high level diagram of functionality that should exist in the Yellow Jeep Cloud. This roughly follows the structure of the Oracle IoT Platform I described in my March 22nd post.

 

One basic design objective is that all functions will be exposed as secure API’s that could be consumed by web apps or mobile apps as needed.  Therefore, the primary interface to the open Internet is a secure API gateway.  This may operate in conjunction with an enterprise service bus that manages a catalog of available services and API’s.

For the purpose of this post, available services are divided into five major categories, with three major data repositories:

First, the data repositories:

Data Repository.  This is the database where all data from the Jeep (or many Jeeps) will be collected and stored for functional processing or analysis.

Device Repository.  This database will be used to maintain a complete catalog of all available and used devices, along with capabilities pertaining to each device.

User Directory.  This directory will be used to maintain all users, access rights and credentials necessary to access data services and applications in the YJJ cloud.

Now, the functional elements:

Functional Services.  These services are really the focal point of the YJJ cloud.  It is this functionality that will make the the data collected and used from the Jeeps used.  Some functions may be quite generic, such as data ingest, event processing and data analytics, but I anticipate that a set of #YJJ-specifc services (yet to be defined) will be the most important set of functions in this group.

Device Management.  A complete catalog of devices authorized to connect to the YJJ Cloud will need to be maintained, and secure access rules enforced.  Functions to discover, register and manage changes to this large network of devices will be required.

User Management.  All users that will access YJJ data, services, APIs or applications will need to be registered and access rights be appropriately granted.  

Access Management. Access Management or Control functionality will be needed to enforce security polity for application access by users as well as to secure the APIs that can be used by external applications for accessing YJJ functionality.

Administration Services.  Common administration services will be needed to monitor the health of system components and provide auditing and reporting functions.

This provides a very high level view of my thoughts for YJJ Cloud functionality.  Much more definition is needed for each set of services.  Stay tuned!

Roll on Yellow Jeep Journey!

 

The following diagram illustrates how the the sensors I proposed would map onto the general Oracle Internet of Things reference architecture I recently discussed.

At the first level, this diagram shows possible raw sensors and the device controllers responsible for configuring and monitoring the sensors.  The gateway device would aggregate the data and forward that data in either raw or summarized form to the data ingest function in the cloud.  Intermediate storage at the gateway level would allow the Jeep to continue to operate in cases where wireless communication is not available.  The gateway would also provide local APIs what could be consumed by a user interface app on an iPad via Wi-Fi connection.

Of course, a lot more detail is needed.  Each little subsystem could become quite complex. What fun!

Roll on Yellow Jeep Journey!

 

Today, I learned of a new sensor I will absolutely need to add to the #YJJ Architecture instrumentation list  The IPSO Alliance announced a new Psychokinetc Energy (PKE) smart sensor:

This new product will allow consumers to remotely monitor paranormal activity in their home and work environments. It is currently under patent review.

Boy, this new sensor should help to identify the ghosts of old Willys Jeeps that might be hanging around and help ferret out mysterious, phantom engine anomalies! The Internet of Things may have just crossed over into the Twilight Zone!

The sensor comes with an impressive list of product features:

• Unprecedented sensitivity – up to 300 meter detection zone
• Quadcore technology – track multiple entities simultaneously
• Astral Positioning System enables real time map tracking/Google maps overlay
• Connecting multiple systems enables wider coverage
• Sends alerts via SMS and Twitter to avoid supranatural interference
• False positive detection software filters out non psychokinetic activity
• Internet enabled
• iPhoneâ„¢/Androidâ„¢ Applications
• IPv6 compatibility
• Supports optional Home Entity Management System (HEMS)
• Google Glassâ„¢ and IP-based actuator interfaces: sense activity, record and share

For more information, please contact:

• Laff Sonyu, IPSO Marketing Director (marketing@ipso-alliance.org)
• Hugh Morris, Grid Connect Marketing Lead (marketing@gridconnect.com)

Roll on Yellow Jeep Journey!

As a starting point to explore how to implement the YJJ Architecture, let’s take a look at the Oracle Internet of Things platform. The following diagram highlights what parts of the Oracle reference architecture would be installed in the Jeep and which would be in the Yellow Jeep Cloud.

The Oracle architecture is built end-to-end on Java.  At the device and gateway end, Oracle Java ME Embedded can e leveraged in the sensor devices. Oracle Java SE Embedded would be used in the Gateway device that ties multiple sensor subsystems together and communicates wirelessly to the Yellow Jeep Cloud in a data center.

In the Yellow Jeep Cloud, a variety of Oracle middleware and application products, also implemented in Java, can be leveraged, based on the specific application. 

In future posts, I will drive to a deeper level of detail on both the Jeep and cloud sides of the architecture to examine how this reference architecture can be applied to equip my Yellow Jeep for its journey.

Much of the discussion of the Internet of Things revolves around the myriad of intelligent sensors that can be used to collect data from almost anywhere (even pulse rate from your ear . But I really think the power of IoT will really be harnessed when data from all those sensors is used to make intelligent decisions and provide feedback control that improves the operation of whatever systems we are using.

I like to think of this in terms of Supervisory Control, a concept I first learned about and applied in implementing manufacturing and process control systems in the 1980’s.  Extrapolating that concept forward to the Internet of Things, I like to use the following diagram as a framework for discussion.

 

Three levels of control are illustrated in this diagram:

1. Device Control

Each individual intelligent device may collect data from multiple sensors and exert control over the device.  

For example, in a Yellow Jeep or other modern vehicle, the Engine Control Unit (ECU) depends on both sensors and actuators to control engine function. The following diagram illustrates how various input sensor are used by the Electronic Control Unit (ECU) to control various actuators (e.g. igniter, injector) and generate operator alerts (e.g. Check Engine Light).

 

2. Gateway or Subsystem Supervisory Control

Gateways or subsystem controllers may be used to aggregate data from multiple devices and provide subsystem-level supervisory control over those devices. 

For example, in the Yellow Jeep example, a video subsystem may aggregate video feeds from multiple cameras while providing synchronized control over video zoom, pan and tilt functions.

 

3. Overall Supervisory Control

As data is gathered from various subsystems into the Cloud, that data can certainly be ingested and stored for historical analysis and visualization, but real time analysis of that data could be used to coordinate may subordinate systems.  

For example, what if an army of Yellow Jeeps were exploring different parts of the world at the same time?  Each of these Jeeps may have one or more subsystems that collect data and perform their own local supervisory control functions.  However, data collected from all those Jeeps could be analyzed in the cloud in real time and fed back to the individual Jeeps to control how they are operated.  I’m not sure just what that supervisory control might be, but it is worthy of exploration.

 

Please let me know what you think.

Roll on Yellow Jeep Journey!

When I posted my thoughts about how to instrument my Yellow Jeep, Ricardo Diaz, an Oracle colleague, offered a great recommendation for extra instrumentation via a LinkedIn message:

Heart beat monitor sensor with GPS SMS alerting for concerned fathers.

I’ve rolled a Jeep once. A slow roll off a sand dune in Florida. My heart jumped out of the Jeep before me!

Well, Ricardo, here’s an idea I found on the web – a pulse rate sensor you can clip to your ear!  Certainly we should be able to capture that rate and generate an appropriate alert when things get hairy in the jeep!

 

The Pulse Sensor team introduces the sensor this way:

Pulse Sensor Amped is a greatly improved version of our original Pulse Sensor, a plug-and-play heart-rate sensor for Arduino.  It can be used by students, artists, athletes, makers, and game & mobile developers who want to easily incorporate live heart-rate data into their projects.  

Maybe it could also be used by a Yellow Jeep guy!  We might even start rating Jeep trails by the high heart rates they cause!

Roll on Yellow Jeep Journey!

Having previously introduced my thoughts about Yellow Jeep Architecture Users and Instrumenting the Jeep  we can begin to explore what functionality should exist in the Yellow Jeep Cloud. Here are some functions I have considered:

Basic Yellow Jeep Cloud functions:

• data ingest
• data storage
• event processing
• historical analysis, trending
• supervisory control functions
• historical route mapping
• authentication
• authorization
• user registration / profile management
• user password/credential management
• API security

Of course, in keeping with modern standards in the API Economy  cloud functions would all be exposed in the Yellow Jeep API, with capabilities such as these:

• ingest data
• ingest audio
• ingest video
• request raw data
• request data summary
• request calculated data
• request supervisory control data
• request video stream/segment
• request audio stream/segment
• authentication
• authorization
• user management

What functionality should I add?  What capabilities do you think should existing in the Yellow Jeep API?

Roll on Yellow Jeep Journey!

What instrumentation do you think I should install in my Yellow Jeep for its long journey?

Here are some of the sensors that I have considered:

• Engine monitoring – via On Board Diagnostic (OBD) port
• tire pressure
• location – GPS coordinates
• internal temperature
• external temperature
• light intensity
• video – forward, reverse, left, right, driver, passenger, roaming camera
• audio – multiple microphones
• driver ID
• passenger ID(s)
• velocity
• acceleration
• yaw, pitch, roll
• altitude
• air pressure
• humidity

Some human input that may be appropriate in the Jeep includes

• audio/video/text comments
• ongoing journal
• still/video camera, independent of vehicle

A friend suggested that fingerprint sensors should be added for identification of the driver and passengers.

What suggestions might you have?

Roll on Yellow Jeep Journey!

When I prepare my Jeep for a long Yellow Jeep Journey, who would possibly use the technology?  What should the User Interface support?

I expect that users will roughly fall into four groups:

1. Driver:  The guy who drives the Jeep 
2. Passengers:  People who come along for the ride
3. Observers:  Folks to may want to monitor trip from afar
4. Technical Support:  People who keep the technology running.

I expect that any one individual may act in any of these roles over time.

I presume that information will be either near real-time (representing stuff that is happening now), or historical (data collected over a period of time).  The user interface should provide tools to appropriately display and interact with either real time or historical data for each category of users.

I suppose that the types of interactions for each type of user include those listed below:

Drivers will be interested in such things as:

• Engine health
• Location/position
• Direction being traveled
• Destination and directions
• Weather – current and forecast

Passengers may be interested in thing such as

• Route planning
• Response to observers questions and comments
• Updating blogs and articles while traveling

Observers may be interested where they Jeep has been and what is happening

• Location
• Direction
• Destination
• Route travelled
• Weather
• Photos, video, audio recordings, blog posts.

Technical support folks may want to monitor

• Health of the electronics
• Alarms and warnings

Do you have any other ideas?  What would you like to see on this blog or accompanying website if you were to monitor my long Yellow Jeep Journey?

Thanks for your input.

Roll on Yellow Jeep Journey!