Brick ontology and run rules based on meta data?

[bbartling]

If anyone has any ideas to try please let me know. I would love to eventually be able to write FDD reports where fault rules run based on meta data alone Vs having to do this below and making sure all your data has the correct column names.... which is as bad as trying to use Microsoft Excel.

config_dict = {
    # used for report name
    'AHU_NAME': "MZVAV_1",

    # timestamp column name
    'INDEX_COL_NAME': "Date",
    'DUCT_STATIC_COL': "AHU: Supply Air Duct Static Pressure",
    'DUCT_STATIC_SETPOINT_COL': "AHU: Supply Air Duct Static Pressure Set Point",
    'SUPPLY_VFD_SPEED_COL': "AHU: Supply Air Fan Speed Control Signal",
    'MAT_COL': "AHU: Mixed Air Temperature",
    'OAT_COL': "AHU: Outdoor Air Damper Control Signal",
    'SAT_COL': "AHU: Supply Air Temperature",
    'RAT_COL': "AHU: Return Air Temperature",
    'HEATING_SIG_COL': "AHU: Heating Coil Valve Control Signal",  # aka Heat Valve Command Col
    'COOLING_SIG_COL': "AHU: Cooling Coil Valve Control Signal",  # aka Cool Valve Command Col or clg_col
    'ECONOMIZER_SIG_COL': "AHU: Outdoor Air Damper Control Signal",    # aka Outside Air Damper Command Col
    'SUPPLY_FAN_AIR_VOLUME_COL': "vav_total_flow", # not provided in default data set

    'SAT_SETPOINT_COL': "AHU: Supply Air Temperature Set Point",

[bsimmons-onboard]

You could set it up such that each fault condition defines a set of "target" brick classes (outside_air_temperature_sensor) that are required for each analysis to run.
It would also be helpful to see a matrix of brick classes and fault conditions to see where there is overlap between the fault conditions and the required classes.

[bbartling]

Yes absolutely but I may need some help. I have an example ipynb notebook that I am working on for an AHU. I'll give it a crack and check back with you to see if this is what you envisioned on running fault rules against a data model.

…

On Mon, Aug 12, 2024, 4:50 PM Brian ***@***.***> wrote: You could set it up such that each fault condition defines a set of "target" brick classes (outside_air_temperature_sensor) that are required for each analysis to run. It would also be helpful to see a matrix of brick classes and fault conditions to see where there is overlap between the fault conditions and the required classes. — Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHC4BHOMWGR7AUCCKFMY7YLZREUZTAVCNFSM6AAAAABLKPG6OGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBUHE3DIMZTHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bbartling]

@bsimmons-onboard can you check this out? examples/ahu_fault_one_brick.ipynb

https://github.com/bbartling/open-fdd/blob/master/examples/ahu_fault_one_brick.ipynb

Real curious on your thoughts I haven't worked with ontologies a whole lot so its a learning experience for me but if it looks cool i can overhaul the repo for it.

Cell 11 the column mapping...

column_mapping = {
    'http://example.com/building/Supply_Air_Static_Pressure_Sensor': 'SaStatic',
    'http://example.com/building/Supply_Fan_VFD_Speed_Sensor': 'Sa_FanSpeed',
    'http://example.com/building/Static_Pressure_Setpoint': 'SaStaticSPt',
}

that seem legit?

[bbartling]

this is also the fault code running under the hood with a BRICK make over which would need to be done for all fault rules. https://github.com/bbartling/open-fdd/blob/master/open_fdd/air_handling_unit/faults/fault_condition_one.py

[bsimmons-onboard]

Thanks for the example! Interesting, now I see where you're going with BRICK query. I was thinking that the query is abstracted away from the fault condition rules. Intuitively I'd expect to run the fault analysis on a df of time-series data where the column names are the BRICK classes (Supply_Air_Static_Pressure_Sensor). That can save some complexity on managing the translation, and if they are defined in the fault condition class as self.Supply_Air_Static_Pressure_Sensor = float that would make the requirements more transparent.

And I like the direction of adding the errors if columns are missing raise ValueError("Required sensors are missing