Representative End User Clients
Representative Automation Clients
Representative Software Clients
Industrial facilities, whether large commercial buildings or industrial plants, typically feature monitoring and sensor/actuation networks that are accessed through SCADA systems. Sensors or control point labels (sometimes referred to as “tags”) typically describe function, type, location and relationships to other subsystems. Label naming remains diverse and inconsistent between vendors and in many cases, different systems set up by the same vendor. This makes scalability of analytics and other applications an expensive and enormous challenge. When you consider that there are thousands of system integrators and EPCs involved, this issue becomes magnified.
Today, interpreting the metadata is a labor-intensive effort that takes intimate knowledge of each facility or plant’s specific systems. On several occasions, I have been told that it typically takes weeks of engineering time and can cost more than 100k dollars to map a fault detection and diagnosis (FDD) application to a building. One of my colleagues was speaking with a user who dumped their historian data into a data lake with the hopes of doing descriptive analytics but was surprised to see that all they had was tag numbers. The user was left to sort out which tag means what, no locations, no units, nothing. If metadata is standardized, applications can be developed on a uniform data model.
At a recent BACnet users group that I attended, this topic was touched upon during a presentation and further discussion supports the idea of users creating label and metadata registries. A campus was constructing a new building and wanted to connect a chiller system from a nearby existing building so that cooling for both buildings could be accomplished in the most efficient way using either or both buildings chillers. The integration team from the automation vendor had received in advance what he thought were the asset labels for the chiller system installed by the EPC and had pre-programmed the software prior to the day of installation. Once he arrived, he discovered from the engineer on-site that he had never seen this label report and that the labels were not correct. The integrator had to spend half a day recoding the software on-site. When further probed, the integrator revealed that this is considered the norm and it occurs on many projects.
Users should develop their own organization’s standard registries for labels and metadata and require vendors and integrators to comply. For the developer community, standard metadata will allow software engineers to develop applications that can gather data and use it in a meaningful way that does not need specific facility/system knowledge, and the possibility of weeks of engineering time and costs to deploy. If users embrace standard data methodology for their systems, unique aspects of equipment can be encoded in metadata at the time of installation by experts. Users will find that applications become portable to their facilities and assets that employ a standard ontology. If industry adopts a common metadata schema, operators could eventually even have access to an app store containing a library of various applications which could be downloaded and applied with relative ease.
With the advancement in cyber-physical systems and the great numbers of applications such as Fault detection and diagnostics (FDD), energy optimization, and demand response having come to market, a lack of common descriptive metadata ontology for sensors, subsystems and relationships among them is preventing broader market adoption. The open source Project Haystack is aiming to solve this dilemma for buildings, but its lack of tools and missing location specifiers makes mapping to many buildings problematic. The Brick schema is an open source solution developed by several Universities and IBM Research which further extends Project Haystack. I recommend visiting their website for more information about their solution and documentation on this topic.
Today, interpreting the metadata is a labor-intensive effort that takes intimate knowledge of each facility or plant’s specific systems. On several occasions, I have been told that it typically takes weeks of engineering time and can cost more than 100k dollars to map a fault detection and diagnosis (FDD) application to a building. One of my colleagues was speaking with a user who dumped their historian data into a data lake with the hopes of doing descriptive analytics but was surprised to see that all they had was tag numbers. The user was left to sort out which tag means what, no locations, no units, nothing. If metadata is standardized, applications can be developed on a uniform data model.
At a recent BACnet users group that I attended, this topic was touched upon during a presentation and further discussion supports the idea of users creating label and metadata registries. A campus was constructing a new building and wanted to connect a chiller system from a nearby existing building so that cooling for both buildings could be accomplished in the most efficient way using either or both buildings chillers. The integration team from the automation vendor had received in advance what he thought were the asset labels for the chiller system installed by the EPC and had pre-programmed the software prior to the day of installation. Once he arrived, he discovered from the engineer on-site that he had never seen this label report and that the labels were not correct. The integrator had to spend half a day recoding the software on-site. When further probed, the integrator revealed that this is considered the norm and it occurs on many projects.
Users should develop their own organization’s standard registries for labels and metadata and require vendors and integrators to comply. For the developer community, standard metadata will allow software engineers to develop applications that can gather data and use it in a meaningful way that does not need specific facility/system knowledge, and the possibility of weeks of engineering time and costs to deploy. If users embrace standard data methodology for their systems, unique aspects of equipment can be encoded in metadata at the time of installation by experts. Users will find that applications become portable to their facilities and assets that employ a standard ontology. If industry adopts a common metadata schema, operators could eventually even have access to an app store containing a library of various applications which could be downloaded and applied with relative ease.
With the advancement in cyber-physical systems and the great numbers of applications such as Fault detection and diagnostics (FDD), energy optimization, and demand response having come to market, a lack of common descriptive metadata ontology for sensors, subsystems and relationships among them is preventing broader market adoption. The open source Project Haystack is aiming to solve this dilemma for buildings, but its lack of tools and missing location specifiers makes mapping to many buildings problematic. The Brick schema is an open source solution developed by several Universities and IBM Research which further extends Project Haystack. I recommend visiting their website for more information about their solution and documentation on this topic.