It's your place to connect with experts and peers, get continuous support, and share knowledge.
Contact SchneiderCommunity.Support@se.com if you have any questions.
You can subscribe to this forum after you log in or create your free account..
Posted: 2014-08-20 08:25 AM . Last Modified: 2021-10-25 11:16 AM
I received a question yesterday that I wanted to post and start a discussion about. Here it is:
"Looking for some feedback on Schneider’s views on Project Haystack. We are rolling out Studio360 and are looking to adopt the SEBA standardizing point naming convention. I don’t know much about the Project Haystack but I understand one aspect of the project is another way of standardizing point names throughout the industry. There has been talk that the Project Haystack system may be adopted by ASHRAE someday. Do you have any thoughts on this subject? "
I must confess that I have not studied Project Haystack (PH) in depth, but I have taken a look at the website. It seems to be an open source community based standard of point naming, which I think is wonderful. PH has categories of the types of equipment that it applies to; chillers, boilers, AHUs, etc. then is broken down into points like "discharge air temp sensor" as well as some other tags.
The main issue that I see with PH is that it seems incomplete and I really don't see a framework or guidelines for creating additions to the standard in real time (when you are designing or programming a job). I think it also seems to concentrate on hardware only, not necessarily software point names (although I do see a couple). We originally designed the SEBA (Schneider Electric Buildings Americas) to be flexible, simply an agreed to abbreviation for certain words, an order to combine the abbreviations and a method of combining them using CamelCase. So if you need something that is not covered in the list, just do your best to come up with an abbreviation and use the other two conventions of order and camel case. We could always add that abbreviation, or modify it slightly and add.
Another big downside to me is that the point names are so long and contain spaces. We designed the SEBA point name convention to fit all of our product lines; Continuum, I/Net, Vista, I/A, and SmartStruxure. Most of those product lines have a certain restriction on the amount of characters in a point name, like 16 or 20 (SmartStruxure has 255). So our goal is that each of the abbreviations are no longer than 4 characters, and with 5 or so levels of order, the longest point name should be no more than 20 characters and most less than that. I am always trying to keep them under 16 characters.
There are other reasons behind the decision not to use PH and to continue with the SEBA point name convention. Another positive is that Australia has also adopted the SEBA point name convention, with a few modifications, and I believe that India and some of Europe is looking into them. It would be wonderful if we could make it a global standard.
I am interested in hearing what you guys think, both pros and cons for the PH standard and the SEBA standard. I am always interested in ideas to make our standards better and more universal.
Posted: 2014-08-20 09:47 AM
We are using the SEBA point names. They are already being used by the branches and are in Studio360. Any sharing of drawings or programs that occurs between offices will be more effective if we are all using the SEBA point names.
If HayStack were to become a widespread industry standard, then it might be worth considering.
That's my two cents...
Posted: 2014-08-20 12:22 PM
I would agree at this point we need to focus on the SEBA point names. Project Haystack does look interesting and there is good information on their website. My biggest issue is the PH does not seem abbreviate the point names and thus really does not seem practical to me.
Posted: 2014-08-22 12:43 PM
My name is Steve and I'm an project manager/engineer at the Chicago Branch. I've interacted some with Pat (hey Pat) and Lonnie, you've been on some calls that I've been on before (hi). We are slowly starting to get integrated into the broader Schneider engineering "community" here at the branch - to some I'm sure it feels like we're late to the game but there are, of course, challenges to integrating an acquired partner and a few of us (including myself) have only recently joined the company. I believe you guys have been aware of the recent presence of Ryan Zimmerman and Jeff Kohn (engineers here at the branch) on the national calls. We have also been working some with Julio Cortes to integrate SmartStruxure software best practices into our operations so that we can take advantage of the work being done by others.
With that preface, I wanted to say that I'm all for getting things standardized (often to the point that I'd like to see it in places I notice that it's lacking such as the look and feel of stencils in the D360 package - for what it's worth after a broad survey of industry standards I think I would've landed on SMACNA standards for much of what we do in the shop drawings, and I suppose we still could (without deviating much or any from the intended D360 usage) if we generated our own stencils in Homewood for the schematic portions of those drawings: https://www.smacna.org/docs/default-source/technical-resources/smacnacadstandard.pdf?sfvrsn=2). But I digress...I wanted to share with you what I felt to be valuable information related to the topic at hand. Being that, perhaps, the greatest value proposition aside from internal engineering efficiency gains is value to the external world ind the form of usable data (analytics) I reached out to my contact (Alex Grace) at Schneider Electric's primary analytics provider - KGS (KGS Buildings) - to see if they had an awareness of Project Haystack, a preference for it versus some other development, existence of competing standards, etc and because I was concerned that it was supported by SkyFoundry (a competitor of our partner KGS) and Siemens (a competitor to us) (http://www.prnewswire.com/news-releases/project-haystack-announces-formation-of-non-profit-corporati...). I presumed them to be as versed in this topic as anybody else in the Schneider sphere and they seem to be. Long story short the email got forwarded to the top there and, for what it's worth, here is their CEO's response:
"We've been following Haystack, but we do not currently use Haystack tags in our platform. Having ANY standard will help us, regardless of whether it is SEBA or Haystack or any other and we are therefore in favor of the adoption of a standard. With any standard, we can do a mapping of most of the embedded information to our ontology. If it is Haystack, we can work with that although there may be some gaps in the information provided by Haystack. Haystack is a very flat ontology. Everything gets a "tag", but there are no relationships. Tags are also used to illustrate relationships for example with the "entering" tag or "exiting" tag. I happen to think Haystack is insufficient but great that it is something. It is true that Haystack originated within the Tridium ecosystem and is heavily influenced by it and SkyFoundery, which is a competitor. For that reason and the uncertainty that brings with it, we have remained neutral on Haystack rather than a supporter. I also think that with Haystack tags you may well have both point naming conventions and a set of Haystack tags that are associated with it, even if the naming convention is just a concatenation of tags... because most BAS need a point name, not an assembly of tags. I can also tell you that the BACnet data modeling working group at ASHRAE is actively discussing these issues
I don't believe Haystack will be the be all end all but it is a beginning point for these discussions, and getting commercial traction already. This is a conversation I'd be interested to continue with the right teams. I am cc'ing Shafique Shah who is our R&D offer manager and has also participated in some of these discussions...
Nicholas Gayeski, PhD
Partner, Co-Founder, CEO
KGS Buildings, LLC"
Hopefully, this is a valuable contribution to the discussion. I'd love for us here in Homewood to use some of our horsepower to continue to help shape these standards as they are developed. There is a good deal of engineering expertise up here that could be helpful in getting things standardized in the best possible way. Thanks guys - feel free to reach out to me if I can be of any assistance on this.
Posted: 2014-08-23 06:57 AM
Great post Steve! Very valuable information/input to the conversation.
Lonnie - I agree with everyone here that we have a good start to a standard naming convention and it is really beginning to take hold. Our future related to engineering efficiency is very dependent on our adoption of standard point naming conventions like the SEBA Point naming. It is true that the SEBA point names can be very cryptic to someone that is not used to it. I think the PH method was developed to be a more point name friendly standard for people who are not necessarily from our industry but want to be able to mine the data with reporting and analytics. I think it would be worth keeping an eye on PH to see where it goes, as well as the BACnet DM group, but we should continue with our own adoption and development with the SEBA point naming standard. Our binding templates and other automation are very dependent on our standard point names. It also sounds like maybe we need to get KGS more aware of the SEBA standard. I am all for adding value to the external world and helping to move our industry forward. However, I believe there are too many different control system manufacturers and independent integrators, to think that we will soon be able to get everyone to agree to the same standard naming convention. It will be up to the analytics engine developers to build their templates to convert the systems point names to their standard names that their algorithms use.
Posted: 2014-08-25 07:36 AM
Hi all, Rob, we definitely would like to see greater and greater adoption of standards and will be the first to support it! re SEBA naming conventions, KGS' challenge is that to date we have been involved in very few projects where the SEBA naming conventions have been or are being applied, therefore it has had limited impact on our tasks to date. That said, it is a long term strategy and it will impact us heavily and help us a great deal over time!
Posted: 2014-08-25 09:04 AM
I'll look forward to discounted pricing on our projects with KGS, since we use the SEBA naming convention.
Posted: 2014-08-25 09:54 AM
If we truly get to a point where the cost reductions on our side are realized by having standard naming conventions... unofficially, it is only a matter of time - we know. But we need critical mass and we need more tools to exchange metadata.
Posted: 2014-08-26 12:23 PM
While I'm not wanting to throw water on something that I embrace in spirit, I probably fall into the camp that would describe the SEBA convention "cryptic". Coming from a systems engineering educational background I truly appreciate, accept as gospel, and wholeheartedly pursue the benefits of standardization in terms of empowering engineering efficiency and ultimately improving customer satisfaction - this is my world. And while I agree with the notion that "any standard is better than no standard", the whole thing falls apart if supposed systems are constructed in such that they can be utilized in multiple ways to represent the same thing. When I look at the SEBA convention I see two features that might be problematic: 1) I feel like it can be used in multiple ways to represent identical data points and 2) the nomenclature seems arbitrary (it doesn't seem to follow any authoritative standard that I've seen - such as ASHRAE or SMACNA). For example, if the piping service options are clear-cut in the 2009 ASHRAE Handbook Fundamentals (http://kntu.ac.ir/DorsaPax/userfiles/file/Mechanical/OstadFile/dr_sayadi/19337425502009AshraeFundame...) - see page 852 - why are we not presenting all of these (in their suggested form) as options, the only options? When I look to the SEBA convention I don't see some options present - such as chilled water supply (CHWS - am I supposed to combine Chw and S to form ChwS?), low-pressure steam (LPS - not present?), high-temp hot water supply (HTWS - notice the T - this seems to be a standard in SMACNA as well, not HWS, whereas SMACNA refers to this HTWS as "heating water supply"). While this second issue is probably more minor, and until a universal standard is adopted by ASHRAE or somebody else, will ultimately remain a matter a tastes, the first issue could potentially be a deal breaker. When I look to the SEBA convention I notice that I could feasibly use the scheme to name many concepts several different ways:
AHU1 low limit alarm/freeze stat: AHU1LlmtAlm, AHU1AlmLmt, AHU1FzAlm, AHU1AlmFz, AHU1DetLlmtAlm, AHU1DetFzAlm, AHU1DetFz, AHU1Llmt, AHU1Fz...and so on...
This is one example, but I'm sure we all could spend time walking through the scheme I've been provided (which I believe to be the latest incarnation) and find our own versions of the issue I'm trying to convey above. My perceived issues could be due to my naivety of the process of how this convention was developed or because nobody has told me precisely how to use it to avoid issues. But I suppose the question I would pose would be whether or not the structure of A/B/C/D/E with A being "System/Location", B being "Device/Service", C being "Action/Measurment, and D and E being "Attribute/Property/Parameter" 1 and 2, is actually the best way to structure this naming process, especially if there is no documented procedure for engineers to use when walking through the naming process.
|A||System / Location||B||Device / Service||C||Action/Measurement||D||Attribute/Property/Parameter 1||E||Attribute/Property/Parameter 2|
You might be able to write up something for this. Or present a comprehensive listing of all possible points (with the exception of the equipment tag, which is always unique) in a drop down - though this would also provide too much flexibility (in my mind) for people to select the wrong thing from time to time (though this could be alleviated some with a description next to the point name). For example, the engineer knows the tag (AHU1) will precede the only option in the dropdown of "LlmtAlm [Description: low limit alarm (e.g. a low limit switch/freezestat, typically found in an air handler.)". Or perhaps you could have a wizard tool where one uses radio buttons to select the intended point and it spits out only 1 point name to use for you.
Perhaps I'm making out mountain out of a molehill here but I worry about presenting something as fully baked when there might be potential issues at play. Can we really take advantage of a convention in terms of using software widgets for efficiency (such as a few of those I saw demonstrated by Jeff Morton, Mike Bottens, and others at the FrontlineExchange 2014 events) if we cannot guarantee that these points are only created in one precise format. Perhaps if I was given accompanying instructions with the SEBA Excel table to ensure consistent usage I would have more confidence in the way I'm trying to use it. And perhaps there are some of you out there that have established a way of using the convention that we all could latch onto - Steve Joanis, you say your group is using this convention? Are you having to make a few of these judgement calls on naming from time to time? Perhaps the decisions you've already made with regards to this could be latched onto by the rest of us elsewhere.
I just want to make sure that we're addressing these issues now before we all plunge into using this in different ways. I know up here in Chicago we haven't used it at all. This is partly because no one has shown us precisely how to use it, because when we saw point names in D360 they didn't appear to be consistent with the Excel file that's been shared, and probably most significantly, because the vast majority of our work occurs on existing sites where a naming convention already exists - so it hasn't been a pressing issue. So if I missing something here please let me know or if I can help ensure that globally we are consistently using these conventions the way they're intended, I'm more than willing to lend a hand.
Posted: 2016-04-14 11:04 AM
http://SEBA.ENESystems.com has been updated with the latest list of SEBA names from Schneider's list. This update brings our list of tag names to 1,232 tag names.
We have added many new tag names, for all those putting in new names into the http://SEBA.ENESystems.com database, thank you.
http://SEBA.ENESystems.com is open to anyone to use. If you'd like to add names (which will be sent to Schneider via Lonnie Caroon eventually), please register on the site.