BComponent design
Native BComponents and BServices that appear in your palette like any standard component — with lower CPU use than complex, nested wire-sheet logic.
Key capability: Custom slot-based logic and type-safe properties
Beyond the wire sheet
Custom Niagara 4 modules and drivers, engineered in native Java
We extend the Baja runtime with custom Java modules. When the standard palette creates bottlenecks, we engineer compiled components sized for JACE and Supervisor environments.
@NiagaraType
@NiagaraProperty(name = "status", type = "BStatus",
defaultValue = "BStatus.ok")
public class BFiabtecService extends BAbstractService {
public void doProcess() {
// Compiled logic, sized for JACE hardware
}
}What we build
Components that live in your palette
Driver architecture
Master and slave drivers built on the Niagara driver framework. We handle low-level serial and IP communication and normalise the data into standard points.
Key capability: Message queuing and optimised poll engines
Web & UX widgets
HTML5 and JavaScript interface components that integrate with the Niagara web server through the HX and UX frameworks.
Key capability: Responsive D3.js and Vue.js dashboard integration
Choosing the right tool
Wire sheet or native module?
The wire sheet is the right place for most station logic. A compiled module earns its place when logic is reused widely, runs on constrained hardware, or is valuable in its own right. Read our full guide.
| Wire-sheet logic | Native Java module | |
|---|---|---|
| Best for | Site-specific sequences a technician will adjust | Logic reused across many points, stations or sites |
| Runtime cost | Every block is a component with its own overhead; deep nesting adds up on embedded hardware | Compiled code; one component can replace dozens of blocks |
| Making changes | Edited live in Workbench | Versioned releases, tested before deployment |
| Your IP | Visible and copyable in any station backup | Delivered as a compiled, signed module |
| Skills to maintain | Workbench and Niagara configuration | Java and the Niagara developer framework |
Why native Java?
Faster stations, protected logic, room to grow
A well-designed module exposes the settings technicians need as ordinary properties, so the site stays adjustable — without anyone editing the underlying logic by accident.
- Resource optimisationNative code runs efficiently on embedded JACE hardware, avoiding the memory and CPU cost of over-extended standard logic.
- Intellectual property protectionCompiled modules protect your algorithms far better than open wire sheets.
- ScalabilityManage thousands of points across distributed systems with centralised custom services and global tags.
Process
Our Niagara 4 development lifecycle
From protocol analysis to a signed module running on your hardware.
Baja discovery
We audit the station, find where the palette or protocol support falls short, and agree the component’s properties, actions and behaviour.
Java module coding
Native Java against the Niagara developer framework, with versioned source and repeatable builds.
Signed packaging
Modules are built and code-signed, so the station can verify exactly what it is running.
Workbench testing
Load and soak tests in Workbench and on representative JACE hardware before commissioning.
Deliverables
What you receive
Every engagement ends with assets you own and can maintain.
Signed modules
Code-signed builds compatible with Niagara 4 module signing requirements.
Engineering docs
Palette guides, point schemas and commissioning notes for your technicians.
Test reports
Load and soak test results from Workbench and target JACE hardware.
Upgrade path
Versioned releases maintained across Niagara maintenance builds.
Frequently asked questions
Which Niagara versions do you support?
We develop and test against current Niagara 4 releases and maintain compatibility across maintenance builds. Legacy AX migrations are handled as part of an upgrade engagement.
Who owns the intellectual property?
You do. Source code, build scripts and documentation are delivered under terms agreed in the contract — including source escrow if your procurement requires it.
Will a custom module strain my JACE?
The opposite is the goal: compiled Java replaces sprawling wire-sheet logic, typically reducing CPU and memory load. Every release is soak-tested on representative hardware first.
Can you extend modules from other vendors?
Where licensing permits, yes. Otherwise we engineer a clean-room equivalent against the protocol or API itself, so you are never locked to an unsupported binary.
What do you need from us to give an estimate?
Your Niagara version, what the module needs to do, the target hardware (JACE model or Supervisor), and any protocol or API documentation you have. From that, the discovery phase produces a fixed estimate before development begins.
Related
Service
System Integration
Custom drivers for legacy, industrial and cloud protocols — engineered, tested and secured.
Explainer
Niagara Explained
How stations, JACEs and Supervisors fit together — with a glossary of the terms you’ll meet.
Software development
Wire sheet or custom module?
The wire sheet is the right tool for most station logic. Here is how to recognise the cases where a compiled Niagara 4 module is faster, safer and cheaper to maintain — and the cases where it isn’t.
Need a component the palette doesn’t have?
Describe your station, protocol or data challenge — an engineer replies within 24 hours.