Internet of Things - Continuous Engineering based on Open Services for Lifecycle Collaboration

Good morning. My name is Frank Försterling. That will be a joint presentation between Continental, where I belong to, and IBM, where Ulf is belonging to. Our short title is Dynamic Horizon for the Connected Vehicle. The long title has been announced before that one. So that means we would like to talk about, let's say, the internet of everything in terms of how to work together between to different industries, what does it mean in terms of challenges and what we would like to achieve and what we already have achieved. So I would like to start with a couple of introductional words in terms of the dynamic horizon, and Ulf then will continue with the next steps of how to implement those topics. So talking about the vehicle, we had the situation a couple of years ago that it was more or less the last white spot in the internet world. Vehicle was not connected by no means There were a couple of reasons behind, starting from HMI and user distraction topics up to, let's say, too expensive connectivity costs, things like that. Now we are in the situation that we see that around 2020 the vehicle will have a multitude of cloud connectivities. On the one side, it will be connected to the infrastructure, especially the road infrastructure. The vehicles will talk to each other via short-range communication or other means of communication. The vehicle is in any case connected to the smartphones. That's already, let's say, state of the art today. And the vehicles on the other side will also have lots of connectivity and connections to the cloud in order to utilize the cloud. We have to act within the automotive industry. We have three major areas we have to talk about and think about innovative solutions. On the one side, it's comfort. On the other side, of course, is safety, especially safety, and as well efficiency. In terms of comfort, you see more and more that we have traffic jams on the road, that it's quite complicated to drive. Today we see that the driver spends about 38 hours in traffic jams each year on average. In terms of safety, we have to reduce the amount of death on the roads in a significant, significant manner. Today we see that around 90% or more than 90% of all accidents are caused by human beings. And in order to avoid that kind of accidents, we have to think about alternative solutions, because driver distraction is one of the challenges. And the vehicle can do lots of things in terms of reducing and avoiding driver distraction. Connection, but once you have a smartphone with you in the vehicle, there's no chance for the vehicle to, let's say, manage your smartphone. And everybody knows that there's lots of texting, attempts of texting during driving in place, and we have to work on that one. Efficiency, one of the key topics also. We see there are lots of opportunities to reduce the fuel consumption by more than 20%, and that's significant. And therefore we have to find solutions for that direction. So in order to implement that kind of challenges and in order to get rid of those problems, we believe it's important to implement new value-added services, new functions to the vehicle. And lots of those new functions are only implementable based on fresh data. Fresh data, I think, is the most important topic for the vehicles of today in order to improve the functionality and the performance of the vehicles. One of the examples is, for example, the reduction of fuel consumption. We have called it electronic horizon-based fuel consumption or reduction of fuel consumption, especially in the truck business and the fleet business. It's very important to go that way. Because fuel is one of the key cost drivers in terms of business. And therefore you need a kind of solution in terms of predictive viewing what's going on on the road in order to reduce the amount of fuel consumption. On the other side, in terms of augmented reality head-up displays, you see there are lots of opportunities to improve the comfort for the driver. Again, you need lots of data in order to have the right augmented reality solutions in place, which are then displayed into the windscreen. And one of the most popular solutions, which is currently in everyone's mouth in order to discuss it, is the automated driving. Automated driving, one of the key challenges within the automotive industry for the future. In order to make that happen, we are heavily working in that direction. and those solutions do need fresh data. Having a look onto automated driving, having a little bit deeper look onto that one, what does it mean? Automated driving needs lots of, let's say, solutions starting from legal, solving legal issues, social issues. In terms of technology, it's very important to implement lots of different sensors, local sensors. But nonetheless, in terms of fresh data, there are also other challenges in, and that is, that means that we do need, for example, a highly precise digital map. The highly precise digital map means that we have to have lane-specific information in place. The map should be always up to date. Today we have the situation, once you're utilizing your navigation solution, that after 3 months or so, you are a little bit disappointed about the quality of the navigation solution because the map is not any longer up to date. Once you're talking about automated driving, that cannot be the case. And therefore you have to run permanent updates of the digital map in order to have the best and freshest map in the vehicle. And the second topic which you have to manage are the so-called dynamic services, whether it's traffic jam information, whether it's closed lane information, whether it's end of, end of traffic jam information, construction areas, speed limits, lots of dynamic services you need in order to implement highly automated driving solutions. In order to do it, there's not any longer the case to get all the different kinds of information just from the vehicle. You do need an IT infrastructure, you do need the cloud in order to manage those challenges. And then IT backend in the cloud, which should support that kind of technologies, is highlighted here. So that means on the one side you have the inner circle around the vehicle, you have lots of local sensors in which are managing and monitoring the environment of the vehicle. That's great, but it's not powerful enough. On the one side, as we discussed previously, On the previous slide, we need the highly precise digital map. The digital map will be delivered via the backend and always updated via the backend. That digital map supports or acts as an additional sensor to the vehicle in order to run predictive driving. Secondly, all the local sensors in the vehicle have a limited range between 50 up to 300 meters depending on the traffic. But once you're driving with a speed of 130 kilometers per hour, once you have to consider the situation that the driver is out of the loop and has to be brought back into the loop, you have to have a much, much broader view on what's going on along the road. That kind of extended view on the road, that is called the electronic horizon, and that needs additional information which can be provided by the backend only. The next topic why you need the IT backend is the situation that the processing power and the memory power of the backend is much, much more powerful than within the vehicles. Therefore, that's an extension of the computing power of the vehicle will be put into the backend. Last but not least, very important, we are talking about fresh data. Currently you might get lots of fresh data or lots of data from the internet. There are traffic information providers in place. Nonetheless, very often you see that the information you get via traffic information providers are not the freshest data. The most freshest data you will get via the local sensors of the vehicle, via the probe data. And therefore it's quite important to collect from the different vehicles from the vehicle fleet the probe data and crowdsource them in order to create new data and send them back to those vehicles which are in need of this kind of data. So once you have that kind of infrastructure in place, then you can also implement new services, whether it's the information about the traffic light, about green phases, when you have to accelerate the speed or reduce the speed in order to meet the green light phase. Whether you will get information what happens around the corner where you have no chance to viewing via the local sensors, all the different kind of additional functionalities can be implemented. In order to do that, we introduced the wording of the so-called electronic horizon. The electronic horizon in a certain sense is nothing else than to have an extended preview on the road. The electronic horizon is initially— was initially dedicated to and digital map so that you have a view on that, on the digital map, and you know what happens in 1 kilometer and 2 kilometers along the road. Nonetheless, we saw that it's not powerful enough, and therefore we implemented or we defined a roadmap in terms of electronic horizon. We called it static electronic horizon, connected electronic horizon, and dynamic electronic horizon. The static electronic horizon is already in place today. Here we are talking about, let's say, a local map which is downloaded to the vehicle and then utilized by the vehicle functions in order to have that extended preview. The disadvantage is it's locally and therefore the information of the map is already not the freshest one. Then we decided to introduce the so-called connected electronic horizon. We still have a dynamic— a static map in place, Nonetheless, here we have the opportunity to collect data from different vehicles, to crowdsource them, and to improve the quality of the digital map. So in terms of, for example, slope information, curvature information, those data are currently not really implemented by the digital map, or they are— they have that little bad quality. Via crowdsourcing of those data, you can improve those attributes. And the last step is the dynamic electronic horizon. Here we are talking about the situations that we are looking for a digital map which is always up to date, which is lane-specific, we have highly precise information in, and so that you have a chance or opportunity to update the map within even seconds. The second topic is that the digital horizon, electronic horizon, will be extended extended via dynamic data so that you always get the freshest information about traffic jams, about closed lanes, dangerous objects on the road. And it's all also all related towards lanes, not just towards the road, but towards lanes. Very, very important. And based on that technology, we already have made the first steps. So the so-called static electronic horizon already is in operation. Since 2012, mainly used by the truck industry. Currently it's in deployment strategy for passenger vehicles as well. And furthermore, based on that one, we are working on the next steps. And the next step is so that we have the Dynamic Electronic Horizon in place. And that is where we decided to run a strong partnership between different industries. We as Continental see that we have lots of competencies within the automotive industry, within the vehicle, also in terms of vehicle components. We see that a couple of vehicle functions will be outsourced towards the cloud and vice versa. From the cloud, we will get additional functions to the vehicle. It's all the automotive domain where we are quite strong. Where we have, let's say, missing know-how as Continental, is the cloud, is the IT technology, which is a platform technology in order to support big data processing, real-time data processing, analytics, and that's the reason why we decided to run a close cooperation between Continental and IBM, which we have announced 2 years ago, and where we see the first results now on the road. A third partnership that we have announced was this cooperation between our ourselves and Nokia here in order to get the highly precise digital map and to implement, let's say, an end-to-end solution. And the complexity of what does it mean, you see on that slide. So that means on the one side, on the left side, you see, let's say, the competence of Continental. In the middle, you see these challenges in terms of the connected vehicle cloud, where the platform is, will be provided by IBM. We will care about the applications, the so-called electronic horizon-based applications, and Nokia here will provide as a service the highly precise digital map. In order to implement that one, you see here our automotive domain expertise. So that means we identified lots of functionalities in the vehicle, whether it's the high beam solution versus automated driving, whether it's augmented reality, head-up display, whether it's advanced fast force feedback pedal, whether it's power management in terms of electric vehicles, all those different kind of solutions we are now capable to implement with a much, much better performance on that one based on that electronic horizon approach. And we will combine that competency with the competency of IBM and And Ulf will explain that slide.

Yes, thank you, Frank. Yes, from IBM side, we have in this cooperation several technology which are used for this project. So starting from our standards for telemetry or transport MQTT, for instance, hardware for the cloud, we have also software technology in there from InfoSphere and Geospatial Toolkit. But there are also a few interesting parts in the RMT or IBM IoT Foundation, what we offer in services and technologies. And last but not least, a part what I also want to explain a little bit more in detail to the end regarding the engineering or how we can support with our strategy of continuous engineering such very complex innovative projects. Because we have to understand this is really something innovative and new. It's not like we we have in historical situations where still the combination of mechatronic, electronic software in car and embedded system is only the challenge. We have now the challenge that we have for cloud technologies and use our services which become developed and are much more faster in the iteration and innovation cycle as the classical car technologies. But this is something I will go later.

Yeah, thank you. And in order to explain to you, it's not just theory. We are currently working on the deployment strategy of that kind of solutions. We have a reference implementation in place, which is highlighted here. It's a map of Las Vegas, and we showed it at the last Consumer Electronics Show in January 2015 in Las Vegas as a first step. And the next step we will present together with IBM at the IBM booth at CeBIT in Hannover. And the idea here is to say, OK, that we have the learning map in place. On the very left side, you see that on the map of Las Vegas, we had a couple of vehicles driving along the road in Las Vegas. And then those vehicles identified new traffic signs. Those traffic signs have then been communicated to the backend. The backend then has implemented a learning algorithm to identify, okay, based on the threshold level value, there's a new traffic sign of 30 miles per hour or so, and then we started an update mechanism of the digital map, not the complete digital map, but exactly a couple of tiles, and so that then we had the chance to send the newly updated or the new new version of those tiles to the vehicle. Very important here to mention in such a way that the size of the tiles has a limited size or quite small size in order to transfer it over the air. So that means it should be more or less below 500 kilobytes, maybe even below 50 kilobytes. So that's the intention what we are currently— we have in mind and we implemented in such a way. So it means, first of all, we collected the data via probe data collection, then we aggregated the data, learned that there's a speed limit sign, a new one, and then we updated the digital map. So that is one of the examples in terms of learning map, and there are lots of additional thoughts behind of how to implement that one. So in terms of dynamic data, it's always good to have a cloud in the background. So that means you can collect the different data in order to identify what is the speed limit ahead, what is in terms of accident and reduced speed information, what is ahead in order to inform the vehicles behind you. It always has to be dedicated information. That information should not be shared randomly between all the vehicles, but it has to be sent to those vehicles which have a need in that kind of information. And of course you can also run remote vehicle diagnostics in order to improve the, let's say, vehicle performance on that one. So one of those dynamic events we also implemented as a reference implementation. We had a simulator in place also in Las Vegas and we will have it at the CeBIT as well, simulating 75 vehicles and based on, let's say, accidents land information or emergency vehicles on the road information. It was immediately then calculated in the backend via technologies of IBM. And then afterwards, within milliseconds, sent to the appropriate vehicles, into the vehicle. And the information came then to the head unit and has been displayed on the one side on the display for the map. Furthermore, we've We got the warning information by the cluster. And we also influenced the haptic pedal in order to reduce, let's say, or to give a certain pressure in terms once you put the pedal, gas pedal for more energy in order to reduce it. So that means you have got several hints within the vehicle in order to reduce the speed and to get the right information. Altogether, there are a couple of challenges in terms of the electronic horizon in place we are currently working on. We believe that we have to implement this continental backend and end-to-end solution from the automotive domain. We believe that we are the right ones to do it. From the IT technology point of view, we do need the strong partnership with IBM in order to implement and based on that one, we are working on the strategic approach to run the right collector services for probe data. We implemented a certain amount of collection policies in order to reduce the traffic over the air. Over the air is still a scarce resource, even we're talking about LTE. We have to manage that air interface. We are doing We are dealing with a highly precise digital map, the learning map, which has lane-specific, lane-level information in, and we implement in current the dynamic events in order to provide enough information for new valued services in the vehicle. We see there is a huge amount of flexibility requested because the requirements are changing more or less on a monthly base, and in order to implement that kind of, let's say, flexible and agile development process. Again, we are using tools from IBM which will now be presented by Ulf.

Thank you, Frank. Okay, first of all, before we start and go more in deep, when we think about Internet of Things, so solution what we can provide from IBM side, it's really a big house. So it's nothing where we say Internet of Things is kind of revolution addressing everything at one time. So on one side it's an evolution, on the other side there are really different areas like to operate, manage data, secure aspects, analyze optimization. What I would like to focus is a little bit on an area of this Internet of Things which is not so common addressed. We all like the outcomes, innovative products, are coming out of this. But there's one piece what we have to take a little deeper on it. So what we say, it's continuous engineering. That is a vision strategy from IBM where we say according to be able to realize our new world of Internet of Things, we also have to do some changes and optimization in the area where we do design and engineering. This is what I like to address, so continuous engineering for the Internet of Things. One thing what we can see, first of all, is there's one side in this discipline we see a growth, mass of data are coming up, so much more as we have seen in the past since we are addressing not only the traditional kinds of engineering, we have much more information to be collected, analyzed, and used. On the outside, we see an emerging way of engineering themselves. When I come from the past, I was born in the area of ALM, Application Lifecycle Management. Then I learned more and more what it's about PLM. Both areas have an accord to addressing one side the product, the other side the application going to develop. What we see now today is that another part is becoming more and more important, it's the human being in between. So we see the engineering as discipline, and also we sometimes talk about engineering lifecycle management, becomes even more critical as to handle with the data we have seen before. On the other side, it is still really on give and take, and then very fast iteration give and take, learning out of what we're doing on the side of production, bringing the experience into the engineering, and getting forward, forward and forward. And realize new things we have not seen before. On this part of the engineering, this is a picture I guess most of you know. We have seen this several times in the past, also here on this conference. We see on the one side we have the traditional approach for product development, and on the right side we see a more agile interdisciplinary work. It's easy to show slides like this. It's a fast game. All we know, it's right, it's true. We have on one side we have the silos. On the outside, everything looks perfect. But in reality, there's something really changing in our market, in our industries, coming with small piece of products we have seen in the past, like iPhones or something like that. Something is going to change, and it's enormous, rapidly going to change. We have to take care about this. And the reason for this change is, in short words, most of that is based on kind of Software drives innovation, that is sure, but it drives innovation with exponential speed and complexity. There's no way around it, so we can't say, okay, we don't like so much complexity, it's there. The question is, it's complex, but are we able to handle this complicated, or are we able to handle this more simply? And the approach we like to present is ways and proof technologies how we can handle this more simple. And so this is to help you and your organization develop future products and solutions easier and faster. Continuous engineering is all about three very important for our side and important aspects and basements. So one part of this philosophy is to unlock engineering knowledge. In today's development, we have very high competent engineers' teams, they're experts on their own. I don't, also personally, I don't think we need to harmonize all of the different processes, which are different. The process of making mechanical, electronic engineers is definitely different to what we see in the software area, and even more when you come to agile software development. We don't need to harmonize it all, but we have to make sure that these these different teams have a better communication path, that they can work easier together to unlock this engineering knowledge and share this knowledge in between. We have on the second part what we say continuous verification. The basic idea of continuous engineering is really there's no, today there's no really starting and end. It's an ongoing process. You don't have today where you say you start on a green landscape, everything you start from Setting up first requirements and go down and then do the validation on the end of the V-model. Now when you start, some other product is going to end or is in the middle. So you have to be able to have an integration of different Ys or V-models in coming together. And continuous verification is important part to be able for early simulation verification in this engineering process. If I'm able to simulate, and that's a good example in one presentation, as I mentioned before, make a simulation of crashes and exceptions could happen with the product as early as possible. I can learn out of this and this saves me time and money. It not only saves me money because you don't have to crash the plane or the car, it saves me money because everything I'm going to change earlier in the engineering phase, it's much cheaper as I find change need to be done later in the phase. Last but not least, strategic reuse. As I said at the beginning, continuous engineering doesn't mean we start up with a complete new kind of project never been there in the world before. We have to adapt this concept on existing landscape of our customers. And you have very excellent technologies, innovation in place. We have projects with lots of data and you want to improve, innovate, and this need to be strategically used. And this means in some areas we see today starting where we have modular toolkit strategy. So we have variants you can build, you have reuse of components which are not only used in the project right now, also in future projects, or you have a project platform development is going more to the end and then you have new development with improvements you want to turn back. So these are the branch and merge aspects we know from the software engineering, which becomes more and more important in the overall engineering of complex integrated systems. One part of this vision and philosophy from IBM is also something you have heard in some of the presentations on this conference, is OSLC. OSLC, and I would like to give you a little bit more in view what OSLC is. OSLC means. OSLC stands for Open Services for Lifecycle Collaboration. And what does OSLC mean? So this is actually one of our core elements of our strategy. OSLC is an open community. It is driven from IBM, that's right. So we started to drive this since we understood its enormous importance to get better technologies and concepts to integrate different systems. There are also some standards like Eclipse we drive from IBM. And this is something where I say this is kind of, we can really understand as a backbone for future integrations, this open community. It's an architecture where I use a lot of technologies from the web. Some people say it looks like Google for engineering in some cases. In some areas they're right. It's based on dynamic linked data concepts and it provides architectures and concepts to simplify the integration of different heterogeneous engineering technologies you use. I think that is very important because in the new world we will not be able to find a monolithic everything-solving platform. Neither PLM nor ILM platform solves everything. We have to be able to integrate and adapt these systems and platforms engineers need to be more effective and develop the systems you like to see in the future. One thing what we provide here, that is the Jazz Integration Platform. So we use the technology concepts, services from OSLC, but we provide additional important services like project administration, report, dashboard systems, query mechanism, and our technologies for the engineering lifecycle management, what we can see here. But what is the key challenges? What are the key areas where we see, okay, that is why we think OSLC can help us, what is critical in integrated such heterogeneous environments? And that is the three parts where I say the pillars: change management, requirements management, and the connection to product structure. This is what we need to support to be able to visualize, to analyze over the borders and to organize such complex projects. I will give you, I'm not sure if it's possible to see from the backend, but just a little bit technical insight how such an integration architecture based on OSLC can look like in the example integrating ALM platform with the PLM platform. OSLC is based on adapters. It's a standard adapter, and one of the difference from OSLC to other perpetual integration is that we don't need to provide 5, 10, 8, whatever integration from one product to other products. We provide the interface to OSLC standard. This makes much easier to exchange different tools, to put new tools in. Plug and play and to maintain the services behind. It includes something called TRC, called Track Resource Set, and this is one of the key innovations we see in the service-based approach, open architecture of OSLC. This TRC covers and gets all of what is going to change. So if I have a requirement in requirements management and I link this to an artifact component I have in the PDM system and something is going to change, it's become recorded and it's available lifetime, so in real time. And so whenever anytime someone from a PDM system, from any kind of ADM modeling environment or from software side is going to look what has happened with this requirement, you can see the latest information or the requirement on the change. We call it a Hoover Uwer. So you go with a mouse on this item and you see what has changed on the other side of the world. This helps in many cases most to understand, OK, something changed relevant for me. I can understand what has changed. And if I want to step into over this, we say this border in the other area, I can link on and it moves up in the different environment. But the principal idea is here to keep the engineer Where is his comfort zone? Let him stay where he is in this environment, not that he must software engineer go into a PDM system. It's not necessary. In many cases, it's only important that he knows what is relevant for my work, what has changed for me. And to support this, our lifecycle query engine was providing dashboard information. What we offer here is our Engineering Lifecycle Manager from Rational to do this. So last slide, don't want to go on all of the, what we see as benefits if you are using OSLC, the standard for continuous engineering, but to give some thoughts in your head. One aspect, what's here as a benefit is that with OSLC we're able to support heterogeneous platform strategies. This is something that we found very important with many customers we are talking to. Because the need to go on a master data management on a vendor monolithic platform is a very critical task today. If a company is working on its own, maybe it works. But more and more companies in the industry going in joint venture, so they want to cooperate with other companies. Or we say that companies buying other companies, merging them in. And when each of them has their monolithic our PLM platform they're working on. It's an enormous cost aspect. Cost reduction on customization and maintenance. This is an element together with fast realization we also can only underline. We know how expensive it can be to adapt and customize monolithic environments. If you are able to adapt easier different technologies tools we use for the project. This is only faster and it's much more cost, lower cost level. Okay, last but not least, there's the part of what I sometimes get asked, how mature is the standard or is it something just more academic or something new? I can say there are many customers from our side using this today, but they're also very interested projects in the industry that it becomes really more and more practice-proof. So today there are several of these working groups and standards which are finalized, so for requirements, for change, for quality management. So it's a different profile from OSI, the finalists, and there are a few new and additional ones who are on the road. And this is, we'll see, it's really evolution versus revolution. We have a lot we can use today. It supports what we want to do, but there are also a lot of new things coming up for the future. So it's not a status of today that it's the end, it's really ongoing for the future. So from my side, thank you very much for your time and I hope we have still some time for questions.