We are working with HayStack on tags, and we need the following items nailed down so we can implement them as well. They might not be needed in SkySpark as much, but I think it's very important for us to know these things for configuring and building the projects out. So here is my question.
1.Controller is the controller that the inputs wire to. It could be the following controller = EasyIO, Spyder, etc.... What should we name this Tag?
Network (Driver????), I'm not sure the Network is the right thing to name this, maybe Protocol would be better? THis would be Network / Protocol / controllerType = Sedona, LonWorks, Bacnet, and so on
Global Controller. globalController = JACE-6, JACE-2, Sedona, Supervisor, Mediator, and so
Do we have a globalControllerRef, and a networkRef too? As a controller could be a Global controller as well, let's say a JACE-2 could also be the COntroller, and the Global Controller?
Brian... You are good at this, can you help us nail this down, and come up with a good standard?
Brian FrankTue 20 Sep 2011
Well from an analytics or visualization perspective, I'm not sure we care much about the physical devices and networking. Although I suppose it is useful to model, maybe even provide value for analytics of network communications. I'm up for trying to model those sorts of things though as long as it doesn't conflict with the logical equip modeling.
At the most basic level, I think the key things to capture:
device: models the device itself (Jace, EasyIO, Spyder, PLC, etc)
"networking": what protocols does the device speak? with how does the device communicate directly?
You could potentially model something like a deviceRef on your points to show what device a point is sourced on. Although I'm not sure we should go there until value is proven.
You could also potentially get into trying model the role of the device (supervisory, equip control, sensor, etc). But not sure everything would be so clean.
I think the first step is to talk about use cases. What would we do with this model?
Winston HetheringtonTue 20 Sep 2011
Brian, I agree with the first part of your comment. In general I am having a difficult time understanding to what end the Haystack Project is heading with respect to controls. It is one thing to try to model an installed system with possibility the objective of analyzing performance. Beyond this, the likely hood of ever having direct access to override or tweak any control function (while feasible maybe) is beyond reasonable expectation for most of the participants of this project. So, who could benefit from this part of the exercise. From my experience every BAS installations in existence is unique. No two buildings perform the same and even for identical buildings, there seem to be some unique installations that make then respond differently. Intimate knowledge of each system would be required to run comparisons for performance. From my perspective the existing installed systems as of today would require significant modifications to permit access to data to make it available to external sources following this model. There are two issues to face after fully defining Haystack; legal liability for the interconnection and ownership (property/building owner) and control (authority having jurisdiction) of any/all installed systems. Many building systems include life-safety implications and even if not owners would not be happy to find system operation modified without their consent. So again I ask what is the goal here. Several previous discussions have caused me to be concerned.
Jason BriggsTue 20 Sep 2011
If we want a tool that can auto configure tagging, we need it to be more power than just tagging things for analytics.
I thought this project was to help standardize on how we build things and name things, if it is, than networks, drivers, and controllers should be apart of that for sure. Just because someone doesn't use it all the time, doesn't mean we shouldn't come up with a standard for it? What is the downside to picking this now, I'm sure I can come up with a lot of scenarios on why you would define this now, but I'm not sure the point of it. Why not just pick it and be done with it?
Example: I want to visualize sparks a certain way, per network, or per controller, and so on. This will help the user be able to drill down into sparks.
Brian FrankTue 20 Sep 2011
In general I am having a difficult time understanding to what end the Haystack Project is heading with respect to controls.
I am not sure how to restate what is already on the home page. The goal is simply to model data. That could be asset data, control/sensor operational data, or data about how systems are put together. In this case data about controllers may or may not be useful, but it doesn't really have anything to do control itself per se. If you want to discuss further, you are welcome to create another topic, but let's not tangent this discussion which is on how/if to model physical devices.
Jason BriggsTue 20 Sep 2011
networkType = Would that work? Sedona, LonWorks, etc....
controllerType, as device could actually be a sensor too? I think we want to know that it is a controller, and that controller has IO?
globalController could just be a marker? globalControllerRef = Would this work too? A Sedona controller could reference it's globalController?
Brian FrankWed 21 Sep 2011
After sleeping on it, I can definitely see some real value in modeling the physical devices and networks. I think the right place it start is modeling the network topology. Then from there we can go back and add tags to further describe networks and devices. Let's consider this example network topology (Niagara specific since that is what I know :-)
I agree with Jason and Brian in that it would be beneficial to model the network devices but a key consideration would be how this hierarchy interacts with the site/equip/point model - ie: Would an equip have a networkRef tag?
Brian FrankWed 5 Oct 2011
Would an equip have a networkRef tag
In many cases a single piece of equip like an AHU is associated with one controller, so the equip entity could reference the device via deviceRef (which in turn would reference one or more networks). But there isn't always a one-to-one mapping between equipment assets and devices, so you might have to associate individual points with a device where their I/O or control is mastered.
Richard McElhinneyTue 22 Oct 2013
Just raising this topic from the dead!! :)
This modelling came up in discussions today as a requirement and I was wondering if it went anywhere?
I checked the tag documentation and it appears as if none of Brian's proposals made it into the official documentation unless I didn't look properly.
Is anyone else modelling devices and networks? Are there any other proposals?
@Jason Briggs: how have you solved this problem given that it was originally your question?
Jason BriggsTue 22 Oct 2013
This is what we do so far, we aren't complete but I agree with Richard we should nail this down right away.
I think there are two different ways to look at it. One is Physical layout, and the other is Network layout. I say we do network layout now, and worry about physical/locations later.
So if I had a Haystack Server talking to a Niagara Supervisor that talked to a Bacnet Global controller, that talked to a arcnet to mstp gateway, that talked to a bacnet arcnet controller. This is what it would look like.
I just quickly put something together, I positive that some of the names are dumb, and some of this won't work, just wanted to get something to start talking about.
I put protocl(x) based on what is being used, not what it's capable of. This way you can walk up to a job, and see what all protocols are being used.
Richard McElhinneyWed 23 Oct 2013
@Jason, that's a pretty complete approach. Couple of thoughts from me based on the 2 solid proposals from Brian and Jason.
I would propose a slight variation and break up a few of these tags and combine your ideas with Brian's original proposal.
So the basic network/device tags would be:
network
networkRef
device
deviceRef
Let's take from your proposal:
server
controller
protocol
however I would like to propose to change protocol to be an enumerated tag with pre-defined values like you've captured, BacnetMstp/BacnetIP/Haystack/Sedona/ModbusTCP/ModbusRTU etc. This list can always be added to.
I like the idea of server and controller. I'm not sure it's necessary to break them into global controllers or other types of controllers as that would be implicit based on what sort of network they are on and where they are in the hierarchy of networks.
I think we can also keep and add in for device documentation purposes things like:
deviceSoftware // optional
deviceSoftwareVer // optional
deviceVendor // optional in case vendor and manufacturer are different
deviceManufacturer // optional based on the type of system
deviceLoc // optional device location string
Personally the ones I'm not so keen on are
routerDevice
gatewayDevice
these 2 seem to get more into the physical networking infrastructure side of things rather than the logical relationships.
Look forward to everyone's thoughts!!
Cheers, Richard
Jason BriggsWed 23 Oct 2013
Richard... I like your proposal much better. You have my vote.
Yes the router and gateway would be for physical. As soon as we tackle this one, let's finish physical too.
Brian FrankWed 23 Oct 2013
What Jason posted really doesn't make sense on its own. Rather what he has there are marker tags that you might apply to the generic device and network entities in the original proposal (not sure if that was his intention or not). We could define a whole library of tags to put on device and network to describe the role of the device and the protocol(s) being used by the network.
As far as standardizing this, I would be reluctant to formalize it in the documentation until someone has actually built something with it. Can you describe what you might do with it Richard?
Christian TremblayWed 23 Oct 2013
Just to add my 2 cents. I can see something really interesting regarding bacnet. I'm actually hitting my head trying to figure a good way to represent a big network using bacnet/MSTP, bacnet/IP, bacnet/Ethernet all on the same network, under different subnets... Every controllers have to have a unique DeviceID, every Segment-network have to have a unique number...
On a tagged network. It would be possible to browse the data base and ask :
Is deviceID 1234 already taken
what's under MSTP network #2
what's the IP of the router to communicate with deviceID (wich is under MSTP #23, for example)
The model would need tags like, 'deviceID', 'networkNumber', 'physicalLayer'(?) [b/ip, ethernet,mstp,arcnet,etc...], 'address' on the physical layer, 'BBMD', etc...
Those tags "could" even be generated automatically by a Jace (or other device)...maybe... As those informations are part of the configuration of the bacnet network.
This said, you will understand that from my point of view, I would keep routerDevice, at least :) for bacnet/IP -> MSTP routers
Richard McElhinneySat 26 Oct 2013
Just to bring this to a logical summary/conclusion at this point, I had a brief offline chat with Brian and I think that the main point here is that we need to prove it out.
In the context that I want to use these tags we will go ahead and use what has been proposed so far and at an appropriate point I will report back.
This really feels like we have a solid proposal that is "pending" approval based on real world feedback. I think that there have probably been a number of these proposals that would be in a similar situation that others have posted.
So I guess I'm aiming a question at Brian and the rest of the Project
Haystack team, is it possible that we could create a section on this
website for "proposals pending approval"?
To get your proposal on that section of the website would require at least 2 or 3 other people to provide positive feedback, as we've seen here.
At least that way everyone can see what proposals are out in the field and are actively being worked on.
I'd be happy to provide my proposals in Fandoc or Markdown if it helps ease the formatting of the web pages.
In the future we can work on a process that allows a proposal go from "pending" to "official". However in the meantime it will provide an easy reference to see what work is going on in the community.
Cheers, Richard
Jason BriggsSat 26 Oct 2013
I totally agree with Richard. Great idea.
Brian FrankTue 29 Oct 2013
I don't have any problem publishing a chapter on device networks and just say its a prototype until we get some experience under our belt (which really this whole library is about :)
I will draft the chapter based on my proposal from 21 Sept 2011. If anyone has specific feedback to that, please share now.
Jason Briggs Mon 19 Sep 2011
We are working with HayStack on tags, and we need the following items nailed down so we can implement them as well. They might not be needed in SkySpark as much, but I think it's very important for us to know these things for configuring and building the projects out. So here is my question.
1.Controller is the controller that the inputs wire to. It could be the following controller = EasyIO, Spyder, etc.... What should we name this Tag?
Do we have a globalControllerRef, and a networkRef too? As a controller could be a Global controller as well, let's say a JACE-2 could also be the COntroller, and the Global Controller?
Brian... You are good at this, can you help us nail this down, and come up with a good standard?
Brian Frank Tue 20 Sep 2011
Well from an analytics or visualization perspective, I'm not sure we care much about the physical devices and networking. Although I suppose it is useful to model, maybe even provide value for analytics of network communications. I'm up for trying to model those sorts of things though as long as it doesn't conflict with the logical equip modeling.
At the most basic level, I think the key things to capture:
device: models the device itself (Jace, EasyIO, Spyder, PLC, etc)You could potentially model something like a
deviceRefon your points to show what device a point is sourced on. Although I'm not sure we should go there until value is proven.You could also potentially get into trying model the role of the device (supervisory, equip control, sensor, etc). But not sure everything would be so clean.
I think the first step is to talk about use cases. What would we do with this model?
Winston Hetherington Tue 20 Sep 2011
Brian, I agree with the first part of your comment. In general I am having a difficult time understanding to what end the Haystack Project is heading with respect to controls. It is one thing to try to model an installed system with possibility the objective of analyzing performance. Beyond this, the likely hood of ever having direct access to override or tweak any control function (while feasible maybe) is beyond reasonable expectation for most of the participants of this project. So, who could benefit from this part of the exercise. From my experience every BAS installations in existence is unique. No two buildings perform the same and even for identical buildings, there seem to be some unique installations that make then respond differently. Intimate knowledge of each system would be required to run comparisons for performance. From my perspective the existing installed systems as of today would require significant modifications to permit access to data to make it available to external sources following this model. There are two issues to face after fully defining Haystack; legal liability for the interconnection and ownership (property/building owner) and control (authority having jurisdiction) of any/all installed systems. Many building systems include life-safety implications and even if not owners would not be happy to find system operation modified without their consent. So again I ask what is the goal here. Several previous discussions have caused me to be concerned.
Jason Briggs Tue 20 Sep 2011
If we want a tool that can auto configure tagging, we need it to be more power than just tagging things for analytics.
I thought this project was to help standardize on how we build things and name things, if it is, than networks, drivers, and controllers should be apart of that for sure. Just because someone doesn't use it all the time, doesn't mean we shouldn't come up with a standard for it? What is the downside to picking this now, I'm sure I can come up with a lot of scenarios on why you would define this now, but I'm not sure the point of it. Why not just pick it and be done with it?
Example: I want to visualize sparks a certain way, per network, or per controller, and so on. This will help the user be able to drill down into sparks.
Brian Frank Tue 20 Sep 2011
I am not sure how to restate what is already on the home page. The goal is simply to model data. That could be asset data, control/sensor operational data, or data about how systems are put together. In this case data about controllers may or may not be useful, but it doesn't really have anything to do control itself per se. If you want to discuss further, you are welcome to create another topic, but let's not tangent this discussion which is on how/if to model physical devices.
Jason Briggs Tue 20 Sep 2011
networkType = Would that work? Sedona, LonWorks, etc....
controllerType, as device could actually be a sensor too? I think we want to know that it is a controller, and that controller has IO?
globalController could just be a marker? globalControllerRef = Would this work too? A Sedona controller could reference it's globalController?
Brian Frank Wed 21 Sep 2011
After sleeping on it, I can definitely see some real value in modeling the physical devices and networks. I think the right place it start is modeling the network topology. Then from there we can go back and add tags to further describe networks and devices. Let's consider this example network topology (Niagara specific since that is what I know :-)
+--------------------+ | Supervisor | +--------------------+ | | IP Network | +--------------------+ | Jace | +--------------------+ | | | Bacnet | Modbus | | +--------+ +--------+ | Spyder | | EasyIO | +--------+ +--------+In this example we have four devices:
To model this properly I think we need three tags:
device: models a physical microprocessor based device (PC, controller, etc)network: models network with specific physical media, and maybe specific protocolsnetworkInterface: our "join" entity to glue devices to networksWith those tags, we could model our example network topology as follows:
Clayton Miller Tue 4 Oct 2011
I agree with Jason and Brian in that it would be beneficial to model the network devices but a key consideration would be how this hierarchy interacts with the site/equip/point model - ie: Would an equip have a networkRef tag?
Brian Frank Wed 5 Oct 2011
In many cases a single piece of equip like an AHU is associated with one controller, so the
equipentity could reference the device viadeviceRef(which in turn would reference one or more networks). But there isn't always a one-to-one mapping between equipment assets and devices, so you might have to associate individual points with a device where their I/O or control is mastered.Richard McElhinney Tue 22 Oct 2013
Just raising this topic from the dead!! :)
This modelling came up in discussions today as a requirement and I was wondering if it went anywhere?
I checked the tag documentation and it appears as if none of Brian's proposals made it into the official documentation unless I didn't look properly.
Is anyone else modelling devices and networks? Are there any other proposals?
@Jason Briggs: how have you solved this problem given that it was originally your question?
Jason Briggs Tue 22 Oct 2013
This is what we do so far, we aren't complete but I agree with Richard we should nail this down right away.
I think there are two different ways to look at it. One is Physical layout, and the other is Network layout. I say we do network layout now, and worry about physical/locations later.
serverDevice
globalControllerDevice
controllerDevice
routerDevice
gatewayDevice
So if I had a Haystack Server talking to a Niagara Supervisor that talked to a Bacnet Global controller, that talked to a arcnet to mstp gateway, that talked to a bacnet arcnet controller. This is what it would look like.
--- dis: Server-1
serverDevice
deviceSoftware:finStack
protocolHaystack
protocolPop3
protocolSedona
--- dis: My Sup
serverDevice
deviceSoftware:niagaraAX
serverDeviceRef:@Server-1
protocolHastack
--- dis: My Bacnet Global Controller
globalControllerDevice
deviceSoftware:alertonBacnet
serverDeviceRef:@My Sup
protocolBacnetIP
--- dis: My Arcnet to Mstp Router
gatewayDevice
deviceSoftware:fieldServer
globalControllerDeviceRef:@My Bacnet Global Controller
protocolBacnetMstp
--- dis: VAV-1
controllerDevice
deviceSoftware:ALC
protocolBacnetArcnet
I just quickly put something together, I positive that some of the names are dumb, and some of this won't work, just wanted to get something to start talking about.
I put protocl(x) based on what is being used, not what it's capable of. This way you can walk up to a job, and see what all protocols are being used.
Richard McElhinney Wed 23 Oct 2013
@Jason, that's a pretty complete approach. Couple of thoughts from me based on the 2 solid proposals from Brian and Jason.
I would propose a slight variation and break up a few of these tags and combine your ideas with Brian's original proposal.
So the basic network/device tags would be:
Let's take from your proposal:
however I would like to propose to change
protocolto be an enumerated tag with pre-defined values like you've captured, BacnetMstp/BacnetIP/Haystack/Sedona/ModbusTCP/ModbusRTU etc. This list can always be added to.I like the idea of
serverandcontroller. I'm not sure it's necessary to break them into global controllers or other types of controllers as that would be implicit based on what sort of network they are on and where they are in the hierarchy of networks.I think we can also keep and add in for device documentation purposes things like:
Personally the ones I'm not so keen on are
these 2 seem to get more into the physical networking infrastructure side of things rather than the logical relationships.
Look forward to everyone's thoughts!!
Cheers, Richard
Jason Briggs Wed 23 Oct 2013
Richard... I like your proposal much better. You have my vote.
Yes the router and gateway would be for physical. As soon as we tackle this one, let's finish physical too.
Brian Frank Wed 23 Oct 2013
What Jason posted really doesn't make sense on its own. Rather what he has there are marker tags that you might apply to the generic
deviceandnetworkentities in the original proposal (not sure if that was his intention or not). We could define a whole library of tags to put on device and network to describe the role of the device and the protocol(s) being used by the network.As far as standardizing this, I would be reluctant to formalize it in the documentation until someone has actually built something with it. Can you describe what you might do with it Richard?
Christian Tremblay Wed 23 Oct 2013
Just to add my 2 cents. I can see something really interesting regarding bacnet. I'm actually hitting my head trying to figure a good way to represent a big network using bacnet/MSTP, bacnet/IP, bacnet/Ethernet all on the same network, under different subnets... Every controllers have to have a unique DeviceID, every Segment-network have to have a unique number...
On a tagged network. It would be possible to browse the data base and ask :
The model would need tags like, 'deviceID', 'networkNumber', 'physicalLayer'(?) [b/ip, ethernet,mstp,arcnet,etc...], 'address' on the physical layer, 'BBMD', etc...
Those tags "could" even be generated automatically by a Jace (or other device)...maybe... As those informations are part of the configuration of the bacnet network.
This said, you will understand that from my point of view, I would keep routerDevice, at least :) for bacnet/IP -> MSTP routers
Richard McElhinney Sat 26 Oct 2013
Just to bring this to a logical summary/conclusion at this point, I had a brief offline chat with Brian and I think that the main point here is that we need to prove it out.
In the context that I want to use these tags we will go ahead and use what has been proposed so far and at an appropriate point I will report back.
This really feels like we have a solid proposal that is "pending" approval based on real world feedback. I think that there have probably been a number of these proposals that would be in a similar situation that others have posted.
To get your proposal on that section of the website would require at least 2 or 3 other people to provide positive feedback, as we've seen here.
At least that way everyone can see what proposals are out in the field and are actively being worked on.
I'd be happy to provide my proposals in Fandoc or Markdown if it helps ease the formatting of the web pages.
In the future we can work on a process that allows a proposal go from "pending" to "official". However in the meantime it will provide an easy reference to see what work is going on in the community.
Cheers, Richard
Jason Briggs Sat 26 Oct 2013
I totally agree with Richard. Great idea.
Brian Frank Tue 29 Oct 2013
I don't have any problem publishing a chapter on device networks and just say its a prototype until we get some experience under our belt (which really this whole library is about :)
I will draft the chapter based on my proposal from 21 Sept 2011. If anyone has specific feedback to that, please share now.