02 / ECRT / ENERGY SYSTEMS
Modernising the tools
behind energy sites.
I helped modernise ECRT, an application for consulting and configuring energy sites. My work connected measurement histories, graphical site views, and document management across the interface, backend, and database.
THE PROJECT IN CONTEXT
From a sensor on site to a decision on screen.
I worked on the web application within CRT, the regional system that collects and supervises energy-site data. ECRT gives people a way to consult that information and configure their sites. My work sat between those everyday tasks and the services that make them possible.
- 01
On site
Meters, sensors, and controllers produce readings from an energy installation.
- 02
In CRT
Acquisition and application services collect those readings and support supervision.
- 03
In ECRT
Users consult measurements; configurators manage site equipment, data, and graphical views.
New capabilities. Existing data to protect.
I joined a large, established system moving configuration features from a legacy application into ECRT. The challenge was to introduce a new way of working while preserving site data already in use. A screen could look correct and still be wrong if its saved model, permissions, or historical data no longer matched.
Three connected areas of the product.
I worked across measurement histories, graphical modelling, and file management. I contributed heavily to the overall design of graphical modelling and led the technical design of the reusable file manager. I then carried those designs through Angular, Java/Spring services, FastGet reads, Oracle migrations, and tests.
A view is only saved when every part agrees.
I built the save operation around the complete view the user sees. The backend compares it with the stored version, checks site ownership and references, and applies the changes in one Oracle transaction. If a step fails, the whole save rolls back. That keeps the visual model and its underlying data together.
Measurement histories people can act on
I developed exports, imports with line-by-line error reports, and workflows for missing measurements. I kept selected dates, values, and identifiers consistent from the screen to the final file or backend operation.
Site views with a durable data model
I helped define the new graphical model and built much of its write API: view creation, properties, visibility, ordering, and deletion. I migrated existing structures and updated the read path so the interface could reconstruct the saved view.
One file manager, several contexts
I redesigned a context-specific modal into a reusable manager for site configuration, system screens, and graphical modelling. I preserved existing integrations while separating shared behaviour from each screen’s context.
Permissions enforced beyond the screen
I aligned interface permissions with read-service and backend checks. Before modifying or downloading a file, the service verifies its stored library scope instead of trusting a value supplied by the browser.
An import error should tell you what to fix.
When users import a file of historical measurements, some rows may be rejected. I worked on making those failures useful inside the import workflow.
Validate the incoming rows
I aligned import contracts, date formats, and backend validation with the data being received.
Return an actionable report
I connected rejected rows to their error causes, giving users a precise explanation of what needs correction.
Bring the result back to the screen
I surfaced that report in Angular so users could understand the import result without having to interpret a backend exception.
How I checked the work
I used unit, controller, and integration tests across the affected layers. For graphical views, I checked the complete path from migration and transactional writes through FastGet reads to the Angular display, including rollback and permission scenarios.
Load a saved view
The usage service and FastGet retrieve the model for Angular to display.
Save a change
The command service validates the model and commits the changes together.
I worked across these layers to keep changes consistent from the graphical workspace to the database.
What I delivered.
I delivered changes across three substantial areas of ECRT, including data migrations and the services behind the interface. My contribution covered both the design of new behaviour and its integration into an existing system: the data had to migrate, save, reload, and appear correctly for the right user.
I’m always happy to talk through the engineering. Let’s talk