Print Friendly, PDF & Email

What is Tridium Part 1

I’m proud to say that for several months now this post is the number 2 result on Google Search for “What is Tridium”. So if you are landing here for the first time, first off welcome!

The post below is 2 part series that seeks to provide an overview of what Tridium is and what Tridium isn’t. At the end of this article, I will provide you some related articles and a chance to learn more about building automation.

So what is Tridium?

Tridium is the latest buzz word in the Building Automation Industry.

There are three driving factors behind the adoption of Tridium:

  1. A large amount of third-party integration drivers
  2. A distributor model that provides open availability of the product
  3. A SDK that allows developers to customize their own integrations

Tridium is built on Niagara AX (or N4 as Tridium is calling the new platform) which is a proprietary framework.

Tridium itself is the brand name for the product built upon the AX framework. A typical Tridium device is comprised of several open and proprietary protocols provided on a scalable platform from which building operators can design their automation systems. This device called a JACE will be covered in greater detail later.

Tridium is typically delivered through smaller contracting outfits as a secondary product for the larger controls contractors (examples would be Siemens Talon, Johnson Controls Facility Explorer).

However, some companies have thoroughly embraced Tridium as their sole product. As of now there are three main Tridium brands in the market these brands are Vykon, Honeywell Webs, and Johnson Controls Facility Explorer. (Author’s note, yes I know there are more systems, but I picked the top three for the sake of my fingers).

As I said earlier Tridium is  built on the Niagara AX framework. Prior to AX Tridium was built on the R2 Framework. Thus when someone tells you they have a Tridium R2 system they are referring to the framework on which their platform is built.

There are four key parts to the Tridium offering :

  • Niagara AX Architecture
  • Niagara Structures
  • Niagara Protocols
  • Niagara Platforms

Niagara AX Architecture

 WIT1

Niagara Software Stack

If you have followed my other posts you will recall that both the TCP/IP and OSI Layer consist of Protocol stacks. Tridium AX as a framework is no different.

The Tridium architecture is built around a series of software layers that contain protocols, functions, and transmission mediums. For those who are familiar with the Top-Down OSI model layer the Tridium AX software stack may look a little disjointed.

However, I assure you the data flow is built along OSI model standards and Tridium software functions just like any other protocol stack.

Niagara AX Structures

 WIT2

Bringing integration through embedded programming.

The Tridium Architecture is built around four key structures which each contain their own protocols and processes. These four structures are:

  1. Station– The station is a Java VM (or Virtual Machine) that runs the Niagara AX application. This is one of the reasons Tridium is so liked. Because of the station framework users can run graphics and development applications through the station rather then needing additional software (usually).
  2. Workbench– This is the engineering tool from which the database is developed, API’s (more on these later) are deployed, and various other engineering actions are conducted.
  3. Daemon– The Daemon processes or as I call them VM background services. Is the functionality to run the background processes that a user does not need to see but are vital for  the station to function. If you are a geek like me and you want to know more about Java Daemons, you can read about them here and here.
  4. Web Browser– Ok, if you don’t know what a web browser is then I honestly do not know how you got to my site. That being said, for those of you whose computer mystically ended up on my blog a web browser is a program that you use to access the data on the internet.In the case of Niagara AX the web browser allows the user to perform web service calls and writes via HTTP/HTTPS through the Tridium UI. One of the most common forms of this is the Web Workbench which allows operators to engineer systems directly from a web connection to their local or remote station.

Niagara AX Protocols

 WIT3

The Protocols of Tridium

Tridium through its API’s and Java VM supports a slew of protocols. This platform supports the typical web services protocols that you would expect to find in the TCP/IP stack. Tridium also supports most of the open protocols of the BAS sector such as Lon, BACnet, and Modbus.

These protocols are open but depending on the protocol users are charged a fee for the object licenses or API’s (drivers). Tridium  also has its own proprietary protocols, these are described below:

  • Fox Protocol- Fox protocol facilitates the communications between the stations and the workbench software. This is why when you go to integrate a Web server or a JACE you have to buy drivers that can communicate to your platform.
    Because Fox is utilized to communicate between devices without a driver third party systems cannot communicate to Tridium. Architecturally Fox sits at the top levels or application/transport levels of the TCP/IP Stack. Fox utilizes port 1911 to communicate with the fellow Tridium devices.
  • NiagarAd- NiagaraAd is the protocol for communication between workbench and daemon services. Whereas many competitive offerings utilize simple web services calls against XML data in their databases Tridium utilizes a proprietary protocol to call upon data.

Niagara AX Platforms

There are three main platforms from which the Tridium station collects and interfaces with the field devices. These devices are:

  • Tridium JACE’s (Java Application Control Engines)- The JACE is capable of being a standalone supervisory device and will host the station and damon processes. As of currently the workbench software cannot be embedded in a JACE.
WIT6

Breakout of a Tridium Jace

  • Tridium Supervisors- These devices go by many names, server, host, web supervisor but essentially the supervisor is the machine that is running the Station for the customers site. supervisors usually provided enhanced trending, graphics, and alarming. Additionally the supervisor is capable of hosting the Workbench software.
 WIT4

Tridium AX Software

  • Client- Not to be confused with a client server architecture the client is Tridiums way of saying the UI. The client allows the user to connect to the station via a web browser of via the Workbench software.
 WIT5

Example of the Tridium UI

 

Conclusion

Ok, so now you know a bit about Tridium. Before I tell you how to know more I want to know a bit about you. Something brought you here, you were hoping to learn a thing or two, maybe a make a decision on a system.

In the comments section below you can ask me those questions. Better yet if you’d like to talk to me directly you can contact me here.

Finally, if you found this article informative then I encourage you to become a subscriber. My subscribers are the first to receive notification of new articles and are a key voice in influencing what I write about here on Building Automation Monthly.

Like this Content? There's much more...

Join the BAM nation and gain access to BAM Nation only videos, templates, and checklists. Also get notified when I post new content and take advantage of subscriber only pre-sales on my products!

Powered by ConvertKit

In my next article in this series I will discuss the actual protocols that exist within the Niagara Framework with specific topics covering:

Thanks for stopping by,

-Phil

Pin It on Pinterest

Share This