 Hello everybody. I'm Chris Harding, the Director for Interoperability at the Open Group. And part of my role is to be the Forum Director for Open Platform 3.0, which is the Open Group initiative to enable enterprises to gain business value from new technologies, including the Internet of Things and also including such things as cloud computing. Social computing, mobile computing, and big data analysis. But today, our focus is on the Internet of Things. And it's my pleasure to introduce Cary Framling, who will give the main presentation. He is a professor of practice in building information modeling at Althair University in Finland. And he is also CEO of the Finnish company ControlThings. And last but not least, he is the chair of the Open Platform 3.0 workgroup on the Internet of Things. So Cary, over to you. Thank you, Chris. So since the introductions are made already, I'll go straight to the presentation. So the summary of today's presentation is the following. I'll go through some of the background of our work, where it comes from, why we did it, and so on. Then go through the principles and use of the Open Messaging Interface, or Maya and Open Data Format Standards, show a reference implementation of these standards, what you can do with it, how it works, and so on. Some applications for illustrating what you can do in reality, a quick comparison with other standards, and then a conclusion. So the background, well, our work actually at Helsinki University of Technology on the Internet of Things started around 2000, and in 2001 we wrote this dialogue Internet of Things Middleware, which at the time was very focused on RFID tags and so on. But we actually quickly came into the kind of Internet of Things that we are dealing with today, meaning send source, intelligent products, getting information from all kinds of different information sources about different products, what happens to them, and so on and so on. So the figure that you can see here actually illustrates that kind of a system. Then we started doing this EU product called Promise in 2004, where we could apply all these different concepts. Now I promise that the goal was to manage the life cycle of different kinds of products in different kinds of domains. So we had companies illustrated here, such as Caterpillar with their heavy machines, we had Eveco with their trucks, Fiat with their cars, Intasit with their fridges and other household devices, Infracon with telecommunications equipment and so on. And with all these different companies in Promise wanted to be able to do was to collect information about the usage of their products so that they could detect any kind of problems and do improve the maintenance of them as well as the design and manufacturing of those products based on all this collected data. So in order to be able to do this for all these different companies and domains, in Promise we came up with some interoperability specifications that we then took and went with to the open group where this workgroup on the Internet of Things or actually it was called Quantum Life Cycle Management was established in 2010. And finally in 2014, so last autumn we, meaning the open group and the Internet of Things working group, workgroup published this open messaging interface and open data format. Now before I go to the next slide, I would emphasize the figure that you see here. So you have many different kinds of product, service source, RFID technologies, but you also have backend services and so on. So this is the kind of view that we have had of the Internet of Things when specifying these standards. Now that's a certain contrast compared to how it seems like most people and companies look at the Internet of Things today. So I see loads of different systems and platforms where the main goal seems to connect or gather sensory information into different applications, platforms and so on. And it seems to be the case quite often even that you might have several sets of sensors measuring the same thing at the same place, but just feeding different platforms and applications. So that's what is meant by this point saying that data is collected into vertical silos. So you would have loads of interesting, useful data and information potentially available, but it's difficult to use it because they are collected to these specific applications or platforms. Also if you want to do some kind of machine-to-machine communication, that tends to be limited to local networks. And it's difficult or even impossible to do a bi-directional control. So the challenge with the way the Internet of Things works today is that you actually get or gather huge amounts of data from sensors. And this data keeps on being collected just because it's supposed to be good to have loads of data. And then you get this phenomenon called big data and you sort of hope for somebody to be able to analyze this data and come up with something useful. Well, that might be the case, but in practice we have seen that most of that data might not be usable or interesting even in practice. Also it's hard to achieve interoperability between these different devices, machines, platforms, applications and so on. And finally the Internet of Things that really requires communication between systems and organizations, not just local machine-to-machine communication. So what we want to enable or think we are enabling with open messaging interface and open data format, it's really what you can see in the red arrows here in this picture. So we're not speaking so much about sensors. We are more dealing with more intelligent products that might or usually have sensors connected to them. But then we have these platforms adjusted before. Now what we want to enable and think we are enabling with OMI and ODF is that you can have direct machine-to-machine communication as bi-directional, even over the Internet, not just locally. But you can also connect these different products or information systems, not just to the initial application that they were feeding to, but also easily share information with other platforms and applications, so directly from the machines to the systems or from the systems to other systems and so on. So with OMI and ODF we think that horizontal integration should be as easy as vertical integration and even vertical integration should become much easier than it is just now when you have appropriate standards for doing it. So also with OMI and ODF the purpose is that you should be able to collect the data as and when needed on the flyer without having to do any programming or systems integration and you should also be able to establish this kind of two-way time-limited information flows between trust identities and the physical products when you need it for some reason. Now we'll see examples of how you do that in practice in a moment. So based on this view of the Internet of Things, so for the Internet of Things workgroup it's really a question of creating and enabling systems of systems. So for us a system could be or has been passed just an RFID tag or it could be an intelligent sensor, it could be some system connected behind a gateway or it could even be an entire ERP system or the weather forecast service or a smart car. But the specifications of OMI and ODF have been specified in such a way that they are agnostic in what comes to the size of the system. You sort of deal with all kinds of systems in a pair-to-pair manner. Now I already mentioned I think this product lifecycle management and what we have been calling a closed loop lifecycle management for some of the last 10 years maybe. So that's a typical case where you have a need for systems of systems. So if you take any kind of, well, some any kind of smarter products let's say this way such as as a truck and if you need to do to perform some maintenance on that specific truck for instance, well all the information about that truck might be stored in many, many different information systems owned by many different organizations and so on. So if I want to do the maintenance on my EVECO truck for instance, well at first I will want to get access to how the truck has been used and so different statistics stored on the truck itself in the trucks information system. But I would also like to get access to earlier maintenance records made either by me or by some other organization as well as access to the maintenance instructions for that specific truck that might come from the manufacturer or somewhere else. So this, when you are dealing with closed loop lifecycle management, that means that you really are dealing with systems of systems where the systems can be embedded systems, sensors or any kind of backend systems of different kinds. So in this picture the IoT is really an enabler for accessing all this information and OMI and ODF are the standards that enable you to do it. Then to some other kinds of systems of systems. As Chris said, the Internet of Things workgroup is a part of the Open Platform 3.0 forum and together with the Open Platform 3.0 forum we have specified a certain number of use cases that are illustrated by this picture here. So here you can see also that it's really about systems of systems. So if you want to do intelligent utility energy management, intelligent automotive management, intelligent traffic management and so on, you typically need information coming from many different kinds of sources. So in the same way OMI and ODF are really enablers for these red lines that you can see here between different for enabling ad hoc information flows between relevant information systems for whatever is your application. Okay, so then the next part of the presentation is to have a look at what OMI and ODF actually look like and how you use them. So as I said they were officially published by the Open Group on the 16th of October in 2014 and the two standards have different roles in the sense that the Open Messaging Interface specifies a protocol for communication while the Open Data format specifies a standard, a very generic standard for the payload. Now the model for this is similar to what is being used on the web. So as presumably most of you know, for the web the cornerstone protocols and standards are HTTP and HTML where HTTP specifies a very simple command vocabulary for accessing information while HTML is the format for specifying the actual contents or the payload. Now what you can do with OMI and ODF is that when you have some new information system or a new device that comes into a new context, so for instance I install a new machine or a new sensor into my home, then that machine should be able to publish that it's present there as well as tell what is the information that it can provide as well as what other services provided by it. Now then the building and the other systems they should be able to discover that okay now we have a new information system here, a new device and it provides these and these pieces of information and these services so now we can do new things together with this new system. Doing new things that assumes of course that you can communicate with it so that means that you need read and write operations for accessing and updating information and one of the cornerstone operations is of course that you should also be able to subscribe to information so one information should easily be able to subscribe to information from this new information system and contrary to many other protocols and standards that we are not using the complete published subscribe design pattern we are actually using the observer design pattern. I won't go into the sort of very details in how that differs just now. Both standards over my and ODEF are specified using XML schema and one thing that makes them quite different from most or maybe even all interval things the standards that I'm aware of is that they can be transported by any underlying protocol more or less. So usually we are using HTTP or HTTPS but you can actually run over my and ODEF also over FTP, SMTP, XMTP file transfer even send them on USB sticks, plane sockets and so on. Now this is quite important in the sense that you can use over my and ODEF both as standardized IOT REST APIs as well as using them for machine to machine communication as well as machine to system communication, system to machine and so on and so on. So then some more details about the open messaging interface and here you can see all the possible operations and the variations of them. So write, read and cancel. Of course the names tell it more or less directly what you can do with them. With a reader you can get the current and historical information about alerts, sensor values and so on. This is the immediate retrieval part here. You can also write information using the write operation and then the subscription operation comes here in this branch. So you can do it in many different ways using a callback address without callback address and you will see in a moment that you can specify for how long a subscription should be valid. So it can be time limited. You can specify regular intervals for it or use event-based subscriptions and you also have a piggybacking functionality that allows you to do even control through firewalls and so on. And then finally the cancel operation for cancelling subscriptions before they expire. Then the open data format allows you to specify a very generic object hierarchy. So it's shown here on the right side. So an ODF structure always starts with this object on the upper most level. Object can contain other objects and then every object can have properties specified by info items or other sub-objects. And every info item can have some metadata about it as well as values of course. And here on the left you can see just a simple example of how you combine OMEI and ODF. So this would be a write command. And the object that is sending the write command is this smart fridge that you can see here identified by a sort of generic name here in this case. And it is sending the current fridge temperature set point and the current freezer temperature set point. So this is a very simple example of what an OMEI and ODF message can look like. You'll see more examples of these in just a moment. Now what is more interesting is to see how you can subscribe to information. So in this case I am using the read operation. I am giving an interval of 600 seconds. So I am requesting for information every 10 minutes and it should be sent to the OMEI node at this callback address. And the time to leave the minus one means that this subscription should exist forever or until it's canceled. And in this case I am using ODF as the query language. So I am saying to this, or telling this OMEI node that I want to read information from this smart fridge two, two, three, three, four, four, one, one. And the information that I want to get every 10 minutes is the door status, the temperature, and the consumed electrical power measure. And then once this subscription has been made, I start getting this kind of response messages every 10 minutes with the actual, with the same ODF structure but with the actual values here as you can see in the value tags. So this is sort of the basic introduction to what it looks like. Now it will become a little bit more challenging because we are passing live. So as for most standards, it's very useful to have a reference implementation that shows how you can use the standards, how you should use them that you can interact with so that you can check that your implementation is compatible. And also since it's published as open source, you can actually take the code as such and integrate it into your own applications so that the implementation efforts of getting the standards into your own system are kept as low as possible. Now the plan is also to disseminate this reference implementation through this iotflips.org and other appropriate dissemination channels. And what this reference implementation implements, we have URL based discovery and read operations and web GUI for more advanced operations. It's written in the Scala programming language which is sort of the new language that's rising at least in our university but we do also have implementations in quite a few other languages. I'll quickly show you a small implementation made just with a simple Unix JavaScript for publishing information. So then I will jump over to Google Chrome or any browser but in this case I am using Chrome. So what I will start with is showing how you can access information using just simple URLs. So if I write here the address of the ominoad slash objects, I will get a list of all the objects that I have available here at this ominoad. Then since I'm sitting in Finland I will of course go to the sauna and see what information I have from there and I think you got the idea already. I just see what are the different sub-objects and info items and then I add them to the URL and get access to the next level. Then if I want to get just a raw value I can write slash value here at the end and if I want to get access to the metadata about this temperature in fight then I just write metadata here. So well metadata can be information such as unit manufacturer and so on. To be honest this is just an example of how you can specify metadata. In practice it's recommended to use some other kind of standard for device descriptions or this UDF framework for instance. UDF standard that is also developed by the open group. So that was the URL based discovery and how you can access information that way. Now if you want to use the total range of possibilities and functionality of OMI and ODF then you should go to this example web user interface Now what I have here is first the address of the OMI node again. It has now fetched all the objects automatically that are available there. So here I can select from the hierarchy from this window what information I would like to request. So for the sauna for instance I take the CO2 level current humidity and temperature and then in the next step I generate the corresponding OMI and ODF request. Now I can modify the parameters of the request from here so the time to live says how long this message should be kept alive if it can't be delivered or if it's a subscription then it says how long the subscription should be valid. Now the interval parameter specifies in seconds how often I want to get the values or if I specify minus one here then that means that I want to get an event every time that the value changes. So for instance that's good for monitoring door openings and closings or let's say a fridge that's going to break down and you would like to have potential of subscription that is eternal but you only want to get an event when something unexpected is happening. Then you do also have the possibility to specify a time frame. This is if you're just doing a basic read for getting historical data between two dates you can also request for the newest available number of historical data available or the oldest ones and then you can specify a callback where the data should be sent. But in this case what I'll do is I'll just send the request and then I get a response that shows me just the current values of these info items. Now in this case these are fake values because since it's a reference implementation that is supposed to run anywhere we haven't connected this one, specific one to real sensors but you'll see some of those in just a moment. Okay, I think that was showing what the read operation looks like. Now next I will jump to something a little bit more nerdy or geeky. So what I have here it is I'll just jump over to my virtual box virtual machine with the Linux running there. Now I'll try to be not to be too quick with this but what we have here it's actually a Unix shell script that is a generic script for generating write messages using OMI and ODF. So I'll just show you that it's very short this will also be published as open source so this sort of implements the whole OMI ODF that you need for producing this kind of write message. So the formatting doesn't look that great here but that wasn't the purpose. Normally it would be on just one line but what you can see here you have the OMI header so this is a write operation and what I am sending it's an object called a basement one because I plan to install some temperature and humidity sensors into a room in our basement and I have three different sensors and for, okay so sensor three and all three sensors provide me with temperature and humidity values. Now the actual physical sensors are one wire sensors and they're on the table here beside me in fact so I could show them live but the way that you get the information from them is by defining a simple data structure that looks like this. So this system is actually running on a Wi-Fi router which we have flashed with a Linux and installed these scripts on it and the fact or how the way in which we define this whole ODF structure that you saw looks like this so I just define the basement one level here three sensors here and I say that they all have temperature and humidity readings and if I uncomment these which I do when the script is installed on the router then I will actually get the real values from the sensors. So the point that I want to make by showing this system is that you can implement and know and my know that gets real sensor values so in this case six sensor values with real minimal effort and on really let's say low range hardware so actually if you have a look at this shell script well it's that's something that you can put or implement even on very low range low memory and so on hardware. Okay I hope that at least that many of in the audience could follow this what was happening on the Linux system so this was the reference implementation part now then I'll quickly show some example applications as you probably can imagine over the years since 2001 we have made loads of different implementations, real business applications and so on also but today I'll just show some work that we have ongoing so as Chris Harding said a moment ago I'm also professor or official professor in building information modeling so this will be very building focused. Now buildings are a typical target for the internet or things smart products and so on and that's because well there are many different challenges they have long life cycles you have information coming from CAD systems from you have different machines installed coming from different manufacturers when you want to optimize your energy consumption and so on you need information from what about energy prices weather forecast, weather conditions you need to be able to control different systems inside your house and so on and so on. So the first thing system that I'll show rapidly is something that or it's a system that we have implemented for one of the university buildings or the other university in Helsinki so what you can do with this system is that we have taken the CAD models of the building and try to use them for first visualizing the whole building and allowing you to get access to different things there but the interesting thing here is that for the moment you can get access to the installed sensors and get the readings of them in this way so this is sort of a 3D visualization that's mainly because it looks good and so on but what is more useful is actually this kind of a 2D view where we can visualize a heat map in this case of the different rooms on one floor we can also change it into humidity or any other values and we have the possibility to actually go and have a panoramic view of the different some of the rooms so here in this case I'm in the corridor and apparently it tends to flicker a little bit when I move around so I will stop here and here I can also see one of the sensors where it is actually installed as well as the current readings from it now the purpose here it's not just to sort of install sensors it's really about that when we install these sensors they publish immediately that now I am here in this place and I can provide you with this information so temperature, light, CO2 humidity and occupancy information and then the building and the building itself as well as this whole visualization tool can know that okay now I have a new information system it happens to be a sensor that provides me with this different information so then once I have all these different information sources publishing information using OMI and ODF I can combine them and build new services for energy efficiency or combine information from access control systems from heating systems and so on and so on now I would say, speaking about this bi-directional controller quite a bit in the beginning of my presentation and I really think the internet of things and what we are doing should make it possible to control or improve the way in which buildings and all other systems are controlled so what I will be showing next I will quickly jump back to this slide it is a system that is installed in our house in fact it's a ventilation machine that looks like this with heat recovery and so on in modern buildings this is sort of a cornerstone piece of equipment for making things or for making buildings energy efficient now what makes this machine interesting is that when you have installed it in your house and if it's connected to the internet then it will immediately give you access to this user interface so from a smart phone or any kind of browser or whatever and it will tell you it's phone serial number as you can see here as well as a pin code so that you can establish an SS cell connection all the way from my browser to the actual machine now this is quite important that you do have a complete security as you will see in a moment so what I can see in this window now it's the current status of the machine so HRC that I don't remember what that is to be honest you can get access to different kinds of set points but to get the connection with OMI and ODF I will jump to this measurements window here where you can see all kinds of sensor information which have been collected here in southern Finland in the last week so these are real data as you can see by the curve you can also see that there was a real storage here and in this case for these sensor values they are collected and stored with 10 minutes time interval so that's showing this interval based subscription that for this kind of information it's enough to get it every 10 minutes now that has been selected so that also this machine maintenance provider and manufacturer can gather relevant data about these machines such as the heat recovery rates on the incoming and outgoing sides of the machine I won't go into the details about what these mean but you can actually deduce quite a lot from these values so you can deduce how well the machine is performing but you can also see if you should change your filters soon or if anyone has been changing the air flows or doing something that might potentially make your home get moisture and health problems of all kinds now what I usually show to emphasize the importance of security in the Internet of Things it's the CO2 sensors that we have installed in two of our bedrooms so the CO2 sensors are used for controlling the machine so that the CO2 level doesn't go too high at any moment and that's usually due in the night because it's in the bedroom so well from this kind of course you can actually deduce quite a lot of very sensitive information such as how many people have been sleeping where and so on so I won't stay here for longer at this page now so those values were collected every 10 minutes that's opposed to what you can see here actually this value 632 that is updated on a much more quicker interval so in this case since the machine and the system knows that there's a browser now looking at this information then it starts updating this value with much quicker so this is to show that in most cases it's enough to collect information every 10 minutes but when the context changes that somebody is actually looking at this might want to control it then you have to update information much quicker and in this case you can even control it online and directly in real time so now since I happened to sit actually in my home presenting this I can even hear the airflow increasing but that doesn't make a difference I could be in the United States or anywhere okay those were the demonstrations of some systems mainly because I like demonstrating real systems but it was also for showing or for linking to the fact that the kind of real applications that OMI and ODF have been specified for so you already saw this picture in smaller earlier but as I said OMI and ODF are really made for enabling all these red connections that you can see here and we have actually implemented quite many of these different kinds of interfaces already I think I spent more time than I expected on the earlier part of the presentation so I won't go into the details of this slide now about other Internet of Things than that there has been well due to the increased visibility of the whole Internet of Things there has also in a lot of Internet of Things standardization activities going on but what we can see is that most of those new standards are really more or less machine to machine standards such as MQTT co-op and so on which are binary standards using TTP or UDP as the run line protocols which gives you some challenges in going through firewalls and also when you have mobile devices and so on even though you can come over without using for instance web sockets but the main thing is that these protocols are not really intended nor suitable for system-to-system communication in the sense that I showed you earlier meaning weather forecast services and so on they are really intended for being implemented on low range cheap hardware with low connections most of these new standards also use the publish-subscribe model rather than using the observer model I won't go into details about this this neither but that using the publish-subscribe model usually signifies that you have to have a more powerful server machine that actually handles most of the data with observer it's much easier and intuitive simple to do pair-to-pair communication between any systems so then the other end of the standards perspective is the REST APIs now there are many many individual things that platforms and systems and applications that provide you with REST APIs for communicating with them but in reality as you know well REST is not a standard it's just an architectural model of how you should build web systems most are just not all Internet of Things REST APIs that I have seen so far have been proprietary so there's really a huge huge number of different REST APIs for the Internet of Things and integrating with them and communicating with them is not immediate at all so the conclusions well in the best case we think that OMI and ODF will do the same thing for the Internet of Things as HTTP and HTML for the web meaning that they would be sufficiently generic and good to be usable for anybody for publishing information and that wouldn't be a tens of different standards different organizations service companies as you saw well OMI and ODF enable you to create new Internet of Things systems or systems also without programming just in the same way that you can publish information using HTML and HTTP without doing any programming then this keep it simple well the OMI specification is that when one page is ODF is ten pages so I think we have managed to keep it simple but that's also because we have been working on these specifications over many years going through many real life implementations and so on so they are pretty mature and that's well nobody knows who actually thinks that I didn't have the time to write a short letter so I wrote a long one instead that's something that also applies to OMI and ODF we have been improving them a lot over the time so now that we claim that they are generic, compact, complete and they are also extensible for using in all kinds of applications IOT applications at least so anyways we all know about the challenges of interoperability and when we start implementing or when we really want to go for the Internet of Things cyber physical systems and so on it will be a nightmare if we don't come up with some generic standards such as OMI and ODF that can do the same thing for the Internet of Things as you can see the BNHDML for the web well thank you Cary that was a fascinating presentation for me at least and I see we have a pretty significant number of questions I don't know that we'll have time to get through all of them but let's see if we can at least get through some of them let me start with one a fairly basic level which is about whether we could increase efficiency perhaps by reducing the overhead in the XML envelope and specifically why not use JSON instead of XML has the project team thought about that at all? Yes we have actually when we started specifying OMI and ODF JSON was not a big thing but one reason for I'll just jump quickly here one reason also for using XML schema is that it's sort of more rigorous and formal tool for specifying this kind of standards rather than using JSON prototypes or similar but as you know well you can translate XML more or less one to one into JSON and we have actually done that in real implementations Okay so what you're saying basically is it should be possible to use JSON but it's not a part of the standard at this point but it's something that would still be considered perhaps for a future version Yes Okay I've combined two questions there I'll probably be combining two at this point and I don't know let me do another straightforward one hopefully first is there it's from Paramesh is there any limitation on the maximum length of the data and total count specified for information info items? No there's none Okay so that's and can we embed a sensor ML message or something similarly complex inside an info item element? I don't remember exactly what sensor ML looks like but the answer is yes we have in real applications also used even CSV for instance as info item values because with ODF you can have at least the column names as metadata for instance so if you want to make it more compact then you can do it this way So here's another question from Shult are the companies producing the reader's writers such as RFID buying in or is this simply an academic standard? Well I don't think the RFID reader producers will be doing it because they are more focused on EPCIS which is a global standard which even that hasn't been completely adopted Well it's sort of a tricky question in the sense that it's not an academic exercise because my company and many other companies have been implementing these standards in their own systems but there's of course a huge challenge in take up of new standards by companies so that's why we are doing these reference implementations also in order to make it easier Perhaps it might be worth saying something more about the promise project and what led in fact the requirements as to why the protocols were developed and took the form that they did what was the reasoning behind for example setting the observer pattern rather than publish subscribe Okay but the requirements so I mentioned that we had these Caterpillar machines and and trucks and so on which already have their own embedded controllers on them as well as RFID tags and so on so well the requirements that sort of came from that Industrial companies participating in that project and I guess they had some input as to what would be useful features in the protocol We were actually implementing this with we had six different industrial implementations of the predecessors of OMI and ODF and that included SAP for instance it really came from real requirements of real products, real systems of real companies definitely even this dialogue platform was developed for real industrial requirements for tracking shipments in multi-organisational projects over the world Okay that's a question Any suggestion or a point of contact to begin getting one's feet wet from Marmoud Well I think if you are a member of the open group one good thing to do would be to join the Internet of Things work group or open platform work and then I also had this link now for accessing the software which is the one in GitHub just now it's a temporary one we will move this somewhere else that all that will be published through the Internet of Things work group as well as the place where you saw the reference implementation So people could go to GitHub and get something that they could stop playing with Yep, you can get that already now in fact maybe not recommend doing it straight away then again why not but there might be some more things to clean up still Okay It seems that Internet of Things this is from Jasbinder Instead of things use cases of more for construction and manufacturing industries Do you have any thoughts about other industries such as banking, finance, insurance or other services based ones To be honest I guess there could be but it's not something that I have personally been working with Okay I guess in principle a sensor is a sensor whether it's on a digger or on a cash machine but you haven't sort of had experience in or done any thinking specifically in that area I should add something I applied OMI and ODF also to design processes where different designers in different companies can subscribe to changes in design documents made by other designers in other companies So this subscribing to any kind of events happening such as a document being updated or a part of a CAD model being updated You can also apply that at least in the design domain I guess in finance you could also subscribe to I don't know the price of a certain stock paper falling radically or subscribing to stock paper prices Why not? Because they are in fact quite general standards but of course as you said the nature of requirements study for them has more been in areas such as manufacturing Okay so there are some other questions that we haven't had time to get to and I'm sorry that we haven't been able to do that but thank you everybody for participating and thanks particularly Carrie for your presentation Thank you very much everybody