Niagara 4 rewards candidates who can separate its layers: the platform layer manages a host — licensing, backups, certificates, station start and stop — while the station layer runs components, points, schedules, alarms, and histories. Study plans built only around clicking through a palette tend to blur these layers, and scenario-style questions punish that blur. This guide teaches the component model, tags, drivers, data storage, and the security model through named concepts, two worked decision scenarios, a sandbox exercise with a self-check rubric, and a preparation sequence you can adapt to your own schedule and available software.
Platform versus station: which layer owns each task
The platform layer manages the host — station start/stop, licenses, backups, certificates — while the station is the runtime holding components, points, schedules, alarms, and histories. Decide ownership before acting.
On a JACE or supervisor, a platform service runs continuously and exposes Platform Administration in Workbench. From there you commission the device, install or review licenses, manage certificates, restart the host, and take a full backup archive. The station is a separate process you start from the platform; it loads the component tree, opens drivers, and begins executing logic. When Workbench reports it cannot connect, first identify which of the two endpoints you were addressing.
Worked scenario: a technician must update logic on a remote field controller and refresh its license. The mistake is connecting to the station, editing the wire sheet, then hunting station-side menus for license tools and stopping the station process expecting them to appear. The better decision is to edit and save inside the station, then reconnect to Platform Administration, where licensing and backups belong. Why it matters: the platform can be healthy while a station is stopped and vice versa, so diagnosing the wrong layer wastes a site visit and leaves changes unverified.
| Task | Where it belongs | Why |
|---|---|---|
| Stop or restart a station process | Platform Administration | The platform controls the station process on the host |
| Edit control logic | Station wire sheets | Logic executes inside the running station |
| Install or review a license | Platform | Licenses are host-level records |
| Full device backup | Platform backup archive | Carries station databases, files, and license together |
| Create a tag on a point | Station | Tags are station metadata |
| Manage certificates and trust | Platform | Host trust material lives outside the station |
Components, slots, and tags: how Niagara 4 organizes data
Every Niagara item is a Baja component — a container or point with typed slots. Tags are searchable metadata you attach to components, independent of where they sit in the station tree.
Open any station and the tree reads station, services, drivers, devices, points — but each node is the same kind of object: a component with a type, named slots, and a property sheet. Wire sheets let you link slots between components, for example a schedule's output into a setpoint, and a Program object adds scripted logic where point links fall short. Reading an unfamiliar station therefore means reading types and slot names, not just the folder structure.
Tags work differently from hierarchy: you define them in a tag dictionary with types and allowed values, apply them to components, then search across the station or a connected network. A chiller point buried three levels deep becomes findable by a query on equipType. When a scenario asks how to make points discoverable by building system without reshuffling the tree, the expected answer is a dictionary and tagging plan — not moving components. Hierarchy expresses structure; tags express searchable meaning, and mature designs use both deliberately.
Making device integrations behave: drivers, discovery, and point bindings
Drivers translate field protocols such as BACnet and Modbus into Niagara components. Discovery builds device components, and each point extension binds a Niagara point to a protocol address with a defined read or write behavior.
For a BACnet network, the driver discovers devices and their objects, and you select which objects become Niagara points; writable objects such as setpoints get writable points, while sensor values stay read-only. You then choose how values refresh — polling at an interval versus subscribing to change-of-value — trading network load against responsiveness. A plausible mistake is discovering everything at once: a large unfiltered point list inflates the station and slows it down, when a deliberate point list would cover the work.
Modbus points show why slot settings matter: one register can represent different data types and byte orders, so a temperature read as an integer instead of a scaled float displays wrong values even though the link appears to work. The better decision is to verify each point against the device's register map — address, function, data type, scaling — before trusting it. Why it matters: drivers pass through whatever the configuration says; the driver does not correct a wrong assumption about the field device, and a bad binding quietly corrupts trends and alarms downstream.
Histories, alarms, and schedules: where data actually lives
History records, alarm records, and audit records persist in station databases, separate from the logic export. A .bog file carries structure, not data; a platform backup carries both structure and data.
When you export a .bog from a station you capture the component tree, wire sheets, and tags — a portable logic snapshot. You do not capture trend logs, alarm records, or host-level settings, because those live in the station's databases and the platform layer. Schedules fit this pattern too: a schedule is a component whose output changes with configured time ranges, so it travels in the .bog, but past history records are not part of that file at all.
Worked scenario: an integrator replaces a supervisor and must preserve years of tenant energy history. The mistake is exporting the .bog from the old station, importing it into the new one, and declaring the migration complete — the trend data never moved. The better decision is to take a full platform backup and restore it on the replacement, or to export histories explicitly and import them into the new station. Why it matters: logic recreates behavior while history recreates evidence, and treating one as a substitute for the other destroys the record the customer paid to keep.
The security model: roles, permission schemes, and certificate-based trust
Niagara 4 secures stations with named users, roles, and permission schemes applied at component level, and it uses certificate-based trust for connections. Design permissions around least privilege per audience.
A role groups permissions; a permission scheme maps actions such as read, write, invoke, and alter onto components, and you assign roles so an operator can view one building's points but not modify enterprise logic. Users and their assignments export with the station, making them part of your design rather than an afterthought. A scenario describing a contractor who needs trend access only is testing whether you scope a narrow role and scheme instead of granting an administrator-level account.
The second half is transport and host trust: the platform manages certificates, and connections between Workbench, stations, and other stations rely on that trust rather than on shared passwords alone. In a scenario where a field controller accepts connections from an unknown client, the better decision is to review platform-level certificate and connection settings before blaming station permissions. Why it matters: user permissions control what an authenticated session may do; platform trust controls who may authenticate at all, and the two diagnostics point to different fixes.
A sandbox exercise with a self-check rubric
Build a sandbox station with a simulated device, tag it, add a schedule and an alarm, then back up and restore. Score yourself against the rubric below before moving on.
Use your training software's demo licensing and a sandbox host — never production hardware. Create a blank station, add a driver, and use its simulator or a test device to create about ten points. Apply dictionary tags such as building, equipType, and pointType, wire a schedule into a setpoint, and configure an alarm on one point with a recipient. Finish by taking a platform backup and restoring it into a second, separate station.
Run the exercise twice: once with notes open, once with everything closed. The differences you notice — which menus live under Platform versus the station, which dialog edits the tag dictionary, what the backup archive actually names — are exactly the recall that scenario-style questions reward. Log observations after each pass; if the second pass feels identical to the first, you are rehearsing clicks rather than decisions, so change the device type or the permission setup in your next pass.
- Correctly started and stopped the station from Platform Administration, not by forcing the process down.
- Created a deliberate point list whose read/write behavior matches the simulated device, including one writable and one read-only point.
- A tag query returns exactly the intended points; dictionary edits show up in search results.
- The schedule output drives the setpoint, and the alarm fires on the configured condition and reaches its recipient.
- The restored second station carries logic and data intact — and you can explain why a .bog export alone would not have carried histories.
An adaptable preparation sequence and concrete readiness checks
Sequence your study as: layers and architecture, a hands-on build, drivers and tags, data and security, then timed scenario review. Readiness means explaining every decision aloud, not finishing quickly.
A realistic, adaptable sequence: one block on platform-versus-station and the component model, using the Section 1 table as your notes; two or three blocks building and rebuilding the Section 6 exercise on different drivers; one block on histories, alarms, and backups using the migration scenario as your template; one block on roles, schemes, and certificates; and a final block working scenario questions aloud, naming the layer before naming the action. Scale block length to your available schedule rather than to a fixed calendar.
For administrative facts such as current versions, training availability, and certification administration, treat Tridium's own site as the reference rather than memorizing third-party summaries — the product line keeps moving, and the concepts above stay stable across 4.x releases. Readiness checks below are learning milestones for your own tracking, not predictions of any exam outcome.
- You can state, for any given task, which layer owns it and why the other layer is the wrong place to act.
- You can rebuild the sandbox station from a blank file with notes closed, in one pass, on a different driver.
- You can explain what a .bog carries versus what a platform backup carries, using the history-migration example.
- You can design a role and permission scheme for a limited-access user and describe what that user still cannot do.
- You meet your target on the Section 6 rubric twice in a row with different devices or permissions.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.