One interface where engineers enter and review industrial asset integrity data, manually recorded and automatically streamed alike, define their own calculated metrics, watch live sensor trends, and act on alerts, without waiting on a backend release for every change.
Drawn from the application's architectural knowledge-transfer documentation. It covers the front-end application layer; the client's name, product name and internal identifiers have been redacted or generalized.
Eight feature modules behind a single /home shell, sharing one auth, state and HTTP convention.
Six NgRx feature stores provided on the route definition, created fresh on every visit.
Engineers author, test and deploy their own calculated tags without a platform release.
Unauthorized elements are removed from the DOM, not merely disabled.
The client operates across marine classification, certification and engineering assurance for industrial assets. Its platform gives engineering and operations teams a way to monitor the integrity of physical assets over time.
This application is the single-page frontend that sits at the front of that platform: where engineers record measurements, watch tag data, define their own metrics and respond to alerts.
Physical industrial assets whose integrity is tracked over time.
Recording measurements, watching tag data, defining metrics and responding to alerts.
Some measurements come in as live tag streams; others are recorded by hand or uploaded in bulk from a CSV. Both had to feed the same Item of Work records and the same historical view, through one consistent entry point.
Standard tags do not cover every asset's needs. Engineers needed to define their own calculated tags, as real logic expressed in Python, test them, and put them live without waiting on a platform deployment.
Real-time tag values and paginated historical data had to coexist without either one blocking or overwhelming the interface.
With eight feature areas and multiple tenants, a user's access needed to be enforced by role and feature permission, not by which links happened to be visible.
How do engineers capture manual and automated measurement data through one consistent interface, single record or bulk upload alike?
How do engineers define and safely deploy their own calculated tags, as real Python logic, without a full platform release?
How is real-time tag monitoring delivered alongside historical trend analysis, in the same workspace, without either one degrading the other?
How is access controlled precisely enough that a user only ever sees the assets and features their role actually permits?
Standalone, lazy-loaded modules behind a shared shell, each answering one of the four questions.
Everything else, from KPI dashboards and alert management to embedded Power BI reporting, sits alongside these four as peer feature modules behind the same shell, sharing the same auth, state and HTTP conventions.
Sign-in dispatches through a custom authentication library wrapping Azure AD B2C, and the resulting bearer token is attached to every outbound call by a dedicated interceptor.
Feature modules are lazy-loaded under a single /home shell that hosts the toolbar, side navigation and router outlet. It is the one part of the application still built as a traditional NgModule, because it is the shell every other route mounts into.
Switching the active asset in the toolbar resets feature state application-wide, so no screen can show stale data for the wrong asset.
Provided only while the feature's route is active.
Persist across the whole session.
As documented in the application's own architectural reference.
These practices are as described in the project's architectural knowledge-transfer documentation. This case study is based on that reference rather than an independent code-level security review.
The documented verification workflow covers unit testing and static analysis, and this section says plainly where that documentation stops.
Karma-based unit tests via ng test, and ESLint checks via ng lint, with Husky enforcing lint checks at pre-commit time.
Coverage thresholds, integration testing and end-to-end testing strategy are not described in the reviewed documentation.
Three environment configurations are defined, each with its own configuration file and gateway target, built through Angular's standard environment file-replacement mechanism.
CI/CD pipeline details, hosting infrastructure and release process sit outside this application-layer documentation.
Outcomes here are architectural and capability-based. No adoption, performance or business-impact figures are available in the source documentation.
One interface for asset integrity data that arrives in every form, hand-entered, bulk-uploaded or streamed live, with the controls to let engineers define their own metrics safely.