#971 CDL Annotations

Joel Bender Tue 1 Mar

I posted this on LinkedIn for some broader response to this MIME-like annotation concept, but I would like to see a more specific response from the Haystack community. The most basic example would probably be a string like "mixed air temp point" for a single interface element, but that doesn't help as much as a query string that closely associates all of the interface elements together with a piece of equipment like what you might find for an ASHRAE Guideline 36 function.

ASHRAE Standard 231P, CDL - A Control Description Language for Building Environmental Control Sequences, is working on definitions for "function blocks" that can be represented in both graphical and text formats. One aspect of this work is to associate the "interface elements" (i.e., inputs, outputs, and parameters of a function) with annotations, semantic information suitable for an integrated development environment (IDE) to assist the user in "binding" the interface elements to some model.

In the example below you'll see that the block and interface elements have human readable character string descriptions. I would like associate additional machine readable character strings specific to different communities (with a type like a MIME type) and I'm looking for examples.

block AddParameter "Output the sum of an input plus a parameter"

  parameter Real p "Value to be added";

  Interfaces.RealInput u "Connector of Real input signal";
  Interfaces.RealOutput y "Connector of Real output signal";

  y = u + p;

end AddParameter;

One example would be associated with the AddParameter block the type "text/sparql" with the string "SELECT ?u ?y WHERE { ... }" describing some constraints on "real" inputs and outputs assuming an underlying RDF model.

Any assistance would be appreciated!



Brian Frank Tue 1 Mar

I am not sure what exactly you are asking for - how do we bind points for application logic? I'm pretty sure all the Haystack vendors just use filters to bind points

In SkySpark, we bind points to variables for rule logic using a filter which contains a place holder for the equipment being processed. For example, an analytic rule looks like this:

// rule is bound to a specific equipment type
ruleOn: "ahu"

// rule logic creates variables bound to specific 
// point on the equipment target using curly brace macro
cool:  { bind:"cool and cmd and equipRef=={{target->id}}" }
heat:  { bind:"heat and cmd and equipRef=={{target->id}}" }

The Benefit project will likely result in a standardized template model for creating bindings like that

Joel Bender Tue 1 Mar

Yep, that's what I was looking for, thank you.

Login or Signup to reply.