In a break from filling in the back story of FogLAMP I thought I would write about my experiences and conversations I had last week at the EMEA PI World conference in Gothenburg. OSIsoft run two conferences a year, one in San Francisco and one in a city in Europe, this year it was the turn of Sweden and the city of Gothenburg. Dianomic, as a company part owned by OSIsoft and also aimed at producing software for use in this environment, usually attend these events. This year was no exception as we attended as an exhibitor and to give a training lab session on the last afternoon of the conference.
In my position as the architect of FogLAMP these events give be a good opportunity to both present that architecture to real industrial users and also to get a better sense of how what we are building might fit into their environment. This tends to make place in the exhibition hall, in which Dianomic has a presents, however before this can can the conference always starts with keynote speeches. Since the exhibition hall is closed these are the few talks that I manage to attend during the 3 days of the conference. The keynotes are given by OSIsoft themselves and by invited OSIsoft customers.
We, as the FogLAMP developers are very lucky that for the past few conferences we have been mentioned in the keynotes as part of the OSIsoft pervasive data collection story. FogLAMP being the open source, Linux collection mechanism in this strategy. This year was no exception, however it went slightly further we a section about how OSIsoft had used their own PI Data Historian within the automated headquarters building in San Leandro, the SLTC. FogLAMP formed part of that SLTC installation, with Phidget sensors being installed in the conference rooms to measure the light levels, noise levels, temperature and humidity. This data is fed into the building PI Server and used to verify the performance of the building automation system. Watching the software being demonstrated live on stage was a little nerve racking, but it went smoothly and served to illustrate the flexibility and usefulness of FogLAMP in situations we never envisaged.
Once the keynotes were complete the conference swung into its second phase, at least for me, manning the exhibition booth talking about FogLAMP and how it might fit in wit the various visitors projects or plans for the future. This is always interesting and throws up unexpected or new use case for FogLAMP. I particularly like hearing about what potential users are looking for as it helps form a future roadmap for FogLAMP or at least steer the priorities. The other thing that I like is to listen to how other portray what we are doing, I think it interesting how other with a different viewpoint depict the project.
One thing that is clear to me is that trying to describe the entire project in one go is not the best approach, there are so many options and components that it makes no sense. The usual approach most people take in describing FogLAMP is a bit like peeling an onion. The starting point is often a very high level description; it is a piece of open source software for connecting any sensor or machine to any data storage and analysis platform. Although, since this conference is all about the PI Server, that later part is often changed to be "to any PI Server or other system". The next level of description would then talk about the plugins for the sensors and protocols in the south service. This would include some of the examples of the plugins we already have, scheduled as modbus, OPC UA, DNP3 etc and also discussion around what it takes to add a new hardware device or protocol. This was always aided by having examples of hardware such as a Flir infrared camera and Advantech data acquisition modules on hand to illustrate the types of devices.
Buffering was the next level down into the architecture we would usually venture, expelling the reason for it and talking about use cases without always on or reliable network connectivity. We would discuss in relation to this that we can use the buffered data for accessing recent history and providing edge applications with that history. The example we always quote here is that of mining trucks that spend the day underground, gathering information and when they emerge they push all that accumulated data to the central data historian. I was given another example by one of our visitors, that of trains spending the day out on the network gathering data on the train and track and then transmitting that data for analysis, combined with the data from all the other trains, once it get back to the depot.
Our next level of discussion goes to the filtering capabilities of FogLAMP and the ability to modify the data as it traverses the FogLAMP services. This is an area that when we first started on the project we were told to avoid, the advice being send all the data unadulterated and let the transformation take place centrally. It has transpired this was not good advice for a number of reasons; some data is very high bandwidth and can not be buffered and transmitted sensibly so must be summarised using some algorithm at the edge. This could be because the data is truly high bandwidth, like vibration data or that the communication links are very slow or expensive. Another reason to modify the data at the edge is to augment it and add value at the edge. This allows for better edge analytics and letting to be performed. This then brings us on to the net level of discussion, the ability of FogLAMP, again via plugins, to run event notification rules and deliver notifications, via another set of plugins, at the edge itself.
Having the ability to do edge notifications is important in case where time is critical, the example invoked here is the self driving car. You would not consider gathering all the data from he sensors on the car and sending that data to the cloud in order to determine if it should apply the brakes. Of course we are not looking at utilising FogLAMP in the control system of a self driving car, but it may be used were it can alert to stop a process due to some measured values falling outside of an acceptable range for example. This need for events close to the edge is even more important when networks are slow or intermittent.
We also talk about how we are experimenting with adding machine learning to FogLAMP, either within a south service to use cameras as a way to create data, usually in the form of image classification, or we use machine learning to determine normal operating parameters and alert on anomalies.
The final afternoon of the conference is spent running a practical lab session, something we have done now at a number of PI World conferences, in each one the content of the lab becomes more complex as the FogLAMP project matures. This year we had a full house of 30 students in the lab, each of whom is given a remote control car with a Raspberry Pi Zero and an Envirophat sensor board attached. A USB battery pack provides the power for the Raspberry Pi and the Envirophat. The Envirophat has sensors on it for acceleration, a gyroscope, temperature and light levels, we use this to measure the movement of the cars and when it they pass under coloured lights.
The content of the lab takes the students through installing and configuring FogLAMP for basic data collection, attaching the FogLAMP to a PI Data Historian and then adding filters and edge notifications to the FogLAMP instance running on the car. We cap the afternoon off with having points baed game where everybody drives the cars around the floor trying to score points for exuberant driving and for driving under lights that are constantly changing colour, getting points based on the colour of the lights. Points are lost if the car is rolled. The points are all calculated in the central data historian and a live scoreboard is shown based on the data being collected from he sensors on the car. This is always chaotic and great fun, this year it was made worse because we forgot to labelled the tops of the cars and people quickly lost track of which car was theirs.
In my position as the architect of FogLAMP these events give be a good opportunity to both present that architecture to real industrial users and also to get a better sense of how what we are building might fit into their environment. This tends to make place in the exhibition hall, in which Dianomic has a presents, however before this can can the conference always starts with keynote speeches. Since the exhibition hall is closed these are the few talks that I manage to attend during the 3 days of the conference. The keynotes are given by OSIsoft themselves and by invited OSIsoft customers.
We, as the FogLAMP developers are very lucky that for the past few conferences we have been mentioned in the keynotes as part of the OSIsoft pervasive data collection story. FogLAMP being the open source, Linux collection mechanism in this strategy. This year was no exception, however it went slightly further we a section about how OSIsoft had used their own PI Data Historian within the automated headquarters building in San Leandro, the SLTC. FogLAMP formed part of that SLTC installation, with Phidget sensors being installed in the conference rooms to measure the light levels, noise levels, temperature and humidity. This data is fed into the building PI Server and used to verify the performance of the building automation system. Watching the software being demonstrated live on stage was a little nerve racking, but it went smoothly and served to illustrate the flexibility and usefulness of FogLAMP in situations we never envisaged.
Once the keynotes were complete the conference swung into its second phase, at least for me, manning the exhibition booth talking about FogLAMP and how it might fit in wit the various visitors projects or plans for the future. This is always interesting and throws up unexpected or new use case for FogLAMP. I particularly like hearing about what potential users are looking for as it helps form a future roadmap for FogLAMP or at least steer the priorities. The other thing that I like is to listen to how other portray what we are doing, I think it interesting how other with a different viewpoint depict the project.
One thing that is clear to me is that trying to describe the entire project in one go is not the best approach, there are so many options and components that it makes no sense. The usual approach most people take in describing FogLAMP is a bit like peeling an onion. The starting point is often a very high level description; it is a piece of open source software for connecting any sensor or machine to any data storage and analysis platform. Although, since this conference is all about the PI Server, that later part is often changed to be "to any PI Server or other system". The next level of description would then talk about the plugins for the sensors and protocols in the south service. This would include some of the examples of the plugins we already have, scheduled as modbus, OPC UA, DNP3 etc and also discussion around what it takes to add a new hardware device or protocol. This was always aided by having examples of hardware such as a Flir infrared camera and Advantech data acquisition modules on hand to illustrate the types of devices.
Buffering was the next level down into the architecture we would usually venture, expelling the reason for it and talking about use cases without always on or reliable network connectivity. We would discuss in relation to this that we can use the buffered data for accessing recent history and providing edge applications with that history. The example we always quote here is that of mining trucks that spend the day underground, gathering information and when they emerge they push all that accumulated data to the central data historian. I was given another example by one of our visitors, that of trains spending the day out on the network gathering data on the train and track and then transmitting that data for analysis, combined with the data from all the other trains, once it get back to the depot.
Our next level of discussion goes to the filtering capabilities of FogLAMP and the ability to modify the data as it traverses the FogLAMP services. This is an area that when we first started on the project we were told to avoid, the advice being send all the data unadulterated and let the transformation take place centrally. It has transpired this was not good advice for a number of reasons; some data is very high bandwidth and can not be buffered and transmitted sensibly so must be summarised using some algorithm at the edge. This could be because the data is truly high bandwidth, like vibration data or that the communication links are very slow or expensive. Another reason to modify the data at the edge is to augment it and add value at the edge. This allows for better edge analytics and letting to be performed. This then brings us on to the net level of discussion, the ability of FogLAMP, again via plugins, to run event notification rules and deliver notifications, via another set of plugins, at the edge itself.
Having the ability to do edge notifications is important in case where time is critical, the example invoked here is the self driving car. You would not consider gathering all the data from he sensors on the car and sending that data to the cloud in order to determine if it should apply the brakes. Of course we are not looking at utilising FogLAMP in the control system of a self driving car, but it may be used were it can alert to stop a process due to some measured values falling outside of an acceptable range for example. This need for events close to the edge is even more important when networks are slow or intermittent.
We also talk about how we are experimenting with adding machine learning to FogLAMP, either within a south service to use cameras as a way to create data, usually in the form of image classification, or we use machine learning to determine normal operating parameters and alert on anomalies.
The final afternoon of the conference is spent running a practical lab session, something we have done now at a number of PI World conferences, in each one the content of the lab becomes more complex as the FogLAMP project matures. This year we had a full house of 30 students in the lab, each of whom is given a remote control car with a Raspberry Pi Zero and an Envirophat sensor board attached. A USB battery pack provides the power for the Raspberry Pi and the Envirophat. The Envirophat has sensors on it for acceleration, a gyroscope, temperature and light levels, we use this to measure the movement of the cars and when it they pass under coloured lights.
The content of the lab takes the students through installing and configuring FogLAMP for basic data collection, attaching the FogLAMP to a PI Data Historian and then adding filters and edge notifications to the FogLAMP instance running on the car. We cap the afternoon off with having points baed game where everybody drives the cars around the floor trying to score points for exuberant driving and for driving under lights that are constantly changing colour, getting points based on the colour of the lights. Points are lost if the car is rolled. The points are all calculated in the central data historian and a live scoreboard is shown based on the data being collected from he sensors on the car. This is always chaotic and great fun, this year it was made worse because we forgot to labelled the tops of the cars and people quickly lost track of which car was theirs.
No comments:
Post a Comment