A Cloud In TheSky

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
==== Niagara ====

The best informations source on the internet for Niagra related questions, will always be Tridiums official [[https://www.niagara-community.com/Login|Niagara Community]]
- 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. 

==== 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 (1 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~~
A Cloud In TheSky

User Tools

Site Tools

Page Tools
