- Jan 15, 2013View Source
I like it when we are in violent agreement.
As you pointed out we came at this from different directions.
But one point I would like to highlight is the existence of both interfaces and object descriptions. In my view, Profile_Name would continue to be the pointer to the object description or “class”; it has nothing to do with interfaces. Note that Interfaces declaration also have nothing to do with object descriptions; they provide a mapping from interface elements to properties and any extra properties in the referenced objects are not described in the interface declaration at all.
If we believe that the Profile_Name approach provides benefit, then the device object could be bestowed with a list of implemented interfaces. This would be included so that a consumer would not have to load and parse all of the XML in order to determine what interfaces the device implements. Consider how much fun it would be if we had to load all properties from all objects to determine whether or not a device contained an Analog Input named OAT.
I think it would be interesting to consider:
Keeping Profile_Name, and adding Profile_Location (to each object or just the device object?)
Adding Interface_List, and Interface_Declaration_Location to the device object.
Note that interfaces can be “system” things that are not really rooted at any particular device but in the approach proposed would be. So where an interface spans devices, and does not have an obvious home, could the problem of multiple declarations be solved by having the declaration include 2 pieces of information: root device (the artificial logical home) and declaration location (the source location of the declaration)?
One last thought, while I like the idea of well-known files (interfaces.xdd), I prefer that interface declarations actually be independently documented (each in its own file). Not that this is how we would require it, but I would prefer that this approach be supported (which it probably is) and clearly documented as an option.
Carl Neilson, Project Manager
Delta Controls Inc.
Thanks for the early feedback. On a quick read through the comments, it struck me that some of your questions come from us starting at two different points (isn't it always the case?).
I know we have talked in the past about the advantages of using a CHOICE in the Profile_Location of either an URL or a BACnetDeviceObjectReference, rather than just making it a string. And I agreed with you entirely. So what happened? Coming at it form the other direction, that's what...
The proposal in DR-040-1, does not use Profile_Name or Profile_Location at all. There is no "interface object". The CSML declaration of an "Interface" instance in the xdd files is not "rooted" in any one object at all. Ergo, there is no object that represents the "interface", and therefore, no object whole Profile_Name or Profile_Location point to the file. Or, simply put: The file points to the objects not the other way around.
In a sense, then, this would appear to be an an abandonment of the never-used Profile_Name. But it really means that I hadn't considered how/where these two starting points can be used together and where they meet. As written, Profile_Name was not used. But you bring up some good points, born of that other starting point, that I think will help the discussion a lot.
The main reason for doing it the "file points to the objects" way was because of deployment flexibility and declaration consistency:
In a VFD, I could see where a manufacture might want to make one big object with all the interface members as properties of that object, and then he could use that object's Profile_Name/Location to declare that fact, voila, this object implements that interface.
However, for an air handler, as a collection of many inputs, outputs, loops, etc, what object would you use to declare the "interface". Using the SVO approach, we forced the creation of an extra object just for this purpose, as a discoverable placeholder to be the interface instance. In the xdd files approach, the instance exists only in the file, and it points to all the locations (via the 'href') to all the object that make of the members of the interface.
i.e. an Interface instance it's like a soft SVO - it doesn't exist as an actual object. The "discovery" of interfaces is done by reading the interfaces.xdd file, not by reading the Object_List and then reading every object's Profile_Name. At the very least then, interface discovery is likely faster/simpler.
But the real reason for doing it this way is that it doesn't impose the creation of a bogus "holder" object to be the root of an Interface instance. Which really comes into play when addressing your last comment... where all this resides "disembodied" somewhere.
Now, with that background/directional perspective, I can address your comments.... and we can probably, again, have our cake and eat it too, with your added perspective.
On Jan 14, 2013, at 5:41 PM, Carl Neilson <cneilson@...> wrote:
1) I am wondering whether relying on filenames and hrefs for redirection in all cases is the best approach.
The benefit of using properties (such as Profile_Location, or Interface_Location) is that devices that do not support file objects do not need to be extended with support for them. It also ensures that there is no conflict over file names (but this is probably not a real issue).
I really hadn't considered yet the idea of a device supporting Profile_Name/Location but not the File objects in the device. I.e. an object would say "my definition is over there... in that other device".
I think that would work fine in the case where an object, like a proprietary object, is wanting to describe itself using csml metedata. And I think that can be added as a scenario in this scheme easily.
As said above, the problem I was primarily addressing with this new approach was that of an interface, especially, where there is no obvious "root object" to declare that interface.
In mulling this over, I wonder about cases where different instances of objects in a single controller are different. If those instances are known beforehand, there would not be much of a problem, but if the instances are effectively dynamic (set property 321 to 1 for type A, 2 for type B, etc) then the definitions.xdd could not refer to specific instances.
Good point! The approach as initially laid here out only defined object types in the device. This was, perhaps, a naive "classic" viewpoint - that Object_Type actually means something. That the device doesn't have a single proprietary object type that can be mutated dramatically into different functionality at configuration time. The possible coming and going of optional properties was expected, as for our beloved Clause 12 objects, but wholesale behavior/property-set changes were not anticipated.
So yes, using Profile_Name in conjunction with a definitions.xdd (either local to the device or remote) would work for this case. I can add that as a scenario and indicate that, when present, Profile_Name trumps Object_Type for finding a definition.
What this points out to me is a difference between a device that uses Profile_Name, and one which does not. In the first case, the definitions.xdd file would describe profiles, and in the second it would specify specific instances of objects (as seen in DR-040-1).
I'm not sure if the reference to "DR-040-1" is correct here? That was the proposal that specifically lacked the per-instance declaration that we are talking about adding. But, anyway, I agree with your comment! I did not address the per-instance case, and this could be easily added, as discussed immediately above.
I agree that the content of these files is best is if it is static (I think more devices would provide this information if it were static and not dependent on deployment / configuration).
Yes, absolutely. Suggesting that a device itself should be capable of generating dynamic zipped XML files was a non-starter!
2) I don’t see the need for the CSML in the device to provide links to actual real data. Those pointers back into the objects to retrieve the values should be optional (they just waste space stating the truism that the value of the property is the value of the property). Or does the existence of these pointers somehow make the web server implementation trivial because it can just barf back whatever it read from the device?
I would agree with you entirely... if we were starting at the object, via it's Profile_Name/Location, back to the file. With that perspective, I can easily see where the hrefs out to the properties seems redundant. But in the interface case, there is no redundancy because there is no object pointing in to the file.
I think we'll find our "have our cake and eat it too" moment here.... see my comment under your "If the hrefs are optional..."
I think that expecting hrefs to be present in these files means that for programmable controllers, the content of these files would not be static from the factory but would have to be updated as the product is configured. If the configuration tool is not updating the files then the controller has to be which is a significant increase in burden on the controllers.
There were three scenarios that were attempting to show where this files were generated (i.e. "how static is static").
Case 1: fixed function device (e.g. VFD drive)
Here, the file as shown in the document is completely fixed from the factory (It could be in code space, effectively in "ROM"). That is why the hrefs use "." for the device identifier, meaning "this device".
Case 2: fixed function device with some configuration-time binding (e.g. AHU with an embedded factory controller)
This is shown in the "binding objects" scenario. Here, also the file shown in the document is completely fixed from the factory ("ROM"). The required configuration time bindings are done by binding objects which the "ROM" file points to.
Theoretically then, as an bizarre edge case, I could ship a device with a ROMed interface declaration file where every member of the interface points to a binding object... efectively recreating the extended SDO idea of completely writable member pointers for a "fixed" interface instance.
Case 3: programmable device.
In this case, the xdd files are not fixed at the factory, therefore are not in "ROM". They are "programming artifacts" written to a File object that was likely created for the purpose of holding them as part of the download/programming process. At this point, you could say that they are as "dynamic" as the programs and associated objects are. But as soon as the programming is over, they become "static" at runtime. But they are not created or modified in any way by the device, they are created/updated only by the programming tool.
If the hrefs are optional, is there ever a benefit to having an href that just points back to the source property (since you cannot rely on it, and the assumption would be that if it were not there, the value is found by referring to the source property)?
The hrefs are used in the document only for interface instances that don't have an associated root object whose "source properties" can be inferred, therefore they are never optional. So you'll notice that they are not used for definitions of object types - in that case, the xdd file indeed uses property numbers instead of hrefs because that implicit like is made by in fact having an object to tie them together.
So generally, I agree entirely with you that they are not used, and they actually can't be used, for objects. But they are always used for interfaces.
This is actually the key point of all this that was clearly sorely missing from my introduction to the document... interfaces are not objects.
3) DR-040 also provides a method for remapping enumerations.
The approach is fine for devices that consume the CSML, but does not solve the problems for the device that interacts with the interface but does not consume the CSML. For example, if the enumeration values can be remapped, then the AHU would need to consume the CSML in order to interact with the VAV that remapped its enumerations. I would not expect the AHU to do this, I expect the binding tool that links the AHU with its VAVs would consume the data and point the AHU at the VAVs it needs to interact with.
Ah yes. That's a great reason why we shouldn't allow this. I just keep getting asked about it, since whenever we talk about the capability to "bless" existing installations with conformance to a newly defined interface, the enumeration remapping is often the first thing they notice that will be a problem.
I am in no way wed to this notion and I will certainly take it out as a poison pill or lightning rod in the proposal document!
4) In the case of the “field applied interface declaration”, which devices are expected to contain the declaration?
Do all devices that implement a piece of the interface contain a copy?
No. There is only one instance of an interface, and it points to all its members who are either local or remote the the device that contains the instance declaration (the members could all be remote, I guess!)
Is one of the devices somehow identifiable as the custodian of the declaration?
Can there be a central interface library on a site so that one only one of the devices need the capability to store interface declarations?
So, absolutely. Another edge case here.... bestow all this magic on all the controllers you are shipping today! Simply store all your "programming artifacts" in a single place (maybe even, ouch, a workstation/device) that has all the BACnet file objects that other clients then "discover".
The discovery process would thus be:
1) find all devices (including workstations/servers)
2) search for xdd File objects.... searching.... searching.... searching.... BAM! all in one place!
This is pretty gross as an end goal, but might actually work as a transition technique. (and in reality, a human would ask another human "where is the gold mine" rather than go looking for it in every VAV box!)
Well, that was a fun morning, and all on only one cup of coffee!