User Tools

Site Tools


c_niagara:headpage

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
c_niagara:headpage [2022/02/24 20:27] mkc_niagara:headpage [2022/02/25 22:17] (current) mk
Line 4: Line 4:
 - Remember to use the search button before asking any questions, and that although an answer might be 5 years old, many basic functions remains the same today.  - Remember to use the search button before asking any questions, and that although an answer might be 5 years old, many basic functions remains the same today. 
  
-==== Test 1 ====+==== Introduction and brief overview ==== 
 + 
 +So, what is this Niagara Framework (Framework), I keep talking about, you might ask? 
 + 
 +Basically it's a computer system (Framework), that can be run in a windows PC (Supervisor/server) or a unix based controller, and is programmed primarily from a Windows PC (Workbench). 
 +Niagara is maintained and developed by [[https://www.tridium.com/us/en|Tridum]], owned by Honeywell International. 
 +[[https://www.centraline.com/enGB/centraline-integrated-building-management.html|Centraline]] and [[https://buildings.honeywell.com/gb/en/brands/our-brands/trend-controls|Trend Control Systems]] are both using the Niagara framework. 
 + 
 +Niagara has in my opinion 4 primary functions: 
 +  * First, controlling output and input points (IO), which in turn can control all kind of actuators, motors or sensors. 
 +  * Second, integration of pretty much any network (Driver) or system you can imagine. My personal favorites being Bacnet, Modbus. But can also do more exotic things like MQTT. 
 +  * Freely programmable using functions blocks or java code. 
 +  * Presentations from a webserver (Any framework installation contains build in web server) 
 + 
 +==== Licensing ==== 
 +Licensing is working really well in the framework. 
 +The standard method is using "The" licensing server, it contains licenses for both technician workbench, supervisor or controllers. 
 +Any installation of the framework generates a Host ID, any licensing is bound to this Host ID. 
 + 
 +=== Workbench license === 
 +Normally your company would create a partnership with the preferred system provider, which offers training courses and after this, the technician can obtain a license for a workbench PC. Both partnership and workbench license would be an annual-fee-type-of-deal. 
 +A technician license is "unlimited" for programming, and testing purposes. But if using exotic drivers in developing, might require an extra license for the driver. 
 + 
 +=== Supervisor license === 
 +Installing the workbench program on a windows pc, obtaining the Host ID and ordering a license from the system provider, turns the PC into a supervisor/server. 
 +A supervisor license also contains an amount of points, each hardware or driver point can count towards the limit. Programming points isn't counted. 
 + 
 +=== Controller licenses === 
 +Controllers of a specific provider is primarily based on the same processing unit, what matters is how many points you order with it. 
 +It comes with a pre ordered amount of points, usually cheaper then buying points afterwards. 
 +But here you get the Host ID from controller, and use it to order extra points if needed, after purchase, the extra license is fetched from the licensing server. 
 +Points in controllers don't count on supervisors too, you only pay once! 
 + 
 +Common for all customer licenses is that after purchase, it is bound to that specific Host Id. I've never seen a license being moved. 
 +Workbench license can be moved to a new PC, but it's not something you do for fun. 
 + 
 +==== System overview ==== 
 + 
 +A typical office customer setup would be comprised of the following: 
 + 
 +  * Supervisor (PC or Controller) 
 +  * Main controllers (pr floor typically) 
 +  * IO Room controllers connected to main controllers (1 pr 1-2 room) 
 +  * Airhandling unit with integrated controller connected to supervisor or main controller 
 +  * Airhandling unit with direct IO controllers from a main controller or dedicated controller. 
 +  * Any integration from light or other, connected to main controller or supervisor. 
 + 
 +All network connections is preferred to be TCP/IP but serial 2 wire connections is widely used too. 
 + 
 +Best practice is to keep as much programming and calendars as local as possible. Meaning, if you can keep a 0 point supervisor, it's preferred. 
 +Also, direct signal transfer from controller to controller is preferred. 
 +This way, if supervisor restarts, controllers keep running their programs. 
 + 
 +The supervisor is then used for collecting alarms, history data and proxy points from controllers, to present on a website. 
 + 
 +{{:c_niagara:pasted:20220225-213456.png}} 
 + 
 +==== Framework breakdown ==== 
 + 
 +Framework runs as a 2 part deal, a platform and a station. 
 + 
 +=== Platform === 
 +The platform is running either on a unix based controller or windows based PC, and can best be compared to "a firmware"
 +It contains settings for TCP/IP and licensing. 
 +It also contains systems to copy stations and control start/stop of these. 
 + 
 +== Platform tree structure example == 
 +See below image of a standard platform setup 
 +{{ :c_niagara:pasted:20220225-214956.png |}} 
 + 
 +=== Station === 
 + 
 +It's where all the magic happens! 
 +It it build up like a tree structure. 
 +First comes  
 + 
 +  * Alarms 
 +  * Config 
 +  * Files 
 +  * Hierarchy 
 +  * History 
 + 
 +== Alarms == 
 +Shortcut to alarm section, with views and database maintenance. 
 + 
 +== Config == 
 +Where all primary programming is located, it also contains Services, Drivers and Apps. 
 + 
 +  Services 
 +  Contains alarm handling, user services, web and the internally used fox servers  
 +  and other primary backend systems.  
 +  If you want a primary function to work, this is where to locate and install it. 
 + 
 +  Drivers 
 +  Contains programming part of the station, including Bacnet and Modbus drivers,  
 +  but this is also where you create your programming,  
 +  in separate folders or directly inside the drivers network. 
 +  A folder contains multiple view options like property sheet or wire sheet. 
 +  They also supports a custom view (Px view), meaning to show website animations. 
 + 
 +  Apps 
 +  I actually don't know what this is for? 
 + 
 +== Files == 
 +Is the local file storage, it contains images, px files (website animations) or other files used. 
 + 
 +== Hierarchy == 
 +One of the newer functions, used to dynamically build a tree structure for your site, and to allow easier navigation. 
 +In my opinion it's not "completely there yet" and I look forward to new updates and features for this part. 
 +The hierarchy is build using tags on folders and points, they can be direct or implied. 
 +What is needed to make it really nice is implied relations and better interaction with objects. 
 + 
 +== History == 
 +Contains all your history files and the ability to run database maintenance. 
 + 
 +== Station tree structure example == 
 +{{:c_niagara:pasted:20220225-221554.png}} 
 + 
 +==== Workbench breakdown ==== 
 + 
 +\\ 
 +\\ 
 +\\ 
 +\\ 
 +\\
  
 ~~DISCUSSION~~ ~~DISCUSSION~~
c_niagara/headpage.1645730867.txt.gz · Last modified: 2022/02/24 20:27 by mk