Connected Consumer Experience in Automobiles

by Christoph Schittko, Darryl Hogan, and Jon Box

Summary: What sets a vehicle apart from a hunk of metal and four wheels? It’s all about features. Manufacturers are constantly adding newer media devices, more powerful motors, and softer seats, all in the name of improving the driver’s experience. Yet with all these improvements, auto manufacturers have barely scratched the surface with respect to the capabilities of the myriad of software and services advances available in recent years.

There has been a lot of talk around services in the cloud and their application based on the consumption of services. Despite this, many reference architectures and papers aimed at demonstrating patterns for designing these systems have taken an idealistic approach to the application—frequently citing simple examples or applying scenarios that are not pragmatic. This paper defines a practical solution architecture based on a scenario one might encounter in everyday life. We intend to inspire architects to use the same approach to define innovative solutions for the problems they face.

The solution architecture defined here is a combination of real platform services that exist today and fabricated services that help round out the solution. This solution will demonstrate the application of Software + Services (S+S) to mobile application architecture as a means to extend the digital lifestyle beyond the desktop. Security, privacy, and data architecture will be addressed broadly.

Contents

Scenario
Solution Architecture
Value Add Services
Services Technology Platform
Mobile Client Technology Platform
Client Application
Service Delivery Patterns
Security, Identity and the Client
Authentication and Authorization
Multitenant Data Architecture
Conclusion
About the Authors

Scenario

The Woodson family has just purchased a new car with a mobile computer on board. This PC serves as their guidance and entertainment system, but also comes preloaded with several productivity applications, such as travel planning, reminders, and a list manager. The software loaded on the Auto PC not only performs processing locally on the device, but also leverages services in the cloud to enhance the capabilities of the device and to ensure that the information presented by the software is up-to-date.

The Woodsons have decided to take their new car on the upcoming family road trip. Mary Woodson is not only the mom; she is the family event coordinator. Mary sits down at the family computer to plan their adventure using a Web-based version of the trip planning application shipped with their in-car computer. Mary plans the route they will drive and makes reservations for hotel and restaurant stops along the way. Mary unwittingly uses a mashup consisting of a number of services running in the cloud. All the information pertinent to the trip is stored remotely in an Internet-based location which is accessible only by Mary and her designates.

“The Internet is at the beginning of its transformation to become a platform for services in the cloud: Platforms such as Windows Live provide AP Is for presence, alerting, contact and calendar management, as well as maps and directions; as another example, BizTalk Services will offer a pub-sub platform and message routing and delivery.”

When the time comes to confirm the hotel reservations and pay for attraction tickets, Mary hesitates when she’s asked for her credit card information. She’s heard that entering your credit card information on a Web site can potentially lead to identity theft. She’s soon relieved to discover that she can create and use a digital information card managed by her bank to present payment information to the various vendors. This option provides a measure of safety over presenting her credit card information over the Internet to each of these vendors individually. She can select the appropriate card right from her desktop as a source of payment information, allowing her bank to pass her secured credit card information to the necessary vendors without transmitting sensitive information from her PC.

The trip starts with a reasonable lack of eventfulness. The kids have chosen to take only a few of their own DVDs along for the trip. If they decide on a whim that they’d like to see something different they can always download a movie to the car. For Dad, his smartphone connects itself to the car via Bluetooth and his calls, text messages, and email are now directed to the vehicle’s computer rather than his phone. An incoming text message from the home security system indicates that one of the motion detectors has picked up movement in the backyard. Dad places a call to Bob Thomas next door who checks the situation to find it was only one of the neighborhood kids chasing a stray ball.

A few hours into the journey the engine light comes on. Data is immediately sent to a diagnostic service provided by the vehicle manufacturer. The service finds a warranty issue that needs to be tended to and returns a message to the on-board PC with a simple diagnostic report and the name and location of the dealer nearest the car’s current location. Mom clicks on the dealer’s address to get turn-by-turn directions and the family heads for the detour. The family uses the search functionality on the car’s computer console to find a restaurant near the dealer for a quick snack. (Figure 1 illustrates this engine light scenario.)

After servicing their car they are back on their way, three hours behind schedule. Mom pulls up the travel itinerary she created at home. The dinner reservation at the restaurant in the next town needs to be cancelled and new dinner plans need to be made. Mom orders pizza online to be picked up at a nearby pizzeria and pays for it once again using her banking information card. After a great meal they all look forward to a memorable trip.

Figure 1. The Auto PC offers applications to manage the vehicle and travel

Solution Architecture

Architecture Options

As you can imagine from the scenario, the solution brings together services from numerous providers and applications that consume these services. The consuming applications could either be application containers following the composite User Interface (UI) pattern to allow dynamic provisioning of new services or it could be special purpose custom applications delivered as client applications. The general approach follows the S+S paradigm to provide a simple, yet rich and intuitive user experience across devices and audiences. The combination of client software and remote services is particularly important in this mobile scenario because the locally running software can improve user experience by masking the high latency over-the-air service invocations or temporary network connection problems that are common even on modern wireless wide area networks.

The services fall into three general categories (Table 1):

• Common Platform Services, commodity services published by third-party service providers. These are the kinds of services that other service providers will build on top of in order to extend their story, as well as to utilize the maturity and stability of others’ infrastructure, specialization, and business efforts (one of the core principles of S+S). Many software and online businesses have realized the opportunity of building out a platform “in the cloud.” Microsoft’s offering of services under the Windows Live brand is one example for an Internet platform.
• Manufacturer Services, provided by the manufacturer either within the car or in the cloud to access vehicle, dealer, and manufacturer information.
• Value Add Services, provided by the car manufacturer or third parties to offer services that increase sales or customer loyalty or services offered to support special purpose devices sold by third parties.

These service categories refine the more generic service taxonomy for Windows Live services listed at: https://www.microsoft.com/online/default.mspx

Connected Consumer Experience Service	Windows Live Service Category
Common Platform Services	Building Block Service
Manufacturer Services	Attached Service
Value Add Services	Finished Service or Attached Service

Table 1. Connected Consumer service categories relationship to the Windows Live service taxonomy

Technology Environment (Constraints and Assumptions)

The solution requires an environment where Internet access is widely available, but not necessarily ubiquitous. Ideally, the car has the means to connect to the Internet without additional devices — for example, it does not require a cradled cell phone to enable network access to services provided by the car. Network access to the car enables application scenarios such as remote start, remote diagnostics, and notifications of events in the car.

Some applications that benefit from location information may not need the context provided by vehicle-specific data. Such applications could also run on commodity devices, such as GPS enabled smartphones and personal digital assistants, because there is no dependency on the vehicle-specific data. These devices are often equipped with modern platforms like the .NET Compact Framework and can access SOAP-based Web services just like a server or a desktop computer. Visual Studio 2008 and .NET Compact Framework 3.5 add support for consuming WCF and WS-* based web services for WS-Addressing and message-level security based on WS-Security.

Value Add Services

In our scenario, the Woodson family touches many different types of software and services. For instance, the vehicle manufacturer provided a service to analyze vehicle diagnostic data and to notify the vehicle owner of a problem along with information on where to get the problem fixed. The trip planning service stored their travel itinerary and made it accessible from the Internet. These are value-added services which can be more completely described as services which provide a unique experience to the consumer. They differ from common platform services in that they are not considered general purpose or widely available. Instead, they are most likely developed to establish a competitive advantage and perhaps to extend the usefulness of another product.

In many cases, these services may be composites of custom code and one or more core platform services, allowing the service provider to make available features where they are lacking domain-specific knowledge. An example of a composite application would be a dealer locator service (Figure 2). An automotive manufacturer may know the location of their dealerships, but it is unlikely that they would have the data necessary to provide navigational guidance to the dealer from a specific location. The manufacturer would most likely rely on services provided by Windows Live Maps or Mapquest.

Figure 2. The RescueMe composite services aggregates car manufacturer and third-party services

In and of themselves, value-add services would not be considered finished products. These services are domain-specific building blocks to build complete applications. We can say that these services provide the features used to create a more complex and complete piece of software.

The most flexibility is gained using a deployment model that consists solely of services running in the cloud, because changes only require updates to the servers hosting the services, not to each car that consumes the service. These services are typically HTTP-based services that can be invoked by a client — either an application or another service. The benefit of this approach is that all the executing software is centrally deployed to a data center making it easier to manage. The drawback is that the service consumer must have a connection available to make use of the service (Figure 3).

Figure 3. The most flexible architecture consumes only remote services

Although it is possible to run the complete solution on the client, this pattern constitutes a closed environment where access to more relevant and up-to-date data is not possible, making the solution less useful. This is the blueprint that exists today for many mobile computing systems, especially those based in automobiles. The upgrade path for these devices is non-existent and the limited functionality they provide is of minimal benefit to the owner of the device (Figure 4).

Figure 4. The least flexible architecture consumes only local services offered by the vehicle

A preferable pattern for a mobile computing solution takes advantage of the ability to access software and data stored on the local device. In this case we can deploy the value-add logic to the device and make enough data available to the application that the application would be useful even when the connection is unavailable. This model decentralizes a great deal of integration and control logic and introduces maintenance and bug fix challenges, but the improvement in the user’s experience will likely make the pains worthwhile (Figure 5).

Figure 5. The Software+Services architecture combines benefits of local and remote services

Services Technology Platform

The Internet is at the beginning of its transformation to become a platform for services in the cloud: Platforms such as Windows Live provide basic APIs for presence, alerting, contact, and calendar management, as well as Virtual Earth maps and driving directions; as another example, BizTalk Services will offer a pub-sub platform and message routing and delivery. These are all key ingredients for rich, robust connected applications, but current feature sets and SLAs reflect that these services are still early in their life cycle.

Future services could extend presence settings with a “driving in the car” setting that always allows traffic alerts and some alerts that the driver configured—the alert API could add “car” in addition to “IM application,” “email,” and “SMS” to the list of notification endpoints.

Mobile Client Technology Platform

There are several platforms to choose from when it comes to realizing the connected consumer experience and there are trade-offs between the platforms. The priorities and constraints dictated by the actual solution have to drive the platform selection. In general, Windows Vista Embedded enables the richest experience through the feature set of the operating system and the full .NET Framework, but it’s also the platform with the largest footprint, the most demanding processor requirements, and highest licensing cost. Windows CE provides a lower cost alternative with lower hardware requirements, and more options to customize the operating system but fewer capabilities. A Windows CE-based platform should include the .NET Compact Framework to take advantage of the productivity benefits of managed code development and base class libraries. Finally, Windows Mobile provides a constantly improving richer experience. Platform services are provided through the compact framework, providing a programming model consistent with the skills of a broad set of developers. Table 2 lists the strengths and limitations of each platform for mobile application development.

	Windows Embedded .NET Framework	Windows CE .NET Compact Framework	Windows Mobile .NET Compact Framework 2.0 (3.5)
Target Scenario	Rich In-Vehicle Scenario UMPC	Low Fidelity In-Vehicle Scenario	Consumer Device
UX	Full WPF feature set	Windows Forms Silverlight in the Future Touch	Windows Forms Silverlight in the Future Touch
Communication	WCF SOAP, REST and JSON	WS-I SOAP Web Services WCF Client (3.5)	WS-I SOAP Web Services WCF Client (3.5)
Interaction	Speech with Vista or Third-Party Add-OnTouch	Speech Third-Party Add-On Touch if hardware support	Speech Third-Party Add-On Touch on PocketPC devices
Authentication	CardSpace	Username	Certificates
Data Storage	Full access to local storage devices and a variety of databases	Local file system Optional SQL CE	Local file system SQL CE
Development Tools	Visual Studio	Visual Studio	Visual Studio
Car Integration	Yes, via serial or custom ports	Yes, via serial or custom ports	No

Table 2. Client platform decision points

Client Application

Several options for interacting with computing systems are available to us today. Rich client applications realize the greatest benefits consuming services because they can take advantage of local data storage mechanisms and computing power that is not available through Web-based delivery mechanisms. Web applications have the benefit of being centrally hosted and managed but, being connection-dependent, cannot fully realize the connected consumer experience. A rich client application, in addition to providing the most comprehensive user experience, is more readily able to take advantage of services that might only be available locally. It is more practical to consume and evaluate vehicle performance data locally in the vehicle rather than passing the data into the cloud for further processing. We also avoid any privacy and security issues when we don’t transmit data from the car to remote services.

Lastly, a rich client application can handle identity and session more easily than a Web-based application. It is a trivial exercise to store information cards locally on a device and use those cards to establish identity with a service or another application.

Service Delivery Patterns

We can expect that Internet connectivity is widely available to our solution, but we cannot make the assumption that connectivity is ubiquitous. Each service delivery pattern has different strengths in terms of latency, flexibility, and functionality (Table 3). A rich client allows us to adopt a set of design patterns that allow us not only to account for those times when we are disconnected from the network, but also to use the additional capabilities of the client to enhance the user experience.

Pattern	Latency	Flexibility	Functionality
Thin service consumer	High	High	Medium
Richer client	Medium	Medium	Medium
Smart client	Low	Low	High

Table 3. Comparison of client architectures

Many rich applications built these days are only shells providing input and output for a set of services living behind the user interface. In this pattern, the client is highly reliant on connectivity to provide any kind of useful interaction for the end user. This client may have simple caching to deal with network latency or conditions where the network is simply not available, but it does not extend its usefulness beyond what is available through the services it consumes.

We can extend this pattern to create a second, more useful pattern in which the client remains a dependant service consumer, but the computing infrastructure is extended to the client. In other words, we take advantage of the application’s ability to perform processing tasks in the vehicle, thereby relieving the services of some of the processing burden. A typical result in this case is a more responsive albeit still underachieving application.

Short of downloading all functionality to the client device, we can implement a pattern in which services become simple data providers and consumers. The logic for how we utilize the data is embedded in the client and the client becomes the focal point of the user’s experience. This pattern allows us to deal with latency caused by slow or non-existent network connections as well as presenting to the user an experience resembling her home PC. One issue related to this pattern is that of upgradeability. Because the application is deployed to the client device it becomes more difficult to add functionality or to upgrade existing functionality. Services such as the .NET Framework’s click-once deployment model and adoption of composite UI application patterns help overcome this challenge. New services can be readily upgraded and added, as is the case with any Web service.

It is possible for software vendors and service providers to offer multiple versions of their products—for example, a vehicle-independent version for devices offered through regular retail channels and a vehicle-specific version offered through the vehicle manufacturer that offers additional functionality (Figure 6). An enhanced model would “light up” the experience on the device and in the car when a customer buys both products. The mobile device application could also provide value-adds, such as the display of the current location of the car, remote start, and automatic data sync from the device when it’s brought into the car. Both, the device application and the vehicle application can access the service provider’s cloud-based services, which increases their utilization because of the larger target audience.

Figure 6. Different heads allow for better utilization of service and a more differentiated user experience

With the S+S architecture, client applications are not bound to the vehicle. Services can be offered through myriad commodity devices such as smartphones and mobile PCs with user experiences tailored to those platforms. Because data stored in the cloud is available to any and all devices, we can make the transition between devices almost completely seamless. The important tenet to maintain is that interaction with the devices should be a natural experience for the user. The growing collection of more and more powerful devices presents many options to present a consistent level of interaction between client and computer. The user interface may change to suit the form factor, but the level of service will remain the same.

Security, Identity and the Client

Identity is a challenge in any system as are authentication, authorization, and privacy. This is especially the case with mobile applications. The greater the remove between the core application and the device, the more difficult it becomes to deal with matters of security. A richer client allows us to maintain security tokens on the device, creating an arguably more secure application.

Secure Communication

Privacy is a major concern for anyone exchanging data with services in the cloud. In the past, the focus was on HTTPS and SSL for transmission of encrypted information. The problem with SSL is that it is a point-to-point protocol and doesn’t allow for data to be exchanged securely between multiple endpoints. Composite applications (comprising multiple services almost by definition) require an end-to-end approach to security. A better solution would be to obscure the data on the device and allow it to be transported over an encrypted or clear connection. This is the approach taken by the authors of the WS-Security protocol. The client device possesses a public key used to encrypt the data before it is release for transport. Only the destination service is able to the decrypt the message. Data in the message intended for different recipients can be encrypted with different public keys, thereby ensuring that data can only be read by the intended recipient. Client-side development platforms like the various versions of the .NET Framework implement WS-Security as part of WCF.

Digital signatures provide an added measure of trust. The client could use a unique identifier such as a private key from an X.509 certificate to sign the message, ensuring that the data was indeed sent by the party whose identity is claimed in the message; the digital signature would also provide the assurance that the data was not tampered with in transit. A digital signature is essentially a one-way hash of the originating data. If the hash cannot be reproduced by the recipient, the signature is understood to be invalid: Either the key pair does not match, invalidating the claimed identity, or the data has been tampered with in transit.

The S+S approach enables use of WS-Security, but it offers an even more secure option to improve privacy: Not transmitting any secure information at all. Moving computing operations that include personally identifiable data to the car or the device eliminates the need to transmit the information over insecure channels. Take CardSpace authentication as an example. A CardSpace identity tied to the car avoids transmitting personal identity or weak username/password combinations.

In the interest of privacy, service providers are encouraged not to require any sensitive information. For all exceptions, the application provider should request the user’s permission for transmitting information to the service. By default, each application should follow Microsoft’s guideline for secure computing and not transmit any sensitive information without explicit permission from the user.

Authentication and Authorization

Identity tokens can be used to authenticate and authorize users for services they would like to access. An information card such as a CardSpace card would allow the user to present a claim of identity to a service. The burden of verifying that identity could be held by the service or a relying party could be used to validate the identity. Authorization would still be the responsibility of the invoked service.

Authentication is very important in our mobile scenario for a number for reasons: We need to restrict access to the application to paying customers, but we also need to ensure that each user’s private data is protected from unauthorized access. In our scenario, there’s an additional concern: Remote access to the car. There are privacy concerns around accessing the car’s location and travel history, but there are also safety concerns. Starting or stopping the car, for example, is a feature that needs to be guarded very tightly. You wouldn’t want a malicious hacker to shut off your car’s engine while you’re driving down the highway.

“The S+S approach enables use of WS-Security, but it offers an even more secure option to improve privacy: Not transmitting any secure information at all. Moving computing operations that include personally identifiable data to the car or the device eliminates the need to transmit the information over insecure channels.”

On the Internet, user identity is typically established by entering a username/password combination but that’s not the experience we expect when we get into a car. The key is the traditional means of getting access to the car and its services. We can employ a similar interaction model for in the connected services scenario with smart keys or CardSpace-based solutions.

However, there are a few interesting architectural concerns around identity in the car. For one, the car itself is a multi-tenant application because it can have multiple drivers potentially with different roles—the owner, the owner’s teenage daughter, or a mechanic that services the car are a few examples. Many cars today offer preference settings for seat and steering wheel positions for different drivers based on the key they carry. This experience can be extended to computing devices in the vehicle, making applications and data available based on the current driver’s identity. Access to the entire system can be limited for guests in the car.

The concept of identity exists even for the vehicle itself (Figure 7). A digital identity could be assigned to individual cars allowing access to manufacturer services that provide vehicle-specific services. Drivers on the other hand need a portable identity. Most computer users today have at least one digital identity associated with them. Extending that identity to be used in a vehicle is not trivial, but is entirely possible.

Figure 7. Car and drivers need their own different digital identities to access services

Multitenant Data Architecture

Another factor to consider is the problem of data storage and privacy. In order to make this type of computing experience useful a good amount of personal information would need to be stored in the cloud. This creates a challenge for the data architect who must make sure that the data is stored in an efficient manner while not compromising the security and privacy of a consumer using the service.

Arguably the best solution for a data store with a large number of tenants is the shared database, shared schema method. In this case, the data of every tenant is stored in the same tables with data associated to each tenant through metadata. This pattern places the guarantee of privacy and security on any application accessing the data and may dictate additional software development costs, but the cost savings for the long term maintenance of the data far outweighs this cost.

Conclusion

Connected consumer experiences such as the one outlined in this article present a great opportunity to add value to existing products. The current and upcoming generations of consumers are technology savvy and will rely on digital helpers everywhere, not just on their desktop at work. The ubiquity of computing devices and the wide availability of network connectivity present an opportunity for manufacturers and new service providers to connect with their customers in new and meaningful ways (Figure 8).

The car in particular is such an important part in many people’s life. You bring kids to school, visit customers, or take road trip vacations. You may spend hours each week driving around and you find yourself in situations where some extra help can make a big difference to you.

Figure 8. The Internet services platform enables connected consumer experiences in the car, on devices and the PC

The Microsoft Platform is very well suited for building S+S solutions on the client and on the server. Technologies like WCF and the .NET framework are well-suited to building cloud-based services because support for message exchange protocols—such as JSON, POX/REST, SOAP, and WS-*—guarantees interoperability with all kinds of service consumers. Often, services are not built from scratch but by aggregating existing services. Technologies like BizTalk Server or the cloud-based BizTalk Services are well-suited to aggregate building-block services into value-added services. The platform also offers Windows Live building-block services, such as contacts, alerts or photos, which can be included in value-added services.

Software + Services provide an excellent pattern for delivering services across a number of platforms. Flexible service delivery mechanisms allow us to quickly add new features with little interruption to existing systems. Advances in presentation technologies and device form factors enable us to present software to users in the most context-appropriate manner.

We’re already seeing the combination of Software + Services emerging in many areas. Early adopters are proving the value of these solutions and setting the bar for others to meet. The tools and the platforms are there. It’s only up to the application providers to build solutions that reach users in the best possible ways.

About the Authors

Darryl Hogan is an architect in Microsoft’s Developer and Platform Evangelism Group. Darryl has extensive experience architecting and implementing numerous enterprise applications during nearly 15 years in the IT industry. In his current role, Darryl provides guidance and education to architects implementing enterprise solutions and enterprise architectures on Microsoft technologies.

Christoph Schittko is an architect for Microsoft based in Texas where he works with customers to build powerful solutions that combine software + services for cutting edge user experiences and leveraging service-oriented architecture (SOA) solutions. Prior to joining Microsoft, Christoph assisted with companies adopting service orientation and delivering Software-as-a-Service (SaaS) solutions. Christoph has over 14 years experience developing and architecting software solutions in a wide variety of industries. He writes and speaks on Web services and XML at various conferences. Christoph holds an advanced degree in Electrical Engineering from the Friedrich-Alexander University Erlangen-Nürnberg.

Jon Box is an architect evangelist at Microsoft. He works with customers to utilize Microsoft technologies to build impactful solutions. Jon has been programming professionally since 1985. He has worked in a variety of environments and languages that include COBOL, Assembler, Clipper, C, C++ (Borland, ATL, MFC, Win32, COM/DCOM), VB5/VB6, and .NET. For more thoughts from Jon, see his blog at https://blogs.msdn.com/jonbox.

 

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal Web site.