 Tervetuloa, Keri Frömmlingin. Tervetuloa. Kiitos, Steve. Okei, nähdään... Oikein. Tämä oli todella mielenkiintoista katsomaan Markus ja Sore. Haluan, että olen sanoittanut niitä oikein. Ja... Täällä oli todella todella paljon näkökulmista asioita, mitä olen saanut tänään. Oletko sanoa, että ensimmäinen on aika identikaista, mitä ne sanoivat. Ensimmäinen kysymys on, mitä on smart city? Mitä ovat tehtäviä ja rajana, mitä teemme ja teemme tänään. Sitten olemme katsottaneet todella smart service, joka olemme implementeet biotoprojektin, smart parking ja charging. Sitten olemme katsottaneet sen, miten tämä oli implementeet, miten se toimii käyttämään ja sitten katsottaneet. Okei, niin mitä on smart city? Seuraavaan, kun olemme kysyneet kysymyksiä, mitä on smart city, olimme pitäneet kysymyksiä ja kysymyksiä, miten me tarvitsemme smart citys, miten haluaisimme become smart at all. Tämä oli hienoa, että tämä oli tämän weekendin, kun olemme katsottaneet sen, että society tarvitsemme tulevaisuudessa. Tämä oli 220 mega-citys, miten olemme katsottaneet, ja olemme katsottaneet sen 2050, että nämä katsottaneet ovat 60. Nyt, mitä sosioologiset voivat tapahtua tulevaisuudessa, on, että nämä katsottaneet ovat enemmän järjestelmässä, jota on tärkeää, ja jotenkin järjestelmässä. Joten, miten olemme katsottaneet, että se on tärkeää? Tämä on eri asioita, että on se, että on hyvä, on hyvä ihmisiä, on hyvä publikaservi, mitä on koko kautta, ja kun olemme Firlandissa, niin se on tärkeää, joka on yksi asio, ja edukaisu. Joten, kun olemme kaikki nämä katsottaneet, okei, minä olen Firlandissa, eli climate on hyvä, jotenkin, vaikka Dublinin, okei, mutta kun olemme kaikki nämä järjestelmässä, jotenkin katsotaan hyvää katsottaneita, jotenkin olemme hyvää katsottaneita, ja se on tärkeää, jotenkin katsotaan, jotenkin, että nämä voivat ottaa tämän hyvää katsottaneita, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, jotenkin, Obvious when you look at these use cases, that you will have to have systems that can interoperate between different companies, different domains and different systems in general. Now relating to the previous presentation, all these use cases were actually described using Archimator in the Biotov project. So I think Marcus and Soda, if you, I don't know where you have, it could be a good idea also if we share these descriptions with you. Okay, it's good to be able to implement all kinds of smart services, but then the next question is how much are those services allowed to cost because in the end we are all paying for these services as tax payers or users of these services. So it's quite relevant or really relevant that these smart city services are affordable. Now what are the main hurdles for these being sort of affordable? Well if you want to, or now when you start implementing smart city services, then typically you might get something like a smart lighting service or a platform running on one specific platform, but that platform and service will not be discussing with your smart mobility systems. And even if you are implementing some kind of mobility as a service services, you will still have quite many different systems and organizations that might not interoperate. And if you want to make these systems discuss with each other, that could be, that will take for the moment usually quite a long integration time. So interoperability between proprietary platforms is for the moment complex and it's very expensive to implement also. And then finally, if you buy your system from one specific system provider without, or that is only using proprietary interfaces, platforms and so on, then you have quite a big risk of vendor locking. So then some economics bargaining power of cities, that's what we think that the cities should be getting back as a bargaining power so that they could ensure that these services are implemented in ways which don't become too expensive over time. Now this picture here comes from an article by Michael Porter and I don't remember something in Heppelman on the five main competitive forces in any kind of business. And these same forces do also apply to cities and since the cities are typically end users, it's really a question of the bargaining power of buyers. So if you want to ensure that the cities have some bargaining power on the services that they are buying from companies, for instance, then they should be able to require those services are provided through some kind of standardized APIs, which means that if you do manage to do this, then you can also change the service operator if and when needed. Because then you can impose it, okay, if you want to do business with us, then you have to implement your service using these specific standards. So that means that you have a way of avoiding vendor locking. It's also quite important that it becomes much easier to create new and more complex services. So if you have a simple service that's published using an open standard, one or two or five different services, you might actually get some other companies or geeks even just combining these different services into more complex ones and creating new services, which is quite difficult to do in the current landscape. So through all this, well, cities would gain increased bargaining power for the smart services that they implement there. Okay, so that's the background and those were actually the incentives for us to specify this EU product called Biotope initially. And so the Biotope project, it started in January 2016 and it will end in the end of May this year. So we are close to the finish and that's why we can actually show quite a lot of implemented systems. So the objectives of the Biotope that we set out in the beginning, we had four main objectives. And it was quite nice to see that Marcus and Soda was saying the same things that you should not go technology first. You should really go and see what are the end user needs. So we started off the product by really asking these product partner cities what are the most relevant services that you think would be useful for your city. And then based on those requirements, use open and open standards to implement them. And then deploy test and validate these systems in real use cases so that we can show and have proof of concepts that it's possible to do it. And not only that, it's also about creating sort of sustainable business ecosystems. So have proof of concept installations that are up and running but also have enough business incentive for all the partners that implement those use cases. So that they would keep them running on a sort of business-based basis. Okay. The consortium, well, the cities, the main partner cities that we have in the product are Helsinki, Brussels and Leon. But we did also get St. Petersburg on board later on that doesn't show here on the map. And Melbourne in Australia. I think one of the important partners to mention here, it's definitely BMW who that you will be seeing in the implemented use cases pretty soon. So since I'm fundamentally a geek, I would say I can speak about business stuff and so on, but it's when we get to the real implementations that it gets fun. So this slide is quite old. I think many of you have seen it already many times, but it hasn't lost any of its relevance over the years. So what we want to achieve is that when we have a BMW or any car that arrives to any town here on Earth, it happens to be a BMW here that arrives to Helsinki. So what would happen when this BMW arrives to Helsinki? Well, we would like it to be able to discover all the services provided by the IT infrastructure or ecosystem that we have in Helsinki. So if I need to find a parking place with potentially a place or possibility also to charge by electrical vehicle, then I would like to find one place where I can actually find the available parking places in real time and then even, well, potentially reserve them if needed. Okay, that's the use case that I'll be showing in a moment, but you could also do other fun stuff. So once the car is inside of your city, if it agrees, then it could also start sharing information with you, such as if it notices that it's slippery in some place, in some street, then it could just send an event to the city infrastructure, saying that in this street it's slippery just now, and once the city infrastructure has received 10 of these different notifications, 10 or more or whatever, then it could start sending or notifying other vehicles about this in advance so that either the car itself or the driver would know in advance that there's a slippery spot 100 meters ahead. So this is really the kind of visions that we set out in Bayatope. Okay, now I was saying that we focused on the smart parking and smart charging first. If you have a look at the real services in these domains that you find in different cities for the moment, you will see that it's a completely different companies and organizations who typically manage the parking places. You might have easy park, I don't remember the names of all these companies. And then on the other hand you have the electrical vehicle charging companies. So these, you already have two kind of domain specific silos that you would need to discuss with if you want to create this kind of services. And then in addition to this, all these companies tend to have their own company specific information system silos. So you could have an electrical vehicle charging operator that has its own charging poles that only negotiate with their own cloud service that only discusses with their own app. So as an end user or a BMW owner, if I would like to charge my BMW and Helsinki, well I would have to find out what all the electrical vehicle charging operators are there if I would like to be able to find all the places and also especially be able to pay. Somebody might be thinking that there are already services called open charge map and this kind of things. Yes, you do have different services that collected this kind of information, but they are not publishing it using any specific standards. Okay, so those were challenges, but what did we do in Bayatope? Well, we applied so to say our all the open standards that we could find that are usable directly. And then this will allow me to have a short break because we have a video of three minutes and something. And before I put that on, I hope there's the sound is switched on. Okay, let's go ahead. We present our use cases related to smart equipment and electric vehicles. It has installed Intervent Corporation's Smart Air Handle Unit in his home. When he is away from home, he can save energy by setting his home in that way mode. This information can also be shared with his other smart appliances and his car. BMW has installed their Biotope prototype dashboard in Robert's electric vehicle. They can control the car automatically based on contextual information such as temperature and Robert's distance from the car. Now the car knows Robert is leaving and is being preconditioned. Doing this while still plugged in saves batteries. It is now comfortable. Robert is going to a meeting and a location where he needs to find charging for an electric vehicle. He receives a list of charging spots suitable for his car near his destination. He selects a spot provided by parking energy and enjoys a ride towards his destination, parks his car. But when he is selecting his charging spot, so he only needs to enable charging, he connects the cable and charging starts. And Stasia is preparing for a meeting. She doesn't need charging, but does need parking. Open parking data from the city of Helsinki, allow a service search for available parking. This alternative university app uses the same Biotope technology as Robert's car. It could also guide owners of electric vehicles to parking areas that provide charging. Okei, I guess it's finished. So those who were at the Open Group conference in Singapore, some of you might have seen this video already. We did this in September last year, so there has been quite a lot of progress since then. And then the focus was actually on the security and safety of Internet of Things systems. So the focus was slightly different. This time the focus is on what really happens in the Helsinki use case, because all these systems were implemented and installed on real devices, real information systems and so on. What you see happening on the BMW dashboard, it's actually programmed by BMW and discussing with real information systems behind the scenes. So the Helsinki use case actually became a combination of several smaller use cases. So we first had this preconditioning idea, meaning that for electrical vehicle, especially in Finland, I guess in Houston or in warm places, it's the same thing too. If it's cold or really cold or real warm outside, then you would like to cool or heat the car in advance as long as you have access to the grid. You don't want to use the car battery. So that's why we connected this signal from the air handling unit of ventilation system to react based on the context, the outdoor temperature to actually start cooling down the vehicle in advance before a robot gets there. Robot is not here yet, but he'll arrive actually this evening. Okay, then we combine this with real time traffic information and especially this smart charging and smart parking. So the point here is really to emphasize that, well you remember this silo picture. In this implementation, we are using what we call OMI nodes. So they are nodes information systems that implement the open messaging interface and the other standards here. So the point here is that you only have these bi-directional connections shown by the arrows here that happen when you actually need them. So the air handling unit takes contact with the BMW back end system only once it has something to tell it, meaning that in this case what it has to say is that the robot is leaving from home. So you might need to know this and do something smart based on that. Okay, that's the first connection, but there's only one message going between the two different nodes when and as needed. So there's no sort of continuous integration or software integration work that would have been done. Okay, so then the BMW starts, Robert starts driving the BMW, doesn't drive by itself yet, but the car will know where Robert wants to go. So then it starts looking for different OMI nodes that actually provide this smart parking and smart charging service. And once it finds some of them, then it tasks them for the available places where you want to go and for that specific time and so on. So there's no system integration, it's just a query, well discovery and query mechanism that happens in this specific context for a specific purpose. Then we do also have an integration or let's say information exchange interoperability between the electrical vehicle charging operators and the parking operators so that you can combine these different pieces of information together. And finally this Gruppo Siegelad that you see here on the bottom. So that's a partner that joined the Biotov project a year ago through an open caller. So they have actually implemented this commercial level app that we are using nowadays that discovers all published parking places when and where you need to have them. Okay, so the point here is no system integration, open standards all the way and you find and communicate with information sources when and as you need them. So then I always, people always keep telling me that don't show that XML in your presentations. Now I'm still showing some XML in this case. So why do I do this? Well all these different OMI nodes publish or have what we call a data model of the data that you actually can publish. So what we see here, it's a short snippet of description of parking places and their availability. Now in practice so all this information here or most of it is accessible using this kind of data model. But the point here is that you don't actually have to have these data models published. So when people say that in smart cities you have to publish all data as open data, no you don't have to. Because what you actually want to have it's some kind of smart services. No matter if all this parking place data was published or not openly. The only thing that the BMW and the BMW driver wants to know about is some kind of service to which you can say where am I going and when, where and when. And then I would get as a return result a list of the places that I could try or should try and so on. So based on the context find the D service that I need and then just be able to use this service. No matter if the data is open or proprietary as long as the API is open and standardised. So IoT standards by the open group. So the standards that we are using here or this one specified by the open group. So it's the open messaging interface and open data format. The first version was published already in 2014 of them. And I think we might be the first Internet of Things work group in the world. I'm not sure we established ourselves in 2010. And we are still active. So some of the functionality, quite a lot of this functionality that we used in this video actually comes from the version 2 of this standard. So that's upcoming in 2019 meaning that we actually are going to get them published quite soon. And then we also speak about this open data element framework as an Internet of Things standard. Quite often it's published by the open group. It's not the Internet of Things work group but we think it is very relevant still in this Internet of Things landscape. And I'll explain soon in what way. So a little bit more about the vision and background of this whole Internet of Things work group. So I wrote my first Internet of Things implementation in 2001. And we actually published that in 2002. So I keep on saying this that well what comes to Internet of Things. There are not many people in this world who have done it longer than we have. But over the years and after working with loads of different companies and different kinds of machines in different domains. We started speaking more and more about these systems of systems which I think the US army initially coined as a concept. But the point here is that contrary to quite many current Internet of Things systems. We think that in real systems or systems world you should be able to have even low level automation devices discussing directly using the same standards as they are using for discussing with back end systems. And back end systems are discussing with each other using the same standards. It shouldn't really make any difference if it's a low level information system or a cloud based service. And it should also be possible to discuss both ways. So it's not just about pushing loads of sensor values to the cloud. It should really be possible to do control even locally within this room for instance. You might not want even to have all that data going out to the cloud because of security reasons and other reasons. So then a little bit more about technology and these standards. So the open messaging interface it has all the operations that we think are needed in this kind of systems or systems system. So read operation of course for getting the current values. Write operation for notifying an updating sensor values or notifying about events of all kinds such as a slippery road. So those are kind of classical stuff that you find in just about all rest APIs I would say. But in this internet of things and systems of systems world what is real relevant is that you have some kind of way of subscribing to the specific information that you are interested in in a given context. So I could for instance subscribe to Steve's fridge somewhere wherever that is and ask that to tell me if ever Steve has left the door open or whatever if Steve allows me to do so. And then I could even specify for how long I want to know this so for the next half hour or for the next lifetime or whatever. And whenever Steve would leave the fridge door open for too long then I would get a notification about that. Of course you need a way also of canceling such subscriptions and I was speaking about this fine parking method so we have a call function and of course delete functionality. Then the open data format it's a pretty small standard. It just specifies a vocabulary of objects and info items and metadata related to them and of course values. So objects correspond to some kind of things. A thing could be a car, a fridge or whatever else it could even be an ERP system in some cases. An info item again it could be a sensor value but it could also be some kind of event that you can subscribe to. And we use OMI and ODF together to get to accomplish this thing of the needed functionality of publishing information, discovering it, querying it for it and then retrieving that information. Now the third thing here on this slide the type attribute metadata elements. We use these for both objects and info items have something called type in ODF. And the way in which we use this in the Helsinki use case for instance is that since we ourselves don't want to start specifying well too many data types and semantics and this kind of stuff. We would like to prefer or we would prefer using existing standards whenever possible. So what we are using in practice in the Helsinki use case it's something called schema.org and something called a mobivok which is an extension of schema.org for mobility purposes. Okay so I don't know how many of you know schema.org but it specifies objects such as sparking facility. No wait a minute it's mobivok that specifies sparking facility. Schema.org specifies what a location is, what an address is and so on. So these were the sort of trendy things that our developers preferred using but the thing is that both of these is that they are quite domain specific. Schema.org is not very domain specific but it's still quite limited and either one of these are standards. So coming to this third Internet of Things standard so to say so the open data element framework. Now that is quite interesting, very interesting because it's not domain specific. So ODEV in itself on the uppermost level has concepts which are sort of cross domain ones. And what is very interesting about ODEV also is the so called plugins concept that allows you to reuse many already existing standards that are being used by most industries out in the world as well UNESCO, UNEC, SIC and ISO 4217. Okay so what does ODEV look like? I suppose many of you have seen it already but I think it's still good to have it in this context of Internet of Things. So you have basic concepts such as person, family name, that's the first column here. Then you have a name for that concept in English, so person name.family. But what is maybe the most interesting part here is the last thing so you have this numeric correspondence to that concept which is not language specific so it's not specific to English or any other spoken languages. So you remember we had this air handling unit in the Helsinki use case that was discussing with the car well this is an example of a small part of the data model of that air handling unit and what this actually says if I'm using ODEV codes is that this object is a product according to the UNSPSC specification that is an air handling unit and it's reporting its fresh air sensor value which is actually the current outdoor temperature using the UNECE Rec20 specified value. So okay, now I lost my own track. So temperature expressed in degrees Celsius. So that's one example of how you can combine these standards together to actually represent your data in a standardised and annotated way. And yesterday somebody was speaking, I think it was the first presentation on the subservice service work and so on where there was a requirement on separating data and services. Well, this is one way of doing it. If you store data using these standards then you will understand what it is about. And I won't spend too much time on this because I only have one minute left. So the advantage of ODEV, there are several advantages. It's a simple low band with code but also it's not languages specific. So I think the world is getting more and more global. That's quite an important aspect of ODEV. So the common standards landscape in Bayotope or actually with the Internet of Things workgroup we think that when you implement any kind of Internet of Things system or system assistance well you will have a stack of different standards and protocols that need to interoperate. Depending on the actual use case requirements on lowest level you will have to choose them based on if they are wired, wireless or other sort of use case specific requirements. On the uppermost level you might want to use semantics that are specified or standardised for different domains. But still if you want to keep all this interoperable then this waste here should be pretty thin. Just like for the web you have HTTP and HTTPS. Well in the same way for this Internet of Things to be successful you would like to have quite few standards there. In the middle. So we have applied this principle in Bayotope for implementing many other services also in the participating cities. So bottle bank emptying and other kinds of things. We have also done this smart parking system implemented that in all the three cities together with the BMW. So then we come to conclusions because I see that I should be stopping now based on the timing. Conclusions. Open standards for implementing smart cities do exist. Then it's a different question if the cities will start requiring the use of these. And the whole point here if you remember the beginning is that smart cities could actually increase the bargaining power to allow us as citizens also to get these services simpler but also without paying too much for them. We do have real life implementations as you saw they have made quite a lot of progress since that video. And tomorrow morning we have all the three partner cities presenting their use cases and how they were implemented. That's the morning program. So afternoon you can participate in this coding workshop where you can see all the open source components and so on. It's actually very easy to take into use and publicly available. Please take a seat. Thank you. We do have a couple of questions. Let's see. Do you see a future where all these smart things are represented in ODF or ODF to allow more seamless interoperability. Well actually I think there's sometimes misunderstanding that you don't have to represent all the data and all the services of these things are using these standards. It's just like with the web that you have loads of information about different things in databases and so on. But what you actually publish to be available to others is just a small subset of that. So you would not have to model all of them using these standards. But if you want the data that you want to exchange and the services that you want to publish them then those should be represented of course using some open standards. Okay. The common standards landscape and ODF you said different domains have different vocabularies and requirements. Can you share what is the main added value of ODF? Oh I should have taken Ron here. Yes I know Ron would be here. Well I did have a slide on that so okay it's a low bandwidth and so on. But I think the main thing is really that's my personal view. It's the support of these plugins. So the support for existing standards which are already used by customs and manufacturing companies all around the world. So since we already do have these standards I think it would be worth at least taking them into use as far as possible before starting to reinvent new vocabularies. One of the things that seems to be consistent about smart city implementations around the world is a lack of standardization between those implementations and approaches. You're using open standards in the biotope project. How do you see the role of open standards or how can it be expanded? Yeah that's what I guess you see the value of it but how do we get other people to see the value of it I guess. Yeah I think well let's say that this this kind of conference is all the kind of events that we have tomorrow. That's for really showing that it is feasible and simple to do with using these standards. I think most of these systems can be implemented in simpler ways even if you reuse what we did in these cities. Then if you actually start a completely new product. So through use cases showing that it's feasible and not more expensive. So you mentioned you mentioned tomorrow you're going to give a plug for the event tomorrow or should I. Yeah so I also a little bit quicker with the conclusions so yeah tomorrow I think it's in this room or one part of these rooms. So we have the whole morning session where we go through the technical levels of this or what we have implemented. But especially if we have these three partner city presentations. So the end users saying what are the benefits that they got from this and how it was implemented. How it was perceived and so on. And as I was saying in the afternoon there's a coding workshop so I might be long on this. My students when they see how I or we have are setting up Internet of Things systems in five to ten minutes. They have been asking me for years that why don't you tell other people about this. Instead of getting your own Raspberry Pi's and all that is doing spending loads of time. You can get it up and running quickly. And then we expand that also through the Leon use case to real systems or systems. The last question Kerry do you think it's possible to scale what you are learning and defining about smart cities to a global stage. Oh technically definitely yes. But the big challenge is quite often tend to be commercial or political. Yeah understood. Thank you very much.