WSO2 IoT Server's roadmap is now maintained by Entgra, WSO2 Technology partner for IoT. For more information visit entgra.io

Connected Car: Vision for a Unified Platform

Today, there are special services available for cars, such as emergency calls and remote diagnosis, and there is a growing market to add more functionality. However, it would be inefficient if every manufacturer were to build its own system, Dr. Wichmann observed. Providing the industry with a unified platform is the mission behind the Connected Car project at T-Systems.

The Connected Car Platform will sit in the center and work with several segments, Dr. Wichmann explained. It will provide any-to-any services between telecom service providers and a range of mobile and in-vehicle devices. It also will serve as a platform for automakers and other OEMs and suppliers to deliver white label solutions. Additionally, it will support revenue-sharing opportunities with service and content providers, as well as governments.

The Connected Car Platform will feature enabling services—including identity management, billing, installation and updates, and security—on top of which other providers can add their services. This platform will include two parts: a central cloud platform and the client system or device.

Choosing a Middleware Platform

Building a generic platform that can support any-to-any connections is a tall order, and it makes several demands on the underlying middleware. T-Systems conducted an extensive evaluation of middleware platforms based on 18 key criteria and a requirement to support more than 33 standards, protocols and platforms. These included mobile and wireless communications standards, network protocols, network cryptographic protocols, standard languages for data definition and retrieval, Web service standards and protocols, security standards, runtime platforms, and design and development platforms.

When matched against the criteria, WSO2 met T-Systems’ requirements, Dr. Wichmann said. Top priorities were the overall completeness of the WSO2 middleware platform along with security functionality and performance factors, such as cluster support, high availability, fault handling, and reliability. Since monitoring will be important, he and the team liked the fact that WSO2 both offered WSO2 Business Activity Monitor and would allow T-Systems to integrate its own monitoring with the WSO2 ESB.

It was also important that WSO2 offered an open source platform that supported open standards—with no vendor lock-in—and that it enabled integration flexibility through existing adapters and the ability to write custom adapters. WSO2 also met T-Systems’ demands for mature software that was already in production.

POC – Where the Rubber Meets the Road

“Theoretically everything looked good,” Dr. Wichmann said. However, T-Systems wanted to conduct a proof of concept (POC) with WSO2’s middleware to make sure it worked as well in practice as it did on paper.

In June 2011, T-Systems engaged WSO2 in a six-day QuickStart project to conduct the POC. The project assumed that the operators would be in a large data center running a critical system and that they would also have some responsibility for smooth operation at the application level.

In general, the WSO2 middleware was easy to use, Dr. Wichmann said. He noted that installation of the WSO2 ESB was really simple. It just took 4 seconds to unzip the WSO2 ESB file and change the ports, plus another 30-60 seconds for it to start up.

Overall, WSO2’s middleware met 40 operational criteria across 10 categories: installation, patch installation, integrity, availability, scalability and performance, security, privacy, administration, monitoring, and maintainability. Dr. Wichmann noted that, among these, security was one of the most critical. Here, WSO2 had to meet seven factors, including the baseline protection outlined in the 4,000-page guide by the German Federal Office for Information Security (BSI).

At the conclusion of the QuickStart engagement, it was clear that the WSO2 components worked well, and that any small problems were easily solved by the two WSO2 consultants and four-person T-Systems project team.

On the Road

Following the success of the POC, T-Systems is well on the road with using WSO2’s middleware to implement the Connected Car Platform. The first task was using the WSO2 ESB to develop ESB proxies for 33 existing SOAP services and 159 XSDs; WSDLs were generated via EMF scripts. Since then the team has also written proxies for another SOAP service, non-XML HTTP Post and Get services, transformation, binary XML, and POST with query parameters. The result so far, Dr. Wichmann said, is that everything works.

Today, the services are deployed standalone on Tomcat. However, taking advantage of WSO2’s OSGi-compliant architecture might be an interesting alternative, Dr. Wichmann said. He noted that OSGi probably offers “better dependency management and more deployment options.” He added that T-Systems also plans to add data services.

Long-term T-Systems wants to be a PaaS service provider, and Dr. Wichmann observed, “That is what WSO2 Stratos is made for.”

To learn more about how T-Systems is using WSO2 for the Connected Car Platform, view Dr. Wichmann’s full presentation here.