Why did we build our own operating system in the browser?

If you go round a mid-sized industrial site and ask who works with which system, you rarely get a short answer.

Energy monitoring runs in a web interface. The process is controlled by a SCADA system. Maintenance lives in another program — or still in a spreadsheet. Purchasing works in the ERP. Alarms arrive by e-mail and by phone. And projects, contracts and attendance data have yet another tool of their own.

Each of these systems may work perfectly well, even excellently, in its own domain. The problem is not necessarily the systems themselves, but the gaps left between them.

Decisions get lost between systems

In earlier parts of the OT knowledge series we kept arriving at the same point: measured data has no value on its own. It becomes valuable when a deviation turns into an event, the event into a task, the task into completed work, and the work into a result that can be measured back.

Yet this chain almost never fits inside a single conventional specialist system.

The measurement originates in one. The decision is made in another. The work is recorded in a third. The spare part is ordered in a fourth, and the cost is booked in a fifth. At every handover someone has to copy, reconcile and remember — or forget something.

In such cases the company often does not suffer from a lack of data. Quite the opposite: the same information exists in five places, in five different states.

Which figure is current? Who changed it last? Was the intervention carried out? Has the problem really gone away? And who actually sees the whole process?

We did not want yet another standalone application

We did not want to answer this problem with another dashboard. Another standalone application would only have created one more island.

That is why we built OrigSmart WebOS: a shared operating environment, running in the browser, for both physical and business operations.

You could also put it this way: an “umbrella” over the company’s existing IT, energy and entire data-asset ecosystem. The specialist systems keep doing their own jobs, while WebOS brings the available data, users, decisions and executable processes together in a shared working environment.

This is not merely a common screen or menu system. Underneath, different systems can keep running; above them, a coherent company operation can be followed and managed. Connecting them naturally requires integration work: an application appearing on the same interface does not automatically make its data and processes shared.

The name “operating system” does not mean that we want to replace Windows or Linux. The analogy is about the operating model. Just as an operating system on a computer provides a common foundation for users, permissions, files, windows and applications, WebOS provides a common foundation for devices, data, people and business processes.

The user sees a familiar, window-based workspace. They can open side by side the energy data of a building, the related maintenance task, the supplier contract or the budget of a construction project. In connected processes they do not have to piece together the full picture manually from separate systems, nor enter the same data over and over again.

Why in the browser?

Because today the browser is available on practically every work device. No separate client program needs to be installed, updates can be managed centrally, and users reach the same working environment from their office computer, a shop-floor terminal or — depending on their permissions — a mobile device.

But the browser alone does not turn an application into an operating system. That takes a common data model connecting the different sources, unified permission management, real-time collaboration and applications that can be linked with one another.

What makes this more than just another piece of software?

Different data sources — a shared interpretation

Unified operation does not mean that all data has to be moved into a single database. Financial data can stay in the ERP, process states in SCADA, measurements in the energy system, and documents in the existing document repository.

The job of WebOS is to put these into a shared context. The asset ID in one system, the cost centre in another and the maintenance history in a third should all be linked to the same real piece of equipment. A customer, site, project or contract is then not a set of mutually independent records, but a common point of reference in operations.

Part of the integration is also defining which system is the authoritative source for which data, where it can be changed, and how the change reaches the related processes. Instead of keeping five separate copies in order by hand, you use one piece of information of defined, traceable origin in several places.

This is not merely a matter of convenience. A shared interpretation and clearly assigned data ownership reduce the operational errors that stem from diverging versions, manual copying and uncertain data sources.

Real-time collaboration

If two colleagues open the same document, record or budget item, each sees the other’s changes. The system handles concurrent work and prevents anyone from unknowingly overwriting someone else’s edit.

The same real-time operation also links people with the OT side. A new measurement, status change or alarm coming from a device can immediately appear in the application, and for the user, where there is something to be done about it.

Collaboration then does not mean exchanging e-mails and separate file versions, but working from the same current operating state.

Precisely controlled access

In a corporate environment it is not enough to determine whether someone has access to an application. Often it also matters which data they may see within it, and which field they may change.

In a construction project, for example, one person is entitled to decide on the client price, another may record the subcontractor’s quote, and yet another may approve the purchase. They can work on the same line item, with everyone reaching only the data and actions their role requires.

OrigSmart WebOS controls this down to field level. It is not just the interface hiding forbidden actions: permissions are also checked and enforced on the server side. An unauthorised change is rejected even if someone bypasses the interface and tries to call the WebOS back end directly.

Separate organisations, shared platform

Several companies, sites or customers can use the same platform while the organisational and permission boundaries of their data remain separate. Each participant sees its own operating environment, while authorised central players can also manage consolidated processes and reports.

This is especially important in service-provider, group and multi-site operations, where the advantages of a unified platform are needed, but mixing up data is obviously not.

Extensible, not to be replaced

When a new business need emerges, a new application can be built on the existing users, permissions, data connections and shared services. There is no need to create a separate login and a standalone application environment every time, or to rebuild integrations that already work.

Nor do you have to throw away what already works well. WebOS was not built to replace a proven ERP, SCADA system or accounting package at all costs. It can connect to them, take over or pass on the necessary data, and handle the operational chain that would otherwise break between the specialist systems.

Same data, different decisions

Take a simple example. The power consumption of a refrigeration compressor has been rising slowly for days.

In a conventionally fragmented environment, someone notices this on a chart at some point. They write an e-mail. The maintenance technician calls back with questions. The result of the inspection may end up on a work sheet. The spare part is ordered in another system. The cost later appears in a financial report — but by then the link between the original measured deviation and the economic result of the repair has been lost.

In an environment connected with OrigSmart WebOS, the measurement can become an event, and the event a work order for the responsible maintenance technician. The parts requirement, the purchase and the approval can be linked to the work order. After the intervention the system can check whether the power consumption has really returned to the normal range.

For this, the measurement can still come from the existing energy system, purchasing can take place in the ERP, and the task can be handled in a WebOS application or an integrated maintenance system. The point is not that every step happens in the same software, but that the link between the original deviation, the person responsible, the intervention and the result is preserved throughout.

Every stakeholder sees the same case from their own perspective:

• the energy manager sees the deviation and the consumption curve;
• the maintenance technician sees the fault, its history and the task to be done;
• purchasing sees the parts requirement and the approved budget;
• finance sees the cost and the financial impact of the saving;
• and management sees the full journey of the problem, from detection to verified result.

These are not five separate stories, but five views of the same operational event, shaped by permission and task.

Does everyone need WebOS?

No.

At a small site where a single measurement and alarm task has to be solved, a targeted application may be enough. The same applies to a company whose every essential process genuinely runs in a single, properly customised enterprise resource planning system.

In such cases individual OrigSmart modules — for example data acquisition, metering or alarm management — can also be used on their own, fitted to the existing systems.

Many industrial companies, however, do not work like that. They have several systems of different ages and purposes running side by side. For them the real question is not whether everything can be replaced in one big project, but whether a shared, governed and further extensible operating layer can be created on top of the existing ecosystem.