Git Product home page Git Product logo

google / digitalbuildings Goto Github PK

View Code? Open in Web Editor NEW
348.0 39.0 132.0 96.02 MB

Digital Buildings (ontology and SDK) currently being used by Google internally to manage our own buildings.

License: Apache License 2.0

CSS 0.20% HTML 0.43% JavaScript 3.72% Starlark 0.07% Python 94.91% Java 0.29% Batchfile 0.08% Shell 0.30% Dockerfile 0.01%
ontology rdf brick-schema buildingsmart digitalbuildings

digitalbuildings's Introduction

Tools Ontology Type Validator Node.js CI GitHub stars License

Digital Buildings Project

The Digital Buildings project is an open-source, Apache-licensed effort to create a uniform schema and toolset for representing structured information about buildings and building-installed equipment. A version of the Digital Buildings ontology and toolset is currently being used by Google to manage buildings in its portfolio.

The Digital Buildings project originated from the need to manage a very large and heterogeneous building portfolio in a scalable way. The project aims to enable management applications and analyses that are trivially portable between buildings. This goal is achieved through a combination of semantically-expressive abstract modeling, an easy-to-use configuration language, and robust validation tooling. Digital Buildings work has been inspired by Project Haystack and BrickSchema and maintains cross-compatibility and/or convergence as a long-term objective.

In creating the Digital Buildings project, we have considered the following:

  • Human readability
  • Machine readability and interpretation
  • Composable functionality
  • Dimensional analysis
  • Correctness validation
  • Cross-compatibility

Project Structure

This project is structured as follows:

  • An ontology that defines the parameters of the semantic data model ("Terminology box") and tools for building, validating, and associating real equipment with a specific model. It contains the following formats:

  • A model instance configuration (a.k.a building configuration file) that contains a mapping between the ontology and the "raw" real-world data. Building configuration files are the "Assertion box."

  • Tools that enable the following:

    • ABEL: facilitates easier building configration construction by converting from a templatized Google Sheet to a building configuration file (and from a building configuration file back to a Google Sheet).
    • Explorer: allows users to explore ontology type fields and compare ontology types to each other.
    • Instance Validator: validates a concrete application (instance) of DBO (i.e., a building configuration file) with optional telemetry validation.
    • Ontology Validator: validates the ontology upon a change or an extension (currently supports YAML format only).
    • RDF/OWL Generator: generates an RDF version from the YAML ontology files.
  • An Internal Building Representation (IBR) file format to represent data from different verticals such as spatial or assets.

Learning Modules

The learning modules provide an overview of the following key concepts:

  • The main concepts and components of the Digital Buildings Ontology
  • How to model entities and extend types in the ontology
  • The components of building configuration files
  • How to use the validation tools for ontology extensions and building configuration files

Module 1: Digital Buildings Ontology (DBO)

In this module, you’ll fully explore the core modeling and organizational concepts of the DBO. These are essential concepts for data modeling and creating building configuration files.

Module 2: Data Modeling with the DBO

In this module, you’ll deepen your understanding of the DBO and practice applying it. Through several hands-on activities, you'll walk through the recommended workflow for creating a building configuration file

Issues

Please post issues in the Issues section.

Discussion

Our team has created an open mailing list to discuss Google's Digital Building effort. The discussion could include general questions, standards, APIs, and more. Join the discussion here: [email protected].

Members are expected to adhere to this code of conduct: https://opensource.google.com/conduct.

How to Contribute

Please see the contribution section.

License

Copyright 2023 Google LLC

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Publications & Talks

digitalbuildings's People

Contributors

a-o-u avatar adelin-diac avatar ahemphill avatar berkoben avatar bsaxpi avatar ccquigley avatar charbull avatar ciaran-oflannagain avatar cstirdivant avatar darshanjain12 avatar db-robot avatar dplute avatar evgeniya-engel avatar ghairapetian avatar htkshimo avatar jmact17 avatar josephedwardchang avatar karthi8883 avatar kevin-hereworks avatar kswang2400 avatar nkilmer avatar pranay2811 avatar rathishkj avatar ray725 avatar shambergoldstein avatar sypks avatar tasodorff avatar tom-skoczylas avatar trav3711 avatar tsodorff avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

digitalbuildings's Issues

Units

How are units applied? i.e. units.yaml contains different units for flowrate with cubic_meters_per_second as STANDARD. We generally name points "Supply Air Flow" for the standard (our standard measure is l/s) and "Supply Air Flow ms" when there's a meter with a non-standard unit.

I don't see anywhere that units are associated with either fields or equipment, is this something which hasn't been finalized?

Also there's a broken link in ontology_config.md line #280

Building_Air_Static_Pressure_Sensor

I apologies if my contributions so far have not been received well. It was my intention to make a constructive contribution, but I think I have made some mistakes with the way I have engaged with this so far.

digitalbuildings/ontology/yaml/resources/subfields/subfields.yaml

line 50 - building: "Applies to the entire building or group of zones within building (e.g. Building_Air_Static_Pressure_Sensor)"

In the case of a "Building_Air_Static_Pressure_Sensor", I assume this tag means the static pressure of the index run ductwork supplying fresh air to the building. I assume it's not a weighted average of static pressures within the building itself, nor a group (perhaps an array?) of static pressures for each zone within the building. If I am correct here, the terms "index run" and "fresh air" would also need defining.

NETWORK (BMS) Namespace Addition

We currently do not model the BMS (or other network) architectures distinctly from the system they control (e.g. HVAC). It may be desirable in certain deployments to model both the devices being controlled and the controllers themselves as separate entities.

Proposal: Add namespace for BMS (or NETWORK to be less specific) and define types/connections for it.

Scope of schema compared to IFC

This looks like an interesting project! I'm curious as to what is the intended scope, especially in contrast to existing schemas like IFC. As stated in the readme, it does borrow heavily from Brick schema, so perhaps mentioning how it plans to fit into the Brick ecosystem would be interesting too :)

[Bug] Instance Validator when is called from a different folder

There is a path bug in the instance validator when it is called from a different folder.

To Reproduce:

python3 ./tools/validators/instance_validator/instance_validator.py -i ./ontology/yaml/resources/pis.yaml

output:

Validator starting ...

Passed syntax checks!
Generating universe ...
UnitUniverse undefined in ConfigUniverse
FieldUniverse undefined in ConfigUniverse
Universe generated successfully
Invalid namespace: FACILITIES
Invalid type
ch-zrh-eurd is not a valid instance

file content example:

ch-zrh-eurd:
  type: FACILITIES/BUILDING
  id: 17400aae-c49a-49d4-a585-8a234f29532d

# Floor 08
ch-zrh-eurd-08:
  type: FACILITIES/FLOOR
  id: 36092aaf-4a0b-4961-b209-6d01f823b440
  connections:
    ch-zrh-eurd: CONTAINS```

Feature request: allow aliases for physical quantities

Describe the bug
At the moment one unit is mapped only to one physical quantity name.
However there are many cases where a unit can measure physical quantities with different aliases.
For instance meters can measure length, height, level, etc.
There are also many adimensional quantities that would map to no_units (typically ratios and factors, like power factor or daylight factor).
I suggest to add the possibility to have "aliases" of quantities.
For instance for "meter" the main quantity would be "length" and it can have "level", "height", "width" as aliases/synonyms.
Thanks!

To Reproduce
N/A

Expected behavior
N/A

Screenshots
N/A

OS (please complete the following information):
N/A

Additional context
N/A

Mappings

Hello,

I am trying to understand the ontology. However, I found it a little bit complicated but it seems to be interesting.

I would like to know if there are any mappings to Brick, SSN, or SAREF, this may enhance my understanding of the ontology.

Thank you,
Amir

Tool to extract the type of the device based on set of point name and entity type

The instance_validator.py is the python script to validate a building ontology YAML file. In the YAML file, the type of device is compulsory e.g. FCU_DFSS_CSP_CHWDC. This instance_validator.py will validate whether the point name list for a respective device fulfills the requirement.

It is advisable to build a tool to extract the type of a device based on the list of point names of the device and the entity type it belongs to.

For example, if a user runs the tool to get the device type for FCU-11 with a list of points names e.g. pn1, pn2. The user would just need to pass in "FCU" entity type together with all the point names as the arguments e.g. tool --entity_type="FCU" --point_name="pn1, pn2". The output will retrieve the type e.g. FCU_DFSS_CSP_CHWDC.

IBR Demo export button: download not defined

Describe the bug
In IBRSDK demo, trying to export selected floors as separate IBRs. Dev tools shows Uncaught ReferenceError: download is not defined at HTMLButtonElement. Files do not download.

To Reproduce
Steps to reproduce the behavior:

  1. In IBR demo, upload the sample SVL IBR file.
  2. Click the Export toggle.
  3. Select multiple floors from the us-svl-tc2-2 object in sidebar.
  4. Open Chrome dev tools with view of Console.
  5. At bottom of sidebar, enter a filename and click the Save and Export to IBR button.
  6. See error in Console.

Expected behavior
I would expect multiple, independent IBRs consistent with the floors checked to automatically generate and download from the browser.

Screenshots
Screen Shot 2021-01-03 at 11 33 46 AM

OS (please complete the following information):
MacOS Catalina v10.15.7
VS Code 1.51.1
Node v14.15.1

Additional context
I tried to troubleshoot by moving script further down index.html to see if it needed to load after the button, with no luck. Based on my limited exposure to Node, my best guess is that the index file is having an issue calling the download() function with three params in the got module.

Perhaps I have also missed an instruction elsewhere in the repo and simply don't have my local instance configured properly.

Examples

I'm watching this project with interest as it's aligned with my research topic (ML and built environment).

Do you intend on adding some examples? I think that would really help, i.e. a minimal yaml example and perhaps a tutorial on how to validate and generate a DRF. Also, it's not really clear to me what I'd do with the RDF, some notes on the application of RDF would be useful.

And do you intend adding some sort of mapping between the representation and the source data - i.e. the main use I have for any building representation is to enable me to query the BMS data I require for my models. So for each sensor I would want to include a field which would contain some sort of query string which would allow me to access a data lake the histories data was stored in, or perhaps the bacnet id's to directly query the BMS. I'm not 100% but neither Haystack or BrickSchema seem to address this other than having say a cur and hist tag.

Finally it's not really clear what the ibr project is all about. The readme implies it's a file format "that can be adapted to multiple use cases " but the example shows a building floorplan. It's not really clear how you'd adapt it to other use cases.

Enhancement on ontology_match_lib.py

Ontology_match_lib.py is great to find the closest type with the proximity level e.g. NONE, CLOSE, INCOMPLETE and EXACT. May I suggest to enhance the tool so it can display the closest set of abstract types?

For example, a FCU consist of the following point:

real_fields = {
"chilled_water_valve_percentage_command",
"chilled_water_valve_percentage_sensor",
"discharge_fan_run_command",
"discharge_fan_run_status",
"schedule_run_command",
"zone_air_temperature_sensor",
"zone_air_temperature_setpoint",
}
fit = ont.find_best_fit_type(real_fields, 'HVAC', 'FCU')

When I ran the tool, it would display the following result:

MATCH COMPLETENESS: 'INCOMPLETE'
MATCHED TYPE: 'FCU_DFSS_DFVSC_ZTC_CHWZTC_DTC_CO2C'

ACTUAL FIELDS TYPE FIELDS REQUIRED
======================================= ======================================= =======================================
chilled_water_valve_percentage_command chilled_water_valve_percentage_command True
chilled_water_valve_percentage_sensor chilled_water_valve_percentage_sensor False
discharge_air_temperature_sensor True
discharge_air_temperature_setpoint True
discharge_fan_run_command discharge_fan_run_command True
discharge_fan_run_status discharge_fan_run_status True
discharge_fan_speed_percentage_command True
schedule_run_command schedule_run_command False
zone_air_co2_concentration_sensor True
zone_air_co2_concentration_setpoint True
zone_air_temperature_sensor zone_air_temperature_sensor True
zone_air_temperature_setpoint zone_air_temperature_setpoint True

The closest type it returned was FCU_DFSS_DFVSC_ZTC_CHWZTC_DTC_CO2C (a new type created by me for another FCU device). Due to the match completeness was ‘INCOMPLETE’, so it still did not fulfil the requirement. Upon looking for the most appropriate abstract types, I could get CHWVM, DFSS and ZTC to create the following new type:

FCU_DFSS_CHWVM_ZTC:
id: "8815310973633036290"
description: "tbc"
is_canonical: true
opt_uses:

  • schedule_run_command
    implements:
  • CHWVM
  • DFSS
  • ZTC

May I know whether you could enhance the tool to display the following extra table? By viewing the below example, I could easily know that I need to create a new type with the abstract type listed in the table.

ACTUAL FIELDS TYPE FIELDS ABSTRACT
======================================= ======================================= =======================================
chilled_water_valve_percentage_command chilled_water_valve_percentage_command CHWVM
chilled_water_valve_percentage_sensor chilled_water_valve_percentage_sensor CHWVM
discharge_fan_run_command discharge_fan_run_command DFSS
discharge_fan_run_status discharge_fan_run_status DFSS
schedule_run_command schedule_run_command
zone_air_temperature_sensor zone_air_temperature_sensor ZTC
zone_air_temperature_setpoint zone_air_temperature_setpoint ZTC

Kelvin

Please could you describe the unit Kelvin and why this is tagged as standard?

Add option to validate an entire directory of YAML files

We currently support users providing the --input parameter multiple times to validate multiple individual files. It would also be useful to have an --input-dir parameter that lets the user validate an entire directory without individually specifying all the files contained within.

OWL.disjointWith axiom violations

Describe the bug
Disjoint classes have extensions in common.

To Reproduce

from rdflib import Graph

db = Graph()
db.load("digitalbuildings.xml")
violations = db.query("""
SELECT DISTINCT ?classA ?classB ?violation WHERE {
    ?classA (owl:disjointWith|^owl:disjointWith) ?classB .
    ?violation rdfs:subClassOf* ?classA, 
                                ?classB .
}
""")
len(violations)
> 3358

Expected behavior

len(violations)
> 0

OS:
macOS Big Sur v11.4

Ontology is full of jargon

Okay, I'm about to get more critical - because I think this is an issue, not a question. I don't understand why this has been closed without answering the question?

I understand the project used OWL. I am not sure that immediately means that a meaningful Ontology has been created. There's a number of examples of unexplained jargon here. For example, how does this project describe what "Building Static Pressure" means (are things getting hotter)? What is a "setpoint" (am I about to achieve something in a tennis match)? Jargon is often discussed in this project, but not defined in an organised way. A meaningful Ontology needs to carefully describe domain specific terms used (perhaps with multiple understandable examples). Has this been peer-reviewed?

As a "model" this project wouldn't be open to such criticism and I think the term is a better fit at the moment.

Originally posted by @aidan-parkinson in #45 (comment)

The instance validator validates connections that are not in defined within the connections.yaml file

Describe the bug
Should the instance validator kick up an error when connections are used in the building_config.yaml file that are not defined within the ~/ontology/yaml/resources/connections/connections.yaml file within the ontology?

To Reproduce
Steps to reproduce the behavior:

  1. within the building_config.yaml file enter in a connection that is not within defined within the connections file. In the example below I have used "BOB" as a connection that isn't defined in the connections.yaml file.

ZONE-202:
type: HVAC/ZONE_HVAC
id: CDM/110111
connections:
UK-LON-X1_L02: CONTAINS
AHU-1: BOB

  1. then run the validator commands:

python3 instance_validator.py --input path/to/building_config.yaml

  1. This still outputs a valid response:

*$ python3 instance_validator.py --input /media/sf_shared/test.yaml

Validator starting ...

Generating universe ...
Universe generated successfully
Validating syntax please wait ...
Opening file: /media/sf_shared/test.yaml, please wait ...
Validating entities ...
All entities validated

Expected behavior
I expected the validator to fail as "BOB" is not defined as a connection in the connections.yaml

OS (please complete the following information):

OS - Ubuntu 20.04.02 LTS
Repository cloned from master on 4/3/2021

Performance issue with python version higher than 3.6.8

Describe the bug
The Instance validator seems to be having performance issue when used with a python version higher than 3.6.8

To Reproduce
Run with python 3.9.1 for example

Expected behavior
The validator will take up to 8 min in the phase after:

Generating universe ...
Universe generated successfully

OS (please complete the following information):
MacOs

Chilled

I don't think chilled water is pure H2O. Chilled water is a solution.

There's a lot to do here.

Consider converting DFR to a class of AHU

The duct furnaces currently observed are essentially AHUs with heating-only (and in observed instances some type of recirc damper).

They handle outside air and return air, and meet the current definition of an AHU. Either propose an additional rule for distinguishing DFR from AHU, or consolidate.

Instance Validator - Bugging out

Describe the bug
When i run instance validator against an building_config.yaml file I now get the following error output error:

oli@zerocool:~/temporary/digitalbuildings/tools/validators/instance_validator$ python3 instance_validator.py -i /media/sf_shared/Building_Config_Test.yaml
Starting validator...
Starting universe generation...
Starting config validation...
Loading config files...
Validating syntax please wait ...
Opening file: /media/sf_shared/Building_Config_Test.yaml, please wait ...
Starting config validation...
Validating entities ...
Traceback (most recent call last):
File "instance_validator.py", line 104, in
handler.RunValidation(args.filenames, args.modified_types_filepath,
File "/home/oli/temporary/digitalbuildings/tools/validators/instance_validator/validate/handler.py", line 96, in RunValidation
entities = _ValidateConfig(filenames, universe)
File "/home/oli/temporary/digitalbuildings/tools/validators/instance_validator/validate/handler.py", line 67, in _ValidateConfig
return helper.Validate(entities, config_mode)
File "/home/oli/temporary/digitalbuildings/tools/validators/instance_validator/validate/handler.py", line 224, in Validate
if not validator.Validate(current_entity):
File "/home/oli/temporary/digitalbuildings/tools/validators/instance_validator/validate/entity_instance.py", line 84, in Validate
return iv.Validate(entity) and gv.Validate(entity)
File "/home/oli/temporary/digitalbuildings/tools/validators/instance_validator/validate/entity_instance.py", line 433, in Validate
if not self._ConnectionsAreValid(entity):
File "/home/oli/temporary/digitalbuildings/tools/validators/instance_validator/validate/entity_instance.py", line 305, in _ConnectionsAreValid
if not (self.universe.connection_universe and entity.connections):
AttributeError: 'ConfigUniverse' object has no attribute 'connection_universe'

I have tried this with both my custom building_config and also the suggested demo version from fake_instances/GOOD/good_building_connections.yaml

When I tested against a previous version of the DBO the file validated.

To Reproduce
Steps to reproduce the behavior:

python3 instance_validator.py -i "path to building instance"

Expected behavior

I expected the validator to either validate or report on what was not configured correctly within my building_config.yaml

Query about the existing standard point name for the "Remote/Local"

We have been told that the Remote/Local is the important parameter to be stored in the cloud database e.g. firestore. I have tried to search the equivalent point name defined in the telemetry field list, but I could not get any name that matches to it. May I know whether there is an existing name that is pointing to this “Remote/Local”

The value set for this “Remove/Local” SCADA point name is “Remote” and “Local”, and the definition of the value is shown as below:

Remote – The system is controlled remotely
Local – The system is controlled locally

Project has a very ambitious name!

This is great work. Good to see

However, the word "Ontology" to my understanding implies a high level of validity (to me at least). An example of which might be "energetics" and "quantum mechanics" as two fundamentally different types of observation.

Isn't this really another "Social Construct" representing quite a contextually dependent system of significant inherent bias? Why was the term "Model" not used for this project, as potentially a more valid and widely used term?

From my perspective there is a danger that the name of this project is over-selling its possible applications. Sorry to be a headache!

Distinction between SubField/Measurement/* and Unit/*

The classes under SubField/Measurement and Unit are equivalent sets (i.e. all classes are same). Why is this?

Additionally, in Protege, when I look at Unit/Concentration (usages), parts_per_million comes up (and confirmed in RDF):

image

However, when I then click on the Concentration below:

Screen Shot 2020-12-21 at 7 33 33 PM

It actually resolves to the Subfield/Measurement/Concentration class. Is this expected? Can others reproduce? Why does this happen?

Difference between `uses` and `implements`?

In the generation of RDF from yaml, it appears that when uses are declared for a type, this translates into a rdfs:subClassOf relationship. uses, however, seem like they should be data properties on a type as opposed to a superclass, where I would expect implements to define the superclass(es) for a type. Can you explain a little bit more how this works / why it works this way?

Generating an instance

How do you create an instance in RDF? I created a building config YAML file following https://github.com/google/digitalbuildings/blob/master/ontology/docs/building_config.md i.e.

# Building
UK-LON-S2:
  type: FACILITIES/BUILDING
  id: FACILITIES/123456

Running the validator on this works fine. But then I assumed you could pass this file to the rdf_generator but the following

python rdfformat/rdf_generator.py --input=/home/david/dev/digitalbuildings/.data/building_config.yaml --output=/home/david/dev/digitalbuildings/.data/digital_buildings.rdf

throws the error

NotADirectoryError: [Errno 20] Not a directory: '/home/david/dev/digitalbuildings/.data/building_config.yaml/FACILITIES/entity_types/Facilities.yaml'

The help indicates:

rdfformat/rdf_generator.py:
--input: The path of the input file
--output: The path of the output file

But it actually appears to expect --input to be the root folder of the ontology (which matches the readme)

Are there any tools to convert a building config into say a TTL file like Brick?

Question: What is the Carson ontology?

Section 3 of the RDF Example README alludes to the "Carson ontology" when instantiating business logic.

Simple question - where can one learn more about said Carson ontology?

I have exhausted the requisite 30 minutes of phrase searching across the broader web, and have read @charbull's PoCBoC paper twice. "Carson" doesn't appear there either.

The example in the README appears it could be a BAS SDK, not unlike OLGA or the ALC SDK I've worked with in the past. A way of representing hierarchical relationships in the BAS as objects, of sorts.

Curiosly,
Drew

Organize the HVAC/ABSTRACT types

Organize ABSTRACT types by function. Ex: all DX types should be in the same section, all SF types should be in the same section

Building Docker with OLGA failes due to missing file or wrong directory

Describe the bug
When trying to built the docker following this example, step 27/30 fails.

To Reproduce
Steps to reproduce the behavior:

  1. Try to built the logger with the made settings.
% ./build-docker-image.sh
Using https://github.com/EcoStruxure/OLGA.git as git repo URL
Using master as git branch
Using OLGA as project
Using OLGA-Core,OLGA-Ws as subprojects
Using OLGA-Ws as Maven artifact ID
Using 0.0.5 as version
Using ecostruxure/olga:latest as the Docker tag
Sending build context to Docker daemon  3.584kB
Step 1/30 : FROM alpine/git as clone
 ---> 8f5f87e1dbac
Step 2/30 : ARG url
 ---> Using cache
 ---> af5efd494ea7
Step 3/30 : ARG branch
 ---> Using cache
 ---> 98dc352216ea
Step 4/30 : WORKDIR /app
 ---> Using cache
 ---> 4570109b47ff
Step 5/30 : RUN git clone -b ${branch} --single-branch ${url}
 ---> Using cache
 ---> e0520e2dc2a7
Step 6/30 : FROM maven:3.5-jdk-8-alpine as build
 ---> fb4bb0d89941
Step 7/30 : ARG project
 ---> Using cache
 ---> aeba4bf3d4f8
Step 8/30 : ARG subprojects
 ---> Using cache
 ---> 202620a431b2
Step 9/30 : WORKDIR /app
 ---> Using cache
 ---> 5e3e3bfbbe92
Step 10/30 : COPY --from=clone /app/${project} /app
 ---> Using cache
 ---> d5bcb57a8d71
Step 11/30 : WORKDIR /app/${project}
 ---> Using cache
 ---> ad0c768b884a
Step 12/30 : RUN mvn --projects ${subprojects} clean install -DskipTests
 ---> Using cache
 ---> 6c57ef6d40b4
Step 13/30 : FROM maven:3.5-jdk-8-alpine
 ---> fb4bb0d89941
Step 14/30 : ARG project
 ---> Using cache
 ---> aeba4bf3d4f8
Step 15/30 : ARG artifactid
 ---> Using cache
 ---> 3885bc681dc2
Step 16/30 : ARG version
 ---> Using cache
 ---> 0017c7c1897d
Step 17/30 : ENV artifact ${artifactid}-${version}-with-dependencies.jar
 ---> Using cache
 ---> fcfb5af4fe3c
Step 18/30 : ENV M2_HOME ${MAVEN_HOME}
 ---> Using cache
 ---> e88f4af25cd3
Step 19/30 : ARG REPO=mcr.microsoft.com/dotnet/core/runtime-deps
 ---> Using cache
 ---> 42d1902900f0
Step 20/30 : RUN apk add --no-cache icu-libs openssl-dev
 ---> Using cache
 ---> 432729cb87cc
Step 21/30 : ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false     LC_ALL=en_US.UTF-8     LANG=en_US.UTF-8
 ---> Using cache
 ---> 2ec1b2f24ffe
Step 22/30 : ENV DOTNET_SDK_VERSION 2.1.607
 ---> Using cache
 ---> 6944623b6da3
Step 23/30 : RUN wget -O dotnet.tar.gz https://dotnetcli.azureedge.net/dotnet/Sdk/$DOTNET_SDK_VERSION/dotnet-sdk-$DOTNET_SDK_VERSION-linux-musl-x64.tar.gz     && dotnet_sha512='61caf6602b8a2aa89769b3e91ddaec963d8ab9f802cd7f6c6da4f02426358712bc2bb0930e7ee3a81d75c7607039543b554cb8ed50e45610655f9e91ed0f2f17'     && echo "$dotnet_sha512  dotnet.tar.gz" | sha512sum -c -     && mkdir -p /usr/share/dotnet     && tar -C /usr/share/dotnet -xzf dotnet.tar.gz     && ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet     && rm dotnet.tar.gz
 ---> Using cache
 ---> 26df7bcc17d7
Step 24/30 : ENV DOTNET_USE_POLLING_FILE_WATCHER=true     NUGET_XMLDOC_MODE=skip
 ---> Using cache
 ---> b6972fd69e7f
Step 25/30 : RUN dotnet help
 ---> Using cache
 ---> 1e1ac47645cc
Step 26/30 : WORKDIR /app
 ---> Using cache
 ---> d1b6538e6ae4
Step 27/30 : COPY --from=build /app/${project}/${artifactid}/target/${artifact} /app
COPY failed: stat /var/lib/docker/overlay2/599d6faae67bccbef0c845ae0404d8ca76feea148940b305da03c788e46592b2/merged/app/OLGA/OLGA-Ws/target/OLGA-Ws-0.0.5-with-dependencies.jar: no such file or directory

Expected Behaviour:
Building of the docker is successful.

OS:
Ubuntu GNU/Linux 18.04 LTS

States do not support 1:many mapping

Certain devices send multistate data that should be mappable to the same standard state in DBO. Here is an example:

discharge_fan_speed_mode:
  present_value: "points.discharge_fan_speed_mode.present_value"
  states:
    HIGH:
    - "1"
    - "4"
    MEDIUM:
    - "2"
    - "5"
    LOW:
    - "3"
    - "6"
    VFD: "7"
    "OFF": "0"

The instance validator does not support this type of 1:many definition for standard states; it will be necessary to modify it to support this mapping.

Generating type IDs

When adding new YAML object types, how do you generate the 19-20 digit ID string?

That every id attribute being divisible by 4 would seem to imply it's auto-generated, though I cannot find any such auto-enumerator or other schema within the repo.

Does the validator generate said id string on some kind of merge trigger?

Cheers,
Drew

PID Loop Modeling Clarification

Looking for additional MQTT Datapoint name (descriptors, etc) for the following (BMS points) Internal PID loop Variables for AHU, FCU, PACU. There is no current sub fields for say Proportional, Integral, Derivative gain values.

BMS Point name:
Zone Temp HTG PID P gain
Zone Temp HTG PID I gain
Zone Temp HTG PID D gain
Zone Temp HTG PID Interval
Zone Temp CLG PID P gain
Zone Temp CLG PID I gain
Zone Temp CLG PID D gain
Zone Temp CLG PID Interval

Thanks

Citation

I'm in the middle of a literature review on the current state of building ontologies. I believe digitalbuildings warrants inclusion. Do you have any publication, if not it would be nice if you added a citation section to the readme?

Creating a DOI would be nice as well - https://github.blog/2014-05-14-improving-github-for-science/

Kill Validator After First Failure

The following is the result of the ontology validator.

Starting Yaml Validator!
Findings in fields/telemetry_fields.yaml
ERROR : Field "water_leak_sensor" is not a valid construction

Findings in SAFETY/entity_types/ABSTRACT.yaml
Traceback (most recent call last):
ERROR : Field name "water_leak_sensor" is undefined.

The second error is redundant and confusing.

A few options:

  1. Make the validator execute in an order and surface like errors together (e.g. evaluate all failed fields, if errors then surface them all then stop).
  2. Kill the validation after the first error.

Make the type validator outputs better

Describe the bug
The ontology validator does not help the user to understand build failures because of the way it presents errors to the user.
For example:

ERROR : Unit "meters_per_square_second" has the unknown measurement type "linearacceleration"

What is the error? Is it with meters_per_square_second or with linear_acceleration? Pretty unclear. It also gives no guidance about what to fix.

Instead of raising the unhelpful error above, the validator should output something more like this:

ERROR : Subfield 'linear_acceleration' is undefined, but the unit "meters_per_square_second" references it. Define the subfield or assign the unit to another subfield.

This sort of user-friendly error message should be added everywhere, for everything.

Unable to setup instance validator

Describe the bug
When installing the dependencies for the instance validator, the following error appears:

error: Setup script exited with error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1

To Reproduce
Steps to reproduce the behavior:

  1. Go to digitalbuildings/tools/validators/instance_validator/
  2. Run python3 setup.py install --user
  3. Error shows for the following: error: Setup script exited with error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1

Expected behavior
Able to install dependencies for the instance validator

OS (please complete the following information):
Linux, Debian x86

Additional context
Ontology validator was successfully setup. Issues encountered onl for the instance validator

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.