Print Friendly, PDF & Email

What is Tridium Part 2

In my earlier article, I went through a level review of Tridium. Much to my surprise that what is Tridium article became one of my most read articles and I continue to get e-mails asking me for greater detail.

A few of the questions I receive are:

  • How does a JACE really work?
  • What are the pros and cons of a platform sold through VAR’s(Value Added Resellers)?
  • What do I need to know if I am looking into Tridium as an offering?

All of these are good and pertinent questions. As I mentioned in my earlier article Tridium exists as a middleware BAS platform that provides the ability to connect to other systems via API’s (Application Programming Interfaces).

A contractor can effectively go to a competitors site, install a Tridium Jace, register the correct API/module and begin to interact with their systems. There are pro’s and con’s to any integration approach and Tridium is no different. In order for you to truly understand what Tridium can and cannot do we need to dig a little deeper into the technology itself.

High-Level Niagara Video Overview

How JACE’s process data

As I mentioned in my earlier article a JACE is a Java Application Control Engine. The JACE is a piece of hardware that is running a Java VM (Virtual Machine) to create a graphical user interface (GUI) from which the client can interact with their connected systems.

While the name JACE has become synonymous with Tridium a JACE is not unique to Tridium. Many companies use a Java Application Control Engine as their supervisors. However, what is unique is how the Tridium AX framework goes about communicating between JACE’s.

Once a JACE is installed and the proper driver (a driver is a module that takes the API based data and converts it to work within the JACE Java Virtual Machine) is purchased the programmer will map objects from a third-party system into the JACE. The JACE will then allow the user to discover and map devices/objects into the JACE (station).

If all this seems a bit confusing take a look at the drawing below to understand how the Module works

Tridium Architecture

How do the API’s work

The API’s are based upon the BAJA specification. BAJA stands for Building Automation Java Architecture. Niagara is a proprietary implementation of BAJA specification that builds upon the BAJA specification. The API’s that exist are packaged inside modules that use XML schemas to convert objects from one protocol to the Niagara protocol. These object types then are built into a variety of Tridium objects.

To make a complex topic simple. Think of languages, anyone with the proper training (API) can understand a language. Tridium’s modules take that language and convert the language into Niagara objects. These objects then allow the JACE to use the proprietary Fox protocol to communicate data around the object to other JACE’s. This is why if the JACE does not have the module for your protocol installed you typically cannot discover it.

Now What?

Now that the JACE database has the proper module installed it can collect data from various systems. Once this data is collected your Tridium programmer will set up the database and graphics using the configuration software called Workbench. Workbench will connect to a station and depending on the NICS (Niagara Information Conformance Statement) will be able to configure the JACE.

Tridium’s platform allows for many plugin modules to be developed and marketed to Tridium customers. Based upon the memory and physical input limitations within your JACE you can purchase a variety of integration modules for your system.

What is Vendor Locking

I had mentioned before about the NICS. This document allows vendors to perform what is called vendor locking. This is one of the areas of concern around Tridium. If a vendor so desires they can set up the JACE so that only their company can utilize workbench to configure and program the JACE’s. This can be easily avoided by specifying that vendors provide open NICS, the workbench software, and all associated programming code.

Rather than going deeper into  NICS I have included a link to a Tridium White Paper Here

Things to consider when designing a Tridium system

First, you must understand if Tridium is right for you if you already have a system that is predominately one vendor it does not make sense to switch controls in most cases due to the following reasons:

  • Stocking Part for Multiple Control Systems
  • Head-End Conflict (two different control platforms fighting against one another)
  • Single Source Service
  • Requirements for new Learning and Procedures

If however, you are a single building or looking to merge multiple systems Tridium is one choice, among many, that you have. Your first step is to identify all the controls protocols that you need to integrate. Typically your contractor can do this for you but I suggest you do it yourself to avoid scope bloat and price gouging.

Next, you need to create a logical/physical topology drawing of where your different systems are and what they are. Once you know what mediums and protocols (Ethernet, Siemens P Bus, JCI N2, etc ) you have between your devices you will be able to design your data flow.

Finally, you need to understand the costs of service and implementation. If you have a mainly BACnet system it is feasible that you could use a Tridium product because you can purchase Tridium based field controllers that will be like for like replacements.

However, if you have a proprietary Alerton IBEX trunk you may want to consider the costs of having to service the field controllers, in this case, it would be wise to pursue an Alerton integration due to their expertise with IBEX systems.

So What?

The point I am making here is just because you can integrate does not mean you necessarily should integrate. In many cases having a single headend sounds awesome.

That is until your team has to service all the field controllers and can no longer do it remotely because the new head end does not support pass-through configuration. Now all of your technicians have to physically visit controllers to repair/reprogram, as a manager with P&L responsibility you have to ask yourself can I afford to have my technicians running around to each field device?

If you decide to select a Tridium system you now must size your controller properly. The JACE relies on memory for plugins and objects different JACE’s support different device counts and feature sets. It is recommended that you not only look at the cost of plugins and hardware when you are designing your system but that you look at the cost of service also.

Finally, you must ask yourself

“If my integrator is discovering another vendors product can my integrator also adequately service those systems?”

(This is a point to call out very clearly in a specification).

Are you struggling with Niagara?

If you find learning Niagara difficult and the idea of shelling out $2,000 to $3,000 dollars to attend a certification class seems like too much then you need to enroll in our Niagara Basics course. Niagara Basics is an on-demand video training course that guides you through the most common Niagara tasks! Click on the image below to learn more.

Enroll in Niagara Basics


Well, this is the end of my Tridium series. After reading this you should have a working knowledge of Tridium and be able to understand basic terms like JACE, Station, API, NICS, etc when you are having a conversation.

I would appreciate your opinion on what else you would like to know about Tridium contact me here and let me know.

Knowledge around Tridium is quite elusive as much of their documentation is not publicly shared so the knowledge base tends to reside within the installers and vendors which leaves customers at a disadvantage. Hopefully, after reading this you are now more aware of how Tridium works.